L’équipe cœur de Ruby reprend la propriété de RubyGems et Bundler

• La propriété des dépôts de RubyGems et Bundler, les gestionnaires de paquets du langage Ruby, est transférée de Ruby Central à l’équipe cœur de Ruby
• Cette décision, menée sous l’impulsion de Matz (Yukihiro Matsumoto), vise à garantir la stabilité à long terme et la continuité de la communauté
• RubyGems et Bundler conservent leurs licences open source en l’état, et les droits d’auteur ainsi que l’historique des contributions des contributeurs existants restent pleinement respectés
• Le mode de gouvernance évolue vers une gestion conjointe entre Ruby Central et l’équipe cœur de Ruby, tout en maintenant un développement piloté par la communauté
• Il s’agit d’une transition structurelle destinée à renforcer le développement durable et l’intégration de l’écosystème Ruby, avec des implications importantes pour sa stabilité à long terme

---

Importance de RubyGems et Bundler

• RubyGems est l’outil central de gestion de paquets de l’écosystème Ruby, et Bundler est un composant essentiel chargé de la gestion des dépendances et du déploiement
• Les deux projets sont des outils standard inclus dans la distribution Ruby et sont étroitement intégrés au langage Ruby
• Pourtant, jusqu’à présent, RubyGems et Bundler étaient gérés indépendamment par Ruby Central, et non par l’organisation Ruby elle-même
  alors même qu’ils constituent des composants standard du langage Ruby, ils étaient exploités dans une organisation distincte sur GitHub, ce qui créait un manque de cohérence structurelle
• L’équipe cœur de Ruby a donc décidé de reprendre officiellement les droits de gestion et de maintenance des dépôts
• L’objectif est d’assurer la stabilité à long terme du projet et son alignement avec l’écosystème Ruby

Principaux changements

• La propriété officielle des dépôts est transférée à l’équipe cœur de Ruby, avec un passage à un modèle de gestion conjointe avec Ruby Central
• Les conditions des licences open source restent inchangées, sans modification de la structure commerciale ou juridique
• Les droits de propriété intellectuelle et les droits d’auteur de tous les contributeurs existants sont intégralement conservés, sans changement de propriété du code
• Le modèle de développement piloté par la communauté est maintenu, et chacun peut continuer à contribuer

Coopération communautaire et suite des plans

• L’équipe cœur de Ruby prévoit de maintenir un cadre de collaboration continue avec Ruby Central et les développeurs du monde entier
• Cette mesure est considérée comme la mise en place d’une base de long terme pour améliorer la stabilité et la fiabilité de l’écosystème Ruby
• Dans sa déclaration, Matz a exprimé sa gratitude pour l’engagement de Ruby Central et a déclaré : « Construisons ensemble un avenir plus lumineux pour Ruby »

Implications

• Ce transfert constitue un événement symbolique qui réorganise l’infrastructure centrale du langage Ruby au sein de son organisation officielle
• Grâce à l’intégration de la maintenance au niveau du langage et à l’unification de l’écosystème, il peut être vu comme un tournant renforçant la durabilité future de Ruby

[GN⁺]

Avis Hacker News

• Je pense que cette décision va dans la bonne direction ; je suis reconnaissant que Ruby Core et Matz interviennent pour garantir la stabilité de l’ensemble du langage et de la communauté.
  • Cela souligne que Matz est un véritable point d’ancrage ; je pense qu’il faudrait remplacer l’ancienne formule « Matz is nice and so we are nice » par « gentil et responsable ».
