Qué factores determinan el éxito de un proyecto de código abierto?[cerrado]

Question

Tenemos una serie de aplicaciones de código cerrado y bibliotecas, por la que pensamos que tendría sentido la apertura del código fuente.

¿Cuál ha sido el bloqueo de ee.uu., hasta ahora, es el esfuerzo necesario para limpiar la base de código y la documentación de la fuente antes de la apertura.

Queremos abrir la fuente sólo si tenemos una posibilidad razonable de los proyectos exitosos, es decir,tener colaboradores.Estamos convencidos de que el código sería interesante para una gran base de desarrolladores.

Qué factores, excluyendo el "interés" y la "utilidad" del proyecto, determinar el éxito de un proyecto de código abierto?

Ejemplos:

• Limpieza de código
• La disponibilidad del código fuente de los comentarios
• Total o parcialmente documentado Api
• Elección de la licencia (GPL vsLGPL vsBSD, etc...)
• Elección de repositorio público de
• La inversión en un sitio web público

Answer 1

Hay varias cosas que dominan el éxito de código.Todos estos deben ser alcanzados para la más mínima posibilidad de adopción.

• El mercado debe haber un mercado para su proyecto de código abierto.Si su proyecto es un exprimidor de naranja en el espacio, dudo que usted va a ser muy exitoso.Usted debe asegurarse de que su proyecto se lleva una gran adopción entre los usuarios y los desarrolladores.Es dos veces más probabilidades de tener éxito si usted puede conseguir otras empresas a adoptar es así.
• Documentación - Como usted ha mencionado anteriormente la documentación es clave.Entre esta documentación es el código comentado, las decisiones de arquitectura, y la API de notas.Incluso si su documentación contiene bugs, o errores acerca de su software es aceptar.Recuerde, la transparencia es la clave.
• La libertad - Usted debe permitir que su código para ser "libre" - con esto quiero decir libre como en el habla, no como en cerveza.Si usted tiene una sensación de que su mercado es el de ser de la biblioteca para que otras empresas la licencia BSD es óptimo.Si su pieza de software que se va a ejecutar en los equipos de escritorio, a continuación, la GPL es su elección.
• La transparencia debe escribir software en un ambiente transparente.Una vez que usted vaya de código abierto no hay secretos ocultos.Usted debe explicar todo lo que haces, y lo que están haciendo.Esto va a cabrear a los desarrolladores como ningún otro
• Comunidad de desarrolladores - Una fuerte comunidad de desarrolladores es necesario.Este debe ser existente.Sólo alrededor del 5% de los usuarios que contribuyen al proyecto.Si alguien se da cuenta de que no ha habido ningún tipo de lanzamiento para un año que no pensar "Wow, esta pieza de software es," piensan "los desarrolladores deben de objeto de dumping." Mantenga a sus desarrolladores a trabajar en él, incluso si eso significa que están costando dinero.
• Comunicaciones - Usted debe asegurarse de que la comunidad es capaz de comunicarse.Ellos deben ser capaces de errores de archivos, discutir soluciones, y publicar los parches.Sin comentarios, es inútil para el proyecto opensource
• Disponibilidad - que el código sea fácil para llegar es necesario, incluso si esto significa que cabrear a los abogados.Usted tiene que asegurarse de que su proyecto es fácil de descargar y utilizar.Usted no desea que el usuario tiene que saltar a través de 18 pantallas de la queja y firmar un contrato con el fin de hacer esto.Usted tiene que hacer las cosas de manera simple y limpia

Answer 2

Creo que el factor más importante es el número de usuarios que están utilizando su proyecto.De lo contrario solo es un muy bien escrito, útil y bien documentado montón de cosas que se encuentra en un servidor de no hacer mucho...

Answer 3

Para adquirir los contribuyentes, en primer lugar la necesidad de los usuarios, entonces usted necesita algunos faltantes.Debe activar el "Esto es genial, pero realmente me gustaría que hubiera este o fue diferente en este camino". Si le falta una evidente función, es muy probable que un usuario se convertirá en un colaborador de añadir.

Answer 4

La cosa más importante es que el programa sea bueno.Si no es bueno, nadie lo va a usar.Usted no puede esperar que la del huevo y la gallina dará marcha atrás y que la gente tome por sentado hasta que se convierte en buena.

Por supuesto, la "buena" simplemente significa "mejor que cualquier otra práctica opción para un número significativo de personas," esto no quiere decir que estrictamente es la mejor, solo que tiene algunas características que lo hacen, para muchas personas, mejor que otras opciones.A veces el programa ha no hay equivalente en cualquier otro lugar, en cuyo caso no hay casi ningún requisito en este sentido.

Cuando un programa es bueno, la gente va a usar.Obviamente, tiene que tener un mercado entre los usuarios, un buen programa que hace algo que nadie quiere realmente no es bueno, no importa cuan bien su diseñados.Uno podría hacer un punto sobre el marketing, pero realmente buenos productos, hasta un punto, tienen una tendencia a comercializar.Es mucho más difícil de promover algo que no es bueno, así que claramente la prioridad debe ser el producto en sí, no la promoción del producto.

