Cómo establecer un programa de código abierto

Aquí se describen las consideraciones clave para establecer un programa de código abierto.

¿Qué significa "código abierto"?

Un programa de código abierto implica más que el acceso público a un código base. Consiste en comenzar un proyecto dinámico en el que pueden participar todas las personas que quieran. Cuando se ejecuta correctamente para un proyecto adecuado, un programa de código abierto puede ayudar a impulsar mejoras considerables en la calidad del producto.

Uno de los motivos principales por los que las empresas recurren a proyectos de código abierto es que les interesa que la comunidad participe. Los proyectos más populares reciben importantes contribuciones de la comunidad de forma gratuita.

No se trata necesariamente de altruismo. Las personas y las organizaciones consumen proyectos porque ven un beneficio personal o empresarial. Cuando el proyecto no satisface sus necesidades o no cumple sus expectativas, pueden aprovechar la ocasión para solucionar errores o agregar características. En lugar de retener estas mejoras en bifurcaciones privadas, se les obliga a contribuir esos cambios al repositorio de origen para que pasen a formar parte de la línea base del proyecto. Este ciclo virtuoso de mejora es por qué muchas empresas producen software mediante el modelo de código abierto.

Objetivos del código abierto

En resumen, la participación en software de código abierto cuenta con tres dimensiones:

• Consumidores, que estudien o usen los repositorios de otros usuarios.
• Colaboradores, que participan activamente en la mejora de los repositorios de otros usuarios.
• Productores, que crean y mantienen sus propios repositorios abiertos a otros usuarios.

Dado que las organizaciones analizan cada vez más a fondo lo que quieren obtener de cada dimensión, es aconsejable valorar dónde se encuentran en la actualidad. Hay cinco niveles de proceso en cada dimensión.

• Ad hoc, que no tiene ningún proceso en vigor. El éxito depende de los esfuerzos individuales.
• Administrado, en el que hay un proceso parcialmente documentado. El éxito depende de la disciplina.
• Definido, en el que hay un proceso documentado, normalizado e integrado. El éxito depende de la automatización.
• Medido, en el que hay un proceso administrado cuantitativamente. El éxito depende de la medición de las métricas con respecto a los objetivos empresariales.
• Optimizado, en el que hay un proceso que se mejora de forma continua y fiable mediante cambios incrementales e innovadores. El éxito depende de que se reduzca el riesgo de cambio.

Para comprender mejor dónde se destaca su organización, consulte las autoevaluaciones de código abierto.

¿Qué debe convertir en código abierto?

Muchos proyectos no son adecuados para la excelencia del código abierto. Aunque los criterios varían en función de los objetivos de la empresa y del nivel de proceso, existe una serie de criterios recomendados que se deben tener en cuenta antes de convertir un proyecto en código abierto:

• ¿Contiene el proyecto propiedad intelectual que quiere proteger? Si es así, el hecho de abrir el código le restaría valor. No convierta en código abierto este tipo de proyectos, a menos que crea que las ventajas superan los riesgos.

• ¿Se encuentra el proyecto en un estado estable y tiene una calidad de código correcta? No hace falta que el proyecto sea perfecto, pero si presenta un estado desastroso, podría disuadir a los posibles colaboradores de participar.

• ¿Es un proyecto útil para personas ajenas a la empresa? Si no lo es, probablemente nadie querrá participar.

• ¿Pueden contribuir personas ajenas a la empresa? Necesitan acceso a todas las dependencias del proyecto, procesos de compilación y todo lo que haga falta para ejecutar el proyecto. Si no pueden ejecutarlo, no podrán contribuir.

• ¿Tiene el equipo los recursos necesarios para admitir un programa de código abierto? Si no es así, espere hasta que los tenga. Si convierte un proyecto en código abierto, pero no lo admite, podría perder la oportunidad de crear una comunidad en la que impere la confianza.

Estas preguntas son solo algunas de las consideraciones más comunes que debe tener en cuenta. Es posible que la organización tenga que valorar otros problemas empresariales o de cumplimiento.

