I'm leaving Ruby Central
111 comments
·September 23, 2025moritonal
827a
Wow. I've seen less corpowashed decision making out of Microsoft. They set their house on fire, its burning down, but spraying water on it would get the curtains wet so we can't do that.
apercu
That's hilarious. "Our business decisions are questionable but for religious reasons we can't talk about it right now now"
null
snickerdoodle14
[flagged]
kace91
Soo let me see if I get the context.
Ruby central was short for cash, Shopify used that to pressure them into a takeover of several core community repos like bundler so that Shopify can control those indirectly? Is that it?
jaredcwhite
In a word, yes.
kace91
What I don’t get is, what does Shopify get from this?
I’m assuming there’s a ton of reputational risk in this move, and my understanding as an outsider is that Shopify already has a ton of weight in the Ruby ecosystem - they seem to be the one case quoted by everyone as the “proof that Ruby scales”.
kimos
It’s easy to point at politics or people and some sinister motive. Maybe that’s what it is. But don’t underestimate what can be accomplished through incompetence.
Shopify is a multi-billion dollar company that has processed over a trillion dollars. They are a high value target for sophisticated attackers. It’s entirely possible they are trying to accomplish some security and supply chain goals to protect their Ruby pipeline, but completely messed up the execution and did not predict the community interpretation and backlash.
plorkyeran
We know very little about what happened between Shopify and Ruby Central. They said that they made no progress towards satisfying Shopify’s demands until they were 24 hours from the deadline, but not what those demands specifically were or why they failed to do anything. It’s possible that what they panickedly did at the last second wasn’t actually what Shopify had intended.
rmoriz
They are a multi-billion company that is highly dependent of RubyGems and a breach could ruin their business. So they have intrinsic reasons to support anything that keeps Ruby and Rails floating.
kmacdough
I suspect they underestimated the lashback. They wanted to make their changes whenever they wanted, to fit their specific needs. They didn't think twice about the community, so much so that they didn't consider the community might not stand for it.
And history ain't written. Who knows how this will hurt them.
pityJuke
From all I can observe, it does seem to have a sinister political undertone. In that, Ruby Central's collapse started because Sidekiq disagreed with them platforming dhh, and then Shopify (who has dhh as a board member, and whose CEO races with dhh) used the funding weakness to demand a purge of anyone they disagreed with.
As an aside, I imagine the discussion of this will be end up being... difficult, because people are tending not react to these sorts of things well.
flkiwi
There are arguably larger reputational risk issues in a company with significant financial/payment activities not having adequate control of their technology. I'm not saying that justifies anything here as I don't know nearly enough about, but I'd wager that even a minor incident arising from them not adequately controlling their stack would create infinitely more issues than this move.
kelvinjps
Isn't most of the reputational risk going to Ruby Central?
th0ma5
Money. Some people seek to extend their claimed intellectual property into previously uncapitalized contexts.
teeray
> Ruby central was short for cash, Shopify used that to pressure them into a takeover of several core community repos like bundler so that Shopify can control those indirectly
Sounds like a variant of the xz takeover, but using money this time and in public.
null
retrorubies
I’ve always acted as a community-oriented person, so I feel it’s my duty to share what really happened, what the current state is, and why Ruby Central has failed in the eyes of the community. This is my perspective — and why I’m leaving Ruby Central by choice, but am being forced out of Bundler, RubyGems, and RubyGems.org.
bradly
fwiw... rubygems.org was one of the only open source projects I contributed to on a regular basis (albeit once every year or two) and it was always a positive experience. Sorry its gone this way for you and others.
This all reminds me of the feelings after Merb was put down after pressure from Engine Yard so they could guard against their Ruby on Rails hosting business.
hosh
Do you have a source for that? I always wondered why Merb disappeared, even after Katz refactored Rails to use ideas from Merb.
bradly
Straight from the Katz mouth via https://yehudakatz.com/2020/02/19/together-the-merb-story/:
> But not everyone felt so good about it. I worked for Engine Yard, and we had made our mark selling Ruby on Rails deployment to large customers like Groupon, Kongregate and Github. I got hired at Engine Yard in part because the company's founders were worried that Rails wouldn't make it long-term. They wanted to hedge against this possibility.
> Unfortunately for me, waging an all-out war against Ruby on Rails from inside of a company that makes its money selling Ruby on Rails deployment is a pretty bad life strategy.
> I don't know everything that went on behind the scenes, but Engine Yard's management eventually asked me to consider merging with Rails. If I'm being honest, they pushed me to consider merging with Rails.
I'm sure there were other reasons for the merge as well, and I don't want to take anything away from Yehuda and the decision he made at the time, but I was a volunteer at the first MerbConf just a couple months before the "merge" and it all felt very sudden and at odds with the direction the project was headed. I had my cynical take that EY was behind the move, but those were just my personal feelings. Honestly it was refreshing to read Yehuda's story 12 years later as it helped put some of the pieces together as to why.
jonquark
For those (like me) who didn't understand what MINASWAN means, it stands for Matz Is Nice And So We Are Nice: https://en.m.wiktionary.org/wiki/MINASWAN
chuckadams
Not that he has any real power here, but has anyone asked Matz what he thinks about all this?
kimos
He usually just stays out of this stuff.
The funny thing about inventing a language you love, is you spend your career writing C rather than actually writing code in the language you love.
pmontra
> My critique is directed at the process, not at people.
People are not logs floating helplessly in a river. People take decisions and make things happen. They create and run the process, not viceversa.
The critique must be directed at people.
Terr_
Right, people build Unaccountability Machines [0] to shield themselves, which range from justified to malicious.
[0] https://press.uchicago.edu/ucp/books/book/chicago/U/bo252799...
dzdt
This post jumps into the center of some controversy in a very unclear place. Is there a short (preferably neutral) summary of what this is all about somewhere?
LightBug1
See the link in the third paragraph of this fine article.
dygd
Discussed today: https://news.ycombinator.com/item?id=45348390
IshKebab
[flagged]
jcmfernandes
Where to start...
DHH created Rails, but he didn't write Rails - a large community did. This is an attempt to be factual. Linus created Linux, but he didn't write Linux. Etc.
Criticizing an *individual* for stopping to *donate* is pointless.
null
cortesoft
You picked ONE of the controversial things DHH has written about, and you chose one of the least controversial ones.
Analemma_
[flagged]
nenenejej
The solution is to design package managers around the uniform resource identifier: a way to locate online assets that is mostly (ignoring DNS) decentralised and better than having one org own all the packages.
notatallshaw
Taking PyPI as a central place of packages, it is known that their bandwidth bill would be $1.8+M per month (https://dustingram.com/articles/2021/04/14/powering-the-pyth...) were it not for Fastly giving them a 100% discount.
Are there any reliable decentralized package distribution systems operating at within 2 orders of magnitude of that scale? How do they handle administrative issues such as malicious packages or name squatting? Standards updates? Enforcement of correct metadata? And all the other common things package indexes need to handle.
I'm clearly skeptical, but would be very interested in any real world success stories.
hellcow
Go does this, and I’d say it’s been highly successful.
cortesoft
You can absolutely use bundler and gem without touching the rubygems servers. You can point to an alternate rubygems host (including one you run yourself), point to a git repo, or a local gem file source
rmoriz
This resembles the "monolith" vs "micro-services" discussion. If you spread the packages over thousands of domains, hosts, providers, reliability will be horrible. And it's uncontrollable. In theory, RubyGems could run code analyzers on all uploads to detected malware. Good look if you just haven an index of repositories/packages hosted elsewhere.
hosh
That sounds like a neat idea. Do you have a proposal for that?
Would it be compatible with specifying urls (such as git repos)?
hiharryhere
Bundler already does this.
# From a specific branch
gem 'my_gem', git: 'https://github.com/user/my_gem.git', branch: 'development'
# From a specific tag
gem 'my_gem', git: 'https://github.com/user/my_gem.git', tag: 'v1.2.3'
# From a specific commit (ref)
gem 'my_gem', git: 'https://github.com/user/my_gem.git', ref: 'a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0'the__alchemist
Tangent: IMO this is why you keep your repos under your account, and don't give them over to a group acct. Unless you no longer want/care about control, or things like this happening. If that's the case and you've moved on or are OK with moving on, then do the group account.
duxup
Someone took over the supply chain … to save the supply chain from someone taking it over?
fencepost
As a complete outsider I mostly find myself wondering if there's legal recourse for those who were forced out (noting the clear distinction that one person was commenting on between the service owned by Ruby Central and the code that Ruby Central likely has no legal claim to).
ChrisArchitect
Related:
Shopify, pulling strings at Ruby Central, forces Bundler and RubyGems takeover
https://news.ycombinator.com/item?id=45348390
Ruby Central's Attack on RubyGems
https://news.ycombinator.com/item?id=45299170
A board member's perspective of the RubyGems controversy
1a527dd5
Crazy to see that embrace, extend, and extinguish are still fundamental game plans.
I guess the only lesson here is trust no one and keep your repos under your account.
istjohn
How does this fit the EEE pattern? For reference, here is Wikipedia's description of EEE:
> "Embrace, extend, and extinguish" ... is a phrase that the U.S. Department of Justice found was used internally by Microsoft to describe its strategy for entering product categories involving widely used open standards, extending those standards with proprietary capabilities, and using the differences to strongly disadvantage its competitors.
Not every instance of corporate bad behavior in open source is EEE. Shopify isn't in competition with open source or potentially threatened by open source. They are not extending open standards or technology.
Maybe I'm being pedantic, but I'd rather not muddy the water with unhelpful, sloppy metaphors.
Contextually it might be relevant that Ruby Central said they wanted to have a Zoom call today to explain everything, then cancelled it. This was their message.
"Hello Ruby Community, We recognize that our originally scheduled Q&A session overlaps with the observance of Rosh Hashanah and may not have been the best timing for many in our community. We sincerely apologize for the short notice of this change, especially since the session was set to take place tomorrow. In response to the feedback we’ve received, we’ve made the decision to postpone the session. A new date and time will be shared with you in the coming days. In the meantime, we invite you to watch this statement from our Executive Director. This update is intended to ensure everyone receives the same information and can view it at a time that works best for them."