El dato que expone el futuro del open source con IA

En pocas palabras: El open source no muere, cambia de función: pasa de medirse en descargas a servir como referencia canónica para entrenar y auditar agentes de IA. El caso Truss (24.000 instalos, 281 estrellas al 21/9/2026) expone esa mutación en el rol del mantenedor.

Truss, un paquete Laravel para diagramas ER en vivo, tiene 24.000 instalaciones en Packagist y solo 281 estrellas en GitHub al 21 de septiembre de 2026: una relación de casi 85 a 1 que expone cómo los agentes de IA generan código sin que nadie visite el repositorio.

El futuro del open source describe el debate sobre si el software de código abierto sigue teniendo sentido cuando un agente de IA arma código funcional en segundos, sin que nadie instale el paquete, lea el README ni sepa quién lo escribió. El concepto abarca tanto la caída de instalaciones visibles como el rol que cumplen los repositorios públicos al entrenar los modelos que ahora reemplazan esa instalación.

¿Cuántas instalaciones de paquetes open source generan los agentes de IA sin dejar rastro?

Truss, el paquete Laravel que mantiene Alberto Arena para generar un diagrama ER en vivo del esquema real de una base de datos (estructura, nunca datos), pasó los 24.000 instalos en Packagist mientras acumulaba apenas 281 estrellas en GitHub al 21 de septiembre de 2026, según detalló el propio autor en su artículo en Dev.to. Eso da casi 85 instalaciones por cada estrella.

Ojo con esto: esa brecha ya estaba ahí antes de que un agente tocara el código (spoiler: las estrellas nunca midieron uso real, midieron visibilidad). Lo que cambió es que ahora nadie necesita ni siquiera pasar por Packagist para terminar usando la misma lógica que hay en el repositorio.

Ejemplo hipotético para entender la mecánica: imaginemos un paquete de validación de formularios con 500 estrellas y 3.000 descargas mensuales antes de la masificación de agentes. Un desarrollador que hoy necesita esa misma validación no busca el paquete: le pide al agente “necesito validar un email con reglas RFC 5322 y devolver un mensaje de error en español”, y el agente le arma el snippet sin mencionar de dónde salió el patrón. Si ese snippet reproduce casi textual la lógica del paquete original, las descargas del proyecto bajan aunque su código siga circulando, solo que invisible para cualquier métrica de Packagist o npm. El mantenedor de ese paquete hipotético vería caer sus números sin poder saber si es porque nadie lo usa o porque todos lo usan a través de un intermediario que no deja rastro.

¿Y eso qué significa para alguien que evalúa si un proyecto está vivo? Que contar estrellas o forks como termómetro de adopción da cada vez menos información.

¿Los agentes de IA le quitan visibilidad a los mantenedores de código abierto?

Sí, según el caso pesimista que plantea Arena: si un agente reconstruye el 80% útil de un paquete a partir de un prompt de dos líneas, la mayoría de la gente nunca se entera de que el proyecto existe, y mucho menos lo estrella. Menos estrellas significan menos motivación para seguir, y eso deriva en fixes más lentos y documentación más vieja.

Tim Hoffmann, mantenedor de matplotlib, lo puso en términos de costos en GitHub el 11 de febrero de 2026: “los agentes cambian el balance de costos entre generar código y revisarlo. La generación vía agentes de IA se automatiza y se vuelve barata, así que el volumen de código que entra aumenta, pero la revisión sigue siendo una tarea manual humana, que recae sobre los hombros de unos pocos desarrolladores principales”.

Hay un dato que complica todavía más el panorama. Roo Code, la herramienta sobre la que bastante gente armó flujos de trabajo reales, cerró y archivó su repositorio en mayo de 2026. ¿Y qué pasa cuando el equipo que creyó escaparse de depender de un mantenedor termina dependiendo de otra empresa con fecha de vencimiento? Exacto: termina en el mismo lugar, solo que sin los años de historia detrás.

¿Por qué los agentes de IA todavía necesitan proyectos open source para entrenar?

Porque el agente no inventó el patrón de la nada: lo aprendió leyendo millones de repositorios reales, el README, el test suite, el issue donde alguien explicó por qué el enfoque ingenuo se rompe. Si nadie sigue escribiendo ese material en público, el agente no se pone más inteligente, se queda viejo repitiendo bugs de hace un año.

Subís el paquete, lo mantenés dos años, alguien reporta un bug raro, otro lo replica, vos lo arreglás y explicás por qué en el changelog, un tercero lee esa explicación y ajusta su propio código, y todo ese intercambio, público y gratuito, es la materia prima que un modelo absorbió para poder resolverte el mismo problema en treinta segundos.

Matar el incentivo para publicar envenena la fuente de la que toma agua cada agente. No afecta solo a los mantenedores que dejan de recibir un “esto me salvó horas” en los comentarios.

¿El open source va a desaparecer por la inteligencia artificial?

No hay evidencia de que desaparezca, pero sí de que cambia de trabajo. El futuro del open source no parece ser ni el funeral ni el “no cambia nada”: parece un cambio de rol, donde el código público deja de ser el producto final y pasa a ser la referencia contra la que se mide la respuesta de un agente, lo haya instalado alguien o no.

Alguien tiene que seguir escribiendo la versión canónica de un patrón, correctamente, en público, para que el agente haya aprendido de ahí y para que quien audite su output tenga con qué compararlo. Ese rol no viene con contador de estrellas ni crédito visible, pero pesa más ahora que cuando la gente clickeaba “clone”.