Diseño de un programa de código abierto

La ejecución de un programa de código abierto es similar a la ejecución de un programa InnerSource, pero para un público amplio. Como resultado, existen algunas consideraciones adicionales.

Establecimiento de las expectativas de la comunidad

Ciertos archivos, como README.md y CONTRIBUTING.md, resultan todavía más importantes, ya que se exponen a personas que desconocen el contexto de la organización. Deben evaluarse desde el punto de vista de alguien ajeno a la empresa para garantizar la claridad.

Además, es importante comunicar su código de conducta como política. Lo habitual es agregar un archivo CODE_OF_CONDUCT.md a la raíz del repositorio y usarlo para explicar el comportamiento que se espera de los participantes de la comunidad. Este documento deben revisarlo varios grupos de la organización, incluido el equipo legal. Afortunadamente, hay muchos códigos de conducta estándar que se pueden usar como punto de partida. Muchos proyectos usan estos códigos tal cual, sin modificarlos. Obtenga más información en la Guía para códigos de conducta de código abierto.

Preparación de los empleados para mantener un repositorio

Es posible que los empleados no tengan experiencia a la hora de trabajar con la comunidad de código abierto. Para ayudarles a prepararse, se recomienda que la empresa ofrezca una serie de guías que traten los principales factores que todo el mundo debe conocer antes de empezar. Estas guías deben publicarse en un repositorio interno o en un portal al que solo puedan acceder los empleados de la empresa y que se mantenga con regularidad. Las siguientes guías son algunas de las más importantes:

• Una guía "¿Deberíamos abrir este proyecto?" que proporciona un marco para decidir si un proyecto candidato debe ser de código abierto o no. Esta guía se puede estructurar como un diagrama de flujo, un conjunto de preguntas o una lista de consideraciones.

• Lista de comprobación de configuración que incluye todos los elementos de trabajo que un equipo debe completar antes y después del inicio de un proyecto de código abierto. Esta lista debe incluir la adquisición de la aprobación para el proyecto de código abierto, las revisiones de código para asegurarse de que se quiten los datos confidenciales antes de que el proyecto pase a estar activo, una búsqueda de proyecto de marca comercial o de código abierto para asegurarse de que no haya un conflicto de nomenclatura, etc.

• Se requiere una lista de contactos para las personas clave de su organización que podrían necesitar ponerse en contacto con el soporte técnico directo de los mantenedores. La lista debe incluir personas de los equipos de seguridad del software, seguridad del sitio, departamento legal, relaciones públicas, etc.

• Vínculo a un repositorio de inicio que se puede clonar como punto de partida. Debe contener un archivo LÉAME de ejemplo, una licencia, un código de conducta, una guía de contribución y cualquier otro archivo auxiliar que necesiten todos los proyectos de código abierto de la empresa. No debe contener nada que no quiera insertar accidentalmente en un público amplio.

• Guía del mantenedor que explica las responsabilidades que tiene un mantenedor para mantener el repositorio en buen estado. Estas responsabilidades incluyen mantener actualizada la documentación del repositorio, asegurarse de que las incidencias y las solicitudes de incorporación de cambios reciben la atención de las personas adecuadas de forma oportuna, etc.

• Una guía de comunicaciones que ofrece instrucciones para los mantenedores de repositorios para algunos de los temas que prefiere no incluir en archivos públicos como README.md, CONTRIBUTING.mdo CODE_OF_CONDUCT.md. Puede tratarse de temas empresariales confidenciales, como no hablar sobre la competencia; o asuntos más generales, como la manera de reconocer los colaboradores más importantes.

• Una FAQ interna que ofrece respuestas aprobadas a preguntas comunes. Esta lista resulta especialmente útil si los temas tienen matices legales que la empresa podría analizar durante el mantenimiento de un programa de código abierto.

• Una directiva de licencia que muestra qué licencias han sido aprobadas o rechazadas por el departamento legal para el consumo o la contribución de código abierto.