Cuando decimos que algo es “abierto” (open, en inglés) normalmente queremos hacer hincapié en su transparencia o visibilidad. Sin embargo, lo abierto que es un proyecto (su openness, en inglés) está inherentemente ligado al grado de colaboración que existe entre sus desarrolladores y, de esta forma, con la forma en la que trabajan. Colaborar significa lidiar con temas como la organización del trabajo y la distribución de poder — en dos palabras, lo que solemos llamar “modelo de gobernanza” (governance model, en inglés).

En comunidades y organizaciones Open Source, hacer explícitos sus modelos de gobernanza es crucial si queremos llegar a tener repositorios de software libre que no sólo sean libres sinó también comunitarios:

  1. En primer lugar, ayuda a mejorar el nivel de transparencia de la organización: cualquiera puede conocer el tiempo que requiere considerar una propuesta de cambio en el código, las posibilidades que tienen las contribuciones de código en tener un impacto en la organización o quién es el responsable de escuchar las propuestas (o quejas) de los usuarios y desarrolladores.
  2. En segundo lugar, definir los modelos de gobernanza también ayuda a entender y clasificar cómo funcionan las organizaciones abiertas. En otras palabras, los modelos de gobernanza dan pistas acerca de las distribuciones de poder y autoridad en una organización (y saber si se aplica un modelo democrático, meritocrático, dictatorial benévolo, etc.). Por ejemplo, el estudio de los modelos de gobernanza podría ayudar a mejorar la definición de meritocracia en el contexto del software abierto (un tema bastante controvertido que todavía genera discusión).

Pero todo ello es lo que se podría alcanzar potencialmente. Empecemos por el principio: en este artículo estudio cómo funcionan proyectos software reales. ¿Son suficientemente transparentes? ¿Es fácil entender cómo contribuir o colaborar en ellos? ¿Son sus modelos de gobernanza claros y explícitos?

Manos a la obra: Analizando la transparencia de proyectos open source famosos en GitHub

Utilizando la API de GitHub he analizado los 25 proyectos más famosos de la plataforma (los que tienen más estrellas, que son una manera de medir la popularidad de un proyecto en GitHub). En concreto, me he fijado en las siguientes dimensiones de análisis:

  • Métricas básicas de actividad (p. ej., número de commits o watchers)
  • Métricas de colaboración (p. ej., número de issues y pull requests)
  • Documentación (uso de ficheros como contributing.md, code_of_conduct.md, license.md)
  • Uso de etiquetas (p. ej., definición de etiquetas descriptivas)

Una vez recopilada esta información (que comparto), estudié el modelo de gobernanza de cada proyecto (si es que existía o se comentaba). Algunos de los proyectos analizados daban suficiente información para entender sus modelos de gobernanza, pero no muchos: cinco proyectos detallaban este tipo de información, uno de ellos ofrecía una descripción limitada y diecinueve de ellos no la comentaban en absoluto.

Ciertamente encontré buenos ejemplos de transparencia en gobernanza. Por ejemplo, el proyecto Moby describe claramente el proceso de desarrollo utilizando etiquetas descriptivas e indicando la gente involucrada en cada una de sus fases. El proyecto NodeJS ofrece una descripción de los roles de desarrolladores, así como sus responsabilidades y la forma de elegirlos. Finalmente, el proyecto React incluye un documento que describe cómo se tratan los pull requests, el cual especifica el proceso de revisión y priorización.

Una vista al pasado: ¿es el software libre cada vez más transparente?

Estos resultados son claramente mejores que los obtenidos hace dos años. En aquel momento también analicé los 25 proyectos más famosos y los resultados fueron tristemente peores: solamente uno de los proyectos que analicé (Docker) describía este tipo de información, mientras que siete de ellos daban algunas pistas y el resto no decían ni una palabra acerca de la gobernanza.

También es importante recalcar que los proyectos eran diferentes en ambos estudios. La siguiente figura compara ambos resultados:

Al comparar los resultados de ambos estudios también pude comprobar:

  • Un uso más amplio de los ficheros code_of_conduct.md, que ilustran cómo contribuir en el proyecto. Hay incluso iniciativas para promover buenas prácticas.
  • Hay más recursos para enseñar a los recién llegados (newcomers, en inglés) cómo funciona Open Source y cómo pueden contribuir. Así, los ficheros contributing.md se han convertido en un elemento común en GitHub.
  • Un uso de técnicas más descriptivas como el versionado semántico (semantic versioning, en inglés), que ayuda a entender la naturaleza de cada lanzamiento de versiones; o el uso de etiquetas detalladas, que ayuda a entender sus finalidades en el proyecto (con especial atención a las etiquetas help-wanted o good-first-issue, que animan a los recién llegados a participar).
  • Un uso extendido de redes sociales y herramientas de soporte al desarrollo (p. ej., gitter).

Esta comparación muestra una importante mejora con respecto a los resultados de hace dos años. Así que tenemos una respuesta para el título de nuestro artículo.

Sin embargo, creo que todavía hay mucho trabajo por delante. Afortunadamente, actualmente hay movimientos e iniciativas (como los que he comentado anteriormente) que facilitan la descripción de la gobernanza en proyectos y comunidades Open Source por medio de plantillas, guías para recién llegados e indicaciones para licencias.

Quizás el siguiente paso es facilitar a los desarrolladores la creación y adaptación de estas plantillas y guías. Mecanismos para empoderar a los desarrolladores (y usuarios finales) para poder expresar (y hacer explícito) las reglas y normas que gobiernan la colaboración en el proyecto ayudarían al organizaciones y al movimiento Open Source. Un paso adicional podría incluso incluir herramientas de validación (y ejecución) de que la colaboración se desarrolla según se establece en las guías del proyecto (p. ej., mediante bots que hacen cumplir las reglas de gobernanza contactando a los desarrolladores para que soluciones peticiones de cambio a tiempo).

Entiendo que este análisis no se puede generalizar pero dada la importancia de GitHub en la comunidad Open Source, creo que podría ser un ejemplo representativo. Además, el hecho de que estos proyectos formen parte de los más importantes de la plataforma (al menos lo que más interés provocan) también ayuda a mostrar cómo se hacen las cosas.

(Este artículo es una traducción al español del artículo titulado “Projects that make their rules explicit would see more participation” y publicado en opensource.com)

Foto gracias a Alexander Hafemann en Unsplash