Desarrollo colaborativo
En los proyectos de software libre hay una cultura de trabajar en abierto, ya que esta facilita las condiciones que los hacen sostenibles financiera y técnicamente. Es de interés para todos los proyectos incrementar la afluencia de recursos hacia los mismos, y eso pasa por lo siguiente:
-
Incrementar la cantidad de personas o instituciones que utilizan el software.
-
Propiciar la transición de cualquier persona o entidad usuaria a alguien que participe en el proyecto de la manera que sea: contribuyendo con código, testing, correcciones, financiación, difusión, traducciones, etcétera.
Fuera de este modelo, basado en incentivar la colaboración, es muy difícil materializar las ventajas potenciales que ofrece el paradigma del software libre. Hay dos elementos clave en todo esto:
-
Transparencia. Esta no se tiene que limitar al código. Para que haya verdadera colaboración, la transparencia debe abarcar toda la infraestructura de comunicación, conocimiento y toma de decisiones del proyecto.
-
Diseminación del conocimiento. A diferencia de los modelos de negocio clásicos, aquí interesa que el conocimiento sobre el producto, hasta los detalles más técnicos, esté lo más distribuido posible. Eso reduce el riesgo tecnológico y la dependencia del Ayuntamiento sobre empresas concretas.
-
Participación de la comunidad. Esto refuerza tanto el proyecto, con más ideas y recursos, como las comunidades locales.
Trabajar en abierto supone que los siguientes elementos sean públicamente accesibles (para lectura) a toda persona interesada en formatos abiertos, sin tener que usar herramientas privativas y de forma anónima (sin tener que registrarse en ningún servicio web y mucho menos teniendo que contratar servicios de pago):
-
El repositorio de código.
-
El gestor de incidencias (donde, entre otros, se notifican y gestionan los defectos o bugs).
-
Los documentos de diseño.
-
La documentación de usuario/a.
-
Los canales de comunicación donde el equipo de desarrollo toma las decisiones técnicas.
Trabajar en abierto no significa (necesariamente) lo siguiente:
-
Que personas externas al proyecto tengan acceso de escritura al repositorio (son libres de copiar el código en un repositorio propio y modificar su copia).
-
Que todo el mundo tenga permiso para escribir notificaciones de defectos e intervenir en el gestor de incidencias, cada proyecto puede escoger su política de calidad.
-
Que el equipo del proyecto tenga que leer y responder todas las notificaciones de defectos (si están abiertas para escritura) ni todas las preguntas en los canales de comunicación abiertos.
-
Que el equipo del proyecto tenga que revisar todas las sugerencias y contribuciones (pull requests, patches) que reciba, si se considera que los recursos están mejor invertidos en otra tarea.
Trabajar en abierto desde el día 1
Un aspecto importantísimo que tener en cuenta es que cuanto más tiempo se gestiona un proyecto de forma cerrada, más costoso es después abrirlo. Si se espera demasiado, puede suceder que algunas medidas no lleguen nunca a implementarse, pues su coste resultaría prohibitivo. Las razones de esto se resumen en lo siguiente:
-
Tener canales de comunicación abiertos desde el día 1 no significa que los “extraños” nos tengan que distraer desde el primer día. En el presente documento se explica cómo dejar claros cuáles son nuestros compromisos, que podemos modular en cada fase.
-
Es imposible compensar los incentivos que tienen los desarrolladores para hacer cosas de manera rápida y fea con futuras amenazas de apertura. Si no se actúa en abierto desde el principio, inevitablemente se incurrirá en deuda tecnológica con la intención de arreglar las cosas en un futuro (que nunca llega).
-
Cuando llega el día de abrir el código, nos encontramos de repente con que tenemos cuestiones como las siguientes:
-
Configuraciones de usuario específicas y contraseñas dentro del repositorio.
-
Notificaciones de defectos que contienen información sensible que no se puede hacer pública.
-
Correspondencia entre desarrolladores donde se mezcla información técnica útil con opiniones personales que no estaban pensadas para que todo el mundo las pudiera leer.
-
Dependencias sobre componentes de software que no se pueden usar en un proyecto de software libre, o que generan problemas de licencias.
-
Documentación o procedimientos de build escritos con herramientas propietarias que no permiten su publicación.
-
(Y una lista inacabable de cosas).
-
La apertura del código provoca tener que tomar decisiones difíciles, que no se producirían si hubiera sido abierto desde el principio (perder tiempo limpiando el historial de defectos o crear uno nuevo y perder el historial completo, etcétera).
Se crea un gran acontecimiento de apertura que supone un alto riesgo para el proyecto, ya que se tienen que hacer muchos cambios de golpe, y todo el proyecto y sus potenciales vulnerabilidades quedan expuestos también de golpe (y muchos ojos, no siempre bien intencionados, estarán mirando). Antes del acontecimiento, eso crea incertidumbre y preocupación. Después del acontecimiento, puede provocar un alud de incidencias que en condiciones normales habrían llegado escalonadamente.
Todos estos elementos se justifican ampliamente en los apartados “Be open from day one” y “Being open source from day one is especially important for Government projects” del libro Producing Open Source Software, cuya lectura es muy recomendable para las personas responsables de cada proyecto.
Las medidas y recomendaciones que tener en cuenta para no retrasar esta apertura se encuentran repartidas en toda la guía, etiquetadas como “Día1”. Las presentamos todas aquí listadas:
ID | Title | Type | Tags |
---|---|---|---|
A_D4F Vincular el repositorio principal a un gestor de incidencias público |
Alternativa |
Día1_;_ Adaptación_;_ Plugin_;_ NuevoProducto_;_ Publicación |
M_F25 |
Subir un fichero README al repositorio principal |
Medida |
Día1_;_ Plugin_;_ NuevoProducto_;_ Publicación |
M_4F5 |
Publicar unas breves directrices para desarrolladores (developer guidelines) |
Medida |
Día1_;_ Plugin_;_ NuevoProducto_;_ Publicación |
R_368 |
Vincular el repositorio principal a un sistema de integración continua con licencia libre. |
Recomendación |
Día1_;_ Adaptación_;_ Plugin_;_ NuevoProducto_;_ Publicación |
M_97E |
Subir el texto de la licencia al repositorio principal |
Medida |
Día1_;_ Plugin_;_ NuevoProducto_;_ Publicación |
M_A60 |
Crear el repositorio principal en el espacio GitHub de publicación abierta_de software del Ayuntamiento |
Medida |
Day1; Adaptation; Plugin; NewProduct; Publication |
M_A63 |
Utilizar el repositorio principal en GitHub como web de desarrollo del proyecto |
Medida |
Día1_;_ Plugin_;_ NuevoProducto_;_ Publicación |
M_35A |
Vincular el repositorio principal al gestor de incidencias |
Medida |
Día1_;_ Adaptación_;_ Plugin_;_ NuevoProducto_;_ Publicación |
R_2D5 |
Reservar una URL permanente para el proyecto, y usarla siempre para hacer referencia a este |
Recomendación |
Día1_;_ Integración_;_ Plugin_;_ NuevoProducto_;_ Publicación |
|
Implementar y documentar procedimientos de build e instalación con herramientas libres y de uso extendido |
Medida |
Día1_;_ Plugin_;_ NuevoProducto_;_ Publicación |
M_CC5 |
Subir un fichero con instrucciones de instalación en el repositorio principal |
Medida |
Apertura de un código inicialmente cerrado
El Ayuntamiento es propietario de los derechos de autor de mucho código que no se proporcionó bajo una licéncia de software libre y, por lo tanto, es un software propietario.
Esta sección aborda aquellos problemas que afectan específicamente a la publicación bajo una licencia libre de componentes de software que no se entregaron como software libre, y que en la mayoría de los casos se desarrollaron sin prever una distribución pública.