¿Cómo manejar el crecimiento de un proyecto de código abierto?

11

He estado involucrado en ayudar a dar soporte a un proyecto de código abierto durante un año o dos, y el proyecto ha ganado mucha popularidad desde que comencé. El programa ve más de 100,000 descargas por semana, y es utilizado por más del 60% de las personas en su campo primario, por lo que obviamente estamos encantados de que la gente haya disfrutado tanto al usarlo.

Sin embargo, el problema es que la base de desarrollo y soporte no ha crecido tan rápido, y estamos empezando a enfrentar algunos problemas de crecimiento. El pequeño puñado de desarrolladores (el desarrollador principal en particular) se está estirando bastante, y los voluntarios de soporte técnico están comenzando a agotarse.

Hasta ahora, prácticamente ha sido un montón de tipos pasando el rato en IRC, escribiendo este programa y ayudando a los usuarios. No hay una organización 501 (c) (3) o LLC ni nada de eso.

En este momento, no tenemos un rastreador de errores muy formal o una base de datos de problemas (sí tenemos un foro con una categoría dedicada a los informes de errores), lo que sí admito es algo que podríamos mejorar para que más desarrolladores se unan. Pero supongo que mi verdadera pregunta es, ¿cómo hacer la transición de pequeño proyecto personal para una verdadera ... cosa? ¿Cómo han manejado esta transición los grandes como GIMP, FFmpeg, Blender, etc.?

Y además de esto, ¿hay alguna manera de ofrecer una compensación con un proyecto de software libre? Supongo que las donaciones ayudan, pero eso solo va tan lejos ... parece extraño ganarse la vida con el software libre, pero si el programa continuará mejorando, no veo cómo podemos continuar sin compensar a las personas para trabajo a tiempo completo.

Básicamente, estamos teniendo algunos dolores de crecimiento y nos sentimos "demasiado grandes para nuestros pantalones". ¿Qué podemos hacer para gestionar esta transición y no cansarnos de hacer demasiadas cosas a la vez?

Ben Torell
fuente
77
Lo primero es tener un rastreador de errores adecuado en funcionamiento, ningún código abierto podrá sobrevivir sin él, a menos que el equipo central sea muy bueno. También asegúrese de que la dirección de las funciones sea clara y que no se le escape.
monstruo de trinquete
44
Si no te importa que pregunte, ¿cuál es el proyecto?
Robert Harvey
2
Dudo en nombrar el proyecto, en parte porque da un poco de miedo salir y decirle a la gente "¡Hey, no estamos realmente seguros de lo que estamos haciendo, y necesitamos ayuda!" Además, no quería que esta publicación saliera como un anuncio de ayuda con el proyecto. Sin embargo, estoy seguro de que algunas investigaciones superficiales en Internet lo revelarían. : /
Ben Torell

Respuestas:

13

La etapa en la que se encuentra su proyecto es realmente emocionante y crucial, es muy fácil estrellarse y quemarse, pero también es donde puede tomar algunas decisiones cruciales que, si todo funciona, ayudarán a garantizar la viabilidad a largo plazo.

Aquí hay algunas sugerencias.

  • Lea el gran libro de Karl Fogel Producing Open Source Software . Cubre la mayoría de los principales problemas inmediatos. Aunque no estoy de acuerdo con todo lo que dice, eso es solo una opinión. Entiende totalmente el mundo del código abierto.

  • Como dijo @Ross Patterson, debe configurar absolutamente un rastreador y una lista de correo o algo similar para evitar el caos total. ¿Qué estás usando para el control de versiones? Si está en Github, puede comenzar con su rastreador o puede integrarse con Jira o algo similar o, si lo desea, puede ir a SourceForge por ahora y usar su infraestructura gratuita. No dice de dónde descargan las personas, pero desea asegurarse de tenerlo configurado de manera confiable y con un buen conteo de descargas.

  • No hay ninguna razón por la que no pueda ganarse la vida con el software libre si eso es lo que quiere, mucha gente lo hace, pero toma muchas formas diferentes. Debe decidir cómo desea hacerlo antes de tomar decisiones organizativas importantes. Por ejemplo, usted puede y probablemente deba crear una corporación para mantener la marca registrada y los derechos de autor que también proporcionarán alguna protección legal si alguna vez se necesita. Sin embargo, necesitará un presidente o tesorero. El tipo de organización que debería ser (sin fines de lucro o con fines de lucro, LLC, cooperativa, sociedad) realmente depende de sus objetivos y debe discutirse con un buen abogado. Si fue aceptado por Software Freedom Conservacy, lo ayudarían a resolverlo y también ayudarían con los problemas de contabilidad e impuestos, etc. También hay algunas otras incubadoras de software libre comoSoftware en el interés público . Además, creo que Outercurve es una posibilidad.

  • En términos de cómo ganarse la vida, esto dependerá mucho de la naturaleza de su proyecto. Esta es también la razón por la que no saltaría inmediatamente para decir que necesita un 501c3 (y es posible que no lo obtenga ... vea el proyecto Yorba). Blender se apoya principalmente vendiendo documentación. Otros proyectos tienen ecosistemas de pequeñas empresas y / o consultoría que los rodea y los desarrolladores se ganan la vida con eso. Otros proyectos tienen modelos de doble licencia, por lo que venden versiones compatibles (es por eso que MySQL lo hizo y por qué podría venderse a Sun y, por supuesto, hay RedHat) y tienen un lanzamiento de la comunidad por separado. Otros como WordPress tienen la versión alojada como modelo de negocio. Por lo tanto, hay todo tipo de opciones y debe descubrir qué tiene sentido para usted y su comunidad.

  • Elija a alguien ahora para que sea su administrador de la comunidad para comenzar. Y lea el libro de Jono Bacon después de que termine el de Fogel.

  • Decida ahora sobre una hoja de ruta que tenga sentido para su equipo principal; Sea realista y no se deje intimidar por personas que no contribuyen. La hoja de ruta no solo significa planes técnicos y características, se trata de dónde quiere ir como proyecto.

  • No sea tímido al hablar con otros proyectos que admira o que están en el mismo espacio para el caso. Averigüe qué funcionó y qué no funcionó para ellos. Solo envíe un correo electrónico. Además, puede ir a algunos de los eventos generales de código abierto y simplemente hablar con los otros proyectos. En general, las personas son muy útiles.

