Gem.coop

Background: RubyGems governance conflict

• Several commenters frame gem.coop as a response to a “hostile takeover” of the RubyGems GitHub org and infra by Ruby Central, allegedly pushed or supported by Shopify.
• Narrative from one side: long‑time maintainers were effectively fired/locked out, with “security” cited as the reason (especially after an AWS/root access incident), despite them having run things for ~10 years.
• Counter‑narrative: claims that this is exaggerated or unsubstantiated, that Ruby Central is tightening supply‑chain security and consolidating control over critical infra, and that some critics have personal grudges.

rv/Spinel and conflict‑of‑interest concerns

• A major fault line: some RubyGems maintainers were simultaneously paid by Ruby Central and fundraising for a new tool (rv) and a co‑op (Spinel), sometimes using the RubyGems brand in their pitch.
• Critics see this as a security and trust issue, and cite reports that access logs were requested for monetization.
• Supporters argue this is normal OSS evolution (like uv in Python), that infra maintainers must be funded somehow, and that Ruby Central overreacted and then miscommunicated.

DHH, politics, and community standards

• A large sub‑thread debates the creator of Rails: posts about London demographics, immigration, “no politics at work,” and far‑right UK figures are described by some as racist or “fash‑adjacent.”
• Others say “fascist” is an unfair smear, that inviting him to RailsConf is natural, and that politics should be kept separate from OSS work.
• This spills into a broader argument about whether silence equals complicity, whether it’s legitimate to refuse to collaborate with people whose politics threaten one’s rights, and whether open source can ever be truly “apolitical.”

Gem.coop: goals, benefits, and criticisms

• gem.coop is presented as a community‑run alternative registry, initially mirroring RubyGems and run by the ousted maintainers.
• Supporters see it as a Freenode→Libera‑style reset: restore trust by putting control back with known maintainers in a cooperative structure.
• Skeptics worry about ecosystem fragmentation, lack of clear technical advantages so far, and the risk of Ruby ending up with “which registry/manager?” complexity like JavaScript.
• The choice of .coop is debated: some like the co‑op signal; others fear corporate firewalls and “weird TLD” mistrust.

Trust, funding, and co‑op model

• Many commenters say trust in a package index is more about governance and people than code; for them, RubyGems.org broke that trust, while gem.coop’s maintainers earned it over years.
• Others trust Ruby Central/Shopify more than a small group that tried to build a quasi‑competing startup while holding infra keys.
• There’s discussion of co‑op economics: whether maintainers should be paid “market rate” vs equal pay, and how to avoid donor concentration that can be pulled over ideological disputes.

Security and technical directions

• Some want gem.coop to “win” only if it delivers concrete security improvements: mandatory code signing, stronger checksums, namespaces, better handling of supply‑chain attacks, private whitelisting registries, etc.
• RubyGems’ existing optional signing is criticized as effectively unused; recent malicious gem incidents are cited as evidence that more is needed.
• Alternatives like purely git‑based distribution or federated models (inspired by Go modules, container registries, ActivityPub/AT protocol) are floated, but others point to Go’s messy dependency practice and Git’s security limitations.

Meta: flagging, brigading, and community health

• Multiple users note the HN thread being flagged and suspect brigading, either by people wanting to suppress “political” discussion or to protect Ruby Central.
• Some see the fork as sad but necessary; others call it an ego‑driven overreaction and urge reconciliation via contribution agreements rather than long‑term fragmentation.