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

Por Matt Asay

Colaborador, InfoWorld |

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

Esto significa, por supuesto, que no es “código abierto” según la Definición de Código Abierto (OSD), a pesar de que Meta lo anuncia como tal. Esto hace que algunos defensores del código abierto griten, al estilo Rambo, “¡Ellos sacaron la primera sangre!” y “¡Nada ha terminado! ¡Nada! ¡Simplemente no lo apagues!”, insistiendo en que Meta deje de llamar a Llama 2 “código abierto”. Tienen razón, en cierto modo pedante, pero tampoco parecen darse cuenta de lo irrelevantes que son sus preocupaciones. Durante años, los desarrolladores han estado votando con sus repositorios de GitHub para elegir "lo suficientemente abierto". No es que el código abierto no importe, sino que nunca ha importado en la forma en que algunos esperaban o creían.

Hace más de 10 años, la tendencia hacia las licencias permisivas era tan pronunciada que el analista de RedMonk, James Governor, declaró: “Los [desarrolladores] más jóvenes hoy en día se dedican a POSS, es decir, al software de código abierto. [Al diablo] con la licencia y la gobernanza, simplemente comprométete con GitHub”. En respuesta, las personas en los comentarios se preocuparon y regañaron, diciendo que tendencias pasadas como ésta habían dado lugar a “clústeres épicos” o que “el intercambio promiscuo sin licencia conduce a enfermedades transmitidas por software”.

Y, sin embargo, millones de repositorios de GitHub sin licencia después, no hemos entrado en la era oscura de las licencias de software. El software de código abierto, o “suficientemente abierto”, ahora se encuentra en casi todo el software, sin embargo, termina teniendo licencia para el usuario final. ¿Ideal? Talvez no. ¿Pero una realidad de la vida? Sí.

En respuesta, GitHub y otros han ideado formas de atraer a los desarrolladores para que elijan licencias de código abierto para gobernar sus proyectos. Como escribí en 2014, todos estos movimientos probablemente ayudarán, pero la realidad es que tampoco importarán. No importarán porque el “código abierto” ya no importa. Al menos no como una furia contracultural contra la máquina de software corporativa. Todo esto me llevó a concluir que estamos en medio de la revolución post-código abierto, una revolución en la que el software importa más que nunca, pero sus licencias importan cada vez menos.

No tiene por qué gustarle esto, pero los datos que respaldan esta posición abundan en los repositorios de GitHub o en 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 utilizar el software.

Demasiados guerreros del código abierto piensan que la licencia es el fin, en lugar de simplemente un medio para otorgar un acceso prácticamente ilimitado al código. Continúan preocupándose por las licencias cuando los desarrolladores se preocupan principalmente por el uso, como siempre lo han hecho. Tenga en cuenta que, más que cualquier otra cosa, el código abierto amplía el acceso a software de calidad sin involucrar a los equipos de compras o (generalmente) legales. Esto es muy similar a lo que hizo la nube con el hardware. El punto nunca fue la licencia. Siempre se trató de acceso.

Cuando trabajaba en AWS, encuestamos a los desarrolladores para preguntarles qué valoraban más en el liderazgo del código abierto. Se podría pensar que contribuir con código a proyectos de código abierto conocidos ocuparía el primer lugar, pero no fue así. Ni siquiera el segundo o el tercero. En cambio, el criterio número uno que los desarrolladores utilizaron para juzgar el liderazgo de código abierto de un proveedor de 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ía pensar. Una de las cosas que hicimos bien en AWS fue trabajar con equipos de productos para ayudarlos a descubrir su propio interés en contribuir a los proyectos sobre los cuales estaban construyendo servicios en la nube, como Elasticache. No nos centramos en ganarnos el reconocimiento de "la comunidad" (la palabra más utilizada y poco definida en todo el código abierto), sino en poner a los equipos de producto 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 utilizan esos servicios, el “código abierto” es una preocupación secundaria después de “Me ayuda a ser más productivo y más rápido”. Lo cual, nuevamente, no quiere decir que el código abierto no importe en nuestro mundo de software en la nube, como ya he señalado. El código abierto es una forma eficiente de unir estándares, brindando a los desarrolladores (y a las empresas) un acceso más fácil a habilidades e infraestructura comunes.

Pero ese no es el final, y los Rambos de código abierto entre nosotros debemos darnos cuenta de ello. El objetivo del código abierto, de la nube, de las API abiertas, de una excelente documentación, etc., es permitir a los desarrolladores construir con menos fricciones y más oportunidades. ¿Llama 2 es lo suficientemente abierto para que el 99,999% de la población de desarrolladores lo utilice con acceso ilimitado? Sí. ¿Es “código abierto”? La pregunta realmente no importa.

A continuación lee esto:

Matt Asay dirige las relaciones con los desarrolladores en MongoDB. Las opiniones expresadas aquí son las de Matt y no reflejan las de su empleador.

Copyright © 2023 IDG Communications, Inc.