• À long terme, il me semble qu’avoir plusieurs sources comme gem.coop constituerait une structure plus sûre et plus robuste. Mais du côté de RubyGems, la confiance s’est totalement effondrée à plusieurs niveaux — administrateurs, membres de la communauté, sponsors, etc. — et des sujets comme le financement ou la confidentialité des données restent encore à régler. Cela dit, la plupart des membres de la communauté Ruby semblent soutenir ce changement.
  • Quelqu’un peut résumer ce qui s’est réellement passé ? Je n’ai pas suivi l’actualité Ruby récemment et je suis curieux.
  • D’accord ; il faut maintenant voir un peu plus comment gem.coop va mobiliser des forces. Ils ont pris des engagements pour l’avenir et finiront probablement par obtenir des résultats. Quand le service bêta ouvrira, je serais prêt à republier au moins une partie de mes anciens gems, surtout les principaux. Il y a des points à améliorer, notamment la documentation (ce qui touche aussi à la documentation Ruby, le fait que ce soit séparé pose problème). L’absence de namespacing est aussi un problème (Ruby n’a pas officiellement de namespacing, c’est à la fois une caractéristique et un défaut ; il faut un moyen de séparer selon les domaines d’intérêt). Il serait plus réaliste de réévaluer la situation dans environ six mois, vers fin mai 2026. Si DHH continue ses sorties acerbes sur son blog, cela pourrait attirer vers gem.coop de nouvelles personnes mécontentes, augmenter le nombre de contributeurs et les bénéfices associés. Du point de vue des utilisateurs, ce serait une situation gagnant-gagnant avec plus de liberté et de flexibilité. Beaucoup resteront sur rubygems.org, mais de plus en plus de gens pourraient préférer gem.coop. Certains utiliseront sans doute les deux à la fois (c’est un peu complexe, donc gem.coop devrait peut-être aussi envisager une fonction de sélection de source par gem). Il reste beaucoup de travail.
  • J’ai du mal à croire qu’un mainteneur inactif conservait encore des droits root. C’est surprenant qu’il ait gardé le moindre niveau d’accès sur une plateforme centrale. J’ai aussi été choqué de voir récemment des membres de la communauté Ruby s’opposer à des standards de sécurité modernes — et pourtant déjà largement déployés — alors qu’il s’agit d’une plateforme importante du web. Nous ne sommes plus en 2006, ni à l’époque où un curl suffisait pour installer Rails ; cette naïveté face au retour de bâton fait peur. Il est choquant de voir à quel point une posture de sécurité non maintenue exposait directement à une attaque de supply chain. Heureusement que quelqu’un se préoccupe enfin d’une sécurité adaptée à l’époque actuelle.
  • À propos de l’idée que plusieurs sources seraient plus sûres, je pense surtout que cela triple la surface d’attaque et peut augmenter le nombre de vulnérabilités.
  • Ce n’est qu’un changement dans l’outillage Ruby ; rubygems.org lui-même reste, selon le point de vue, détenu par une entité encore hostile, donc je doute que cela aide vraiment à rétablir la confiance.
• On peut voir la position de Ruby Central ici : https://rubycentral.org/news/ruby-central-statement-on-rubygems-bundler/
  • À noter qu’il vaut aussi la peine de lire la déclaration antérieure du 19 septembre, qui mentionne un « engagement commun en faveur de la stabilité et de la croissance à long terme de l’écosystème Ruby » : https://rubycentral.org/news/strengthening-the-stewardship-of-rubygems-and-bundler/
• Je suis profondément reconnaissant que Matz ait exercé directement son leadership dans une situation difficile. En tant que développeur japonais, j’étais très inquiet de la tournure que prenaient les événements récents, et cette annonce me rassure.
  • Je me demande en quoi a consisté ce leadership. Il était déjà clair que Hiroshi Shibata n’agissait pas toujours seul de manière unilatérale. Je soupçonne que la décision de reprendre gem et bundler avait déjà été prise en interne il y a plusieurs mois. Quant à l’idée qu’un développeur japonais puisse se sentir rassuré, moi cela m’inquiète encore davantage. Comme je ne vis ni aux États-Unis ni au Japon, le sentiment que les États-Unis et le Japon dominent excessivement l’écosystème Ruby me met mal à l’aise et me frustre (pour le Japon, je peux le comprendre puisqu’il s’agit de la communauté locale). Mais voir l’influence américaine aller aussi loin me paraît excessif. Je ressens la même chose pour Python, et je trouve cela regrettable.
