Los 5 mitos más comunes sobre Open Source y Código Libre.

Hay un debate recurrente en cualquier proyecto de qué hacer con el código que se programa, ¿es susceptible de mover ese código libre a un repositorio público para que lo tenga todo el mundo? ¿Podemos contribuir a la comunidad Open Source con esta funcionalidad? ¿Esto es lógica de negocio o es una funcionalidad genérica?

En este post voy a tratar de recopilar muchas de estas dudas que se nos plantean en nuestro día a día (y que vosotros seguro que también habéis tenido). Además, vamos a sacar conclusiones y los enfoques a los que llegamos en estos debates.

Mito 1: un proyecto lo componen 4, 8, 12... personas

Cuando nos reunimos con el Product Owner, él ve en la sala a cuatro desarrolladores, un QA y un Scrum Master y le mostramos el incremento de valor del producto y le decimos que nosotros lo hemos realizado, pero desde el punto de vista del desarrollo de software, estamos “mintiendo”.

¿Cómo es posible que en 3 semanas cuatro personas consigan partir de 0 y tener una pequeña web o una API desplegada en entornos productivos? Básicamente porque es “mentira” que para lograr eso haya sido por el esfuerzo de cuatro personas.

Para llegar a ese punto hemos contado con el esfuerzo previo de decenas (o cientos) de miles de personas. Si el proyecto se ha construido sobre Spring Boot o sobre Django, os muestro las estadísticas de Github de gente que ha participado en su desarrollo o indirectamente con librerías de código abierto que usa el framework:

Todo esto sin contar con las herramientas de código abierto para realizar integración continua como Jenkins, para desplegar como Helm, Ansible o Terraform. La infraestructura con Kubernetes, Docker y Linux… todas ellas libres para descargar y modificar a tu gusto.

Mito 2: mejor hacerlo "a mano" que usar librerías

Lo mismo ocurre con las futuras funcionalidades que se hagan en el proyecto. Siempre, lo primero que se hace es buscar si alguien ya ha hecho esa funcionalidad para no reinventar la rueda.

Además, si usas una librería en la que participan cientos de personas, que lleva años de rodaje… tú por muy listo que seas, ¿quién tiene más probabilidades de implementar la mejor solución? ¿Tú que por primera vez te enfrentas a ese problema o todas estas personas que ya han pulido y afinado la respuesta a dicho algoritmo?

Mito 3: hacer Open Source es regalar tu trabajo

Esta creencia quizá viene arrastrada por su término en inglés de “Free Software”, que se malinterpreta como “gratis”, cuando su traducción es “libre”. Libre para que la gente lo analice, lo mejore, contribuya y lo haga crecer.

Cuando “regalas” tu código a la comunidad, no es un beneficio en una sola dirección. Si el código lo puede tener todo el mundo, cuando lo implemente en sus proyectos saldrán casuísticas que ni tú mismo te has planteado, te abrirán incidencias en tu repositorio o te harán contribuciones para mejorarlo.

Esas aportaciones, seguramente en tus proyectos donde tú también uses tu librería, te adelantarán futuros problemas que encontrarás.

Mito 4: es más complicado de mantener

Directamente, un “no” rotundo. Para desplegar tu propia librería, como mínimo, necesitas una infraestructura de integración continua como Jenkins, un servidor donde desplegar las librerías y paquetes, como Nexus o Artifactory, configurar un sistema de perfilado para que, si no son públicas, no todo el mundo pueda acceder a todo.

Si pones este perfilado, tendrá que estar vinculado con tus usuarios con un LDAP. Además, tienes que tener repositorio privado, lo que también es coste que te cobran los proveedores o tu propio servidor que también hay que mantener.

Por último, no nos olvidemos de la seguridad: esta librería tendrá dependencias, ¿no? ¿Quién se va a encargar de estar pendiente de los boletines de seguridad que avisa de vulnerabilidades y si la librería se ve afectada?

Pues bien, con una librería Open Source, todo eso lo tienes gratis y autogestionado. Tienes infinidad de opciones, entre ellas se puede destacar:

• La funcionalidad de Github, que autodetecta posibles fallos de seguridad.
• Pyup te abre pull requests él solito si se actualizan alguna de las dependencias de tus librerías para proyectos de código abierto. Otro servicio similar puede ser requires, pero menos potente.

• Travis te “regala” una CI super-increible-potente, mucho más robusta que cualquier CI privada que he usado en mi vida pudiendo personalizar todo lo que se te pase por la mente: versiones del propio lenguaje, ejecuciones en paralelo… vamos, ¡me tiene loquito!

• Coveralls: se engancha con un clic con los resultados de Travis, mostrándote cobertura de tu código y permitiéndote establecer un porcentaje mínimo para que pueda subir un cambio. Analiza cada rama y cada tag que crees sin configurar nada.

