Ruby-Core-Team übernimmt die Eigentümerschaft von RubyGems und Bundler

• Die Repository-Eigentümerschaft des Paketmanagers RubyGems und von Bundler der Sprache Ruby wird von Ruby Central auf das Ruby-Core-Team übertragen
• Diese Maßnahme wurde auf Initiative von Matz (Yukihiro Matsumoto) beschlossen, um langfristige Stabilität und Kontinuität der Community sicherzustellen
• RubyGems und Bundler bleiben weiterhin unter denselben Open-Source-Lizenzen, und auch die Urheberrechte sowie die Beitrags-Historie der bisherigen Mitwirkenden werden unverändert respektiert
• Der Betrieb wird in eine gemeinsame Verwaltung durch Ruby Central und das Ruby-Core-Team überführt, wobei das gemeinschaftsgetriebene Entwicklungsmodell bestehen bleibt
• Dies ist ein struktureller Wandel zur Stärkung der nachhaltigen Entwicklung und Integration des Ruby-Ökosystems und hat große Bedeutung für die langfristige Stabilität in der Zukunft

---

Bedeutung von RubyGems und Bundler

• RubyGems ist das zentrale Paketmanagement-Werkzeug des Ruby-Ökosystems, und Bundler ist ein unverzichtbarer Bestandteil für Abhängigkeitsmanagement und Deployment
• Beide Projekte sind Standardwerkzeuge, die in der Ruby-Distribution enthalten sind, und eng in die Ruby-Sprache integriert
• Dennoch wurden RubyGems und Bundler bislang unabhängig von der eigentlichen Ruby-Organisation durch Ruby Central verwaltet,
  obwohl sie Standardbestandteile der Ruby-Sprache sind und auf GitHub in einer separaten Organisation betrieben wurden, was zu fehlender struktureller Konsistenz führte
• Deshalb hat das Ruby-Core-Team beschlossen, offiziell die Verantwortung für Repository-Verwaltung und Wartung zu übernehmen
• Ziel ist es, langfristige Stabilität des Projekts und die Ausrichtung (alignment) am Ruby-Ökosystem sicherzustellen

Wichtige Änderungen

• Die offizielle Eigentümerschaft der Repositories wird an das Ruby-Core-Team übertragen, mit einem gemeinsamen Verwaltungsmodell zusammen mit Ruby Central
• Die bisherigen Open-Source-Lizenzbedingungen bleiben unverändert, es gibt keine Änderungen an kommerziellen oder rechtlichen Strukturen
• Die geistigen Eigentums- und Urheberrechte aller bisherigen Mitwirkenden bleiben vollständig erhalten; an der Code-Eigentümerschaft ändert sich nichts
• Das communitygetriebene Entwicklungsmodell wird fortgeführt, und Beiträge bleiben für alle offen

Zusammenarbeit mit der Community und weitere Pläne

• Das Ruby-Core-Team plant, ein kontinuierliches Kooperationssystem mit Ruby Central und Entwicklerinnen und Entwicklern weltweit aufrechtzuerhalten
• Die Maßnahme wird als Aufbau einer langfristigen Grundlage zur Verbesserung von Stabilität und Zuverlässigkeit des Ruby-Ökosystems bewertet
• In seiner Erklärung dankte Matz Ruby Central für ihr Engagement und sagte, man wolle „gemeinsam eine hellere Zukunft für Ruby gestalten“

Bedeutung

• Diese Übertragung ist ein symbolträchtiges Ereignis, bei dem die zentrale Infrastruktur der Ruby-Sprache innerhalb der offiziellen Organisation neu geordnet wird
• Durch integrierte Wartung auf Sprachebene und eine Vereinheitlichung des Ökosystems kann dies als Wendepunkt gesehen werden, der die Nachhaltigkeit von Ruby künftig erhöht

[GN⁺]

Hacker-News-Kommentare

• Ich denke, diese Entscheidung geht in die richtige Richtung; ich bin dankbar, dass Ruby Core und Matz eingreifen und für Stabilität in der gesamten Sprache und Community sorgen.
  • Es wird betont, dass Matz wirklich die zentrale Figur ist; ich finde, die frühere Aussage „Matz is nice and so we are nice“ sollte zu „freundlich und verantwortungsbewusst“ geändert werden.
