Open source vs. agentes IA: US$8,8T en riesgo

La pregunta que vale 8,8 billones que el ecosistema no está respondiendo

"Un agente de IA puede reconstruir el 80% útil de tu paquete a partir de un prompt de dos frases". Lo escribe Alberto Arena, mantenedor del paquete Laravel Truss, en un ensayo publicado esta semana donde pone cifras a un debate que el open source viene esquivando: 281 estrellas en GitHub frente a 24.000 instalaciones en Packagist en su propio proyecto, una proporción de 85 instalaciones por cada persona que se molestó en darle una estrella. El gap no lo causaron los agentes; ya existía antes. Pero la pregunta que deja flotando es nueva: si nadie instala tu paquete porque el agente ya aprendió el patrón, ¿importa que tú lo hayas escrito?

El "funeral del open source" ya tiene cifras que lo respaldan

El 11 de febrero de 2026, Tim Hoffmann, mantenedor de matplotlib, dejó una advertencia en GitHub que hoy suena a profecía: "Los agentes cambian el balance de costos entre generar y revisar código. La generación se automatiza y se abarata, pero la revisión sigue siendo una actividad humana manual, cargada sobre los hombros de unos pocos desarrolladores principales".

El TechBrief de la Association for Computing Machinery's Technology Policy Council, publicado en septiembre de 2026 y firmado por autores como Simson Garfinkel y Josiah Dykstra, advierte que las herramientas de IA están aumentando la carga de revisión en proyectos open source mientras muchos carecen de financiamiento confiable. Entre abril y octubre de 2025, el agente CodeMender de Google envió 72 parches de seguridad a proyectos open source, algunos sobre bases de código de hasta 4,5 millones de líneas.

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

El problema no es solo el volumen, es la asimetría: si la generación se abarata, el cuello de botella se mueve al lado humano. Y el lado humano, en open source, no cobra.

La economía rota que ningún agente va a arreglar

Las cifras ayudan a dimensionar la fragilidad. La Linux Foundation reportó US$292.217.236 de ingresos en 2024. La Apache Software Foundation, citada en el TechBrief como ejemplo de proyectos sostenidos con trabajo voluntario y patrocinios, reportó US$2.379.402 en el mismo año: menos del 1% de la fundación más grande. En todo el open source, la mayoría de los usuarios nunca paga, el patrón clásico del free-rider problem.

Un paper de Harvard Business School citado por los autores estima que, sin open source, las empresas gastarían 3,5 veces más en software. El valor del open source del lado de la demanda, es decir, lo que las firmas globales se ahorran al poder reutilizarlo, se estima en US$8,8 billones a nivel mundial.

Pero ese valor no fluye de vuelta a los mantenedores. Fluye hacia las empresas que construyen productos sobre su trabajo. Cuando un agente replica un patrón aprendido de un README público, el crédito, el sponsor y el "saved me hours" no existen. La única moneda que un mantenedor recibía, la visibilidad, se evapora cuando nadie descarga.

El caso contra el funeral: los agentes también necesitan que sigamos publicando

El argumento contrario es incómodo porque tiene una arista de verdad. Ningún agente inventa el patrón desde cero: lo aprende leyendo millones de repositorios reales. El README, la suite de tests, el issue donde alguien explicó por qué el enfoque ingenuo rompe, el PR donde un mantenedor rechazó pacientemente una mala idea. Cada respuesta instantánea que entrega un agente es una repetición comprimida de trabajo que alguien hizo una vez, en público, y regaló.

Si nadie sigue escribiendo ese material en abierto, los agentes no se vuelven más listos, se vuelven obsoletos. Reproducirán con confianza los bugs de ayer y las buenas prácticas del año pasado, porque nadie quedó actualizando la fuente de la que aprendieron. Matar el incentivo de publicar envenena el pozo del que beben todos los agentes, y lastima más que a los propios mantenedores.

La ironía de "escapar de la dependencia" cambiando de dependencia

Parte de la euforia por "que el agente lo construya" viene de equipos que quieren dejar de depender de la hoja de ruta y el ánimo de un mantenedor externo. Pero las herramientas que construyen son, a su vez, productos de empresas con su propia hoja de ruta y mortalidad. El propio Arena cita el caso de Roo Code, una herramienta con flujos de trabajo reales construidos encima, cuyo repositorio fue archivado en mayo de 2026. El equipo que pensó que había escapado de depender de un extraño terminó dependiendo de otro extraño, con la misma mortalidad y sin los años acumulados.

El código generado por agentes también suele saltarse la parte que hacía confiable a un paquete open source maduro: años de casos límite resueltos por otros, changelogs con "probamos esto y lo revertimos porque", un segundo ingeniero discutiendo si la abstracción valía la pena. Funciona, hasta que toca exactamente el caso que nadie le preguntó al agente, y entonces lo debuggeas tú, sin los años de experiencia que explicarían por qué se rompió.

Qué significa esto para tu startup

La conclusión práctica no es "abandona los agentes", es "rediseña tu relación con el código que usas". Tres acciones concretas que un founder puede ejecutar esta semana:

Audita qué agentes entrenaron con qué. Antes de usar una dependencia crítica, verifica si existe como repositorio público vigente. Si el mantenedor original dejó de publicar, el patrón que el agente replica se va a degradar. El TechBrief de la ACM señala que la mayoría de las aplicaciones open source ni siquiera genera un SBOM (lista de componentes), así que el primer entregable de tu equipo debería ser uno.
Paga o contribuye a lo que tu stack crítico consume. Si dependes de un paquete específico, sponsorea al mantenedor o asigna a alguien de tu equipo a contribuir ar issues resueltos. Las cifras de la Linux Foundation y la Apache muestran que la infraestructura crítica del mundo se sostiene con ingresos que son una fracción del valor que genera. No esperes a que alguien se queme.
Diseña para la auditoría, no para la generación. Cuando integres código generado por agentes en producción, exige revisión humana sobre los caminos críticos. Hoffmann lo dijo claro: la revisión sigue siendo manual y humana. Construye un proceso donde la velocidad del agente se combine con la experiencia del senior engineer, no donde la reemplace.

Conclusión

El open source no va a morir, pero sí va a dejar de medirse por descargas y estrellas. Lo que queda es un trabajo menos visible y más estructural: alguien tiene que seguir escribiendo la versión canónica de cada patrón, correctamente, en público, para que el agente tenga algo honesto que aprender y para que quien audite su salida tenga con qué compararlo. Ese rol no trae contador de estrellas ni crédito visible, pero es quizás más decisivo que cuando la gente hacía clic en "clone".

La pregunta incómoda que Arena deja abierta, y que todo founder debería hacerse antes de pedirle a un agente que "simplemente lo construya", es esta: si nadie instala tu paquete porque el agente ya aprendió el patrón, ¿fueron tus 281 estrellas menos valiosas que los millones de líneas que entrenaron a un modelo que no te nombra?