2010-08-05 9 views
8

Hace un tiempo observé a algunas personas tratando de iniciar un proyecto de código abierto. Aproximadamente una semana después de que el proyecto comenzó, se disolvió más o menos por completo, en parte debido a problemas con la forma en que se administraba el proyecto en sí.¿Cómo se puede comenzar un proyecto de código abierto exitoso?

Las ideas detrás del proyecto fueron sin embargo muy bien pensado y una gran cantidad de personas todavía están interesados ​​en ver que se dio cuenta. Hasta el momento, nadie ha hecho ningún intento serio de recrearlo, pero algunos de nosotros estamos pensando en hacerlo. Por supuesto, no queremos que el proyecto termine de la misma manera que la última vez.

Ahora a mi pregunta. ¿Cómo se debe comenzar un proyecto de código abierto exitoso, donde exitoso se define como "el proyecto no se muere a menos que ya no esté interesado en el software?"

+0

Haga esta pregunta en Hacker News también (news.ycombinator.com/), si aún no lo ha hecho. Ese también es un buen lugar para hacer preguntas de código abierto y de inicio. –

Respuesta

10

Niza cuestión, aunque es más digno de un libro que un simple artículo, en mi humilde opinión. Y espero que no es ninguna sorpresa que la mayoría de los mejores consejos es social, no técnico.

Estas son algunas observaciones en ningún orden en particular:

  • No hacer una gran inversión en la infraestructura en la delantera A menos que usted ya es un confirmador Apache (o algo por el estilo), no darse una vuelta por una organización patrocinadora o alojar sus propios servidores, etc. Levántese en GitHub en 5 minutos y no mire hacia atrás. Pon tu energía en las características.
  • inferior de la barrera para la entrada No haga posibles contribuyentes pasar por el aro o someterse a una verificación de antecedentes antes de que usted escucha a sus ideas. Los proyectos de código abierto son economías en red ... necesita la energía de los demás. Incluso una actividad equivocada es mejor que ninguna actividad en su proyecto. Siempre puede dirigir la base de código en una mejor dirección más adelante.
  • Minimice el código personalizado No escriba una herramienta de registro personalizada o API de análisis XML ... hay implementaciones de código abierto que son (1) lo suficientemente buenas, (2) mejor mantenidas y (3) mejores que las suyas convertirse de todos modos. Mientras más energía pueda enfocarse en su problema central, mejor.
  • vivo en el borde personas y organizaciones sólo invertirán en la mejora de su proyecto si se van a beneficiar directamente. Coma su propia comida para perros. Cree dependencias en sus otros proyectos (como con su empleador) en su proyecto de código abierto, incluso si aún no es "perfecto". (Pista: los proyectos de software nunca son perfectos, son trabajos en progreso o muertos.)
+1

Karl Fogel tiene un libro llamado "Producir software de código abierto". Consíguelo ahora. Cuando salí de dotproject para unirme a web2project, ese libro me sirvió de inspiración para configurar las cosas bien. Fue revelador. La experiencia de Fogel fue como uno de los líderes en Subversion. – CaseySoftware

+0

+1 mantenerlo simple y centrado. Este es más o menos el consejo perfecto. ¿No es –

+0

code.google.com más o menos superada por GitHub hoy en día? –

1

Lo dices tú mismo. Lo más importante es que debe tener gente que se preocupe lo suficiente por lidiar con los problemas en lugar de abandonarlos.

Si a nadie le importa lo suficiente, morirá de nuevo. Pruebe un proyecto diferente donde le importe lo suficiente.

"Una gran cantidad de personas interesadas en ver que se dio cuenta de" no significa nada si nadie realmente va a hacer el trabajo, a combatir las peleas y quedarse.

1

Esto es algo fuera de tema en SO, pero voy a morder de todos modos.

La mayoría de los proyectos de FOSS los inicia una sola persona. Otras personas se unen después de que esta persona ha producido algún código que hace algo vagamente útil. Entonces, si desea comenzar un proyecto, hágalo usted mismo, configure un sitio en algo como Google Code y escriba algún código. El último es el más importante.

5

GitHub es un buen lugar, ya que hace que sea fácil para alguien con aunque sea un poco de interés para bifurcar el proyecto y solicitar su/sus parches para compartir con los demás.

Pero es realmente acerca de las actitudes alrededor de su proyecto de más de donde alojarlo u otras consideraciones simples como eso. Sé benevolente, serio y juicioso, mantén una comunidad en funcionamiento aunque sea bastante pequeña por un tiempo, y así sucesivamente. Acepte parches que deberían aceptarse, rechace parches que deberían rechazarse. Simplemente sea una buena persona, desarrollador y gerente, y aplique esas habilidades a su proyecto, y debería estar bien.

1

no creo que está escrito en piedra, pero para mí el punto más importante es que su proyecto debe llenar un hueco en el ecosistema existente. En otras palabras, tiene que haber un espacio para que su proyecto viva.

Aparte de eso, puedo decir que la mejor manera de mantener la motivación es trabajar en conjunto con la gente. Usted dice que todavía hay mucha gente interesada en verlo realizado. Entonces, ¿por qué esa gente no hace algo al respecto? Sin duda, pueden hacer algo. Creo que una idea errónea común es que contribuir a un proyecto de código abierto significa que debes poder escribir código. Hay más a él:

  • documentación Escribir
  • Crear elementos gráficos
  • examinar sus características y hojas de ruta
  • promueven el proyecto
  • etc., etc.

Claro, no todos estos puntos son aplicables a cada proyecto, pero intentar que la gente se comprometa con un proyecto eventualmente lo ayudará a usted y/oa los miembros de su proyecto a permanecer comprometidos también. No quieres decepcionar a todos los demás en el proyecto, ¿verdad? ;-)

Cuestiones relacionadas