Entendiendo el gobierno de su proyecto en crecimiento

Tu proyecto está creciendo, la gente está comprometida, y estás comprometido a mantener esto en marcha. En esta etapa, es posible que te preguntes cómo incorporar a los contribuyentes regulares de proyectos en su flujo de trabajo, ya sea para darle a alguien el compromiso de acceso o para resolver los debates de la comunidad. Si tiene preguntas, tenemos respuestas.

¿Cuáles son ejemplos de roles formales utilizados en proyectos de código abierto?

Muchos proyectos siguen estructuras similares para reconocer y asignar roles a los contribuyentes.

El significado de estos roles queda a tu criterio. Aquí puedes encontrar algunos tipos de rol que quizás reconozcas:

  • Mantenedor
  • Contribuyente
  • Committer

Para algunos proyectos, los “mantenedores” son las únicas personas en el proyecto con permisos de commit. En otros proyectos, son simplemente personas que están listadas en el archivo README.md como mantenedores.

Un mantenedor no necesariamente tiene que ser alguien que escribe código para su proyecto. Podría ser alguien que ha hecho mucho trabajo evangelizando su proyecto, o documentación escrita que hizo el proyecto más accesible a los demás. Independientemente de lo que hacen día a día, un mantenedor es probablemente alguien que se siente responsable sobre la dirección del proyecto y se ha comprometido a mejorarlo.

Un “contribuyente” puede ser cualquiera que comente en una issue o un pull request, personas que agreguen valor al proyecto (sin importar si sólo está clasificando issues, escribiendo código u organizando eventos), o cualquiera con un merged pull request (esta es la definición más estrecha de un contribuyente).

El término “committer” podría utilizarse para distinguir entre el acceso a commit, que es un tipo específico de responsabilidad, de otras formas de contribución.

Mientras que puedes definir tus roles de proyecto de cualquier forma que quieras te gustaría considerar usar definiciones más amplias para fomentar más formas de contribución. Puedes utilizar funciones de liderazgo para reconocer formalmente a personas que han hecho contribuciones excepcionales a su proyecto, independientemente de su habilidad técnica.

¿Cómo formalizo los roles de liderazgo?

La formalización de tus funciones de liderazgo ayuda a las personas a sentirse propietarias y les dice a otros miembros de la comunidad a quién deben buscar para conseguir ayuda.

Para un proyecto más pequeño, designar líderes puede ser tan simple como agregar sus nombres a su archivo de texto README o CONTRIBUTORS.

Por un proyecto más grande, si tienes una página web, crea una página de equipo o lista tus líderes de proyecto allí. Por ejemplo, PostgreSQL tiene una página exhaustiva de equipo con perfiles cortos para cada contribuyente.

Si tu proyecto tiene una comunidad de contribuidores muy activa, puede formar un “equipo central” de mantenedores, o incluso subcomisiones de personas que se apropian de diferentes áreas temáticas (por ejemplo, seguridad, clasificación de temas o conducta comunitaria). Permite que la gente se auto-organice y se ofrezca como voluntaria para los papeles que más le entusiasman, en lugar de asignarlos.

Los equipos de liderazgo pueden querer crear un canal designado (como en IRC) o reunirse regularmente para discutir el proyecto (como en Gitter o Google Hangout). Incluso puedes hacer públicas esas reuniones para que otras personas puedan escucharlas. Cucumber-rubí, por ejemplo, hospeda las horas de oficina cada semana.

Una vez que haya establecido roles de liderazgo, ¡no olvides documentar cómo la gente puede alcanzarlos! Establece un proceso claro para que alguien pueda convertirse en un mantenedor o unirse a un subcomité en su proyecto y escribirlo en su GOVERNANCE.md.

Herramientas como Vossibility puede ayudarte a hacer un seguimiento público de quién (o no) está haciendo contribuciones al proyecto. Documentar esta información evita la percepción de la comunidad de que los mantenedores son un grupo que toma sus decisiones en privado.

Por último, si su proyecto está en GitHub, considere la posibilidad de mover su proyecto de su cuenta personal a una organización y agregar al menos un administrador de copias de seguridad. Las organizaciones GitHub facilitan la administración de permisos y múltiples repositorios y protegen el legado de su proyecto mediante la propiedad compartida.

¿Cuándo le puedo dar acceso a hacer commits a alguien?

Algunas personas piensan que debe dar acceso de commits a todos los que hacen una contribución. Hacerlo podría alentar a más personas a sentirse dueñas de su proyecto.

Por otro lado, especialmente para proyectos más grandes y complejos, es posible que desee dar sólo el acceso de commit a las personas que han demostrado su compromiso. No hay una manera correcta de hacerlo - ¡Haz lo que te parezca más cómodo!

Si tu proyecto está en GitHub, podés utilizar ramas protegidas para administrar quién puede enviar a una rama en particular y bajo qué circunstancias.

¿Cuáles son algunas de las estructuras de gobierno comunes para los proyectos de código abierto?

