El equipo central de Ruby asume la propiedad de RubyGems y Bundler

• La propiedad de los repositorios de RubyGems y Bundler, los gestores de paquetes del lenguaje Ruby, se transfiere de Ruby Central al equipo central de Ruby
• Esta medida fue impulsada por Matz (Yukihiro Matsumoto) para garantizar la estabilidad a largo plazo y la continuidad de la comunidad
• RubyGems y Bundler seguirán manteniendo su licencia de código abierto, y también se respetarán íntegramente los derechos de autor y el historial de contribuciones de los colaboradores actuales
• La operación pasa a un modelo de gestión conjunta entre Ruby Central y el equipo central de Ruby, mientras se mantiene el desarrollo impulsado por la comunidad
• Se trata de una transición estructural para fortalecer el desarrollo sostenible y la integración del ecosistema Ruby, con implicaciones importantes para su estabilidad futura a largo plazo

---

La importancia de RubyGems y Bundler

• RubyGems es la herramienta central de gestión de paquetes del ecosistema Ruby, y Bundler es un componente esencial encargado de la gestión de dependencias y el despliegue
• Ambos proyectos son herramientas estándar incluidas en la distribución de Ruby y están estrechamente integrados con el lenguaje Ruby
• Sin embargo, hasta ahora RubyGems y Bundler habían sido administrados de forma independiente por Ruby Central, no por la organización oficial de Ruby, y
  aunque son componentes estándar del lenguaje Ruby, operaban en una organización separada en GitHub, lo que generaba una falta de coherencia estructural
• Por ello, el equipo central de Ruby decidió asumir oficialmente la administración y el mantenimiento de los repositorios
• El objetivo es asegurar la estabilidad a largo plazo del proyecto y su alineación con el ecosistema Ruby

Cambios principales

• La propiedad oficial de los repositorios se transfiere al equipo central de Ruby, pasando a un sistema de gestión conjunta con Ruby Central
• Las condiciones de la licencia de código abierto no cambian, y no hay cambios en la estructura comercial ni legal
• Se mantienen los derechos de propiedad intelectual y los derechos de autor de todos los colaboradores existentes, sin cambios en la propiedad del código
• Se seguirá manteniendo un modelo de desarrollo impulsado por la comunidad, abierto a contribuciones de cualquiera

Colaboración comunitaria y planes a futuro

• El equipo central de Ruby planea mantener un marco de colaboración continua con Ruby Central y desarrolladores de todo el mundo
• Esta medida se considera una base de largo plazo para mejorar la estabilidad y confiabilidad del ecosistema Ruby
• En su comunicado, Matz agradeció la dedicación de Ruby Central y mencionó: “Construyamos juntos un futuro más brillante para Ruby”

Implicaciones

• Esta transferencia es un hecho simbólico que reorganiza la infraestructura central del lenguaje Ruby dentro de la organización oficial
• Puede verse como un punto de inflexión para aumentar la sostenibilidad futura de Ruby mediante la integración del mantenimiento a nivel del lenguaje y la unificación del ecosistema

[GN⁺]

Comentarios de Hacker News

• Creo que esta decisión va en la dirección correcta; agradezco que Ruby Core y Matz den un paso al frente para aportar estabilidad a todo el lenguaje y a la comunidad.
  • Quiero enfatizar que Matz es realmente el eje central; creo que aquella frase de “Matz is nice and so we are nice” debería cambiarse por “amable y responsable”.
