Un desarrollador de Ruby archiva todos sus gems y explica por qué
Un desarrollador del ecosistema Ruby archivó el código fuente de todos sus gems y publicó una carta abierta para explicar la decisión. El motivo no es técnico ni económico: dice que ya no le interesa contribuir a un bien común que, en sus palabras, está siendo "minado a cielo abierto" por grandes corporaciones para alimentar a las mismas máquinas cuya producción automática lo contamina.
Para cualquier founder que tenga una app en Rails o dependa de librerías de código abierto, la nota es una señal de algo más grande: el mantenimiento humano del software que sostiene tu producto se está deteriorando, y la IA está acelerando ese proceso en lugar de compensarlo.
¿Qué argumenta exactamente el autor?
El texto arranca con una cita de Yukihiro Matsumoto ("Matz"), diseñador de Ruby, en un artículo del año 2000: para él, el propósito de la vida es tener alegría, y los programadores sienten alegría cuando pueden concentrarse en el lado creativo de programar. Por eso, decía, Ruby está diseñado para hacer felices a los programadores. En una entrevista de 2019 lo resumió distinto: "Diseñé Ruby para humanos, no para máquinas".
Leíste lo que hace la IA. ¿Y en tu negocio?
En CAR, dueños de empresa arman en 7 días su primer sistema funcionando: que ningún cliente se les escape, o que el informe del lunes salga solo. Con otros emprendedores al lado.
👥 Probar 7 díasEl autor sostiene que esa época pasó. Sus tres argumentos concretos:
- Rails está controlado por una sola persona. Aunque es software open source, dice que su dueño es alguien cuyas opiniones le resultan aborrecibles, y menciona que existe un esfuerzo en curso para bifurcarlo (hacer un fork). A partir del keynote de esa persona en Rails World, el autor concluye que ya no le interesa particularmente Ruby, Rails ni la programación en sí.
- El lenguaje Ruby se desarrolla hoy en buena medida con agentes LLM. Matz está dando charlas para reposicionar Ruby como un "Programming Language for AI age", pensado para que lo emitan agentes, y afirma que para lograrlo los LLM necesitan consumir más código Ruby de buena calidad escrito por humanos. El autor señala la contradicción evidente: si el código humano se usa como insumo para entrenar a los agentes que después lo reemplazan, el incentivo a escribirlo se desploma.
- La contribución voluntaria dejó de tener sentido para él. Su frase más dura: cuando se dice que ya no es sostenible escribir código a mano, no están del todo equivocados, pero solo en el mismo sentido en que no es sostenible dormir en una cama después de que alguien se hizo encima.
El cierre es un portazo: "¿Quieres cambios? Ve a pedirle a tu agente. Me dicen que eso es lo que se supone que debes hacer ahora. Yo me bajo".
Por qué el código abierto se está quedando sin mantenedores
El caso no es aislado. La Association for Computing Machinery publicó un análisis de seis autores, entre ellos Simson Garfinkel y Josiah Dykstra, que sostiene que las herramientas de IA están haciendo el código abierto más difícil de mantener y de asegurar (Help Net Security, septiembre de 2026). El argumento: los modelos escriben código y encuentran fallas de seguridad rápido, pero los mantenedores que deciden qué entra en la versión oficial de un proyecto siguen teniendo que juzgar ese output ellos mismos. Más volumen, misma capacidad humana de revisión.
Los números de sostenibilidad son el telón de fondo. Según la encuesta State of the Open Source Maintainer 2024 de Tidelift, citada por Business Standard, el 50% de los mantenedores encuestados dijo estar mal compensado o no recibir pago alguno; el 48% se sentía poco valorado o describía el trabajo como ingrato; el 43% dijo que el mantenimiento sumaba estrés personal; y el 60% había abandonado o considerado abandonar el trabajo de mantenimiento.
El mismo reporte señala que los mantenedores pagados tenían un 55% más de probabilidad que los no pagados de aplicar prácticas importantes de seguridad y mantenimiento. Es una asociación, no una prueba de causalidad, pero marca una dirección clara.
La asimetría de financiamiento es brutal. Según Help Net Security, la Linux Foundation recaudó US$292.217.236 en 2024, mientras que la Apache Software Foundation —descrita como ejemplo de proyectos que funcionan con trabajo voluntario y patrocinios— recaudó US$2.379.402, menos del 1% de esa cifra. La mayoría de los usuarios nunca paga: el clásico problema del free rider.
Y hay un dato que explica por qué esto te toca aunque no escribas una línea de Ruby: un paper de Harvard Business School citado en ese mismo análisis estima que las empresas gastarían 3,5 veces más en software si no existiera el código abierto.
¿Qué pasa cuando una dependencia queda abandonada?
El reporte Open Source Security Signals: Q3 2026 de IBM y Red Hat, publicado el 15 de octubre y reseñado por Business Standard, pone el foco en la parte incómoda: arreglar la vulnerabilidad en el código es solo la mitad del trabajo. La otra mitad es identificar qué sistemas están afectados, probar las actualizaciones e instalarlas.
El reporte modela un escenario hipotético con JAXB, una herramienta para intercambiar datos en XML: estima que 285.000 de tres millones de aplicaciones Java en producción podrían usar una versión potencialmente vulnerable, y que resolver el problema por separado requeriría 5,7 millones de horas de ingeniería y costaría US$712,5 millones. Son estimaciones, no pérdidas reales, pero dimensionan el problema.
También cita investigación según la cual las vulnerabilidades de severidad alta y crítica en aplicaciones y APIs tardaban en promedio 54,81 días en corregirse, y otro estudio que encontró una vida media de remediación de 358 días para vulnerabilidades de terceros detectadas por análisis de composición de software.
El punto para un founder: cuando un mantenedor se baja, el reloj de esos 54 o 358 días empieza a correr sin que nadie lo esté mirando.
Qué significa esto para tu startup
Si tu producto corre sobre Rails, Node, Python o cualquier stack con dependencias abiertas, el retiro de un mantenedor no es una anécdota de la comunidad: es riesgo operativo y de seguridad en tu roadmap.
Acciones concretas que puedes tomar esta semana:
- Haz un inventario real de dependencias. Genera un SBOM (lista legible por máquina de los componentes de tu aplicación). El análisis de la ACM advierte que, pese a los mandatos de EE. UU. y la UE, la gran mayoría de las aplicaciones open source no lo generan ni lo distribuyen. Un SBOM te muestra qué hay dentro; no te dice si cada pieza está mantenida, financiada o abandonada, pero es el punto de partida obligatorio.
- Marca tus dependencias críticas y revisa su pulso. Para cada librería de la que dependa tu facturación o tu autenticación, mira la fecha del último commit, si hay issues sin responder y si el proyecto tiene financiamiento. Un gem o paquete sin actividad en meses es un pasivo, no un activo.
- Presupuesta el mantenimiento, no solo el uso. Si tu empresa factura sobre un componente abierto, donar, pagar soporte o asignar horas de tu equipo a contribuir es más barato que asumir el costo de un parche que nunca llega. El dato de Tidelift sobre mantenedores pagados y mejores prácticas de seguridad apunta en esa dirección.
- No asumas que "open source" equivale a "mantenido para siempre". El caso de este desarrollador de Ruby es la versión extrema de algo cotidiano: proyectos que sobreviven gracias al entusiasmo de una sola persona, y que se apagan cuando ese entusiasmo se apaga.
La pregunta de fondo para el ecosistema
El autor de la carta no pide que nadie deje de usar sus gems: pide que quede claro que ya no los mantiene. Eso, en sí mismo, es un acto de honestidad poco frecuente en un ecosistema donde muchos proyectos abandonados siguen pareciendo vivos.
La tensión que describe —código humano como insumo para entrenar agentes que luego lo reemplazan— no se resuelve con una herramienta. Se resuelve con decisiones: quién paga el mantenimiento, quién revisa lo que generan los modelos y qué pasa cuando la persona que sostenía una pieza crítica decide que ya no le hace feliz hacerlo. Para un founder, entender ese mapa antes de que se rompa algo es la diferencia entre un incidente y una crisis.
Fuentes
- I no longer care to work on any Ruby gems so I've archived all my repositories (fuente original)
- AI is adding to the review load on open-source projects, many of them thinly funded — Help Net Security
- AI makes finding open source flaws easier, so why fixing them remains hard — Business Standard
Leíste lo que hace la IA. ¿Y en tu negocio?
En CAR, dueños de empresa arman en 7 días su primer sistema funcionando: que ningún cliente se les escape, o que el informe del lunes salga solo. Con otros emprendedores al lado.
👥 Probar 7 días
