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.
Comentarios
Publicar un comentario