Buena suerte, es emocionante estar en esta etapa.

Elin
fuente
¡Gracias! El código ya está alojado en Github (que también es donde están alojados los lanzamientos), pero realmente no nos gusta el rastreador de problemas de Github ... uno de los chicos del equipo tiene experiencia con Mantis, así que creo que vamos a usar ese. También te escucho sobre la hoja de ruta ... al menos, tener una hoja de ruta pública será bueno solo para referir a los usuarios que reclaman características particulares, para que podamos decirles cuándo estas características se relacionan con otras características. Estaba explorando Outercurve más temprano esta noche, y también revisaré los otros, así como los libros. ¡Gracias por el aliento!
Ben Torell
1
@BenTorell Le digo a cualquiera que pregunte: "Cada rastreador de errores apesta, la única pregunta es, '¿Cuál apesta menos con respecto a sus procesos?'".
Ross Patterson el
Ross tiene toda la razón. Realmente no me gusta el rastreador de Github por varias razones, pero especialmente por su falta de ACL real. Estoy de acuerdo en encontrar uno que coincida con sus procesos. Muchos rastreadores no funcionan tan bien para proyectos impulsados ​​por voluntarios porque hacen todo tipo de suposiciones que tienen sentido en entornos comerciales, incluso en el vocabulario que usan. Por supuesto, hablar sobre cuáles son realmente sus procesos es un buen ejercicio. No intente utilizar un rastreador para realizar cambios poco realistas en sus procesos. Las cosas son realmente diferentes cuando se trata de voluntarios.
Elin
3

Los chicos realmente grandes creados todos los mecanismos que conoces - corren grandes granjas de servidores, corren (a veces de escritura) de control de errores y sistemas de construcción, etc. A menudo tienen 501 (c) 3 fundaciones propietarias de los derechos de autor, etc. Ellos obtener grandes donaciones corporativas, y las empresas les prestan desarrolladores, etc. Ya sabes, cosas GRANDES.

Los muchachos no tan grandes reciben mucha ayuda de otros lugares. El Software Freedom Conservancy , por ejemplo, ayudará a moderadamente grandes proyectos consiguen sus fundamentos legales derecha, y facilitan las donaciones. Hay muchas opciones para el alojamiento de código y el seguimiento de errores en estos días: diablos, cualquiera puede obtener un sitio de GitHub. Y encontrará que muchas compañías de software pequeñas y medianas donarán licencias para sus productos patentados para apoyar proyectos organizados de código abierto, especialmente cuando se alinean con su negocio de alguna manera.

Ross Patterson
fuente
3
No estoy tratando de ser pedante y estoy 100% seguro de que no lo dijiste de manera negativa, pero realmente no ayuda a aumentar la participación en código abierto para referirse a las personas involucradas como niños. Solo algo para pensar; Sé que es una frase que la gente usa.
Elin
@Elin Simplemente respondiendo a la pregunta: "¿Cómo han manejado esta transición los grandes como GIMP, FFmpeg, Blender, etc.?"
Ross Patterson el
Ah, y +1 en el comentario: los chicos deben ser recordados de vez en cuando. Este negocio está demasiado centrado en los hombres.
Ross Patterson el
Gracias y sí, no noté esa referencia en la publicación original.
Elin
Sí, solo estaba usando "chicos grandes" como un giro de frase ... Supongo que no pensé en eso de esa manera, pero puedo parecer lo que quieres decir. ¡Gracias por el consejo! Mi principal prioridad en este momento es obtener un rastreador de problemas real que los contribuyentes puedan examinar y, con suerte, seleccionar un problema para resolver (en este momento, todo lo que tenemos es un tablero Trello desordenado). Como le dije a @Elin, me estoy inclinando hacia Mantis en lugar del sistema de problemas de Github. Supongo que solo necesitamos algo en este momento.
Ben Torell