• Je pense que quiconque a déjà un peu touché à Ruby considérera que cette issue est un résultat dont personne ne peut vraiment se plaindre.
  • J’ai l’impression que Ruby Central est le seul gagnant. Ils n’ont rien concédé et ont même obtenu le soutien officiel de Ruby Core pour être reconnus comme mainteneurs de RubyGems. La propriété du dépôt a changé de main, mais Ruby Central conserve les responsabilités opérationnelles et de gouvernance tout en collaborant étroitement avec Ruby Core. Andre détient la marque Bundler et a déclaré vouloir la faire valoir contre Ruby Central : https://andre.arko.net/2025/09/25/bundler-belongs-to-the-ruby-community/. Ruby Central transfère la propriété de Bundler à Ruby Core tout en continuant la maintenance, et Ruby Core se retrouve exposé au risque juridique. Si Andre attaque en justice, il devra affronter Ruby Core au Japon, et l’image du projet en souffrira encore plus.
  • Si les gens ne se plaignent pas, c’est seulement parce que Matz n’a pas encore pris position sur des sujets de société comme le droit de l’immigration.
  • J’aimerais vraiment demander si personne n’a réellement de reproche à formuler.
  • Je me demande pourquoi personne n’est vraiment mécontent, alors qu’il reste encore énormément de questions. Le point clé sera probablement de voir à quel point gem.coop gagnera en popularité — si cela arrive vraiment. Créer une nouvelle manière d’installer les projets Ruby aurait peut-être été préférable (comme Rust + cargo), mais j’estime qu’il vaut mieux séparer le fournisseur de service des discussions de développement proprement dites. Le fait d’avoir à la fois les binaires gem et bundle n’est pas idéal. À mon avis, l’API devrait être unifiée (ou bien Ruby Core pourrait maintenir une API simple, et chacun développer librement les fonctionnalités supplémentaires). Au final, beaucoup de projets risquent de finir comme dans le dessin xkcd. J’aimais la simplicité de bin/gem, et Bundler ajoutait quelques fonctions pratiques. Ce serait bien que la commande gem permette de choisir facilement différentes sources, y compris gem.coop.
• Je suis d’accord pour dire que Ruby Core est un meilleur choix que Ruby Central, mais je continue de me demander ce qu’a été exactement cette affaire, et l’image globale de l’écosystème Ruby en ressort un peu brouillée.
  • Je développe habituellement en Go et dans plusieurs autres langages. Je trouve que le caractère distribué de l’écosystème de paquets Go est un énorme avantage (même s’il a aussi des inconvénients). Vu les crises répétées de supply chain autour de NPM et des écosystèmes de paquets publics, je trouve étrange qu’il n’y ait pas davantage de décentralisation ou d’expérimentations portées par les communautés.
• J’attendais cette décision, car elle me paraît être l’option la plus simple et la plus susceptible de rétablir la confiance. Je continue de croire que des dirigeants de bonne volonté peuvent sauver une communauté.
• J’ai suivi cela récemment comme on suit un feuilleton, avec intérêt. Je suis désolé pour les personnes qui ont subi des dommages dans la communauté Ruby. Au final, je pense que Matz est le meilleur.
  • Je me demande si tout cela est parti d’une hostilité envers DHH. N’aurait-il pas été possible de forker rubygems.org de façon indépendante pour y appliquer les améliorations nécessaires en matière de sécurité et de gouvernance ? Dans ce genre de cas, du point de vue open source, le fork n’est-il pas la manière standard de résoudre les conflits ?
• L’attitude de Matz, dans ses actes comme dans sa manière d’annoncer les choses, est vraiment impressionnante et inspire le respect. Cela rappelle ce qu’est la grandeur.
  • En revanche, je n’aime pas le fait qu’on n’ait pris soin que de Ruby Central, perçu comme la partie agressive, sans remercier les anciens mainteneurs qui ont contribué pendant des années.
  • Le fait de ne pas mentionner comment le projet est passé du côté de RC (Ruby Central) donne l’impression qu’on embellit tout le processus.
• Du point de vue d’un observateur extérieur, quelqu’un pourrait-il expliquer simplement cette affaire ?
  • Ce fil peut être utile : https://news.ycombinator.com/item?id=45299170#45300774, en particulier le résumé de Mike McQuaid, qui aide beaucoup. Il a joué un rôle pour faciliter la médiation et la communication, et ses publications sociales récentes valent aussi le détour : https://bsky.app/profile/mikemcquaid.com
  • Le propriétaire a changé plusieurs fois, et les détails de ces transitions n’ont pas du tout été transparents. La tension a grandi dans la communauté, et comme la figure la plus visible et la plus vocale a un style consistant à exprimer des opinions impopulaires mais tranchées, le conflit s’est envenimé.
  • J’ai l’impression que personne n’arrive à l’expliquer clairement ; c’est une situation confuse et sans réponse nette.