Gem.coop

 (gem.coop)
2 Punkte von GN⁺ 2025-10-07 | 1 Kommentare | Auf WhatsApp teilen
  • gem.coop ist ein neuer Gem-Server für das Ruby-Ökosystem
  • Vom ehemaligen Betriebsteam von RubyGems.org für die Community aufgebaut
  • Stellt alle öffentlichen Gems von RubyGems.org per Echtzeit-Synchronisierung bereit
  • Legt mit einer von Homebrew inspirierten Governance Wert auf Transparenz und Beteiligung der Community
  • Ziel ist ein nachhaltiges und sicherheitsgestärktes Gem-Hosting

Einführung in gem.coop

  • gem.coop ist ein neuer Gem-Server, der für das Ruby-Ökosystem entwickelt wurde und eine schnellere und einfachere Hosting-Umgebung bieten soll
  • Bei vollständiger Kompatibilität mit Bundler liegt der Fokus auf Leistung und Stabilität, optimiert für Entwicklungsumgebungen der nächsten Generation
  • Das Projekt wird als Dienst für die Community entwickelt, an dem ehemalige Administratoren und Mitglieder des Betriebsteams von RubyGems.org direkt beteiligt sind
  • Alle öffentlichen Gems werden von RubyGems.org in Echtzeit synchronisiert und sind dadurch auch auf gem.coop sofort nutzbar
  • Es kann sehr einfach eingesetzt werden, da in bestehenden Gemfiles nur die source-Adresse geändert werden muss

Governance und Beteiligung der Community

  • In Anlehnung an das Governance-Modell des Homebrew-Projekts wird eine transparente und leicht zugängliche Struktur eingeführt
  • Mit Unterstützung von Mike McQuaid werden Organisations-Setup und Betriebsmodell vorbereitet; die offizielle Governance-Struktur soll vor dem 10. Oktober veröffentlicht werden
  • Geplant ist eine offene Struktur, in der alle aus der Ruby-Community beitragen und mitwirken können

Service-Ziele und weitere Planung

  • Das ultimative Ziel von gem.coop ist eine Community-eigene Plattform für schnelles, transparentes, nachhaltiges und sicherheitsgestärktes Gem-Hosting
  • Zunächst werden Bundling und Installation aller öffentlichen Gems unterstützt; Funktionen und Qualität sollen anschließend kontinuierlich verbessert werden
  • Über den gem.coop-Newsletter lassen sich monatliche Updates erhalten

