He visto varios estilos de gobierno diferentes en proyectos de código abierto. Algunos tienen restricciones de contribución más flexibles, y la aprobación de relaciones públicas proviene de personas que se han ganado el privilegio para hacerlo, ya sea por mérito, elección o membresía en la fundación / corporación anfitriona. Otros tienen una sola persona con la última palabra sobre el proyecto, un llamado " dictador benevolente, " generalmente el creador / fundador original.
¿Hay beneficios para los contribuyentes y usuarios al participar en proyectos liderados por BDFL en comparación con modelos de gobierno más abiertos?
Comentarios
- ¿Cuáles son los beneficios de otros modelos? Parece asumir que otros modelos son mejores, pero ¿por qué? Un fundador puede asegurarse de que las contribuciones sean consistentes y se mantengan verdaderas. a la visión original del proyecto, que presumiblemente lo hizo exitoso e interesante en primer lugar.
- asentir . Para dar un ejemplo de otro proyecto ect, esto funciona bien para: Clojure se ajusta estrechamente al diseño de Rich Hickey ' s, hay ' mejor componibilidad entre bibliotecas escritas para él que existe, por ejemplo, en el mundo de Scala (que se esfuerza por admitir múltiples modelos para el desarrollo nativo, no solo para la interoperabilidad como lo hace Clojure, y por lo tanto fragmenta a sus desarrolladores en esos modelos compatibles).
- @Polygnome: Bueno, una razón para sospechar que otros modelos pueden ser mejores es que Guido van Rossum decidió dejar de ser DBFL de Python.
- @SteveJessop Eso podría (simplemente) ser un argumento de que ser un BDFL es un trabajo difícil . No podría ' argumentar que Python no ' t tuvo éxito como proyecto antes de que él abandonara, o que no ' en un lenguaje respetable.
- @Voo: mi punto es que GvR, como BDFL, decidió que Python ya no estaba funcionando tan bien en ese modelo como lo haría en un modelo diferente . Entonces, o aceptas su juicio como BDFL, o te niegas a aceptarlo. En cuyo caso, ¿cómo puede apoyar a alguien como BDFL cuyo juicio no ' ya no acepta? 😉 Claro, el modelo funcionó bien durante mucho tiempo, pero Polygnome está escribiendo como si el interrogador necesitara argumentar contra la dictadura para hacer esta pregunta. No ' t: hay razones obvias para no asumir que el modelo BDFL es perfecto, sino para preguntar qué ' s bueno al respecto.
Respuesta
Siempre he visto el modelo BDFL como a medio camino entre un estructura de proyecto tradicional de código abierto y estructura de proyecto corporativo tradicional. Tiene la apertura, la transparencia y la cultura general de OSS, pero con un solo gerente de proyecto fuerte para tomar decisiones de alto nivel y dirigir el esfuerzo general.
Puede ver muchas de las ventajas simplemente desglosando el título en sí:
- Benevolente – una confianza mutua en que esta persona actuará en el mejor interés del proyecto
- Dictador – esta persona es la máxima autoridad en singular
- De por vida – esta persona tiene la intención de liderar t l proyecto a largo plazo, no solo hasta que aparezca algo mejor
Un BDFL está muy involucrado en el proyecto, generalmente el creador original. Su propio nombre y reputación profesional son a menudo inseparables de los del proyecto. A diferencia de un gerente corporativo, a los usuarios les puede resultar más fácil confiar en su liderazgo, ya que el BDFL tiene un alto interés en el éxito y la longevidad del proyecto. Tanto los proyectos corporativos como los proyectos de OSS pueden terminar con una puerta giratoria de liderazgo, que frena el progreso y frustra a los usuarios. Un BDFL generalmente mantiene esa posición durante un largo período de tiempo (por lo tanto, " de por vida "), lo que agrega un grado de estabilidad el proyecto. También permite que el liderazgo se desarrolle y se adhiera a una visión coherente a largo plazo en lugar de una serie de líderes efímeros que cambian constantemente de planes y direcciones.
Con frecuencia, un BDFL también es el indiscutible experto en la materia y el centro autoridad para ese proyecto / tecnología en particular. Los gerentes corporativos pueden ejecutar un proyecto sin un conocimiento profundo de la tecnología o su historia, lo que lleva a decisiones que frustran a los desarrolladores / usuarios. Muchos proyectos de OSS tienen varias personas en roles de liderazgo igualmente poderosos, lo que deja espacio para el desacuerdo y la confusión. Si tiene una pregunta sobre hacia dónde se dirige Python y Guido van Rossum responde a su pregunta, entonces puede estar seguro de que la respuesta es autoritaria. Los proyectos dirigidos por BDFL tienden a atraer menos bifurcaciones por este motivo.Cualquier bifurcación con solo cambios menores parecería un proyecto " menor " sin la participación del BDFL. Esto ayuda a evitar que una comunidad se fragmente en varios grupos que son demasiado pequeños para ser efectivos.
Comentarios
- " dejando espacio para desacuerdo y confusión " – como parte de esto, una sola autoridad técnica puede eliminar una gran cantidad de errores en decisiones relativamente poco importantes. Su preferencia se convierte en la decisión, fin de.
Respuesta
Yo diría que los proyectos que tienen un BDFL finalmente confían la visión del proyecto para una persona , en contraposición al diseñado por el comité .
Puede consultar la lista de BDFL .
Muchas de las personas enumeradas allí tienen st opiniones sólidas sobre lo que su proyecto respectivo debería hacer, no hacer, y cómo debería funcionar (DHH y Theo son ejemplos que conozco). Algunos otros no son tan controvertidos pero son muy respetados en la comunidad (Matz).
¿Hay beneficios para los contribuyentes y usuarios al participar en proyectos dirigidos por BDFL? sobre modelos de gobernanza más abiertos?
Si está alineado con el BDFL en términos de visión para el proyecto, contribuir a un proyecto dirigido por BDFL tiene sentido. Alternativamente, si cree que es más fácil evaluar la confiabilidad de una sola persona (de las decisiones de dirección del proyecto) en lugar de un grupo cambiante de personas, puede apoyar la idea de un BDFL.