Live data from Hacker News

Ruby Central's Attack on RubyGems [pdf]

pup-e.com

11–20 of 286 posts

Re: Ruby Central's Attack on RubyGems [pdf]

#13
The recent actions taken by Ruby Central - removing long-time RubyGems and Bundler maintainers without warning, seizing administrative access, and consolidating control under a small, centralized group - represent a serious breach of trust within the Ruby ecosystem.

This was not a misunderstanding. It was a hostile takeover of key infrastructure, undermining both the long-standing maintainers and the broader community that relies on RubyGems and Bundler every day.

The Ruby ecosystem thrives on collaboration, openness, and mutual respect. What we've witnessed over the past week violates those principles. Ruby Central's actions - unilateral access revocations, exclusion of experienced volunteers, and refusal to engage in transparent dialogue - are not just organizational missteps. They're a threat to the decentralized and community-driven spirit that has sustained Ruby for decades.

I oppose this power grab.

Even more concerning is the idea that contributor access could become contingent on employment status or ideological alignment. Whether someone is employed by Ruby Central - or holds left-leaning, right-leaning, or apolitical views - should have no bearing on their ability to contribute to open source. Merit, dedication, and community trust must remain the foundation.

If Ruby Central is serious about supporting the Ruby community, they must:

- Immediately restore access to all maintainers removed during this incident.

- Publicly commit to a transparent, community-driven governance model, similar to what the RubyGems team had begun drafting.

- Respect the autonomy of open source maintainers, regardless of whether they are employed by Ruby Central.

- Acknowledge the harm caused by these actions and engage in meaningful dialogue to rebuild trust.

The Ruby community has always been about people - diverse, passionate, and united by a love for a beautiful language. It's time we demand that the institutions claiming to represent us act accordingly.

And if Ruby Central does not do this we must pressure sponsors to stop funding Ruby Central and ultimately; if all else fails, we must build and maintain our own infrastructure unencumbered by these shenanigans. Also, in order to re-establish trust in the community; the people responsible for causing this ruckus should be fired.

Ruby-Level Sponsors (Top Tier): Alpha Omega, Shopify, Sidekiq

Gold-Level Sponsor Flagrant

Silver-Level Sponsors: Cedarcode, DNSimple, Fastly, Gusto, Honeybadger, Sentry

Re: Ruby Central's Attack on RubyGems [pdf]

#14
post #13

The recent actions taken by Ruby Central - removing long-time RubyGems and Bundler maintainers without warning, seizing administrative access, and consolidating control under a small, centralized group - represent a serious breach of trust within the Ruby ecosystem. This was not a misunderstanding. It was a hostile takeover of key infrastructure, undermining both the long-standing maintainers and the broader communit…

[flagged]

Re: Ruby Central's Attack on RubyGems [pdf]

#15
post #14
post #13

The recent actions taken by Ruby Central - removing long-time RubyGems and Bundler maintainers without warning, seizing administrative access, and consolidating control under a small, centralized group - represent a serious breach of trust within the Ruby ecosystem. This was not a misunderstanding. It was a hostile takeover of key infrastructure, undermining both the long-standing maintainers and the broader communit…

[flagged]

Your account was created 5 minutes ago. Your username is "clanky". That's hilarious.

For future reference, the flagged parent comment was: "Slop."

Re: Ruby Central's Attack on RubyGems [pdf]

#16
post #8

Could someone with more insight as to the decision-making at Ruby Central weigh in on what's going on here? Between this and drama with the conferences over the years I'm just confused. They've been busy launching podcasts and doing fundraising, email campaigns and all that. Has there been a change in leadership?

Yes, they recently hired a new Executive Director.

Re: Ruby Central's Attack on RubyGems [pdf]

#18
post #15

Earlier quoted context omitted.

Your account was created 5 minutes ago. Your username is "clanky". That's hilarious. For future reference, the flagged parent comment was: "Slop."

[flagged]

what are these hallmarks?

is this becoming the latest way to attack an idea? instead of engaging with the actual content you just claim it is AI and therefore it can be ignored? seems disingenuous to say the least.

Re: Ruby Central's Attack on RubyGems [pdf]

#19
post #8

Could someone with more insight as to the decision-making at Ruby Central weigh in on what's going on here? Between this and drama with the conferences over the years I'm just confused. They've been busy launching podcasts and doing fundraising, email campaigns and all that. Has there been a change in leadership?

Yes, they recently hired a new Executive Director.

Links:

https://rubycentral.org/news/reflections-on-railsconf-2025-f...

https://www.linkedin.com/in/shancureton

Re: Ruby Central's Attack on RubyGems [pdf]

#20
post #6

Ruby Central's whole thing is they maintain, develop, and secure bundler and ruby gems. Marty was previously a lead at Ruby Central and recently came back to RC as their Open Source Lead. It sounds like there was a clusterfuck getting the repo switched over but I'm not seeing how this is an attack on Ruby gems. Am I missing something?

I think the missing piece here is that almost every person publicly involved with RubyGems’ development has left the project in recent weeks. I don’t have any special insight here, but from an outsider’s perspective it seems as through Ruby Central is trying to turn a former “host” relationship into a “control” relationship.

I think you're right, but I suspect the root here is one of legal liability - if rubycentral is operating as a nonprofit that hosts _a recurring attack vector on other companies_, they'll have legal obligations to secure that service against those attacks. I assume they are continuously deploying out of that repository, and took the simplest route to controlling the attack vectors?

I'm not sure how anyone familiar with open-source communities would fail to predict the backlash though. They really should have forked the repository and switched the deployments over to their downstream fork (if I'm right about the root cause here).

(I'm mostly thinking in terms of supply-chain attacks, like this one: https://blog.rubygems.org/2025/08/25/rubygems-security-respo...)

Post reply on HN