Si nadie vuelve a instalar tu paquete porque el agente ya aprendió el patrón, ¿seguís siendo vos quien lo escribió? Arena no tiene una respuesta prolija para esa pregunta. Nosotros tampoco.

¿Qué cambia en la práctica para los mantenedores de código abierto?

Cambia la métrica que importa. Si históricamente un proyecto se medía por estrellas y descargas, esas cifras dicen cada vez menos sobre el uso real, porque una parte del uso ahora pasa por un agente que nunca toca el repositorio.

Tres criterios concretos para chequear si un proyecto sigue vivo más allá de la estrella y la descarga:

• Búsqueda de menciones textuales: buscar en GitHub código o issues de otros repositorios que citen el nombre del paquete o reproduzcan funciones puntuales con nombres de variables idénticos, señal de que el patrón se copió aunque nunca se haya instalado la dependencia.
• Forks con actividad reciente versus forks abandonados: un fork con commits propios en los últimos meses indica que alguien sigue construyendo sobre esa base, aunque no aparezca en el contador de descargas del paquete original.
• Referencias en documentación de terceros: revisar si blogs técnicos, foros o repositorios de ejemplos citan el proyecto como fuente del patrón, incluso sin linkearlo como dependencia instalable.
• Comparar la curva de issues con la curva de descargas: si las descargas caen pero siguen entrando reportes de bugs específicos del comportamiento del paquete, es indicio de que el código circula fuera del canal oficial.

Ninguno de estos cuatro puntos reemplaza a las estrellas de forma prolija ni da una cifra única, pero juntos arman una foto menos incompleta que mirar solo el contador de Packagist o npm.

Errores comunes al leer el impacto de un proyecto open source en la era de los agentes

• Medir el éxito solo por estrellas de GitHub: el caso de Truss muestra una relación de 85 instalos por estrella, así que un proyecto con pocas estrellas puede tener uso masivo igual.
• Asumir que menos descargas significa proyecto muerto: puede que el código se siga usando vía agente sin que eso aparezca en el contador de Packagist o npm.
• Pensar que el agente inventó el código de la nada: el patrón salió de un repositorio real, con años de issues y pull requests detrás que nadie ve en el resultado final.
• Delegar toda la dependencia técnica en la herramienta del agente sin plan B: el archivado de Roo Code en mayo de 2026 mostró que esas herramientas también tienen roadmap propio y fecha de vencimiento.

Preguntas Frecuentes

¿Los agentes de IA van a reemplazar al software open source?

No lo reemplazan como base de conocimiento, pero sí como punto de contacto directo: cada vez más gente resuelve un problema con un agente sin pasar por el repositorio original. El código abierto sigue siendo necesario porque el agente aprendió de él, aunque el usuario final nunca lo vea.

¿Por qué bajan las instalaciones de paquetes open source por la IA?

Bajan porque un agente puede reconstruir el 80% útil de un paquete a partir de un prompt corto, sin que el usuario tenga que buscar, instalar ni citar el proyecto original. El caso de Truss, con 24.000 instalos y solo 281 estrellas al 21 de septiembre de 2026, muestra que la relación entre uso y visibilidad ya venía desbalanceada antes de los agentes.

¿Qué pasa con los mantenedores de código abierto si la IA genera el código?

Pierden el único incentivo que tenían de forma confiable: la visibilidad de descargas y estrellas. Tim Hoffmann, mantenedor de matplotlib, señaló en febrero de 2026 que el volumen de código generado por agentes aumenta, pero la revisión sigue recayendo en pocos desarrolladores humanos, lo que suma carga sin sumar reconocimiento.

¿Los modelos de IA necesitan que siga existiendo el open source?

Sí, porque aprendieron a generar código leyendo millones de repositorios públicos reales, con sus README, tests e issues. Si el open source de calidad deja de renovarse, los modelos empiezan a reproducir patrones y bugs desactualizados en vez de aprender soluciones nuevas.

¿Qué es Truss y qué muestra sobre el open source frente a la IA?

Truss es un paquete Laravel que genera un diagrama ER en vivo del esquema real de la base de datos de una app, solo estructura, nunca datos. Al 21 de septiembre de 2026 tenía más de 24.000 instalaciones en Packagist y 281 estrellas en GitHub, una relación que su mantenedor usa como evidencia de que el reconocimiento visible ya no refleja el uso real de un proyecto.

Conclusión

Lo que cambió no es que el open source haya dejado de servir, sino que dejó de medirse bien con las métricas de siempre. Truss con sus 24.000 instalos y 281 estrellas, Roo Code archivado en mayo de 2026, la queja de Tim Hoffmann sobre la carga de revisión: todo apunta a un mismo movimiento, el valor se corre de la descarga visible hacia la referencia que el agente usó para aprender.

Para quien mantiene un proyecto, la conclusión práctica es dejar de mirar solo estrellas y descargas como termómetro y empezar a rastrear menciones textuales, forks activos y referencias en documentación de terceros, aunque nadie lo instale de forma directa. Para quien usa agentes para generar código, vale la pena acordarse de que ese código salió de algún lado, y que si ese algún lado deja de existir, el agente también se queda sin de dónde aprender lo nuevo.

Fuentes

• Will Open Source Survive the Agents That Replaced It? – artículo original de Alberto Arena en Dev.to