Hay tres estructuras de gobierno comunes asociadas a los proyectos de código abierto.

  • BDFL: BDFL significa “Benevolent Dictator for Life” (en español, “Dictador benevolente para la vida”). Bajo esta estructura, una persona (generalmente el autor inicial del proyecto) tiene la palabra final en todas las decisiones importantes del proyecto. Python es un ejemplo clásico. Los proyectos más pequeños son probablemente BDFL por defecto, porque sólo hay uno o dos mantenedores. Un proyecto que se originó en una empresa también podría caer en la categoría BDFL.

  • Meritocracia: (Nota: el término “meritocracia” tiene connotaciones negativas para algunas comunidades y tiene un historia social y político compleja.) Bajo una meritocracia, a los contribuyentes activos del proyecto (aquellos que demuestran “mérito”) se les da un papel formal de toma de decisiones. Las decisiones se toman generalmente en base a un consenso de voto puro. El concepto de meritocracia fue iniciado por la Fundación Apache; Todos los proyectos de Apache son meritocracias. Las contribuciones sólo pueden ser hechas por individuos que se representan a sí mismos, no por una empresa.

  • Contribución liberal: Bajo un modelo de contribución liberal, las personas que hacen más trabajo son reconocidas como las más influyentes, pero esto se basa en el trabajo actual y no en contribuciones históricas. Las decisiones importantes del proyecto se toman sobre la base de un proceso de búsqueda de consenso (discutir quejas mayores) en lugar de voto puro, y tratar de incluir tantas perspectivas de la comunidad como sea posible. Ejemplos populares de proyectos que utilizan un modelo de contribución liberal incluyen Node.js y Rust.

¿Cuál deberías usar? ¡Tú decides! Cada modelo tiene ventajas y compensaciones. Y aunque pueden parecer muy diferentes al principio, los tres modelos tienen más en común de lo que parece. Si estás interesado en adoptar uno de estos modelos, consulta estas plantillas:

¿Necesito documentación de gobierno cuando lanzo mi proyecto?

No hay momento adecuado para describir el gobierno de su proyecto, pero es mucho más fácil definirlo una vez que haya visto cómo se desarrolla la dinámica de su comunidad. ¡La mejor parte (y más difícil) sobre el gobierno de código abierto es que está conformado por la comunidad!

Sin embargo, una cierta documentación temprana contribuirá inevitablemente al gobierno de su proyecto, así que empiece a escribir lo que pueda. Por ejemplo, puede definir expectativas claras de comportamiento o cómo funciona su proceso de contribución, incluso en el lanzamiento de su proyecto.

Si usted es parte de una empresa lanzando un proyecto de código abierto, vale la pena tener una discusión interna antes del lanzamiento acerca de cómo su empresa espera mantener y tomar decisiones sobre el proyecto de seguir adelante. También es posible que desee explicar públicamente algo en particular sobre cómo su empresa (o no) participará en el proyecto.

¿Qué pasa cuando los empleados de corporaciones comienzan a enviar contribuciones?

Los proyectos exitosos de código abierto se utilizan por muchas personas y empresas, y algunas empresas pueden eventualmente tener flujos de ingresos generalmente vinculados al proyecto. Por ejemplo, una empresa puede utilizar el código del proyecto como un componente en una oferta de servicios comerciales.

A medida que el proyecto se utiliza más ampliamente, las personas que tienen experiencia en ella comienzan a estar más demandados - ¡puedes ser uno de ellos! - y a veces se les paga por el trabajo que realizan en el proyecto.

Es importante tratar la actividad comercial como algo normal y como otra fuente de energía de desarrollo. Por supuesto, los desarrolladores pagados no deben recibir un trato especial sobre los no pagados. Cada contribución debe ser evaluada por sus méritos técnicos. Sin embargo, la gente debe sentirse cómoda participando en la actividad comercial, y sentirse cómoda diciendo sus casos de uso al argumentar a favor de una mejora o característica en particular.

“Comercial” es completamente compatible con “código abierto”. “Comercial” sólo significa que existe dinero involucrado en alguna parte - que el software se utiliza en el comercio, que es cada vez más probable como un proyecto gana la adopción. (Cuando se utiliza software de código abierto como parte de un producto que no es de código abierto, el producto general sigue siendo un software “propietario”, aunque, al igual que el código abierto, podría utilizarse con fines comerciales o no comerciales).

Como cualquier otra persona, los desarrolladores con motivación comercial ganan influencia en el proyecto a través de la calidad y la cantidad de sus contribuciones. Obviamente, un desarrollador al cual se le paga por su tiempo, puede ser capaz de hacer algo más que alguien al que no se le paga, pero eso está bien: el pago es sólo uno de los muchos factores posibles que podrían afectar cuánto una persona hace. Manten los debates del proyecto centrados en las contribuciones, no en los factores externos que permiten a las personas a hacer esas contribuciones.

Usted no necesita una entidad legal para apoyar su proyecto de código abierto a menos que esté manejando dinero.

Por ejemplo, si desea crear un negocio comercial, desee configurar una C Corp o LLC (si vives en los EE.UU.). Si está haciendo un trabajo de contrato relacionado con su proyecto de código abierto, puede aceptar dinero como propietario único, o establecer una LLC (si vives en los EE.UU.).

Si quieres aceptar donaciones para tu proyecto de código abierto, podes configurar un botón de donación (mediante PayPal o Stripe, por ejemplo), pero el dinero no será deducible de impuestos a menos que sea una organización sin fines de lucro calificada (un 501c3, si estás en los EE.UU.).

Muchos proyectos no desean pasar por la molestia de crear una organización sin fines de lucro, por lo que encuentran un patrocinador fiscal sin fines de lucro en su lugar. Un patrocinador fiscal acepta donaciones en su nombre, normalmente a cambio de un porcentaje de la donación. Software Freedom Conservancy, Apache Foundation, Eclipse Foundation, Linux Foundation y Open Collective son ejemplos de organizaciones que sirven como patrocinadores fiscales para proyectos de código abierto.

Si tu proyecto está estrechamente asociado con un determinado idioma o ecosistema, también puede haber un framework relacionado con el que pueda trabajar. Por ejemplo, la Python Software Foundation ayuda a PyPI, el gestor de paquetes de Python y el Node.js Foundation ayuda a apoyar Express.js, un framework basado en nodos.