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. Los usuarios y las organizaciones consumen proyectos porque les reportan una ventaja 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 almacenar estas mejoras en bifurcaciones privadas, se ven obligados a contribuir con esos cambios en el repositorio de origen para que formen parte de la línea de base del proyecto. Este ciclo virtuoso de mejoras es el motivo por el que muchas empresas producen software con 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:
- Los consumidores, que estudian o usan repositorios de otros usuarios.
- Los colaboradores, que participan activamente en la mejora de los repositorios de otros usuarios.
- Los productores, que crean y mantienen sus propios repositorios, que están 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, en el que no se aplica ningún proceso. 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 dónde se encuentra 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, el código de conducta es una directiva importante que se debe expresar. 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 de 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 sobre la idoneidad del código abierto que proporcione un marco para decidir si un proyecto debe ser de código abierto. Esta guía se puede estructurar como un diagrama de flujo, un conjunto de preguntas o una lista de consideraciones.
Una lista de comprobación de configuración que incluya todos los elementos de trabajo que un equipo debe completar antes y después de iniciar un proyecto de código abierto. Esta lista debe abordar el proceso de aprobación del proyecto de código abierto, las revisiones de código para garantizar que los datos confidenciales se eliminen antes de que el proyecto se active, una búsqueda de proyectos de código abierto o de marcas comerciales para asegurarse de que no haya un conflicto de nombres, etc.
Una lista de contactos de personas clave de la organización con las que sea necesario ponerse en contacto en caso de que se requiera asistencia directa de mantenedores. La lista debe incluir personas de los equipos de seguridad del software, seguridad del sitio, departamento legal, relaciones públicas, etc.
Un vínculo a un repositorio de inicio que se pueda 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.
Una guía para mantenedores que explique las responsabilidades de esta figura a la hora de conservar el buen estado del repositorio. 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 ofrezca instrucciones para los mantenedores del repositorio sobre las cuestiones que no se quieren incluir en archivos públicos como
README.md,CONTRIBUTING.mdoCODE_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 serie de preguntas más frecuentes internas que proporcione respuestas aprobadas a preguntas habituales. 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 licencias que enumere las licencias que el departamento legal ha aprobado o rechazado para el consumo o la contribución del código abierto.