• LGTM: que analiza el código estático, sugiriendo mejoras o buenas prácticas, avisos de complejidad ciclomática, análisis de seguridad, clasifica tu proyecto con una “nota” de calidad en base a todos estos análisis y una “pijada” que me encanta: que compara tu proyecto con otros similares de código abierto. Pudiendo hacer sombra a Sonar.

Como veis, dedicarle tiempo a resolver posibles issues, mejorar documentación, interactuar con gente que usa tu librería es mucho mejor que gastar tiempo en tu propia infraestructura y mantener repositorios privados.

Mito 5: el código es de cliente o de la compañía

Por regla general, cuando se desarrolla un proyecto o un producto para un cliente, la propiedad intelectual la tiene este último. Pero entra en contradicción porque ese producto se entrega con muchas librerías de terceros con licencias de código libre que son imprescindibles para poder hacer desarrollos que no se eternicen.

Entonces, si nos podemos permitir esta licencia (nunca mejor dicho), ¿por qué no sacar funcionalidades genéricas, que no impliquen lógica de negocio, de los proyectos a librerías comunes para toda la empresa para ser más rápidos en futuros desarrollos?

Cuando se cae en esa filosofía restrictiva, pueden pasar dos casos en una compañía y un cliente:

• Cultura del copia-pega: si no se distribuye el conocimiento, cuando alguien pasa del proyecto A al proyecto B, lo que va ocurrir es que si surgen las mismas funcionalidades en B que en A, si los tiempos de ejecución van a ser ajustados, lo que vas a hacer es Ctrl+C y Ctrl+V de lo que hiciste y plasmarlo en el nuevo proyecto. A esto lo llamaremos también “Open Source en las sombras” o “Free Software a lo jíbiri”.
• Dictadura del conocimiento: cuando se da este caso, en las compañías se encargan de poner al frente del proyecto a personas que centralizan el conocimiento al haber pasado por más proyectos que nadie y son los únicos con visión global o con el conocimiento de todas las casuísticas.

En contra de esto, si parte del código común (excluyendo la lógica de negocio particular de cada cliente lógicamente), de librerías, de arquetipos… dentro de la compañía y se hiciese accesible entre todos los equipos en un escenario idílico, todo ello bien documentado, se consigue:

• Conocimiento distribuido: ante un problema, todos podemos partir de una solución y adaptarlas a nuestras casuísticas particulares ahorrando trabajo. Uno de los problemas de productividad más típicos de software es hacer una y otra y otra vez el mismo problema en vez de investigar si ya existe una solución (y no me refiero a buscar código en Stackoverflow), entenderla y reutilizarla para nuestro caso de uso.
• Anteponerse a los problemas: cuanta más gente use un código, más casos de uso se pueden dar y puedes solucionarlos antes de que te ocurran. Por ejemplo, en una librería que nosotros desarrollamos para construir servicios API REST, un compañero que también empezó a usar esta librería, detectó que había un problema al usar un proxy inverso con diferente ruta sobre un microservicio en Kubernetes. Aplicamos una corrección en la librería para que el compañero tuviese una solución al bug que detectó y nos permitió tener una solución a un problema que ni sabíamos que existía, pero que en unas semanas nos lo hubiéramos encontrado en un punto crítico al subir a entornos a productivos el servicio cuando cumplir los hitos de negocio eran críticos.
• Calidad de código: cuando trabajas en equipos pequeños, al estar en confianza, si hay prisas, puedes caer en soluciones rápidas que no son lo más elegante. Pero si tu código está a la vista de todos, las informalidades en la codificación desaparecen. Poniendo un ejemplo práctico, comparemos cómo podría ser una misma comunicación por WhatsApp o por un meetup:
  • Whastapp: “eyyy, mañana tenemos meetup! te vienes o k?
  • Comunicado en la web de Meetup: “Nos gustaría recordaros que mañana realizaremos un nuevo Meetup de Python Madrid donde tendremos a Richard Van Black (Nombre inventado) a las 19:00h en Google Campus”.

El mensaje es el mismo, en WhatsApp el receptor tiene contexto y no es necesario aportar información que las dos partes ya conocen. No sigues una ortografía porque primas la comunicación rápida con tu compañero.

En el segundo caso, también lo puede ver gente cercana, pero lo estás anunciando en una página de alcance mundial, donde cualquiera que no sabe ni qué haces puede llegar e interesarse, pero necesita una información para entender qué estás realizando y para qué. Cuando programas, documentas el código, ocurre exactamente lo mismo.

Con este post espero contribuir a romper los mitos sobre el código abierto, y a que se mire con mejores ojos el open source con el que, a la larga, ganamos todos. Y tu empresa, ¿aún se resiste a trabajar con código abierto?