Ho visto una serie di stili di governance diversi sui progetti open source. Alcuni hanno limitazioni di contribuzione più larghe, con lapprovazione delle PR da parte di persone che si sono guadagnate il privilegio per farlo, sia per merito, elezione o appartenenza alla fondazione / società ospitante. Altri hanno una sola persona con lultima parola sul progetto, un cosiddetto " dittatore benevolo, " di solito il creatore / fondatore originale.
La partecipazione a progetti guidati da BDFL offre vantaggi per i collaboratori e gli utenti rispetto a modelli di governance più aperti?
Commenti
- Quali sono i vantaggi di altri modelli? Sembri presumere che altri modelli siano migliori, ma perché? Un fondatore può garantire che i contributi siano coerenti e rimangano fedeli alla visione originale del progetto, che presumibilmente lo ha reso di successo e interessante in primo luogo.
- annuire . Per fare un esempio di un altro progetto ect questo funziona bene per: Clojure si avvicina molto al design di Rich Hickey ', cè ' migliore componibilità tra le librerie scritte cè, diciamo, il mondo Scala (che si sforza di supportare più modelli per lo sviluppo nativo, non solo per linteroperabilità come fa Clojure, e così frammenta i suoi sviluppatori attraverso quei modelli supportati).
- @Polygnome: Bene, una ragione per sospettare che altri modelli possano essere migliori è che Guido van Rossum ha deciso di smettere di essere DBFL di Python.
- @SteveJessop Questo potrebbe (semplicemente) essere un argomento del fatto che essere un BDFL è un lavoro duro . Non si poteva ' sostenere che Python ' non avesse avuto successo come progetto prima di chiudere, o che non fosse ' un linguaggio rispettabile.
- @Voo: il mio punto è solo che GvR, come BDFL, ha deciso che Python non funzionava più bene su quel modello come avrebbe fatto su un modello diverso . Quindi, o accetti il suo giudizio come BDFL, oppure ti rifiuti di accettarlo. In tal caso, come puoi sostenere qualcuno come BDFL il cui giudizio ' non accetti più? 😉 Certo, il modello ha funzionato bene per molto tempo, ma Polygnome scrive come se linterrogante avesse bisogno di sostenere la causa contro la dittatura per porre questa domanda. Non ' t: ci sono ovvie ragioni per non presumere che il modello BDFL sia perfetto, ma per chiedere cosa ' è bravo.
Risposta
Ho sempre visto il modello BDFL a metà strada tra un struttura del progetto open source tradizionale e struttura del progetto aziendale tradizionale. Hai lapertura, la trasparenza e la cultura generale di OSS, ma con un unico forte project manager per prendere decisioni di alto livello e dirigere lo sforzo complessivo.
Puoi vedere molti dei vantaggi semplicemente scomponendo il titolo stesso:
- Benevolent – la fiducia reciproca che questa persona agirà nel migliore interesse del progetto
- Dictator – questa persona è la singolare autorità ultima
- For Life – questa persona intende guidare t l progetto a lungo termine, non solo finché non arriva qualcosa di più bello
Un BDFL è fortemente investito nel progetto, tipicamente il creatore originale. Il loro nome e la reputazione professionale sono spesso inseparabili da quelli del progetto. A differenza di un manager aziendale, gli utenti possono trovare più facile fidarsi della loro leadership poiché il BDFL ha un interesse altamente nel successo e nella longevità del progetto. Sia i progetti aziendali che i progetti OSS possono finire con una porta girevole di leadership, che blocca il progresso e frustra gli utenti. Un BDFL generalmente mantiene quella posizione per un lungo periodo di tempo (quindi il " per la vita "), che aggiunge un certo grado di stabilità a il progetto. Consente inoltre alla leadership di sviluppare e attenersi a una visione coesa a lungo termine invece di una serie di leader di breve durata che cambiano costantemente piani e direzioni.
Spesso, un BDFL è anche lindiscusso esperto in materia e centrale autorità per quel particolare progetto / tecnologia. I manager aziendali possono eseguire un progetto senza una profonda conoscenza della tecnologia o della sua storia, portando a decisioni che frustrano sviluppatori / utenti. Molti progetti OSS hanno un numero di persone in ruoli di leadership altrettanto potenti, lasciando spazio a disaccordo e confusione. Se hai una domanda su dove si sta dirigendo Python e Guido van Rossum risponde alla tua domanda, puoi essere certo che la risposta è autorevole. I progetti gestiti da BDFL tendono ad attirare meno fork per questo motivo.Qualsiasi fork con solo piccole modifiche sembrerebbe un progetto " minore " senza il coinvolgimento di BDFL. Questo aiuta a prevenire la frammentazione di una comunità in più gruppi troppo piccoli per essere efficaci.
Commenti
- " lasciando spazio a disaccordo e confusione " – come parte di questo, una singola autorità tecnica può eliminare un sacco di bikehedding su decisioni relativamente poco importanti. La loro preferenza diventa la decisione, fine di.
Risposta
Direi che i progetti che hanno un BDFL alla fine si fidano la visione del progetto a una persona , in contrapposizione a design del comitato .
Puoi fare riferimento a lelenco dei BDFL .
Molte delle persone elencate hanno st opinioni forti su ciò che il loro rispettivo progetto dovrebbe fare, non fare e come dovrebbe funzionare (DHH e Theo sono esempi che conosco). Alcuni altri non sono così controversi ma sono molto rispettati nella comunità (Matz).
Ci sono vantaggi per i contributori e gli utenti nel partecipare a progetti guidati da BDFL su modelli di governance più aperti?
Se sei allineato con il BDFL in termini di visione per il progetto, contribuire a un progetto gestito da BDFL ha senso. In alternativa, se ritieni che sia più facile valutare laffidabilità di una singola persona (delle decisioni di direzione del progetto) piuttosto che un gruppo di persone che cambia, potresti sostenere lidea di un BDFL.