La respuesta de Jay Kreps es realmente buena.
En cuanto a la documentación, una cosa que intentamos con nuestros proyectos más grandes es darle a un ingeniero que no ha trabajado en el proyecto una copia del código fuente y la documentación para ver si pueden hacer que funcione correctamente. Esto desarrolla la documentación inicial y las dependencias que faltan mediante el uso de una máquina virtual Ubuntu / Debian / CentOS / etc limpia.
El tamaño del proyecto es realmente lo principal que afecta si creamos o no un sitio web separado para él. Para Phabricator, el equipo creó http://phabricator.org/ desde el principio, mientras que FlashCache existe en https://github.com/facebook/flas…. Realmente no hay una respuesta correcta más allá de hacer que sea realmente fácil encontrar la información necesaria para comprender rápidamente qué es el proyecto y cómo comenzar a usarlo.
- ¿Por qué los frameworks como jQuery y Bootstrap son gratuitos?
- ¿Cómo podemos construir una comunidad de desarrolladores (como WordPress ')?
- ¿Es posible que un usuario vea algún código fuente del sitio web?
- ¿Cuál es la diferencia entre un cuadro, un cuadro flexible y una tabla en HTML / CSS?
- ¿Qué debo mostrar primero, una página de destino o el sitio real?
En cuanto a la etapa de desarrollo en la que tiene sentido lanzar un nuevo proyecto, he visto algunas opciones principales:
- Casi todo se hace públicamente desde el principio antes de que se escriba una cantidad sustancial de código. Prácticamente, he encontrado que esto es de muy alto riesgo en términos de que el proyecto logre lo que buscaba debido al bikeshedding; Se necesitan líderes extremadamente fuertes.
- Haga que el proyecto funcione en gran medida, lo que a menudo incluye algún tipo de implementación de producción, y luego abra el código fuente. En esta etapa de la vida de un proyecto, puede ser mucho más fácil aceptar parches y construir una comunidad a su alrededor, ya que todavía está invirtiendo activamente en el desarrollo de nuevas características. Esto significa que tiene una inclinación más natural a aceptar parches externos y hacer cambios más grandes.
- Lanza el proyecto una vez que esté completamente implementado en tu entorno de producción. Esto es lo que hacemos para la gran mayoría de nuestros grandes proyectos de infraestructura. Hacemos esto porque queremos demostrar que una nueva pieza de infraestructura realmente funciona antes de lanzarla y siempre existe una necesidad apremiante en nuestro entorno de producción, lo que hace que sea difícil tomarse un tiempo para apoyar la construcción de una comunidad saludable.
Lo difícil aquí es la diferencia en el riesgo que está dispuesto a asumir al aceptar parches. Depende mucho de que esta infraestructura sea estable y la comunidad acaba de comenzar a usarla. Apache Hadoop ha crecido hasta tener este desafío donde partes de la comunidad tienen implementaciones extremadamente grandes y valoran la estabilidad sobre cualquier otra cosa, mientras que otras están comenzando a usarlo, lo que los hace más propensos a agregar funcionalidad.
No he encontrado un proyecto que realmente lo maneje extremadamente bien, pero la inversión real en pruebas e infraestructura para ejecutarlo a escala puede hacer que esto sea mucho más fácil de equilibrar.
Relacionado con la etapa en la que lanza un nuevo proyecto de código abierto está el modelo de comunidad. En general, creo que es mucho más importante ser sincero sobre el modelo que está eligiendo que el modelo en sí mismo.
Casi todos los problemas que he visto al respecto no se deben a elegir un modelo en el que se lanza el proyecto principalmente para compartir el código en lugar de crear una comunidad realmente sólida. En lugar de que la gente se involucre pensando que desea construir una comunidad sólida sin darse cuenta de que su objetivo era simplemente compartir el código porque es útil.
Con el Open Compute Project siento que hemos encontrado una manera de equilibrar múltiples modelos comunitarios basados en la etapa de los proyectos de hardware. El año pasado, cuando lanzamos nuestros diseños de servidores web, ya estaban fabricados y atendían el tráfico de producción (etapa 3). Pero al mismo tiempo estábamos comenzando a trabajar en la próxima generación de hardware que estaba en una fase de prueba y, por lo tanto, era más probable que pudiéramos aceptar contribuciones de nuevo (etapa # 2). Y hoy hay proyectos como un nuevo diseño de bastidor que se iniciaron dentro de la propia comunidad (etapa n. ° 1).
Por lo tanto, mi tl; dr en los modelos de la comunidad es realmente tener en claro sus objetivos y el modelo que está eligiendo para que pueda establecer las expectativas correctas dentro de la comunidad.