Team

  • Entwicklung und Betrieb liegen bei der Gem Cooperative; federführend sind deivid-rodriguez, duckinator, indirect, martinemde, segiddins und simi

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-10-07
Hacker-News-Kommentare

  • Wenn man alle Kontroversen einmal beiseitelässt, scheint die Lage derzeit so zu sein, dass bei den ursprünglichen RubyGems alle Maintainer weggegangen sind, während beim neuen Projekt die meisten bisherigen Kernbeitragenden mitmachen. Früher war vor allem deivid deutlich sichtbar, aber jetzt scheinen die meisten Schlüsselfiguren hierher gewechselt zu sein. Dadurch wirkt dieser Fork inzwischen wie die besser gewartete Software. Ich frage mich, ob die Leute bald dorthin wechseln werden und ob es Informationen zum Finanzierungsmodell oder zu den Hosting-Kosten gibt. Weitere Infos gibt es auch hier

    • Im Moment sieht dieser Fork vielleicht wie die besser gepflegte Software aus, aber eigentlich dürfte das Entscheidende weniger die Software selbst sein als vielmehr Speicherung und Bandbreite für den Indexing-Service. Ich frage mich, ob es nicht schon gut funktionieren würde, wenn man einfach eine Gem-Suchmaschine baut, die Hashes speichert und Downloads extern, etwa auf Repositories wie GitHub, verlinkt

    • Die Situation ist ein wenig bitter. Wenn dieser Fork erfolgreich wird, stehen wir womöglich wie in der JS-Welt vor der Frage: „Welchen Package-Manager soll man verwenden?“ Dann geht die schöne Einfachheit verloren, dass man einfach nur bundler und rubygems benutzt. Gleichzeitig möchte ich den bisherigen RubyGems-Maintainern, die sich öffentlich gegen die Probleme ausgesprochen und dann still an dem Fork gearbeitet haben, großen Respekt aussprechen. Ein RubyGems-Fork schien unmöglich, aber jetzt schaffen sie immerhin eine kleine Chance dafür. Große Unternehmen werden wohl größtenteils beim von Shopify gestützten RC bleiben, und dort wird es vermutlich auch stärkere Security-Audits geben, aber wenig Innovation. Wenn gems.coop dagegen Erfolg hat, dann wohl schlicht deshalb, weil es sich als das bessere Tool etabliert. Zum Beispiel dürfte rv.dev von André mit Ruby-Versionsverwaltung, Gem-Abhängigkeiten und sogar Funktionen ähnlich wie npx bei der Developer Experience die Nase vorn haben, als schnelles All-in-One-Tool. Außerdem werden Namespaces, Checksums und technisch aggressivere Sicherheitsansätze diskutiert, und wenn RC so weitermacht wie bisher, könnte am Ende die technisch überlegene Seite gewinnen. Was die Finanzierung betrifft, scheint André die Ansicht zu vertreten, dass Organisationen, die sich die Kosten für OSS-Infrastruktur leisten können, auch tatsächlich dafür zahlen sollten, und ich stimme dem zu. So ließe sich transparent kalkulieren, welche Kosten entstehen und wie sie auf die zahlenden Unternehmen verteilt werden. Letztlich denke ich auch, dass die eigentliche Ursache für das Scheitern von RC darin liegt, dass die Finanzierung zu stark bei wenigen Sponsoren konzentriert war. Ich hoffe, dass die Ruby Co-op ein verteiltes Finanzierungsmodell mit 100, 1000 oder mehr Unterstützern aufbauen kann

    • Soweit ich weiß, steht das Finanzierungsmodell noch nicht fest. Passender Link

    • Auf der offiziellen Seite gibt es viel zu wenig Informationen. Wenn man also logisch ein paar Annahmen trifft: 1) Für Distribution ist man zwangsläufig auf RubyGems angewiesen. 2) Für die Gem-Suche und die UI ist man ebenfalls auf RubyGems angewiesen. Unabhängig von den technischen Details gibt es für mich praktisch keinen Anlass zu wechseln, außer ich stimme ideologisch mit den Maintainers des Forks überein. Für professionelle Zwecke sehe ich keinen Grund für einen Umstieg, und wenn es mich privat interessiert, merke ich es mir vielleicht einfach. Wie bei den meisten Forks gilt: Entweder sie erreichen ihr Ziel und werden wieder zusammengeführt, oder sie werden zu einem neuen Standard, oder sie geraten in Vergessenheit. Solange ich nicht direkt betroffen bin, werde ich einfach zusehen. Das soll ihre Kritik oder ihre Arbeit nicht kleinreden, aber die Lage wirkt deutlich überzeugender als etwa ein Rails-Fork wegen DHH

    • Mir fällt keine neue Funktion in ruby gems oder bundler aus den letzten zehn Jahren ein, die bei mir hängen geblieben wäre oder die ich als notwendig empfunden hätte. Es gab sicher neue Features, aber ich habe sie nicht wirklich wahrgenommen

  • Wenn man sich den Ruf von Andre Arko ansieht, wie er kürzlich etwa in diesem Beitrag zusammengefasst wurde, bin ich etwas vorsichtig, was die Motive hinter dieser Bewegung angeht

    • Der Beitrag wirkt eher wie ein persönlicher Angriff aus Groll. Ich würde empfehlen, ihm bei der Bewertung nicht zu viel Gewicht zu geben

    • Im negativsten Szenario sähe es so aus: uv ist ein großartiges Tool, aber Astral plant ganz offensichtlich Integrationen mit kostenpflichtigen Services. Das schafft eine Art Einstiegshürde. Eine Sichtweise ist daher, dass Andre und sein Team sich vom Python-Ökosystem inspirieren ließen und nun in Ruby dasselbe versuchen wollen wie beim Erfolg von uv. Mit der Ankündigung von rv würden sie darauf hinarbeiten, dass Ruby Gems von ihnen abhängig wird, und Beispiele wie Hashicorp zeigen, dass es immer häufiger wird, Leute mit einem kostenlosen Angebot hereinzuholen und essenzielle Funktionen dann hinter eine Enterprise-Paywall zu packen. Ich halte es für genauso gefährlich, wenn das Ruby-Ökosystem von einer bestimmten Person oder einer kleinen Gruppe abhängig wird, wie es jetzt bei Ruby Central der Fall ist

  • Es ist beeindruckend zu sehen, wie sich die Open-Source-Community so zusammenschließt, um eine Lösung zu finden. Ich möchte allen danken, die daran gearbeitet haben

    • Trotzdem müssen Zeit und Fachwissen der Maintainer vergütet werden. Auch wenn Bandbreite und Speicher günstig sind, muss irgendjemand diese Kosten tragen, deshalb halte ich Spenden an das Projekt für sinnvoll

  • Nur so ein Gedanke, aber warum wechselt man nicht zu git als neuem Standard? Mit Commit-Signaturen, Tag-Signaturen und der verteilten Struktur wirkt das wie eine deutlich bessere Alternative, oder nicht?

    • Das git-Protokoll ist komplex und skaliert schlecht. Vor allem wäre es ineffizient, wenn in CI jedes Mal alle Pakete erneut heruntergeladen würden. Ein einzelnes Dateiarchiv lässt sich viel einfacher verteilen. Digests und Signaturalgorithmen sind außerdem nichts, was nur git bietet, und Schlüssel- sowie Identitätsverwaltung sind der schwierigere Teil, den git ebenfalls nicht vollständig löst. Gemeint ist: Man sollte git nicht mit GitHub verwechseln

    • Irgendjemand müsste git-Server betreiben, und für jedes Gem müsste man den jeweiligen git-Server finden und davon pullen. Nicht einmal alle git-Server hätten zwangsläufig die neueste Version, also müsste jeder für sich skalieren. Der Vorteil von Zentralisierung ist, dass alles an einem Ort liegt, man nur einmal skaliert und Updates gleichzeitig ausgerollt werden. Früher habe ich Dinge wie Artifactory als Proxy für NPM, Package-Manager und Docker-Container genutzt, sodass Deployments auch dann funktionierten, wenn ein zwischengeschalteter Dienst ausfiel. Für kleine Entwickler oder Teams wirkt diese Art von Verwaltung aber wie unnötiger Overhead

    • Tatsächlich kann rubygems (die Software) schon jetzt Pakete aus beliebigen git-Repositories beziehen. In gewisser Weise wird das also bereits unterstützt

    • Go nutzt einen solchen Ansatz bereits

    • Wenn man sich das Packaging-Ökosystem von Go ansieht, frage ich mich, ob ein Wechsel zu git wirklich eine gute Idee ist

  • Der wichtigste Punkt ist für mich, dass man wenigstens einen Link zum git-Repository hätte angeben können, damit man von außen sehen kann, wie das Projekt gepflegt wird. Im Moment gibt es das nicht. Es gibt zwar eine Liste der Maintainer, aber keinen git-Repo-Link, und dadurch wirkt das Projekt eher personenzentriert als codezentriert

    • Für ein Package-Repository muss ein Link wie zu einem Ansible-Repo meiner Meinung nach nicht zwingend in der ersten Ankündigung stehen. Das Wichtigste bei einem Package-Repository ist Vertrauen. Die feindliche Übernahme des RubyGems-GitHub-Repositories und der Organisation durch Ruby Central hat dieses Vertrauen zerstört, und eine Alternative, die von den ursprünglich verdrängten Maintainern selbst betrieben wird, ist eher eine gute Entwicklung. Eher wirkt es so, als hättest du dein Fazit schon vorher festgelegt und würdest nur noch Begründungen nachreichen. Nebenbei bemerkt ist auch auf der Startseite von rubygems.org kein Git-Repository-Link besonders prominent zu sehen

    • Der Source Code ist hier

  • Wenn man die jüngste Kontroverse ausklammert, frage ich mich grundsätzlich, ob kompatible alternative Paketquellen, Manager oder Versionsverwalter für Open-Source-Ökosysteme eher neutral, positiv oder negativ sind

    • Ich würde sagen überwiegend positiv. Monopole führen zu Stillstand, Wettbewerb schafft Innovation. Das gilt auch für Open Source

  • Ich verstehe, dass Forks manchmal nötig sind, aber es ist doch etwas bitter, dass man sich nicht besser abstimmen konnte. Wenn alle das gemeinsame Ziel haben, das Ruby-Ökosystem voranzubringen, müsste man dann nicht trotz politischer Hintergründe oder persönlicher Meinungsverschiedenheiten zusammenarbeiten können? Merb und Rails, Bundler und RubyGems sowie RubyTogether und RubyCentral sind schließlich auch irgendwann wieder zusammengekommen, daher hoffe ich, dass sich das eines Tages löst

  • Ich denke, das Problem ließe sich lösen, wenn man die Art und Weise überarbeitet, wie Gems verteilt und heruntergeladen werden. Das Problem ist nur, dass die Akteure, die diese Veränderung herbeiführen könnten, derzeit genau die Software und Infrastruktur kontrollieren und wenig Anreiz zur Verbesserung haben. Schon diese Situation an sich erscheint absurd, und ich verstehe auch nicht, woher die Abneigung gegenüber DHH kommt. Solches Drama und solche Forks sind die einfachste Art, ein Open-Source-Projekt zu beschädigen, und das ist traurig. Ruby ist zwar eine alte Sprache, hat aber keine riesige Nutzerbasis, und solche Kontroversen schaden dem gesamten Ökosystem. Als ehemaliger Ruby-Entwickler macht mich das traurig

  • Ich halte das für eine großartige Reaktion auf die feindliche Übernahme des RubyGems-GitHub-Repositories und der Organisation durch Ruby Central. Ich hoffe, dass es finanzielle Unterstützung für die Hosting-Kosten geben wird

    • Soweit ich weiß, sind die Hosting-Kosten bereits gesichert