• Langfristig betrachtet scheint eine Struktur mit verschiedenen Quellen wie gem.coop sicherer und robuster zu sein. Bei RubyGems ist das Vertrauen jedoch auf mehreren Ebenen vollständig erschüttert worden – bei Administratoren, Community-Mitgliedern, Sponsoren und anderen. Themen wie Finanzierung oder Datenschutz bleiben ebenfalls noch ungelöste Aufgaben. Trotzdem werden die meisten Menschen in der Ruby-Community diese Veränderung wohl unterstützen.
  • Könnte bitte jemand zusammenfassen, was tatsächlich passiert ist? Ich habe die Ruby-Nachrichten zuletzt nicht verfolgt und bin neugierig.
  • Stimme zu, jetzt muss man wohl noch etwas beobachten, wie viel Unterstützung gem.coop tatsächlich bündelt. Sie haben Versprechen für die Zukunft gemacht und werden am Ende vermutlich auch Ergebnisse liefern. Wenn der Beta-Dienst startet, wäre ich bereit, einige meiner früher veröffentlichten Gems erneut hochzuladen, zumindest die wichtigen. Es gibt aber Punkte, die verbessert werden müssen, besonders die Dokumentation, was auch mit der Ruby-Dokumentation zusammenhängt; die Trennung davon ist problematisch. Auch fehlendes Namespacing ist ein Problem. In Ruby gibt es offiziell kein Namespacing; das ist zugleich ein Merkmal und ein Problem, und ich denke, es braucht eine Möglichkeit zur Trennung nach Themenbereichen. Realistischer wäre es, das in etwa einem halben Jahr noch einmal zu bewerten, also gegen Ende Mai 2026. Wenn DHH in seinem Blog weiter scharfe Aussagen macht, könnten Menschen, die schon unzufrieden mit gem.coop waren, neu dazustoßen; dadurch könnten mehr Beitragende hinzukommen und der Nutzen wachsen. Aus Sicht der Nutzer wäre das eine Win-win-Situation mit mehr Freiheit und Flexibilität. Viele werden bei rubygems.org bleiben, aber ebenso dürften viele gem.coop bevorzugen. Manche werden wohl beide nutzen; das macht es etwas kompliziert, sodass gem.coop vermutlich auch eine Funktion zur Quellenangabe pro Gem in Betracht ziehen sollte. Es gibt also noch viel zu tun.
  • Ich kann kaum glauben, dass ein nicht mehr aktiver Maintainer immer noch Root-Rechte hatte. Es überrascht mich, dass bei einer Kernplattform überhaupt noch irgendwelche Rechte verblieben sind. Ich war schockiert zu sehen, dass Mitglieder der Ruby-Community sich gegen moderne Sicherheitsstandards gestellt haben, obwohl es sich um eine wichtige Plattform des Webs handelt und diese Standards längst breit eingesetzt werden. Wir leben nicht mehr im Jahr 2006 und nicht mehr in einer Zeit, in der man Rails einfach per curl-Befehl installiert. Diese naive Gegenreaktion wirkt beängstigend. Erschreckend ist auch, dass man mit einer nicht gepflegten Sicherheitslage Supply-Chain-Angriffen schutzlos ausgesetzt war. Immerhin ist es gut, dass sich jetzt doch jemand um eine zeitgemäße Sicherheit kümmert.
  • Zu der Behauptung, mehrere Quellen seien sicherer: Ich denke, damit vergrößert sich die Angriffsfläche auf das Dreifache, was zu mehr Sicherheitslücken führen könnte.
  • Es geht nur um Änderungen am Ruby-Tooling; rubygems.org selbst gehört weiterhin – je nach Sichtweise – einer feindseligen Entität. Daher frage ich mich, wie sehr diese Situation wirklich zur Wiederherstellung von Vertrauen beiträgt.
• Die Position von Ruby Central ist hier zu sehen: https://rubycentral.org/news/ruby-central-statement-on-rubygems-bundler/
  • Der Vollständigkeit halber lohnt sich auch ein Blick auf die frühere Stellungnahme vom 19. September. Darin ist von einer „gemeinsamen Verpflichtung zur langfristigen Stabilität und zum Wachstum des Ruby-Ökosystems“ die Rede: https://rubycentral.org/news/strengthening-the-stewardship-of-rubygems-and-bundler/
• Ich bin Matz zutiefst dankbar, dass er in einer schwierigen Lage persönlich Führung gezeigt hat. Als japanischer Entwickler war ich zuletzt sehr besorgt darüber, wohin sich die Lage entwickeln würde, und diese Ankündigung beruhigt mich.
  • Mich interessiert, worin genau diese Führung bestand. Es war immer klar, dass Hiroshi Shibata nicht völlig eigenmächtig gehandelt hat. Ich vermute, die Entscheidung, diesmal gem und bundler zu übernehmen, wurde intern schon vor einigen Monaten getroffen. Zur Aussage, man könne als japanischer Entwickler beruhigt sein: Ich bin eher noch besorgter. Da ich weder in den USA noch in Japan lebe, irritiert und verärgert es mich, dass die USA und Japan das Ruby-Ökosystem übermäßig stark zu dominieren scheinen – bei Japan verstehe ich es noch als lokale Community, aber der Einfluss der USA wirkt etwas zu groß. Bei Python ist es ähnlich, und das finde ich bedauerlich.