La verdadera pregunta es: ¿cómo hacerlo bien?Y la respuesta a eso es un dedicado, profesional equipo de desarrollo.Una persona rara vez se puede crear un buen producto por su propia cuenta;incluso si están mucho mejor que los otros desarrolladores, las múltiples perspectivas tiene una increíblemente útil efecto en el proyecto.Es por esto que tener patrocinadores corporativos es tan útil-se pone de otros desarrolladores (de la sociedad) de la mente en el problema para dar su propia opinión.Esto es especialmente útil en el caso de que el desarrollo del programa requiere de una gran experiencia que no suelen estar disponibles en la comunidad.

Por supuesto, estoy diciendo todo esto a partir de la experiencia.Yo soy uno de los principales desarrolladores en x264 (actualmente la más activa), uno de los más populares de codificadores de vídeo.Tenemos dos principales desarrolladores, varios menores a los desarrolladores en la comunidad que contribuyen parches, y el patrocinio empresarial de Joost (Gabriel Bouvigne, que mantiene ratecontrol algoritmos), de hacer uso de los Medios de comunicación (que yo trabajo a veces en un contrato y que actualmente están contratando programadores de contrato para agregar MBAFF entrelazado de apoyo), y de algunos otros que aparecen de vez en cuando.

Un buen desarrollador no hacer un proyecto--muchos de los buenos desarrolladores.Y el resultado final de esto es un programa que codifica vídeo más rápido y a una calidad mucho mejor que la mayoría de los competidores comerciales, hardware o software, incluso aquellos con absolutamente enorme desarrollo de los presupuestos.

Answer 5

En el estudio de estos problemas que usted podría estar interesado en la comprobación de la versión en línea de un curso de open source en la UC Berkeley, llamado de Desarrollo de código Abierto y Distribución de la Información Digital:Técnica, Económica, Social, Legal y Perspectivas.Es co-impartido por Mitch Kapur (Lotus fundador) y Paula Samuelson, una ley que el profesor de la escuela.Tengo un largo viaje y poner el audio del curso en mi iPod el año pasado – se habla mucho acerca de lo que funciona, qué no y por qué, a partir de una muy amplia (aunque, obviamente, académico) perspectiva.

Answer 6

Se han escrito libros sobre el tema.De hecho, usted puede encontrar un libro gratis aquí: la producción de software de código abierto

Answer 7

Realmente, creo que la respuesta es 'la forma de ejecutar el proyecto".

Todos sus ejemplos importa, sí, pero la clave de las cosas son cómo la interacción entre los desarrolladores se gestiona, cómo parches etc son manipulados/aceptado, que 'a cargo' y de cómo manejar esa responsabilidad, y así sucesivamente y así sucesivamente.

Compare y contraste (la historia no es difícil de localizar!) la gestión del desarrollo de la Clase::DBI y DBIx::Class en Perl.

Answer 8

Estaba leyendo esta noche un excelente post sobre el uso de los aspectos de éxito vs infructuosos proyectos de código abierto.

Extracto:

Una gran cantidad de ancho de banda que se ha perdido a discutir sobre la falta de usabilidad en el software de código abierto/software libre (en adelante, "OSS").Continúa el debate en este momento en blogs, foros, y Slashdot comentario hilos.Algunas personas dicen que la mala usabilidad es endémica en todo el OSS mundo, mientras que otros dicen que SOS la usabilidad es grande, pero que el verdadero problema es la mentalidad cerrada de los usuarios que esperan que cada programa clon de Microsoft.Algunas personas afirman que el interfaz de usuario de problemas son temporales dolores de crecimiento, mientras que otros dicen que la OSS modelo de desarrollo sistemáticamente produce mala interfaz de usuario.Incluso, algunas personas argumentan que la GPL indirectamente recompensas de software que es difícil de usar!(Para el registro, no estoy de acuerdo.)

http://humanized.com/weblog/2007/10/05/make_oss_humane/

Answer 9

Acaba de abrir-fuente.Probablemente, nadie va a comenzar a contribuir aún.Pero al menos se puede escribir en los comunicados de prensa de que su producto es GPL o lo que sea.

El primer paso es que la gente empiece a usarlo...
Y quizá entonces, después de que los usuarios estar cómodo, van a empezar a contribuir.

Answer 10

Todos las respuestas han sido buenos hasta ahora, pero hay una cosa que falta y eso es una buena supervisión.Nada mata a un proyecto de código abierto más rápido que el de no tener algún tipo de gestión de proyectos.No decirle a la gente qué hacer tanto como a añadir un poco de estructura y asignación de tareas para los desarrolladores están con la esperanza de atraer.

Desorganizado proyectos de desmoronarse rápidamente.No es un pájaro que acaba de dejar ir y verlo volar.