La guerra de las licencias de código abierto ha terminado

La guerra del código abierto ha terminado por mucho que algunos quieran seguir luchando. Recientemente, Meta lanzó Llama 2, un poderoso modelo de lenguaje grande (LLM, de sus siglas inglesas) con más de 70.000 millones de parámetros. En el pasado, la compañía había restringido el uso de sus LLM con fines de investigación, pero con su nuevo servicio lo ha abierto; la única restricción es que no se puede utilizar con fines comerciales. Solo un puñado de empresas tiene la potencia computacional para implementarlo a escala, Google, Amazon y muy pocas otras.

Esto significa, por supuesto, que no es código abierto según su definición, a pesar de que Meta lo anuncia como tal. Y ya hay muchas voces críticas que reclaman a la compañía que deje de llamarlo así. Tienen razón, pero sus preocupaciones son irrelevantes. Durante años, los desarrolladores han estado votando con sus repositorios en GitHub para elegir qué es “lo suficientemente abierto”. No es que el código abierto no importe, sino que nunca lo ha hecho de la manera que algunos esperaban o creían.

Breve historia del código abierto

Hace más de una década, la tendencia hacia la concesión de licencias permisivas era tan pronunciada que el analista de RedMonk, James Governor, declaró que “los desarrolladores más jóvenes de hoy se interesen por el open source posterior al POSS. Comprométase solo con GitHub”. En respuesta, la gente dijo que tendencias pasadas como esta habían resultado en “agrupaciones épicas” o que “el intercambio promiscuo sin licencia conduce a enfermedades transmitidas por software”.

Y, sin embargo, después de millones de repositorios de GitHub sin licencia, no hemos entrado en la ‘edad oscura’ de las licencias de software. El software de código abierto, “o suficientemente abierto”, ahora encuentra su camino en casi todo el software, sin embargo, termina con una licencia para el usuario final.

En respuesta, GitHub y otros han ideado formas de atraer a los desarrolladores para que elijan licencias open source para gobernar sus proyectos. Es probable que todos estos movimientos ayuden, pero la realidad es que no importarán, porque el código abierto realmente ya no importa. No como una furia contracultural contra la máquina de software corporativo, en cualquier caso. Todo esto me llevó a concluir que estamos en la revolución post código abierto, en la que el software importa más que nunca, pero su licencia cada vez menos.

Los datos para respaldar esta posición abundan a través de los repositorios de GitHub o las tendencias de licencias de código abierto que han estado en marcha durante 20 años. Todo ha tendido hacia un acceso permisivo y lo más abierto posible al código, hasta el punto de que la licencia subyacente es mucho menos importante que la facilidad con la que podemos acceder y usar el software.

¿Fuente disponible? Lo que sea

Demasiados guerreros del código abierto piensan que la licencia es el fin, en lugar de solo un medio para otorgar acceso al código en gran medida sin restricciones. Continúan preocupándose por las licencias cuando los desarrolladores se preocupan principalmente por el uso. Y, más que cualquier otra cosa, el open source amplía el acceso a software de calidad sin involucrar a los equipos de compras o legales. Esto es muy similar a lo que hizo la nube para el hardware. El punto nunca fue la licencia, siempre se trató del acceso.

Cuando trabajaba en AWS, encuestamos a los desarrolladores  para preguntarles qué valoraban más en el liderazgo de código abierto. Podrías pensar que contribuir con código a proyectos de código abierto bien conocidos ocuparía el primer lugar, pero no fue así. Ni siquiera segundo o tercero. En cambio, el criterio número uno que los desarrolladores utilizaron para juzgar el liderazgo de código abierto de un proveedor de la nube fue que "facilita la implementación de mi software de código abierto preferido en la nube".

No estoy sugiriendo que las contribuciones no importen, pero no importan por las razones que podrías pensar. Una de las cosas que hicimos bien en AWS fue trabajar con los equipos de productos para ayudarlos a descubrir su propio interés en contribuir a los proyectos en los que estaban creando servicios en la nube, como Elasticache. No nos enfocamos en ganar elogios de "la comunidad" (la palabra más usada en exceso y menos definida en todo el código abierto), sino más bien en poner a los equipos de productos en una mejor posición para apoyar a los clientes. ¿Adivina qué? Funcionó. Aunque no es perfecto, una creciente población de equipos de productos de AWS está contribuyendo de manera significativa a los proyectos de código abierto.

Sin embargo, para los desarrolladores que usan esos servicios, el "código abierto" es una preocupación secundaria a "Me ayuda a ser más productivo, más rápido". Lo cual, de nuevo, no quiere decir que el código abierto no importe en nuestro mundo de software en la nube. El código abierto es una forma eficiente de unirse a los estándares, brindando a los desarrolladores (y empresas) un acceso más fácil a habilidades comunes e infraestructura común.

Pero no es el final, y los defensores del código abierto entre nosotros deben darse cuenta de esto. El objetivo del código abierto, de la nube, de las API abiertas, de una excelente documentación, etc., es permitir que los desarrolladores construyan con menos fricción y más oportunidades. ¿Es Llama 2 lo suficientemente abierto para que el 99,999% de la población de desarrolladores lo use con acceso ilimitado? Sí. ¿Es "código abierto"? La pregunta realmente no importa.