• Ich denke, jeder, der Ruby auch nur ein wenig benutzt hat, wird mit diesem Ergebnis zufrieden sein.
  • Ich finde, nur Ruby Central profitiert davon. Sie haben nichts aufgegeben und wurden im Gegenteil mit offizieller Unterstützung von Ruby Core als Maintainer von Rubygems anerkannt. Das Eigentum am Repository wurde zwar übertragen, aber Ruby Central behält die Verantwortung für Betrieb und Governance und arbeitet dabei eng mit Ruby Core zusammen. Andre besitzt die Markenrechte an Bundler und hat bereits angekündigt, diese gegenüber Ruby Central geltend zu machen: https://andre.arko.net/2025/09/25/bundler-belongs-to-the-ruby-community/. Ruby Central überträgt das Eigentum an Bundler an Ruby Core und führt die Wartung weiter, während Ruby Core dem rechtlichen Risiko ausgesetzt ist. Wenn Andre klagt, müsste er gegen Ruby Core in Japan vorgehen, und das würde das öffentliche Bild weiter verschlechtern.
  • Die Leute sind nur deshalb noch nicht unzufrieden, weil Matz zu gesellschaftlichen Themen wie dem Einwanderungsrecht bisher keine Stellung genommen hat.
  • Ich möchte zurückfragen, ob wirklich niemand unzufrieden ist.
  • Ich frage mich, warum angeblich niemand unzufrieden ist. Es bleiben immer noch unzählige Fragen offen. Entscheidend wird wohl sein, wie populär gem.coop künftig tatsächlich wird und ob es wirklich wächst. Vielleicht wäre es sogar besser gewesen, eine neue Art der Installation von Ruby-Projekten zu schaffen, wie bei Rust und cargo. Ich finde aber, man sollte den Service-Anbieter und die eigentliche Entwicklungsdiskussion getrennt betrachten. Die Tatsache, dass es sowohl gem- als auch bundle-Binärdateien gibt, finde ich nicht besonders gut. Es sollte eine einheitliche API geben – oder alternativ eine einfache, von Ruby Core gepflegte API, während zusätzliche Funktionen frei entwickelt werden können. Letztlich besteht die Gefahr, dass viele Projekte wie in diesem xkcd-Comic enden. Ich mochte die Einfachheit von bin/gem, und Bundler hat einige Komfortfunktionen ergänzt. Es wäre gut, wenn der gem-Befehl unterschiedliche Quellen einfach angeben könnte, auch gem.coop.
• Ich stimme zu, dass Ruby Core die bessere Wahl als Ruby Central ist, aber ich frage mich immer noch, was hier eigentlich genau passiert ist, und das Gesamtbild des Ruby-Ökosystems wirkt für mich etwas eingetrübt.
  • Ich entwickle normalerweise vor allem mit Go, aber auch mit anderen Sprachen. Ich empfinde die dezentrale Struktur des Go-Paketökosystems als großen Vorteil, auch wenn sie natürlich Nachteile hat. Obwohl sich Krisen in der Supply Chain von NPM und anderen öffentlichen Paketökosystemen wiederholen, wundert es mich, warum nicht mehr community-getriebene Dezentralisierung oder Experimente stattfinden.
• Ich habe auf diese Entscheidung gewartet, weil sie mir als die einfachste Option erschien, mit der sich Vertrauen wiederherstellen lässt. Ich glaube weiterhin daran, dass wohlmeinende Führungspersönlichkeiten eine Community retten können.
• Ich habe das zuletzt mit Interesse wie ein Drama verfolgt. Für die Menschen, die in der Ruby-Community dadurch Schaden genommen haben, tut es mir leid. Und am Ende finde ich: Matz ist großartig.
  • Ich frage mich, ob all das von einer Abneigung gegen DHH ausgegangen ist. Hätte man die nötigen Sicherheits- und Governance-Verbesserungen für rubygems.org nicht unabhängig forken und anwenden können? In solchen Fällen ist ein Fork aus Open-Source-Sicht doch eigentlich der Standardweg, um Konflikte zu lösen, oder?
• Matz’ Verhalten und die Art seiner Ankündigung waren wirklich beeindruckend und flößen Respekt ein. Das erinnert daran, was wahre Größe ausmacht.
  • Mich stört, dass nur Ruby Central als die aggressive Seite berücksichtigt wurde und den früheren Maintainern, die über Jahre beigetragen haben, kein Dank ausgesprochen wurde.
  • Dass nicht erwähnt wurde, wie das Projekt auf die Seite von RC (Ruby Central) überging, wirkt auf mich wie eine Beschönigung dieses Prozesses.
• Könnte jemand den Vorfall aus Sicht einer außenstehenden Person kurz erklären?
  • Es lohnt sich, diesen Thread zu lesen: https://news.ycombinator.com/item?id=45299170#45300774, besonders die Zusammenfassung von Mike McQuaid ist sehr hilfreich. Er half bei Vermittlung und Kommunikation, und auch seine jüngsten Social-Posts sind lesenswert: https://bsky.app/profile/mikemcquaid.com
  • Die Eigentümer haben mehrmals gewechselt, und die Details dieses Prozesses waren überhaupt nicht transparent. Dadurch stiegen die Spannungen in der Community, und eine besonders lautstarke und prominente Person mit unpopulären, aber starken Meinungen trug dazu bei, dass der Konflikt eskalierte.
  • Ich habe das Gefühl, dass es niemand klar erklären kann. Es ist verwirrend und scheint keine wirkliche Lösung zu geben.