Jeg har sett en rekke forskjellige styringsstiler på open source-prosjekter. Noen har løsere bidragsbegrensninger, med PR-godkjenning fra folk som har tjent privilegiet å gjøre det, enten gjennom fortjeneste, valg eller medlemskap i vertsstiftelsen / selskapet. Andre har en enkelt person med siste ord om prosjektet, en såkalt " velvillig diktator, " vanligvis den opprinnelige skaperen / grunnleggeren.
Er det fordeler for bidragsytere og brukere å delta i BDFL-ledede prosjekter fremfor mer åpne styringsmodeller?
Kommentarer
- Hva er fordelene med andre modeller? Du ser ut til å anta at andre modeller er bedre, men hvorfor? En grunnlegger kan sørge for at bidragene er konsistente og forblir sanne til den opprinnelige visjonen om prosjektet – som antagelig gjorde det vellykket og interessant i utgangspunktet.
- nikk . For å gi et eksempel på en annen prosjekt ect dette fungerer bra for – Clojure hewing tett til Rich Hickey ' s design, det ' s bedre komposabilitet mellom biblioteker skrevet for det enn det er i si Scala-verdenen (som prøver hardt å støtte flere modeller for naturlig utvikling, ikke bare for interop som Clojure gjør, og fragmenterer derfor utviklerne på tvers av de støttede modellene).
- @Polygnome: En grunn til å mistenke at andre modeller kan være bedre, er at Guido van Rossum bestemte seg for å slutte å være DBFL for Python.
- @SteveJessop Det kan (bare) være et argument enn å være en BDFL er en vanskelig jobb . Du kunne ikke ' t argumentere for at Python ikke har hatt ' som et prosjekt før han sluttet, eller at det ikke er ' et respektabelt språk.
- @Voo: poenget mitt er bare at GvR, som BDFL, bestemte at Python ikke lenger jobbet like bra på den modellen som den ville gjort på en annen modell . Så enten godtar du hans dom som BDFL, ellers nekter du å godta den. I hvilket tilfelle, hvordan kan du støtte noen som BDFL hvis dom du ikke ' ikke godtar lenger? 😉 Visst, modellen fungerte bra lenge, men Polygnome skriver som om spørgeren trenger å gjøre saken mot diktaturet for å stille dette spørsmålet. De gjør ikke ' t: det er åpenbare grunner til ikke å anta at BDFL-modellen er perfekt, men å spørre hva ' er bra med det.
Svar
Jeg har alltid sett BDFL-modellen som halvveis mellom en tradisjonell open source-prosjektstruktur og en tradisjonell bedriftsprosjektstruktur. Du har åpenhet, gjennomsiktighet og generell kultur i OSS, men med en enkelt sterk prosjektleder for å ta beslutninger på høyt nivå og lede den samlede innsatsen.
Du kan se mange av fordelene bare ved å bryte ned selve tittelen:
- Velvillig – en gjensidig tillit til at denne personen vil opptre i prosjektets beste interesse
- Diktator – denne personen er den enestående, ultimate autoriteten
- For livet – denne personen har til hensikt å lede t han prosjekterer på lang sikt, ikke bare før noe hyggeligere kommer
En BDFL er høyt investert i prosjektet, vanligvis den opprinnelige skaperen. Deres eget navn og profesjonelle omdømme er ofte uatskillelige fra prosjektets. I motsetning til en bedriftsleder, kan brukere finne det lettere å stole på sitt lederskap, siden BDFL har en høy interesse for suksess og lang levetid for prosjektet. Både bedriftsprosjekter og OSS-prosjekter kan ende opp med en revolusjonsdør for ledelse, som stopper fremgang og frustrerer brukere. En BDFL har generelt den stillingen i lang tid (dermed " for livet "), noe som gir en viss stabilitet til prosjektet. Det lar også ledelse utvikle seg og holde seg til en sammenhengende langsiktig visjon i stedet for en serie kortvarige ledere som stadig endrer planer og retninger.
Ofte er en BDFL også den ubestridte fageksperten og sentrale autoritet for det aktuelle prosjektet / teknologien. Bedriftsledere kan kjøre et prosjekt uten dyp forståelse av teknologien eller dens historie, noe som fører til beslutninger som frustrerer utviklere / brukere. Mange OSS-prosjekter har et antall mennesker i like kraftige lederroller, og gir rom for uenighet og forvirring. Hvis du har et spørsmål om hvor Python er på vei og Guido van Rossum svarer på spørsmålet ditt, kan du være trygg på at svaret er autoritativt. BDFL-drevne prosjekter har en tendens til å tiltrekke seg færre gafler av denne grunn.Enhver gaffel med bare mindre endringer vil virke som et " mindre " -prosjekt uten BDFLs involvering. Dette bidrar til å forhindre at et samfunn splinter i flere grupper som er for små til å være effektive.
Kommentarer
- " gir rom for uenighet og forvirring " – som en del av dette kan en enkelt teknisk myndighet kutte bort mye bikeshedding på relativt uviktige beslutninger. Deres preferanse blir avgjørelsen, slutten av.
Svar
Jeg vil si at prosjekter som har BDFL til slutt stoler på prosjektets visjon til en person , i motsetning til design av komité .
Du kan referere til listen over BDFLer .
Mange av personene som er oppført der har st gode meninger om hva deres respektive prosjekt skal gjøre, ikke gjøre, og hvordan det skal fungere (DHH og Theo er eksempler jeg er kjent med). Noen andre er ikke så kontroversielle, men er veldig respekterte i samfunnet (Matz).
Er det fordeler for bidragsytere og brukere å delta i BDFL-ledede prosjekter over mer åpne styringsmodeller?
Hvis du er på linje med BDFL når det gjelder visjon for prosjektet, er det fornuftig å bidra til et BDFL-drevet prosjekt. Alternativt, hvis du mener at det er lettere å evaluere en enkelt person for pålitelighet (av prosjektstyringsbeslutninger) i stedet for en skiftende gruppe mennesker, kan du støtte ideen om en BDFL.