¿En qué etapa de un proyecto de Código Abierto debería invitar contribuciones de la comunidad? [cerrado]

Me he estado preguntando si recibiré contribuciones para un nuevo producto de código abierto que mi equipo desarrollará. Se nos alienta a que obtengamos el mayor apoyo posible de la comunidad en general, pero también puedo ver esto absorbiendo mucho tiempo asegurándome de que terceros ubicados fuera de nuestra oficina estén en camino en lo que respecta a la calidad del código. También al comienzo del proyecto, es probable que tengamos muchas discusiones informales dentro del equipo central con respecto al diseño del sistema, los picos, etc. y llevarlas en línea para permitir la participación de la comunidad llevará mucho tiempo y me imagino que podría hacer que el discusión menos efectiva.

Hay un lado más humano en esto que probablemente deba considerarse: permitir la participación de la comunidad en el proceso de diseño también puede tener sus beneficios con respecto a la percepción de la propiedad del proyecto, y siempre existe la posibilidad de que la participación temprana pueda detectar problemas que el núcleo El equipo no se ha dado cuenta.

Entonces, la pregunta: ¿en qué etapa de un proyecto de Código Abierto debería invitar contribuciones de la comunidad?

Justo al principio! Desea que la comunidad sienta que tienen una participación genuina en su proyecto, de lo contrario sentirán que se están utilizando como mano de obra gratuita.

Toda comunicación debe realizarse a través de una lista de correo o foro público, nuevamente esto mejora la idea de la comunidad.

Puede mitigar el problema del "diseño por comité" presentando una visión clara en sus publicaciones iniciales en la lista de correo, p. Ej.

"Así que estamos buscando un modelo de dominio para representar nuestra tienda de mascotas (según JIRA-4). ¿Alguien ve algún problema importante con este modelo?"

En términos de aceptar contribuciones físicas reales, debe comenzar aceptando parches y realizando revisiones de código público en ellos. De esta forma, los contribuyentes ya pueden ver públicamente a qué tipo de estándares de codificación deben adherirse. Asegúrese de que sus confirmaciones también estén disponibles en una lista de correo de confirmación: ¡debe cumplir con los mismos estándares!

También vale la pena tener estándares de proyecto en un Wiki o algún documento similar.

Lea http://www.producingoss.org para obtener más detalles sobre cómo ejecutar un proyecto exitoso de código abierto.

Esto fue discutido extensamente en la charla de Google IO Mito del programador genio , por Brian Fitzpatrick y Ben Collins-Sussman de Subversion. En resumen, llegaron a la conclusión de que no debería ser tan temprano como para que no haya nada allí todavía (es decir, "¡ven a ver mi increíble proyecto! ¡Todavía no hay mucho aquí pero se planean muchas cosas increíbles!") O demasiado tarde así que todas las decisiones ya están tomadas (es difícil hablar sobre un proyecto en solitario).

Estoy de acuerdo con Martijn Verburg . Debe comenzar a solicitar contribuciones desde el principio. Escribí un poco sobre esto antes.

El resumen de esa publicación es que el software se pudre. Si desea mantenerlo fresco, debe realizar tareas de mantenimiento. Y cuanto más popular sea un proyecto, más errores se encontrarán, más características se agregarán y más esta tarea de mantenimiento lo atascará.

De hecho, este es un problema muy común. Hay una gran charla de Fat llamada ¿Qué es el código abierto y por qué me siento tan culpable? En esta charla (que le recomiendo que vea), cuenta la historia de uno de sus proyectos de OSS y cómo, con el tiempo, se encontró pasando la mayor parte de su tiempo libre haciendo tareas de clasificación y gestión de tickets. Y habla de lo dañino que fue esto. Lo cual es algo con lo que puedo empatizar por completo.

La solución, por supuesto, es agregar personas al proyecto temprano y con frecuencia. Su tiempo es limitado y valioso. Invierta en aumentar su base de contribuyentes, y el resto de sus problemas comenzarán a solucionarse por sí mismos.

Como digo al final de mi publicación: "¿Qué es más importante para su proyecto: características o un futuro? Elija uno y priorice sus esfuerzos en consecuencia".