Actualmente estamos viviendo los puntos de fricción de un cambio que lleva décadas gestándose, pero que, lamentablemente, se ha acelerado de forma drástica bajo la presión de la IA generativa. Durante años, la industria ha operado sobre la base de un mito cómodo y perezoso: que el software de código abierto es un bien público infinito y autorrenovable que no cuesta nada consumir y que no requiere nada para sostenerse.
Las conversaciones que tuvieron lugar durante el Future of Software Engineering Retreat, celebrado en Suiza a finales de junio de 2026, mostraron una realidad mucho más fragmentada y urgente. La realidad que debemos afrontar es que el código abierto no está simplemente atravesando una evolución; está siendo desgastado por el agotamiento estructural y la industrialización de la generación de código.
La economía del agotamiento y la falacia del costo cero
En el centro de la crisis actual existe un malentendido fundamental entre la fijación de precios de los activos y el costo humano. Existe un argumento económico que se escucha con frecuencia y que sostiene que el precio de un activo digital debería tender hacia el costo marginal de su distribución, que en la práctica es cero. Por lo tanto, si copiar una biblioteca no cuesta nada, el software, en teoría, debería ser gratuito.
Pero esta elegante teoría oculta el trabajo humano que está en el centro de todo esto. Aunque la distribución no cuesta nada, el mantenimiento es increíblemente costoso. Quienes mantienen paquetes críticos de código abierto, esos pilares invisibles que sostienen la banca digital moderna, la infraestructura en la nube y las plataformas empresariales, están sufriendo agotamiento y enfrentando acoso psicológico por parte de entidades multimillonarias que consumen su trabajo sin aportar ni un solo centavo a cambio.
Como colectivo, hemos confundido las licencias permisivas con una licencia para explotar. Desde el auge de la nube, quienes defendían el código abierto promovieron las licencias MIT y Apache como la máxima victoria para la adopción del software. Sin embargo, este régimen permisivo se convirtió en la base sobre la que enormes corporaciones construyeron imperios propietarios, envolviendo el código abierto con una ligera capa de orquestación y capturando valor económico mientras devolvían muy poco al ecosistema. Es un sistema de patrocinio para unos pocos afortunados y un estado de bienestar basado en la caridad para el resto. Esto es fundamentalmente insostenible.
Dos presiones: pull requests basura y una confianza en declive
Si la economía estructural del código abierto ya era frágil, la introducción de herramientas automatizadas ha convertido una condición crónica en una situación aguda.
Quienes mantienen estos proyectos se enfrentan ahora a un ataque en dos frentes.
La industrialización del contenido basura
La barrera de entrada para generar código se ha reducido a cero. Aunque esto empodera a las personas, también ha inundado las puertas de entrada de los repositorios con un volumen alarmante de pull requests de baja calidad generados por IA. Quienes antes dedicaban su tiempo a escribir código ahora se ven obligados a convertirse en revisores de código no remunerados a tiempo completo, examinando contribuciones automatizadas de personas que buscan convertir sus portafolios en un juego.
Esto crea un círculo vicioso. La carga psicológica, e incluso emocional, a veces obliga a quienes mantienen los proyectos a cerrarlos por completo a las contribuciones públicas. Esto interrumpe involuntariamente el acceso de la próxima generación de mantenedores legítimos que, con el tiempo, heredarían y sostendrían el proyecto.
Los cambios radicales en el panorama de la confianza
Ya no se puede confiar en las métricas tradicionales de credibilidad del código abierto. El plazo necesario para que un proyecto alcance la madurez se ha desplomado; algunas bibliotecas alcanzan decenas de miles de estrellas en GitHub en cuestión de semanas, impulsadas por el entusiasmo viral en torno a los agentes de IA, a pesar de contar con un historial de commits de apenas tres semanas.
Ahora también resulta increíblemente barato crear pull requests maliciosos. Los agentes encuentran nuevos vectores de ataque cada día, lo que dificulta que quienes mantienen los proyectos realicen el trabajo que hace posible la confianza. En conjunto, el modelo de confianza del código abierto se ha deteriorado gravemente y no existen salidas sencillas a este dilema.
La paradoja de las licencias: de la libertad a la explotación
La fragilidad estructural de la ingeniería de software moderna está estrechamente vinculada con los marcos legales que diseñamos para protegerla. Nuestros modelos actuales de licencias han creado involuntariamente una economía de extracción, lo que obliga a realizar una reevaluación crítica de las filosofías fundamentales que separan las licencias de código abierto “permisivas”, como MIT y Apache, de los acuerdos copyleft, como la GPL.
El consenso histórico promovía las licencias permisivas como el catalizador definitivo para la adopción generalizada del software. Al reducir la fricción y eliminar las barreras de cumplimiento, licencias como MIT y Apache permitieron que el código se difundiera a escala mundial.
Sin embargo, la distribución sin fricciones se convirtió en un arma de doble filo. Una persona participante en el retiro señaló que las licencias permisivas fueron un profundo error colectivo, ya que funcionaron como un mecanismo legal que permitió a las corporaciones más grandes del mundo apropiarse del trabajo voluntario y transformar a quienes mantenían proyectos independientes en colaboradores no remunerados de pilares fundamentales de infraestructuras empresariales valoradas en miles de millones de dólares.
La alternativa son los modelos de licencias restrictivas o dobles. Estos introducen un conjunto completamente diferente de fallos operativos:
El cuello de botella de las adquisiciones. Intentar proteger el código mediante cláusulas de uso no comercial o de “uso gratuito para aficionados” suele significar una sentencia de muerte para la adopción de un proyecto. Un profesional compartió que restringir un proyecto a usos no monetizados paralizó por completo su crecimiento. Los desarrolladores corporativos abandonaron la herramienta, no porque careciera de utilidad, sino porque el cambio de licencia activó complejos procesos empresariales de revisión de adquisiciones y trámites administrativos que los ingenieros simplemente se negaron a gestionar.
El boicot corporativo. Incluso cuando los límites de las licencias dobles se calibran cuidadosamente, como ocurrió con la transición de Akka a una licencia dirigida a organizaciones con ingresos superiores a 100 millones de dólares, las empresas suelen optar por el boicot en lugar del cumplimiento. En uno de los casos citados, una empresa decidió explícitamente abandonar una dependencia crítica que podía pagar fácilmente, únicamente para evitar sentar el precedente de pagar a la comunidad de código abierto.
La carga de hacer cumplir la licencia. Para algunas personas puristas, cualquier restricción de licencia introduce una responsabilidad administrativa. Desde esta perspectiva, añadir restricciones comerciales obliga a quien mantiene el proyecto a convertirse en responsable de hacer cumplir la licencia, transformando un acto de expresión creativa en una tarea legal.
Eludir las restricciones mediante la reimplementación del software. Esto no solo resulta éticamente cuestionable, aunque algunas personas podrían no estar de acuerdo, sino que también plantea problemas prácticos: la reimplementación requiere tiempo y dinero y puede introducir nuevos problemas de seguridad o fiabilidad.
En gran medida, la industria ha eliminado la distinción entre software que es libre para ser modificado y software que es gratuito en el momento de su consumo, lo que suele describirse como la diferencia entre “cerveza gratis” y “libertad de expresión”.
La definición de código abierto surgió originalmente precisamente porque se consideraba que el software libre tradicional no era lo suficientemente favorable para las empresas. Al optimizarlo completamente para facilitar su uso empresarial, hemos llegado a un escenario en el que el patrocinio corporativo se considera una obra benéfica opcional en lugar de una obligación estructural fundamental.
Esta crisis se agrava por el costo emocional y psicológico que recae sobre quienes mantienen los proyectos e intentan corregir el rumbo. Cuando un proyecto importante adopta un cambio defensivo de licencia, la respuesta de la comunidad suele ser hostil. Quienes mantienen los proyectos enfrentan graves represalias reputacionales y psicológicas por parte de los mismos ecosistemas a los que apoyaron durante años. El resultado es un entorno en el que cambiar una licencia se considera un acto de agresión, mientras que explotarla se considera simplemente una práctica empresarial habitual.
El colapso del ecosistema y la crisis de incentivos para quienes mantienen los proyectos
Hemos llegado a un punto en el que el ecosistema podría colapsar. Los incentivos para mantener proyectos están desapareciendo y las presiones más amplias de la industria sobre los puestos de trabajo dificultan que incluso los desarrolladores de software más motivados y entusiastas participen en el código abierto.
La ‘tragedy of the commons’, que describe el fenómeno de un recurso público que se agota debido a que actores motivados por sus propios intereses extraen recursos de él, es un concepto que suele citarse en estos debates. A primera vista, este parece ser un excelente ejemplo de la idea llevada a la práctica.
Sin embargo, aunque el concepto resulta útil, aplicado en este contexto no tiene en cuenta ni ilustra la asimetría existente. En primer lugar, si el software de código abierto es algún tipo de bien común, no se trata de un recurso natural del que cualquiera pueda disponer y extraer algo; es algo que personas construyen y mantienen únicamente con un espíritu comunitario. En segundo lugar, el proceso de extracción está ocurriendo a una escala asombrosa por parte de actores que tienen incentivos comerciales inmediatos.
Mientras que las etapas anteriores del código abierto se sostuvieron, en términos generales, gracias a la sensación de que existía una comunidad de desarrolladores y un sistema de beneficio mutuo, la economía actual del software hace que el valor se extraiga y capture rápidamente, sin ningún mecanismo que permita devolverlo al ecosistema que originalmente lo hizo posible.
La especificación frente al código: ¿hacia dónde vamos ahora?
Como consecuencia de todas estas presiones, estamos observando la aparición de una tesis radical: ¿es la especificación, en lugar del código, el futuro del código abierto?
Con LLM capaces de generar código especializado bajo demanda, los equipos de ingeniería empresarial están empezando a cuestionar la utilidad de incorporar dependencias externas enormes, compuestas por miles de líneas. Si utilizar una biblioteca externa introduce un riesgo inmanejable para la cadena de suministro y un ciclo interminable de correcciones, resulta económicamente lógico utilizar IA para reimplementar únicamente los fragmentos funcionales precisos que se necesitan, dentro de una “burbuja de seguridad” local.
- El modelo “tradicional” → consumir una biblioteca de código externa → heredar el riesgo de la cadena de suministro y el mantenimiento
- El modelo emergente → estudiar una especificación o idea abierta → reimplementación local generada por IA
Sin embargo, esta tesis de la “reimplementación” tiene sus límites. Para empezar, vale la pena señalar que muchas de las historias impresionantes sobre el uso de IA generativa en este ámbito se basaban en elementos que contaban con un conjunto de pruebas muy claro y detallado o con especificaciones muy claras.
Aunque una IA puede crear un generador sencillo de sitios estáticos en una hora, las tareas complejas de ingeniería, como las bibliotecas criptográficas o los frameworks de interfaz de usuario independientes del navegador, requieren un nivel extraordinario de rigor de ingeniería que los modelos automatizados no pueden reproducir de forma fiable sin terminar en un desastre absoluto.
Además, esto también priva de reconocimiento a la persona que creó la biblioteca de referencia. Es posible que esto no sea una prioridad para organizaciones con objetivos comerciales, pero si ese reconocimiento es la motivación de quien mantiene el proyecto, ¿qué ocurre cuando desaparece?
Abandonar completamente las bibliotecas de código compartido en favor de bases de código locales y fragmentadas corre el riesgo de crear una división elitista: por un lado, quienes cuentan con el hardware y el capital financiero necesarios para ejecutar arquitecturas locales de IA sofisticadas y, por otro, quienes se quedan sin ningún software.
Preguntas para ingenieros y arquitectos de software
Para desenvolverse en este panorama, los equipos de ingeniería deben dejar atrás el consumo pasivo y comenzar a plantearse preguntas más difíciles y deliberadas:
- ¿Cuál es la magnitud de nuestras dependencias? ¿Estamos importando una biblioteca externa de 20.000 líneas para resolver un problema que solo requiere 200 líneas de lógica? De ser así, ¿estamos preparados para asumir la responsabilidad del ciclo de vida de seguridad y mantenimiento de esa dependencia?
- ¿Cómo definimos nuestra relación con quienes mantienen los proyectos? Si nuestros sistemas de producción dependen de una herramienta de código abierto mantenida por una persona voluntaria o por un equipo muy pequeño, ¿cuál es nuestro mecanismo para devolverles algo de valor material? ¿Participamos activamente mediante patrocinio corporativo o actuamos como consumidores que esperan recibir gratuitamente soporte de nivel empresarial?
- ¿Dónde trazamos la línea entre la especificación y la ejecución? Para los próximos proyectos, ¿deberíamos recurrir al código abierto por sus patrones arquitectónicos y especificaciones o por sus archivos binarios concretos?
Orientación para los próximos meses
A medida que avanzamos hacia esta era agéntica, las organizaciones de ingeniería deberían adoptar una postura defensiva, pero sumamente intencional, respecto al código abierto:
Pasar del consumo pasivo a la responsabilidad activa. Traten cada dependencia de código abierto no como un obsequio gratuito, sino como código que, en la práctica, han incorporado a su organización. Si mañana la persona que mantiene el proyecto se retira o cierra los pull requests, su equipo debe ser capaz de auditar, corregir o crear internamente un fork de esa base de código.
Implementar auditorías rigurosas de la cadena de suministro. Dado el aumento del 400 % en las amenazas a la cadena de suministro durante los primeros años de la década de 2020 y la realidad de los ataques de ingeniería social a largo plazo, dependan menos del “número de estrellas” o de la antigüedad reciente de un proyecto. Implementen entornos de pruebas automatizados y aislados, verifiquen el origen de los paquetes y establezcan registros internos estrictos en lugar de obtenerlos directamente de repositorios públicos que no hayan sido verificados.
Formalizar un presupuesto de contribución y patrocinio para el código abierto. Si su empresa utiliza software abierto para generar ingresos, establezcan un proceso formal para financiar esos proyectos. Esto no es caridad corporativa; es una medida básica de mitigación de riesgos para evitar el agotamiento de las personas que mantienen viva la infraestructura subyacente.
El código abierto no va a desaparecer, pero la era de beneficiarse gratuitamente de software completamente permisivo, sin verificación ni patrocinio, está llegando a su fin.
Los equipos que sobrevivan y prosperen durante los próximos años serán aquellos que traten el código abierto con el respeto, el análisis crítico y el apoyo material que exige un verdadero pilar estructural.