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:

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:

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:

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?

Cuéntanos qué te parece.

Enviar.

Los comentarios serán moderados. Serán visibles si aportan un argumento constructivo. Si no estás de acuerdo con algún punto, por favor, muestra tus opiniones de manera educada.

Suscríbete