Am văzut o serie de stiluri de guvernanță diferite pentru proiectele open source. Unele au restricții mai slabe de contribuție, cu aprobarea PR provenind de la persoane care au câștigat privilegiul pentru a face acest lucru, fie prin merit, alegeri sau prin apartenența la fundația / corporația gazdă. Alții au o singură persoană cu ultimul cuvânt de spus asupra proiectului, așa-numitul " dictator binevoitor, " de obicei creatorul / fondatorul original.
Există avantaje pentru participanții și utilizatorii la participarea la proiecte conduse de BDFL în raport cu modele de guvernanță mai deschise?
Comentarii
- Care sunt avantajele altor modele? Se pare că presupuneți că alte modele sunt mai bune, dar de ce? Un fondator se poate asigura că contribuțiile sunt consistente și rămân adevărate la viziunea inițială a proiectului – care probabil l-a făcut să aibă succes și interesant în primul rând.
- nod . Pentru a da un exemplu de alt proiect ect funcționează bine pentru – Clojure urmărind îndeaproape designul lui Rich Hickey ', există o mai bună compozibilitate între bibliotecile scrise pentru acesta decât există, să zicem, în lumea Scala (care încearcă din răsputeri să susțină mai multe modele pentru dezvoltarea nativă, nu doar pentru interoperabilitate, așa cum o face Clojure și, astfel, îi fragmentează dezvoltatorii în aceste modele acceptate).
- @Polygnome: Ei bine, un motiv pentru a suspecta că alte modele pot fi mai bune este că Guido van Rossum a decis să nu mai fie DBFL al Python.
- @SteveJessop Acest lucru ar putea (doar) să fie un argument decât a fi BDFL este o treabă grea . Nu puteți ' să susțineți că Python nu a avut ' un succes înainte ca el să renunțe sau că nu este ' un limbaj respectabil.
- @Voo: ideea mea este că GvR, în calitate de BDFL, a decis că Python nu mai funcționează la fel de bine pe acel model, așa cum ar face pe un alt model . Deci, fie îi accepți judecata ca BDFL, fie refuzi să o accepți. În acest caz, cum puteți susține pe cineva ca BDFL a cărui judecată nu o mai acceptați '? 😉 Sigur, modelul a funcționat bine pentru o lungă perioadă de timp, dar Polygnome scrie de parcă întrebătorul ar trebui să facă caz împotriva dictaturii pentru a pune această întrebare. Nu au ' t: există motive evidente pentru a nu presupune că modelul BDFL este perfect, ci pentru a întreba ce ' e bun în legătură cu asta.
Răspuns
Am văzut întotdeauna modelul BDFL ca la jumătatea distanței dintre un structură de proiect tradițională open-source și o structură de proiect tradițională corporativă. Aveți deschiderea, transparența și cultura generală a OSS, dar cu un singur manager de proiect puternic pentru a lua decizii la nivel înalt și a direcționa efortul general.
Puteți vedea multe dintre avantaje doar descompunând titlul în sine:
- Benevolent – o încredere reciprocă că această persoană va acționa în interesul superior al proiectului
- Dictator – această persoană este autoritatea supremă, singulară
- For Life – această persoană intenționează să conducă t proiectul pe termen lung, nu doar până când apare ceva mai frumos
Un BDFL este foarte investit în proiect, de obicei creatorul original. Numele și reputația lor profesională sunt adesea inseparabile de cele ale proiectului. Spre deosebire de un manager corporativ, utilizatorii pot găsi mai ușor încrederea în leadership-ul lor, deoarece BDFL are un interes extrem de mare pentru succesul și longevitatea proiectului. Atât proiectele corporative, cât și proiectele OSS pot ajunge la o ușă rotativă de conducere, care împiedică progresul și frustrează utilizatorii. Un BDFL deține, în general, această poziție pentru o perioadă lungă de timp (deci " pentru viață "), ceea ce adaugă un grad de stabilitate proiectul. De asemenea, permite conducerii să se dezvolte și să rămână la o viziune coezivă pe termen lung, în loc de o serie de lideri de scurtă durată care își schimbă constant planurile și direcțiile. autoritate pentru proiectul / tehnologia respectivă. Managerii corporativi pot derula un proiect fără o înțelegere profundă a tehnologiei sau a istoriei sale, ducând la decizii care frustrează dezvoltatorii / utilizatorii. Multe proiecte OSS au un număr de oameni în roluri de conducere la fel de puternice, lăsând loc pentru dezacord și confuzie. Dacă aveți o întrebare despre direcția Python și Guido van Rossum vă răspunde la întrebare, atunci puteți avea încredere că răspunsul este autoritar. Proiectele conduse de BDFL tind să atragă mai puține furci din acest motiv.Orice furcă cu doar modificări minore ar părea un proiect " mai mic " fără implicarea BDFL. Acest lucru ajută la prevenirea unei comunități în mai multe grupuri care sunt fiecare prea mici pentru a fi eficiente.
Comentarii
- " lăsând loc pentru dezacord și confuzie " – ca parte a acestui fapt, o singură autoritate tehnică poate elimina o mulțime de motociclete pe baza unor decizii relativ neimportante. >
Răspuns
Aș spune că proiectele care au un BDFL au încredere în cele din urmă viziunea proiectului către o persoană , spre deosebire de proiectat de comitet .
Puteți consulta lista BDFL .
Multe dintre persoanele enumerate acolo au st opinii greșite cu privire la ceea ce ar trebui să facă, să nu facă proiectul lor și cum ar trebui să funcționeze (DHH și Theo sunt exemple cu care sunt familiarizat). Unele altele nu sunt la fel de controversate, dar sunt foarte respectate în comunitate (Matz).
Există avantaje pentru participanții și utilizatorii la participarea la proiecte conduse de BDFL? peste modele de guvernanță mai deschise?
Dacă sunteți aliniat cu BDFL în ceea ce privește viziunea proiectului, contribuția la un proiect condus de BDFL are sens. Alternativ, dacă credeți că este mai ușor să evaluați o singură persoană pentru încredere (a deciziilor de direcționare a proiectelor), mai degrabă decât un grup de oameni în schimbare, puteți susține ideea unui BDFL.