• A largo plazo, parece que tener varias fuentes como gem.coop sería una estructura más segura y robusta, pero en RubyGems la confianza quedó completamente rota a varios niveles (mantenedores, miembros de la comunidad, patrocinadores, etc.). También quedan pendientes problemas como el financiamiento y la privacidad de los datos. Aun así, parece que la mayoría de la comunidad Ruby apoyará este cambio.
  • ¿Alguien puede resumir qué fue lo que realmente pasó? No he seguido las noticias recientes de Ruby y me da curiosidad.
  • De acuerdo; ahora hay que ver un poco más cómo logra consolidarse gem.coop. Hicieron promesas sobre el futuro y probablemente al final entreguen resultados. Cuando abran la beta, estaría dispuesto a volver a subir al menos algunos de los gems que publiqué antes, los importantes. Hay cosas que deben mejorar, especialmente la documentación (también relacionada con la documentación de Ruby; el hecho de que esté separada es un problema). La falta de namespacing también es un problema (en Ruby no existe oficialmente, y eso es tanto una característica como un problema; creo que hace falta una forma de separar por áreas de interés). Me parece más realista volver a evaluarlo dentro de unos seis meses, a finales de mayo de 2026. Si DHH sigue publicando comentarios demoledores en su blog, la gente descontenta con gem.coop podría llegar y contribuir, lo que aumentaría sus beneficios. Desde el punto de vista del usuario, sería una situación win-win con más libertad y flexibilidad. Mucha gente seguirá en rubygems.org, pero también parece que crecerá la preferencia por gem.coop. También habrá quienes usen ambos (aunque eso es algo complicado, así que quizá gem.coop debería pensar en una función para elegir la fuente por gem). Hay mucho trabajo por hacer.
  • No puedo creer que un mantenedor inactivo todavía tuviera acceso root. Me sorprende que conservara aunque fuera cierto nivel de privilegios sobre una plataforma clave. Últimamente me ha impactado ver a miembros de la comunidad Ruby oponiéndose a estándares de seguridad modernos (y ya ampliamente adoptados), pese a que esto es una plataforma importante de la web. Ya no estamos en 2006, ni en la época de instalar solo Rails con un comando curl; la ingenuidad de esa reacción me parece alarmante. Me impacta que una postura de seguridad sin mantenimiento dejara todo expuesto a ataques a la cadena de suministro. Al menos ahora alguien por fin está prestando atención a la seguridad actual.
  • Sobre la afirmación de que varias fuentes son más seguras: creo que el área de ataque se triplica y puede haber más vulnerabilidades de seguridad.
  • Esto solo cambia el tooling de Ruby; rubygems.org en sí sigue siendo, dependiendo de a quién le preguntes, propiedad de una entidad hostil, así que dudo cuánto ayude esto realmente a restaurar la confianza.
• La postura de Ruby Central se puede ver aquí: https://rubycentral.org/news/ruby-central-statement-on-rubygems-bundler/
  • Como referencia, también conviene ver la declaración anterior del 19 de septiembre, que incluye la idea de un “compromiso compartido con la estabilidad y el crecimiento a largo plazo del ecosistema Ruby”: https://rubycentral.org/news/strengthening-the-stewardship-of-rubygems-and-bundler/
• Agradezco profundamente que Matz haya mostrado liderazgo directo en una situación difícil. Como desarrollador japonés, me preocupaba mucho hacia dónde iba todo esto, y este anuncio me deja más tranquilo.
  • Tengo curiosidad por saber en qué consistió exactamente ese liderazgo. Siempre estuvo claro que Hiroshi Shibata no actuaba por su cuenta de forma unilateral. Sospecho que la decisión de asumir gem y bundler ya se había tomado internamente hace meses. En cuanto a la opinión de que esto tranquiliza a un desarrollador japonés, a mí me preocupa aún más. Vivo fuera de Estados Unidos y Japón, así que me incomoda y me molesta sentir que ambos países controlan demasiado el ecosistema Ruby (del lado japonés lo entiendo, porque es la comunidad local). Pero que la influencia de EE. UU. sea tan grande también me parece excesivo. Me pasa lo mismo con Python, y eso me desagrada.
