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?
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.
I can't believe that long gone maintainers still had root access, or any access at all to the core platform. Its has been wild to see ruby community members getting upset with modern and established security norms, for a platform that runs a lot of the web. Its not 2006 anymore, and we aren't just running random curl commands off the net to get rails installed. Scary to think how naive the backlash has been. Having an unmaintained security posture that is inherently insecure, just blows my mind. That supply chain was wide open to attacks, may still be, but at least someone tried to bring security up to this decade.
Trying and doing aren’t the same thing. I’ll take competent community members over incompetent leadership any day of the week. And I am right to think so, seeing how they entirely bungled even kicking out the people they wanted kicked out. They literally had their first security incident at second zero of their attempt to “bring security up to this decade”.
* 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.
> having multiple sources like gem.coop is probably a safer and more robust solution
I prefer the Go solution where the package manager uses the git repos instead of a separate package index that might or might not correspond to the git repos.
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?
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.
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).
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.
> As the nonprofit steward of this infrastructure, Ruby Central has a fiduciary duty to safeguard the supply chain and protect the long-term stability of the ecosystem. In consultation with legal counsel and following a recent security audit, we are strengthening our governance processes, formalizing operator agreements, and tightening access to production systems.
It took less than two weeks from this statement for them to put out an incident report from them forgetting to change the password on the infrastructure they took from the previous maintainers. I can't say I'm shocked that this didn't actually result in people's confidence in their ability as steward to provide long-term stability for the ecosystem.
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").
I spend most of my time writing go (among other languages).
Candidly its decentralized nature when it comes to "packages" is one of its strengths. It does have downsides, and yes GitHub could be at issue at some point.
After this, after NPM compromises (left pad and more recently the supply chain attacks) why we arent seeing more community driven changes around decentralization and venturing is beyond me.
I don't think anything about the NPM supply chain attacks has to do with it being centralised. If anything, it made it easier to heal as NPM could centrally remove the bad packages.
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.
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.
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.
This is only a win for Ruby Central. They haven't conceded anything and they've convinced Ruby Core to endorse them as the correct and true maintainers of RubyGems.
> While repository ownership has moved, Ruby Central will continue to share management and governance responsibilities for RubyGems and Bundler in close collaboration with the Ruby core team.
Andre has previously maintained that he owns a trademark on Bundler and he will enforce it against Ruby Central.
So Ruby Central transfers "ownership" of Bundler to Ruby Core. Ruby Central gets to continue to maintain Bundler, and Ruby Core is stuck with the liability. If Andre wants to enforce his trademark, he now has to sue Japan-based Ruby Core and risk the bad optics of that.
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).
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.
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?
No, no, no, this isn't the open source way at all! I can't believe you aren't getting it still!
Because I once installed your project, I need to:
- Take over all of the accounts/access you AND all of your friends/co-maintainers used in connection with it
- Tell you it was a mistake, give back access temporarily
- Do it again!
- Have one of my board members who happens to be the treasurer say it was about the $
- Make a straight to camera YouTube post Addressing The Concerns
- Make a first "continuing our series of transparency" blog post a week later, where I use a dense corporate laden dialect to claim it was for the betterment of all mankind and definitely not about the $; because I need you to understand Where We Are Now; What This Is and What This Isn't.
- Open a Google forms question submission box.
- Smear your reputation, because you had an idea once about tracking which packages go to which companies; so I'll insinuate that you want to read everyone's mail and snoop through their undergarments drawer. What's that? My actions affected much more than just you? Quiet now, we're reshaping the narrative to smear you.
- Answer no questions, explaining that we chose to give you a regular series of Friday updates; but also We Want to Move On from the back and forth but also in that same publication have another go at the smear, because it partially worked.
- Donate the project to my state library, to take some of the heat off of me
Isn't that so much easier than typing "git clone" and "git remote add"?
(I am consistently flummoxed that a handful of people here are buying this narrative; instead of as you point out... Just applying a smidgeon of critical analysis about the usage of tools that the majority of us must use day to day and coming to the conclusion you do.
Instead of doing this or accepting this conclusion, there's a frothy passion it seems for Appeal to Authority/Argument from Authority where any excuse, flaw, etc on the part of the maintainers is used to justify the whole chain of events.
It seems like it hits 5-7 facts and people can no longer manage them in short term memory, go and look at more than what is presented to them by a single party, etc; so they just default to the easiest mental shortcut.
For some reason I keep falling into the trap that "people are more educated, capable of critical thinking, and have easier access to data than ever before in history"; which I rationally know is not true)
seems to me they can happily go back to contributing to the tools, and at the same time ignore the fact that rubygems.org exists, by running gem.coop or whatever else.
Readit News
Dead Comment
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?
* 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.
Deleted Comment
Deleted Comment
I prefer the Go solution where the package manager uses the git repos instead of a separate package index that might or might not correspond to the git repos.
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).
No serious business with real (business) customers will accept that kind of risk and gem.coop will never be a thing outside of hobbyists.
It tripples the attack surface making it more vulernable to having security vulnerabilities.
It took less than two weeks from this statement for them to put out an incident report from them forgetting to change the password on the infrastructure they took from the previous maintainers. I can't say I'm shocked that this didn't actually result in people's confidence in their ability as steward to provide long-term stability for the ecosystem.
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").
Candidly its decentralized nature when it comes to "packages" is one of its strengths. It does have downsides, and yes GitHub could be at issue at some point.
After this, after NPM compromises (left pad and more recently the supply chain attacks) why we arent seeing more community driven changes around decentralization and venturing is beyond me.
> 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.
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.
I'm considering switching to Erlang, which was developed at a corporation from the start and appears to be drama and cancel free.
> While repository ownership has moved, Ruby Central will continue to share management and governance responsibilities for RubyGems and Bundler in close collaboration with the Ruby core team.
Andre has previously maintained that he owns a trademark on Bundler and he will enforce it against Ruby Central.
=> https://andre.arko.net/2025/09/25/bundler-belongs-to-the-rub...
So Ruby Central transfers "ownership" of Bundler to Ruby Core. Ruby Central gets to continue to maintain Bundler, and Ruby Core is stuck with the liability. If Andre wants to enforce his trademark, he now has to sue Japan-based Ruby Core and risk the bad optics of that.
Well,
1. He's not fighting Ruby Central anymore, he'd be fighting the Ruby core team.
2. He's going to have a tough time asserting copyright on a name he didn't come up with on a project which shipped v1 before he joined.
3. If he believes the trademark belongs to the community, the right thing to do would be to transfer it to Ruby Core then, right?
Deleted Comment
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:
https://xkcd.com/927/
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.
I'm sorry for Ruby people that are negatively impacted, tho.
Lastly, Matz is the best!
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?
Not really. Shopify threatened to pull funding for them which set the whole thing in motion
Because I once installed your project, I need to:
- Take over all of the accounts/access you AND all of your friends/co-maintainers used in connection with it
- Tell you it was a mistake, give back access temporarily
- Do it again!
- Have one of my board members who happens to be the treasurer say it was about the $
- Make a straight to camera YouTube post Addressing The Concerns
- Make a first "continuing our series of transparency" blog post a week later, where I use a dense corporate laden dialect to claim it was for the betterment of all mankind and definitely not about the $; because I need you to understand Where We Are Now; What This Is and What This Isn't.
- Open a Google forms question submission box.
- Smear your reputation, because you had an idea once about tracking which packages go to which companies; so I'll insinuate that you want to read everyone's mail and snoop through their undergarments drawer. What's that? My actions affected much more than just you? Quiet now, we're reshaping the narrative to smear you.
- Answer no questions, explaining that we chose to give you a regular series of Friday updates; but also We Want to Move On from the back and forth but also in that same publication have another go at the smear, because it partially worked.
- Donate the project to my state library, to take some of the heat off of me
Isn't that so much easier than typing "git clone" and "git remote add"?
(I am consistently flummoxed that a handful of people here are buying this narrative; instead of as you point out... Just applying a smidgeon of critical analysis about the usage of tools that the majority of us must use day to day and coming to the conclusion you do. Instead of doing this or accepting this conclusion, there's a frothy passion it seems for Appeal to Authority/Argument from Authority where any excuse, flaw, etc on the part of the maintainers is used to justify the whole chain of events.
It seems like it hits 5-7 facts and people can no longer manage them in short term memory, go and look at more than what is presented to them by a single party, etc; so they just default to the easiest mental shortcut.
For some reason I keep falling into the trap that "people are more educated, capable of critical thinking, and have easier access to data than ever before in history"; which I rationally know is not true)
I don't believe this has anything to do with DHH.
https://github.com/rubygems/rfcs/pull/61