Ruby Core Takes Ownership of Rubygems and Bundler
147 comments
·October 17, 2025white-moss
shevy-java
Stepping up how? It was always clear that Hiroshi Shibata didn't act solo without approval. I am not saying he knew the outcome before that, but WHEN was the decision made to take over gems + bundler? I have a slight suspicion that this may have been decided upon months ago already.
> As a Japanese developer, I’ve been worried about the direction things were going, so it’s reassuring to see this.
I am actually much more worried now. I don't live in the USA; I don't live in Japan. To me it seems as if Japan and the USA are totally over-dominating in the ruby ecosystem. While this is understandable that it is Japan (local community, I get it, this is different to english-speaking ones), I am absolutely upset that the USA has so much proxy-influence here. But I guess there is nothing that can be done. I guess in Python the USA also over-dominates. I just think this sucks really.
xg19837
Yes. At least Ruby was always strongly Japanese though. In Python European and Asian developers are overtly exploited, with U.S. corporations and their employed stooges holding the reins of power.
I'm considering switching to Erlang, which was developed at a corporation from the start and appears to be drama and cancel free.
nxor
Or Europeans choose to work for US corporations. What am I missing? I know Europeans who only want to work for American companies.
dudeinjapan
Shopify is pretty much dominating the Ruby ecosystem. It’s Canadian tho :)
dismalaf
> I am actually much more worried now
Why? Japanese culture is more conservative, less prone to knee jerk decisions, and Ruby is their biggest home grown programming language.
I'm also not American nor Japanese and I think this is the best possible outcome.
nxor
More people live in the US. What is overdominating Python?
sebiw
I think this is the right move. Thank you to Ruby Core and Matz for stepping up and providing stability to the language and community as a whole.
delichon
Matz is a pillar. Remember "Matz is nice and so we are nice"? s/nice/nice and responsible/gc.
sam_lowry_
[flagged]
runjake
why’s identity reveal had nothing to do with the Ruby community. A random bad actor posted his personal details in a blog post.
The Ruby community respected his pseudonymity. Some of us already knew his name.
sebiw
I don't like talking about a heterogeneous group of people in a generally negative way. I try to stick to the people I perceive as sharing the same values that are important to me. And there are many such people in the Ruby community.
the_mitsuhiko
> Remember why the lucky stiff?
I remember _why and I definitely don't remember him as toxic.
dudeinjapan
Surprised to hear this, have been a Rubyist for many years and never felt this way about community as a whole. Come to Ruby Kaigi in Japan sometime!
null
s0sa
I think that viewpoint says more about you than it does the Ruby community.
binary132
How dare you. Say Ruby cultists are nice right now or canceled.
shevy-java
Is that a religion now?
The pickaxe guys coined it. People repeat it without thinking about it.
If matz were to say "jump from the bridge", people would do it, because matz is nice?
Just to point out: I do think matz is nice and a great language designer. That in itself doesn't mean anything. Why would I proxy my own decisions based on any mindless slogan? That makes no sense. Why do people in the ruby ecosystem keep on repeating those pointless slogans?
ubercore
I think it's pretty obvious to see the difference between being nice and jumping off a bridge? Curious why this cute phrase bothers you so much.
delichon
I know what you mean about mindless aspirational slogans. "No child left behind" is logically the same as "no child gets ahead". But trying to convince the Ruby community to be nice, by the example of their founder, isn't in that category. And if Matz told me to jump off of a bridge, he has enough stored up credibility that I'd at least consider it.
kamranjon
Is being nice equivalent to jumping off a bridge? I think it's relatively simple to comprehend and also harmless. The guy who built this thing is nice, let's try to continue that tradition so that our community doesn't turn to shit.
dudeinjapan
Matz wouldn’t say jump from a bridge because he is nice.
mcphage
> If matz were to say "jump from the bridge", people would do it, because matz is nice?
As always, there's a relevant xkcd: https://xkcd.com/1170/
...but seriously, what on earth do you think you're saying here?
dluan
In the long run, having multiple sources like gem.coop is probably a safer and more robust solution. But for RubyGems specifically, the trust was fully lost, through several layers - maintainers, community members, sponsors, etc. There's still open questions that probably need to be resolved like the funding and data privacy stuff, but I think most folks in ruby land will be supportive of this.
neya
Any summary of what exaclty unfolded please (if you don't mind)? Sorry haven't been following the Ruby news for sometime.
shadowgovt
The broad-strokes story is:
* DHH said some things on his blog that some people believe to be deeply racist / fascist (not going to unpack whether they were or not because answering that question is irrelevant to the fact pattern; consult other threads for that debate).
* A Ruby conference run by Ruby Central was asked to deplatform him. Since he's the creator of Rails, they declined.
* In response to their decision, a major sponsor (Sidekiq) pulled out of supporting the conference and Ruby Central in general, to the tune of $250k a year.
* This created a "blood in the water" situation where Shopify hit Ruby Central with an ultimatum: they would back-fill the lost sponsorship for oversight control of Ruby Central (and the gem repository they maintain, rubygems.org). And if Ruby Central didn't take the deal, Shopify was going to pull their funding also, leaving them in dire straits (this, BTW, is a fairly common corporate tactic when multiple partners share support of a service that doesn't independently generate revenue. Look for it in your own business, startup company, and nonprofit dealings!).
* Shopify now de-facto controls rubygems.org and people immediately started backing towards the exits because corporate takeover tends to be a harbinger of enshittification. As if to prove the point, Shopify's folks immediately ham-fisted the access controls, yanking several gem creators from the admin roles of the gems they created. They claim this was a mistake; several in the community do not want to give them a benefit of the doubt they are not believed to have earned.
* Community members are standing up gem.coop as an alternative gem repository.
kragen
But Ruby Core is not the same thing as Ruby Central, apparently? This blog post says, "To provide the community with long-term stability and continuity, the Ruby core team, led by Matz, has decided to assume stewardship of these projects from Ruby Central. We will continue their development in close collaboration with Ruby Central and the broader community." What, if anything, is the relationshp between Ruby Core and gem.coop?
ameliaquining
This is missing an important part of the story that makes the Ruby Central side look relatively better, which is that one of the existing maintainers offered to help fill the funding gap in exchange for being allowed to monetize the server logs. https://rubycentral.org/news/rubygems-org-aws-root-access-ev...
shevy-java
This is not 100% correct though; I mean, your summary is good, don't get me wrong so I upvoted it. But it conflates a few issues that are not 100% related.
For instance, DHH and his fancy blog, are not 100% related or relatable to RubyCentral ousting long-term developers. There may be some connection (DHH on shopify's board, tons of ruby developers being paid by shopify and still writing "my opinion is totally unbiased" like byroot did), but there is no 1:1 overlap. For instance, I could not care what DHH writes on his blog any less. rubygems.org changing policies though - that affects me. And if shopify is in part responsible, and DHH sits on shopify and makes decisions, then yes, something changed here. But there are also people who have a vendetta against DHH and they leak into other spaces too. I am not among those people and they shouldn't try to hijack other communities either.
By the way, the Shopify ultimatum also does not explain why all other ruby devs were ousted. Ruby Central lost the narrative here. And, since they accuse Arko as the ultimate bad boy - why haven't they sued him? Why do they continue to refuse to do so? (Because they know their case would be rubbish nonsense and they would have to open up ALL emails, which may make many more people suddenly ... very funky.)
neya
Thanks, that was a superb summary! Appreciate it.
runjake
It's news to me that the RubyCentral event had anything to do with DHH at least directly.
You are alleging that Shopify was retaliating. Do you have any reliable context that Shopify was acting in a retaliatory manner?
shevy-java
Agreed.
I think we have to wait and see how much momentum gem.coop can build. Right now they have promised "things for the future"; they will most likely also deliver eventually. But right now they are not there.
If and when they open beta, though, I'll begin to republish my old gems (not all, some I merged into other gems but most of the core stuff will be back) there. They have some things they should improve on though - documentation (also a problem that ruby doc was separate by the way), namespacing (this is in part also a problem that ruby had no primary way of namespacing; this is also a feature, but it should have a way to separate concerns when possible or wanted).
Anyway, I think we'll soon see what happens - I say people should evaluate again in about half a year or so, say like ... end of May 2026. I think this would be a more realistic time frame.
I do, however had, also suspect that DHH may become the biggest asset to gem.coop - every further snide remark he does on his blog, will gain new people who are upset, and some of those will eventually help contribute and benefit gem.coop. So for the end user this may be a win-win situation since they can install things how they like it, thus having more flexibility. Many can and will stay with rubygems.org, others may prefer gem.coop, many others will probably use and combine both (this may be a bit more difficult; guess gem.coop needs to think of a way to specify different gem sources on a per-gem basis too. Lots of work to be had for certain).
busterarm
Even if you're not an old-timer and don't remember what Ruby Together was like, the AWS root password changing shenanigans, presumably done by Arko, is enough of a red flag that nothing he's associated with has any credibility.
No serious business with real (business) customers will accept that kind of risk and gem.coop will never be a thing outside of hobbyists.
dluan
Read his account of it (https://andre.arko.net/2025/10/09/the-rubygems-security-inci...) and you might change your mind (again).
lyu07282
This is just the tooling though, not "rubygems.org" which is still owned by a hostile entity (depending on where you sit on this), so not sure how this would restore any trust?
rich_kilmer
As a co-author of RubyGems and one of the original Board members of Ruby Central, they are not a hostile entity. They are the entity that we gave stewardship of RubyGems and we/they have hosted it for its entire existence.
shevy-java
I disagree. The actions are orthogonal to your claim - they eliminated everyone else from there. How is that not hostile? Duckinator has been 100% right here.
> we gave stewardship of RubyGems
I didn't sign anything.
I also remember the original creators of rubygems. How old is Ruby Central? 10 years? 15 years? There were several years before that.
lyu07282
It goes without saying that Ruby Central doesn't think Ruby Central has ever lost any trust to begin with.
dismalaf
Hostile entity? The entity that has literally hosted them for their entire existence?
byroot
Ruby Central side: https://rubycentral.org/news/ruby-central-statement-on-rubyg...
gcr
For context, also check out their previous statement from September 19, which also "reflects our shared commitment to the long-term stability and growth of the Ruby ecosystem" [sic]: https://rubycentral.org/news/strengthening-the-stewardship-o...
shevy-java
They keep on using buzzwords. These Ruby central guys never maintained a single gem used by many people in their life. I have no idea what they are writing, but it feels as if AI is writing their statements. Even then it is of such a poor, repetitive quality that even AI may just accidentally write better "summaries". People lost all trust in Ruby Central - there is no way for them to win back trust here.
IMO it would be better to start from a clean slate; dissolve Ruby Central and bring back the community with a new policy, rules - but that's not going to happen. Ruby Central went the corporate way and that's it. It would just be ironic if, say in 10 years, gem.coop proves to be much more successful whereas Ruby Central still writes the same AI-generated text ("we care for the community even if everyone is now elsewhere already").
pebble
Better Ruby core than Ruby Central but still leaves me wondering what the hell happened and slightly sours me on the whole ecosystem.
joshmn
This is the only outcome that anyone who touches ruby cannot be upset with.
shevy-java
How so?
I think there are a gazillion questions left. But, I also agree that the future will tell, e. g. we'll have to see how popular gem.coop will become (if they become popular). And I also, despite my disagreements, think that it may have been better to solve installations of ruby projects from the get go, e. g. Rust + cargo. But I also see this as separate from a service such as rubygems.org (or whoever provides any infrastructure). The question of who develops functionality can be separate, I have no strong preference here. And, I also agree that having both bin/gem and bin/bundle is not good. There should be a unified API (or two - a simple one maintained by ruby core, and then people can build extra functionality into their own variants).
Sadly this all also may end up like this:
What I liked about bin/gem was its simplicity. Bundler brought a few new things or easier things to the table. "gem" should make it much easier to use any source though, including gem.coop.
baggy_trough
cannot?
mring33621
NGL, the drama is entertaining.
I'm sorry for Ruby people that are negatively impacted, tho.
Lastly, Matz is the best!
mring33621
So this whole thing stems from a dislike of DHH?
It also seems like rubygems.org could simply fork the rubygems code, perform whatever 'security and governance' changes they believed were needed in their fork, and run with that?
Isn't that the open source way of handling disagreements in direction?
Mystery-Machine
It seems like it stems from dislike of André
mcphage
> So this whole thing stems from a dislike of DHH?
I don't believe this has anything to do with DHH.
gardnr
Can anyone please explain this in simple terms for a relative outsider?
gcr
See this thread for context: https://news.ycombinator.com/item?id=45299170#45300774
See especially Mike McQuaid's summaries. He did a bunch of mediation and comms work to make the situation digestible to outsiders. Check his recent posts (at time of writing) on https://bsky.app/profile/mikemcquaid.com
shevy-java
Yeah. I think everyone on all sides praises Mike for his effort. Cool guy.
joshmn
Changed hands a couple times with “unclear” transition details at best. How it came about wasn’t all that transparent.
Tensions within the community were heightened because its loudest voice and most recognizable figurehead has opinions that aren’t all that popular and he made them loud and clear as he’s a loud thinker.
binary132
Decentralized package hosting is the only way.
ivan_gammel
The key question here is how exactly the supply chain attacks will be prevented. If you consider release of new version of a library some sort of transaction, it's easy to see then the difference with cryptocurrencies: in crypto transaction can be automatically verified, but with software releases it is impossible. It is hard to imagine hundreds of hostings on the same very high trust level, so either risks become significant or there are several, but not many hostings which everyone can trust. If Number of hostings << Number of users, then it's not truly decentralized and there still exists a different risk, when there's some sort of political split between some of them. Summarizing all of that, I don't know if decentralization is a solution at all. Transparent community ownership over a centralized solution is much better.
shevy-java
The supply chain attack is not the only argument here, though.
For instance, who effectively controls the ruby ecosystem? See ad-hoc restrictions such as 100.000 downloads - past that point you are disowned from your own gem. I always felt that was a direct attack on independent developers. They could have forked those gems just fine (the licence permits this for most gems after all), but nope, they forbid you to remove your own (!!!) code.
ivan_gammel
Decentralization is not the answer to that though.
__float
What languages do you use that have adopted this well?
I'm not counting something like C++ where there's effectively no "packages" to speak of.
zrail
Go, for some values of "distributed". The vast majority of go packages are hosted on GitHub, but nothing stops anyone from hosting elsewhere and Go has explicit support for indirection such that anyone can use a vanity domain that happens to point at GitHub or wherever.
cortesoft
Isn't this the same as ruby gems, then? You can use alternative sources in your Gemfile pretty easily.
shadowgovt
Go's one weakness is that the package source is baked into the package data in a not-automatically-fungible way. And if pkg.go.dev ever becomes a threat vector, we're gonna have a bad time.
dselect solved this ages ago with its mirrors, but at some point it seems every major package manager decided that was unnecessary complexity ("why bother? It's not like a package repo just goes down") and left it out when they built their alternatives.
So, from time to time, when a domain in the Internet goes sour it's a huge problem (whereas were a Debian mirror to go sour I'd add like one line to a config file and never notice the issue again, assuming dpkg doesn't automatically identify the problem and route around it).
pjmlp
Nowadays there are, as vcpkg and conan step by step win the earths of the C and C++ communities, and then there are the distro specific ones, if someone is happy enough with rpm/deb + pkg-config.
However I would say all ecosystems have issues, regardless of the approach, because 99% of the developers have no clue on what they depend on, and there are plenty of ways to mess up with ecosystem.
voxic11
Go has decentralized package hosting and it works reasonably well.
Deno does also but I'm less clear on well how that is working out for them.
monooso
The Deno people recently released jsr.io, "a modern package registry for JavaScript and TypeScript."
I'm not familiar with the technical details, but at first glance it appears pretty centralised.
delfinom
>Go has decentralized package hosting and it works reasonably well.
All go package imports are proxied via Google.
https://drewdevault.com/2022/05/25/Google-has-been-DDoSing-s...
runjake
I think this is great news and the right move!
At the same time, I would like more information around how the Gem supply chain will be handled, particularly how Rubygems and Bundler will be protected against supply chain attacks, which are becoming endemic.
andsmedeiros
So Ruby Central will still be running rubygems.org?
shevy-java
Sadly yes. They probably have no other choice, because what else would they do with their time? Do the unthinkable and create gems other people would use? That would be too much work.
james_marks
Matz' action and tone in the announcement is impeccable. Humbling reminder of what greatness looks like.
jcmfernandes
By not addressing HOW the project ended up in RC's hands, Matz is effectively whitewashing the move.
busterarm
Unless there is some yet-unnamed party with enough credibility and enough money to do a proper takeover from Ruby Central, this was always the inevitable way forward.
In my 17ish-year involvement with Ruby, I can't think of one.
jcmfernandes
I don't understand why the move wasn't undone. This is essentially kicking the can down the road.
Really appreciate Matz stepping up to take on this difficult situation. As a Japanese developer, I’ve been worried about the direction things were going, so it’s reassuring to see this.