• Creo que cualquiera que haya tocado Ruby aunque sea un poco considerará que este resultado no deja a nadie inconforme.
  • Yo creo que la única beneficiada es Ruby Central. No cedió nada y, al contrario, obtuvo el respaldo oficial de Ruby Core para ser reconocida como mantenedora de RubyGems. La propiedad del repositorio se transfirió, pero Ruby Central mantiene la responsabilidad operativa y de gobernanza en estrecha colaboración con Ruby Core. Andre tiene la marca registrada de Bundler y ya dijo que la hará valer contra Ruby Central: https://andre.arko.net/2025/09/25/bundler-belongs-to-the-ruby-community/. Ruby Central entrega la propiedad de Bundler a Ruby Core y sigue a cargo del mantenimiento, mientras que Ruby Core queda expuesta al riesgo legal. Si Andre demanda, se enfrentará a Ruby Core en Japón y la imagen empeorará aún más.
  • La gente sigue sin estar inconforme solo porque Matz todavía no ha opinado sobre temas sociales como las leyes migratorias.
  • Quisiera cuestionar de verdad eso de que nadie está inconforme.
  • Me pregunto por qué supuestamente nadie está inconforme; creo que siguen quedando muchísimas preguntas. La clave será ver qué tanta popularidad logra gem.coop en adelante (si de verdad llega a crecer). Quizá habría sido mejor crear una nueva forma de instalar proyectos Ruby, como en el caso de Rust + cargo, pero creo que conviene separar al proveedor del servicio de la discusión real de desarrollo. La realidad de que existan tanto los binarios gem como bundle no me parece ideal. Creo que debería haber una sola API unificada (o, alternativamente, una API simple mantenida por ruby core y que cada quien desarrolle libremente las funciones extra). Al final, muchos proyectos corren el riesgo de terminar como en la viñeta de xkcd. Me gustaba la simplicidad de bin/gem, y Bundler solo añadía algunas funciones de conveniencia. Sería bueno que el comando gem permitiera especificar fácilmente varias fuentes, incluida gem.coop.
• Estoy de acuerdo en que Ruby Core es una mejor opción que Ruby Central, pero sigo con curiosidad sobre qué fue exactamente todo este incidente, y la imagen general del ecosistema Ruby se me ha vuelto algo borrosa.
  • Normalmente desarrollo sobre todo en Go y en varios otros lenguajes. Siento que la naturaleza distribuida del ecosistema de paquetes de Go es una gran ventaja (aunque claro que también tiene desventajas). Me intriga por qué, pese a la repetición constante de crisis de cadena de suministro en NPM y otros ecosistemas de paquetes públicos, no vemos más descentralización o experimentos liderados por la comunidad.
• He estado esperando esta decisión porque me parecía la opción más simple y la más capaz de restaurar la confianza. Sigo creyendo que los líderes de buena fe salvan a las comunidades.
• He seguido esto con interés, casi como ver un drama reciente. Lamento lo ocurrido por las personas perjudicadas dentro de la comunidad Ruby. Y, por último, creo que Matz es lo máximo.
  • Me pregunto si todo esto empezó por una animadversión hacia DHH. Da la impresión de que quizá se podría haber hecho un fork de rubygems.org e implementar por cuenta propia las mejoras necesarias de seguridad y gobernanza. En un caso así, me pregunto si desde la perspectiva del código abierto el camino estándar para resolver el conflicto no sería precisamente un fork.
• La forma de actuar de Matz y su manera de hacer el anuncio me parecieron realmente impresionantes y dignas de respeto. Me recordó lo que significa la verdadera grandeza.
  • Me molesta que solo se haya cuidado a Ruby Central, que fue la parte agresiva, y no se haya agradecido a los mantenedores anteriores que contribuyeron durante años.
  • No mencionar cómo fue que el proyecto terminó pasando al lado de RC (Ruby Central) hace que todo este proceso parezca embellecido.
• Me gustaría que alguien explicara brevemente este asunto desde la perspectiva de un externo.
  • Conviene revisar este hilo: https://news.ycombinator.com/item?id=45299170#45300774, especialmente el resumen de Mike McQuaid, que ayuda mucho. Cumplió un papel de mediación y apoyo a la comunicación, y también vale la pena ver sus publicaciones recientes en redes: https://bsky.app/profile/mikemcquaid.com
  • El propietario cambió varias veces, y los detalles del proceso nunca fueron transparentes. La tensión dentro de la comunidad aumentó, y una de las figuras más visibles y ruidosas tenía un estilo de expresar opiniones impopulares pero muy firmes, lo que hizo crecer el conflicto.
  • Siento que nadie logra explicarlo con claridad; es una situación confusa y sin respuesta.