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.
> 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?
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).
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.
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.
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?
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.
Does that mean RubyCentral or anyone associated with them no longer have admin access to RubyGems GitHub organization? Watching the debacle unfold made me much less trusting of their "stewardship".
It's good to hear Ruby core team took the ownership. Thank you Matz.
Well - I'd actually argue that it would be better and simpler if there would be just one binary. How it is called is IMO secondary. It would be better if the whole API would be unified. Bundler came later though.
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.
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
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.
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.
rubygems.org will still be operated by Ruby Central, though, so you still have to trust them. Given the state of affairs, this is less than ideal, but it’s probably a better outcome than nothing changing.
As someone who spent a bunch of time talking before and after this all went down with current and past RubyGems maintainers, RubyCentral employees, Gem.coop maintainers and Ruby Core folks: this seems like the best outcome that was actually attainable.
I've been working on Homebrew for 16 years and leading it for some proportion of that and this all "smells" like a more sustainable long-term solution than anything we've seen happen in the last year. Some proposals sounded nicer but were not going to be acceptable to one or more sides.
Ruby already provides a vendored version of RubyGems and (more recently) Bundler so this seems appropriate. It also separates the "running a web service" which has guaranteed hosting costs, requires on-call, etc. from "running an open source CLI/library" which has no guaranteed costs.
It will be interesting to see what the Gem.coop folks do now (disclaimer: I helped them with their governance process). If there's some competition for rubygems.org as a server implementation that feels like a good thing for the community overall.
Thank you for your work in this arena and trying to add clarity. As a business owner and longtime rubyist, I'm very happy Ruby Core is taking stewardship here and that maybe we can put this tempest in a teapot behind us.
Other than personal preference, are there any features that make Ruby worth considering for new apps? As a user, my experience with gems hasn't been great. I don't know any Ruby, I'm just asking out of curiosity.
Ruby by itself is still a pretty decent scripting language. I still think Rake is highly underrated as a command runner.
Rails is still a good web framework within its limits. If you want to build a small, modest complexity web app with like 1 or 2 developers and under maybe 6 months of active development, modest traffic needs, etc, it's a good way to get everything up and running fast with best-practices for everything.
The lack of types may start to pinch some once you get an order of magnitude more developer-months into the app than that. Lack of overall speed, threading issues, and memory usage may be an issue once you get a few orders of magnitude more traffic. But while you're within those limits, I think you'll get features out on it faster than any other language or framework.
As they say, a lot more startups have died due to not being able to iterate fast enough in the early stages than from their traffic capacity, hosting efficiency, and bug count once they get into serious growth.
I’ve been writing Ruby profesionally for over a decade and while the writing has been on the wall for almost the entire time, it’s more certain than ever that Ruby is on its last legs.
Big legacy companies who have invested heavily into Ruby cannot switch but every shop I’ve been at often started new services in non-Ruby (mostly Go but have seen plenty of Node/TS as well or Rust for that matter).
If I were to start a new app Ruby would be far from my first choice and the biggest reason are types. After being in the weeds of big Rails apps while also working with Go/Ts/typed Python, Ruby seems very fragile in big codebases. Sorbet is also not enough.
I've used Ruby off and on since the hype train started with DHH's early videos showing how easily you can make a blog in Rails. Oof, that was published 20 years ago! I wouldn't use it for anything beyond simple shell scripts these days. You're better off with Go for back-end work.
Was there ever a mirror of this dustup in the Linux distro community?
I'm unaware of one ever happening, and I'm wondering whether it's because of mere fortune or because there's something about the APT / dpkg model that precludes this kind of messiness.
Perhaps the Ruby community is suffering the curse of having lived with reliable Internet for so long they never had to solve the problem of building up automatic package mirrors? This just feels like a lot of words and energy burned on a problem that ought to be as simple as "Here's the package, here's its checksum, go to town."
The fact that you speak of "the Linux distro community" but also "the APT / dpkg model" is already telling. Most distros — i.e., everything not derived from Debian — don't even use the same package format. A lot of the problem has been mitigated simply by letting people choose among competitive suites of alternatives.
That said, there's been quite a bit of drama lately in prominent Linux projects — notably bcachefs, X11 (and the fork XLibre), and the Omarchy distribution (even connected to the current story!).
There was - see old systemd discussions. For instance, how devuan was started.
It is not 1:1 comparable though. Ruby, python etc... have a much more varied community. People contribute code. Only few contribute to the linux kernel directly. There are many more who write "apps", so this could be comparable. Still it feels different to me, since a language community is different to a community that uses different programming languages.
> Perhaps the Ruby community is suffering the curse of having lived with reliable Internet for so long they never had to solve the problem of building up automatic package mirrors?
No, I think it is more that people never anticipated that corporations could take over projects. This has become more of a problem in the last years. Who controls github, for instance?
> This just feels like a lot of words and energy burned on a problem that ought to be as simple as "Here's the package, here's its checksum, go to town."
This is the issue of decentralized hosting versus top-down control. Ruby didn't have that problem in the past. It became more of an issue in the last some years. See DHH having an old tweet where he pointed out that he wants more control; I think this was from 2018. I don't remember it fully but it is on the ruby reddit.
Ideologically-rooted dustups are popping off all across open source right now, it seems. Forks-included.
I've even seen unironic claims of certain pieces of technology containing "Hitler particles". That shook me a bit because that's an old in-joke and was always intended to be a joke...
This is a fascinating and seemingly unusual development that will look obvious in history.
I find “BDFLs” and open source communities so incredibly interesting. Especially in the context of geopolitics and state entities. Linux!
This stuff is PHD material for sociology and polisci post-grads and I’m so interested in following the progression of history with these types of things.
I don't think BDFLs are a problem. Nobody questioned, say, guido design of python or matz' design of ruby as such. The issue here is primarily about who controls the ruby ecosystem. Interestingly python also had a somewhat similar discussion in the past; you can see this indirectly if you look at pypi:
I feel like BDFLs are akin to the concept of village elders; they're not immune to corruption or scandal, but they often have this beloved status that can paper over a lot of cracks. That's probably dependant on their leadership style - the hard headed (Linus, DHH) vs the grandfatherly (Matz, Van Rossum).
Which, going back to your note on geopolitics, leads me to wonder: Is it just that more power corrupts more, or is it that (modern-day definitions of) democracy require a desire for power? I guess as the "FL" part of "BDFL" comes to bite more of the communities, we'll see better how different succession styles have different effects. I also wonder if the analytical nature of the individuals within the "populations", and inability to police defectors will mean uprisings will be more successful, either in causing BDFL attitude adjustments, or just overturning the community completely (for example, there's already a lot of momentum for a complete fork of Rails)
(Edit: having submitted this, I now see others have had very similar thoughts! Definitely an excellent conversation topic)
> I find “BDFLs” and open source communities so incredibly interesting. Especially in the context of geopolitics and state entities. Linux!
The diference is that with an open source licence, the comunity can just fork the project (assuming they have enough developers), so the BDFL must master the art of herding cats.
A country has clear phisical borders and tanks, and people can't fork them and ignore the old power structure.
I think you're absolutely right. We are starting to reach the age where a combination of large cooperative non-corporate tech projects and the Internet (that, partially at least, enabled them) are putting us in a place where the actual mortality of project owners matters. The "L" in BDFL is a finite constraint.
I think there's going to be an interesting and complicated churn as several major projects under the BDFL model have their Ds succeed at passing the torch, struggle to pass the torch, struggle to realize the torch needs to be passed, or take the torch and do their best to burn the whole project down so it can't outlive them.
Does this potentially mean that RHEL will include more gems in their supported repos? It would be nice to script in Ruby instead of having to do everything in Python. Ruby is maybe my favorite language simply because of how it flows from left to right and how functional idioms come so naturally. But adding a gem sourced from community would be a hassle for my organization.
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.
Alive and well. I write Ruby every day and enjoy doing so. It's the only thing that consistently got better for me in the last 10+ years without losing it's simplicity and joy. Ruby is truly a programmer's best friend.
Oh no, looks like you're one of today's (unlucky) 10000[0]. (For context I only heard about all this recently).
For the DHH thing he wrote a recent blog post where he said he wants fewer non-white people in London and praises an english far-right fascist figure (Tommy Robinson)[1].
Not really sure about the Shopify stuff. I've heard people aren't too fond of Tobi (the C.E.O. I think), and he's buddies with DHH, but it could just be general distrust of a big company trying to exert control of an open source project (through Ruby Central).
this is good and I hope this puts a lot of the drama in the rearview mirror. younger developers coming across Ruby must be like "wtf" about this situation. very peculiar to have these projects so politicised and I say that to the people that "try and keep politics out" (DHH) more than anyone. making your politics known and then being like "but you're not allowed to have an opinion on it" is't cute or clever. it's childish and everyone everywhere deserves to be treated with more respect than that.
But how does this solve anything? People will still not trust Ruby Central. And rubygems.org is under control by Ruby Central, even IF ruby core tries to jump in to the rescue.
He's also in a bit of a unique situation because of his public political profile was essentially forced.
- Politics at work were becoming a huge problem at 37Signals
- They asked that politics be kept out of company chats, but encouraged people to be political active on non-work channels/social media/etc even during work hours
- People lost their minds at this incredibly reasonable request which then blew up on the internet
- They offered any employee 6 months severance if they weren't comfortable with the new policy. About 1/3 of the company took it.
- Rails Conf dis-invited the creator of Rails
- Obviously, this was not going to sit well as people were trying to create a very public political flex against DHH and at that point, he started getting much more vocal about the problem of politics sweeping into every aspect of life.
In the following years...
- DHH becomes very publicly outspoken against politics infecting everything
- 37 Signals publishes another successful book
- Ships much more quickly as all of the people constantly distracted by politics at work are no longer in the building
- Starts the Rails World conference to great success
- Rails Conf shuts down
- DHH ships Omarchy which is getting significant support
So the end result has been that a bunch of people tried to essentially "cancel" DHH and the result was him having virtually non-stop, resounding success while publicly speaking out against those who created the problem in the first place...because some people really do just want to build cool things regardless of your politics.
> making your politics known and then being like "but you're not allowed to have an opinion on it"
As far as I can tell, this doesn't fairly reflect what actually happened. Ruby users were free to keep their own political views to their own blogs, just as DHH does. Reading world dot hey dot com slash dhh is not in any way required in order to use Ruby, participate in the development of Ruby or anything else along those lines.
There are a lot of prominent developers in the Python community whose politics I strongly disagree with. I got banned from the main discussion forum as a result of objecting to hidden Code of Conduct enforcement principles which (in my view) attempted to bring (many of) those politics in through the back door. (And in the process of getting into that meta argument, and doing research, I encountered several previous unpleasant incidents on the forum and on the mailing list that preceded it.)
But I would never start arguments with people in that space over things they wrote on their blogs. I would not go onto, say, the CPython issue tracker to complain about how certain people needed to be removed from the project because of things they said in their own spaces (like we saw with, for example, Opalgate). If I wanted to talk about someone else's politics — or my own — I would and could use my own blog for that.
The mere fact of people knowing DHH's politics emphatically does not politicize Ruby, Rails or any related project. To the extent that Python development has become politicized, that's a consequence of actual enacted policy, not the political beliefs of steering committee members, PSF board members etc. DHH putting this content on his blog was part of the effort to have it not in the workplace. And, in point of fact, that does keep it out of 37Signals board rooms.
There are numerous questions here, but also a few answers.
For instance, I pointed out days ago that Hiroshi Shibata did not act solo. Now this is confirmed - it was a matz directive. The main question to ask here is: could he not have made this open AND public from the get go? It would have lessened the confusion for some people.
Unfortunately this also has a few added problems now, because ... say that you are an indie dev or a solo dev. Would you want to "interact" with the ruby core team if they can just oust people at will if they feel they need more top-down control? Or, worse, if they only get money if companies pay them to do so? I am not necessarily saying there was a 1:1 connection with money in mind. For instance, the bin/gem was not designed by the ruby core team, in many ways was a mistake from the get go - see how Rust avoided this by having cargo. But one can not help but wonder how deep that money situation goes. u/jrochkind on reddit pointed that out, e. g. that there is very clearly a connection to ruby losing users and developers in the last ~5 years, and a dry-up of financial assets in general. I agree with him. Even if this was not the case here (though I somewhat suspect money had to do with many things here), the situation for ruby in general is really really bad. Perhaps matz felt that this was the only way forward, who knows. Either way it is not a good situation to be had.
It also shows how ruby is WAY too dependent on rails. If rails sinks, ruby sinks. That is BAD. DHH may contribute to this problem with the "I am the richest neo-boy in the USA" and odd blog entries (that's his though, he can write whatever he wants to), but the moment there is a financial interconnection is the moment there is no longer a fair field. And this is really bad, because it means ruby as such will be pulled by those who have money. Bye bye solo devs - you no longer have a place in the corporate infrastructure. And make no mistake about this: rubygems.org is a pure corporate entity now. Look at the new rules they forced onto everyone: https://blog.rubygems.org/2025/07/08/policies-live.html
"Isn't supply chain security a corporate concern?"
And then he weakly tries to say "no, it isn't because corporations finance us now, it is all about LOVE, HAPPINESS and THE COMMUNITY". But in reality - it absolutely is. Corporations wanted more guarantees and these inrastructure-maintainers said "that's ok - we don't pay these indie devs anything but now we force them into mandatory 2FA, ad-hoc 100.000 restrictions (can not remove your gem past that limit) and any other random crap, such as not paying them anything and having them work for us for free". I am sorry but there are soooooooo many things going wrong here - I totally agree with duckinator. This was a hostile take-over, unfortunately now we also know that it was decided from within ruby-core itself.
Note that I am not saying that it is a bad idea to have something such as gem maintained by the ruby core team, I totally understand the reason for this, and I also pointed at the example of rust/cargo. However had, the infrastructure shouldn't be a money-injection team for the ruby core team - the moment this happens is the moment things no longer work here. And ruby isn't merely the part designed by the core team; it also isn't just rails - you had many more people who contributed to ruby in the form of the ecosystem. Granted, many projects are abandoned (this is also a problem for rubygems.org by the way) but at the least this used to be true in the past.
In a way this is all a bit rubbish, because we see MIT/BSD licences, so people could just fork ruby (not that this is likely; I haven't seen anyone object to matz being an excellent language designer. I also don't think it is a problem if matz and the core team profit from this financially, that's perfectly fine. But the whole ecosystem shouldn't be in such a top-down control where corporations just buy their way into things, with DHH making snide remarks on his blog ("we got rid of the boys controlling the infrastructure now") all of the time while on Shopify's payroll - that is no longer a fair playing field here. Everyone can see this.)
Also, if matz made the decision weeks ago and told Hiroshi to do so, HOW was this fair to Mike McQuaid? The latter said he tried to act as man in the middle. But if the decision was made to finalize on this already prior to that, was Mike told that? If not, how is that fair? Either way I guess Mike gets the most praise from all sides simply for trying.
We'll see what happens, whether people love the new corporate-controlled rubygems.org or prefer gem.coop (which, admittedly, still have to deliver). I favour the latter, like the rising phoenix from the ashes - in part because I hated the new corporate rules that was installed onto rubygems.org, including the crap 100.000 download limit, but in part also because I feel that if gem.coop gets enough momentum overall, they can actually begin to solve NUMEROUS issues in the ruby ecosystem, from documentation to namespaced accounts (users and the ruby code as such, see duckinator's proposal) and so forth. Considering the damage shopify caused while wanting to control more of the ruby ecosystem, I expect them to now send more workers to go and improve rubygems.org as much as possible - and not ruin things in the process. Otherwise they would have only caused damage without any real gains.
The biggest loser in this are actually the folks at RubyCentral. Because ... what have they really ever done for the ruby community? Which high profile gems have they maintained? Just throwing fancy parties isn't going to cut it - Titanic was also sinking when it hit an iceberg. RubyCentral may still celebrate while sinking ...
Speaking of Phoenixes this whole debacle made me start diving into Elixir/Phoenix. My first impression is that I much prefer Ruby as a language, however I'm struggling to even think of using Rails currently.
They did not WRITE RubyGems, they inherited it and evolved it. Chad, David, Jim (RIP), Paul and I wrote RubyGems. I hosted RubyGems from my home in Virginia for several years before we could cover the cost of colocation and stood up RubyForge. Its nice to look at the near history and think that this is all of history but it is not. Ruby Central has always been the stewards of RubyGems and then later, Bundler.
So what? NPM wasn't originally owned by Microsoft, nor GitHub, but reality moves forward?
As long as Matz is involved, I have a lot of faith things will get better, not worse, unless you have some strong indication of otherwise. If anything, because things will be nicer.
Some comments were deferred for faster rendering.
sebiw|4 months ago
delichon|4 months ago
dluan|4 months ago
downrightmike|4 months ago
neya|4 months ago
pabs3|4 months ago
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.
lyu07282|4 months ago
shevy-java|4 months ago
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).
charcircuit|4 months ago
It tripples the attack surface making it more vulernable to having security vulnerabilities.
byroot|4 months ago
gcr|4 months ago
pebble|4 months ago
zer00eyz|4 months ago
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.
white-moss|4 months ago
shevy-java|4 months ago
> 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.
joshmn|4 months ago
MatthiasPortzel|4 months ago
> 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.
ergocoder|4 months ago
baggy_trough|4 months ago
shevy-java|4 months ago
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.
mring33621|4 months ago
I'm sorry for Ruby people that are negatively impacted, tho.
Lastly, Matz is the best!
mring33621|4 months ago
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?
AnonHP|4 months ago
riffraff|4 months ago
codesnik|4 months ago
krmbzds|4 months ago
It's good to hear Ruby core team took the ownership. Thank you Matz.
dismalaf|4 months ago
shevy-java|4 months ago
james_marks|4 months ago
jcmfernandes|4 months ago
prh8|4 months ago
binary132|4 months ago
ivan_gammel|4 months ago
__float|4 months ago
I'm not counting something like C++ where there's effectively no "packages" to speak of.
ergocoder|4 months ago
gardnr|4 months ago
gcr|4 months ago
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
joshmn|4 months ago
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.
jrochkind1|4 months ago
andsmedeiros|4 months ago
byroot|4 months ago
shevy-java|4 months ago
winterqt|4 months ago
dismalaf|4 months ago
mikemcquaid|4 months ago
I've been working on Homebrew for 16 years and leading it for some proportion of that and this all "smells" like a more sustainable long-term solution than anything we've seen happen in the last year. Some proposals sounded nicer but were not going to be acceptable to one or more sides.
Ruby already provides a vendored version of RubyGems and (more recently) Bundler so this seems appropriate. It also separates the "running a web service" which has guaranteed hosting costs, requires on-call, etc. from "running an open source CLI/library" which has no guaranteed costs.
It will be interesting to see what the Gem.coop folks do now (disclaimer: I helped them with their governance process). If there's some competition for rubygems.org as a server implementation that feels like a good thing for the community overall.
Good luck to all involved on all sides.
ScotterC|4 months ago
notepad0x90|4 months ago
ufmace|4 months ago
Rails is still a good web framework within its limits. If you want to build a small, modest complexity web app with like 1 or 2 developers and under maybe 6 months of active development, modest traffic needs, etc, it's a good way to get everything up and running fast with best-practices for everything.
The lack of types may start to pinch some once you get an order of magnitude more developer-months into the app than that. Lack of overall speed, threading issues, and memory usage may be an issue once you get a few orders of magnitude more traffic. But while you're within those limits, I think you'll get features out on it faster than any other language or framework.
As they say, a lot more startups have died due to not being able to iterate fast enough in the early stages than from their traffic capacity, hosting efficiency, and bug count once they get into serious growth.
adamors|4 months ago
Big legacy companies who have invested heavily into Ruby cannot switch but every shop I’ve been at often started new services in non-Ruby (mostly Go but have seen plenty of Node/TS as well or Rust for that matter).
If I were to start a new app Ruby would be far from my first choice and the biggest reason are types. After being in the weeds of big Rails apps while also working with Go/Ts/typed Python, Ruby seems very fragile in big codebases. Sorbet is also not enough.
kingnothing|4 months ago
shadowgovt|4 months ago
I'm unaware of one ever happening, and I'm wondering whether it's because of mere fortune or because there's something about the APT / dpkg model that precludes this kind of messiness.
Perhaps the Ruby community is suffering the curse of having lived with reliable Internet for so long they never had to solve the problem of building up automatic package mirrors? This just feels like a lot of words and energy burned on a problem that ought to be as simple as "Here's the package, here's its checksum, go to town."
zahlman|4 months ago
That said, there's been quite a bit of drama lately in prominent Linux projects — notably bcachefs, X11 (and the fork XLibre), and the Omarchy distribution (even connected to the current story!).
shevy-java|4 months ago
It is not 1:1 comparable though. Ruby, python etc... have a much more varied community. People contribute code. Only few contribute to the linux kernel directly. There are many more who write "apps", so this could be comparable. Still it feels different to me, since a language community is different to a community that uses different programming languages.
> Perhaps the Ruby community is suffering the curse of having lived with reliable Internet for so long they never had to solve the problem of building up automatic package mirrors?
No, I think it is more that people never anticipated that corporations could take over projects. This has become more of a problem in the last years. Who controls github, for instance?
> This just feels like a lot of words and energy burned on a problem that ought to be as simple as "Here's the package, here's its checksum, go to town."
This is the issue of decentralized hosting versus top-down control. Ruby didn't have that problem in the past. It became more of an issue in the last some years. See DHH having an old tweet where he pointed out that he wants more control; I think this was from 2018. I don't remember it fully but it is on the ruby reddit.
busterarm|4 months ago
I've even seen unironic claims of certain pieces of technology containing "Hitler particles". That shook me a bit because that's an old in-joke and was always intended to be a joke...
elliotec|4 months ago
I find “BDFLs” and open source communities so incredibly interesting. Especially in the context of geopolitics and state entities. Linux!
This stuff is PHD material for sociology and polisci post-grads and I’m so interested in following the progression of history with these types of things.
shevy-java|4 months ago
https://blog.pypi.org/posts/2023-05-25-securing-pypi-with-2f...
See that question asked:
"Isn't supply chain security a corporate concern?"
He tries to bring arguments to invalidate that. And failed in an epic manner. Now people are more suspicious than before. Kind of strange to see, too.
undecisive|4 months ago
I feel like BDFLs are akin to the concept of village elders; they're not immune to corruption or scandal, but they often have this beloved status that can paper over a lot of cracks. That's probably dependant on their leadership style - the hard headed (Linus, DHH) vs the grandfatherly (Matz, Van Rossum).
Which, going back to your note on geopolitics, leads me to wonder: Is it just that more power corrupts more, or is it that (modern-day definitions of) democracy require a desire for power? I guess as the "FL" part of "BDFL" comes to bite more of the communities, we'll see better how different succession styles have different effects. I also wonder if the analytical nature of the individuals within the "populations", and inability to police defectors will mean uprisings will be more successful, either in causing BDFL attitude adjustments, or just overturning the community completely (for example, there's already a lot of momentum for a complete fork of Rails)
(Edit: having submitted this, I now see others have had very similar thoughts! Definitely an excellent conversation topic)
gus_massa|4 months ago
The diference is that with an open source licence, the comunity can just fork the project (assuming they have enough developers), so the BDFL must master the art of herding cats.
A country has clear phisical borders and tanks, and people can't fork them and ignore the old power structure.
shadowgovt|4 months ago
I think there's going to be an interesting and complicated churn as several major projects under the BDFL model have their Ds succeed at passing the torch, struggle to pass the torch, struggle to realize the torch needs to be passed, or take the torch and do their best to burn the whole project down so it can't outlive them.
poemxo|4 months ago
runjake|4 months ago
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.
xbar|4 months ago
phoronixrly|4 months ago
didip|4 months ago
Is Ruby ecosystem doing well?
krmbzds|4 months ago
bm5k|4 months ago
rvitorper|4 months ago
Hoping for some context
Alifatisk|4 months ago
> Shopify demanded that Ruby Central take full control of the RubyGems
https://joel.drapper.me/p/rubygems-takeover
mijoharas|4 months ago
For the DHH thing he wrote a recent blog post where he said he wants fewer non-white people in London and praises an english far-right fascist figure (Tommy Robinson)[1].
Not really sure about the Shopify stuff. I've heard people aren't too fond of Tobi (the C.E.O. I think), and he's buddies with DHH, but it could just be general distrust of a big company trying to exert control of an open source project (through Ruby Central).
[0] https://xkcd.com/1053/
[1] https://world.hey.com/dhh/as-i-remember-london-e7d38e64
baggy_trough|4 months ago
[deleted]
unknown|4 months ago
[deleted]
tedchs|4 months ago
IshKebab|4 months ago
Edit: Seems like maybe a hostile take-back actually.
dismalaf|4 months ago
itsnowandnever|4 months ago
shevy-java|4 months ago
brightball|4 months ago
- Politics at work were becoming a huge problem at 37Signals
- They asked that politics be kept out of company chats, but encouraged people to be political active on non-work channels/social media/etc even during work hours
- People lost their minds at this incredibly reasonable request which then blew up on the internet
- They offered any employee 6 months severance if they weren't comfortable with the new policy. About 1/3 of the company took it.
- Rails Conf dis-invited the creator of Rails
- Obviously, this was not going to sit well as people were trying to create a very public political flex against DHH and at that point, he started getting much more vocal about the problem of politics sweeping into every aspect of life.
In the following years...
- DHH becomes very publicly outspoken against politics infecting everything
- 37 Signals publishes another successful book
- Ships much more quickly as all of the people constantly distracted by politics at work are no longer in the building
- Starts the Rails World conference to great success
- Rails Conf shuts down
- DHH ships Omarchy which is getting significant support
So the end result has been that a bunch of people tried to essentially "cancel" DHH and the result was him having virtually non-stop, resounding success while publicly speaking out against those who created the problem in the first place...because some people really do just want to build cool things regardless of your politics.
zahlman|4 months ago
As far as I can tell, this doesn't fairly reflect what actually happened. Ruby users were free to keep their own political views to their own blogs, just as DHH does. Reading world dot hey dot com slash dhh is not in any way required in order to use Ruby, participate in the development of Ruby or anything else along those lines.
There are a lot of prominent developers in the Python community whose politics I strongly disagree with. I got banned from the main discussion forum as a result of objecting to hidden Code of Conduct enforcement principles which (in my view) attempted to bring (many of) those politics in through the back door. (And in the process of getting into that meta argument, and doing research, I encountered several previous unpleasant incidents on the forum and on the mailing list that preceded it.)
But I would never start arguments with people in that space over things they wrote on their blogs. I would not go onto, say, the CPython issue tracker to complain about how certain people needed to be removed from the project because of things they said in their own spaces (like we saw with, for example, Opalgate). If I wanted to talk about someone else's politics — or my own — I would and could use my own blog for that.
The mere fact of people knowing DHH's politics emphatically does not politicize Ruby, Rails or any related project. To the extent that Python development has become politicized, that's a consequence of actual enacted policy, not the political beliefs of steering committee members, PSF board members etc. DHH putting this content on his blog was part of the effort to have it not in the workplace. And, in point of fact, that does keep it out of 37Signals board rooms.
shevy-java|4 months ago
For instance, I pointed out days ago that Hiroshi Shibata did not act solo. Now this is confirmed - it was a matz directive. The main question to ask here is: could he not have made this open AND public from the get go? It would have lessened the confusion for some people.
Unfortunately this also has a few added problems now, because ... say that you are an indie dev or a solo dev. Would you want to "interact" with the ruby core team if they can just oust people at will if they feel they need more top-down control? Or, worse, if they only get money if companies pay them to do so? I am not necessarily saying there was a 1:1 connection with money in mind. For instance, the bin/gem was not designed by the ruby core team, in many ways was a mistake from the get go - see how Rust avoided this by having cargo. But one can not help but wonder how deep that money situation goes. u/jrochkind on reddit pointed that out, e. g. that there is very clearly a connection to ruby losing users and developers in the last ~5 years, and a dry-up of financial assets in general. I agree with him. Even if this was not the case here (though I somewhat suspect money had to do with many things here), the situation for ruby in general is really really bad. Perhaps matz felt that this was the only way forward, who knows. Either way it is not a good situation to be had.
It also shows how ruby is WAY too dependent on rails. If rails sinks, ruby sinks. That is BAD. DHH may contribute to this problem with the "I am the richest neo-boy in the USA" and odd blog entries (that's his though, he can write whatever he wants to), but the moment there is a financial interconnection is the moment there is no longer a fair field. And this is really bad, because it means ruby as such will be pulled by those who have money. Bye bye solo devs - you no longer have a place in the corporate infrastructure. And make no mistake about this: rubygems.org is a pure corporate entity now. Look at the new rules they forced onto everyone: https://blog.rubygems.org/2025/07/08/policies-live.html
This also reminds me of Pypi, by the way:
https://blog.pypi.org/posts/2023-05-25-securing-pypi-with-2f...
Quote:
"Isn't supply chain security a corporate concern?"
And then he weakly tries to say "no, it isn't because corporations finance us now, it is all about LOVE, HAPPINESS and THE COMMUNITY". But in reality - it absolutely is. Corporations wanted more guarantees and these inrastructure-maintainers said "that's ok - we don't pay these indie devs anything but now we force them into mandatory 2FA, ad-hoc 100.000 restrictions (can not remove your gem past that limit) and any other random crap, such as not paying them anything and having them work for us for free". I am sorry but there are soooooooo many things going wrong here - I totally agree with duckinator. This was a hostile take-over, unfortunately now we also know that it was decided from within ruby-core itself.
Note that I am not saying that it is a bad idea to have something such as gem maintained by the ruby core team, I totally understand the reason for this, and I also pointed at the example of rust/cargo. However had, the infrastructure shouldn't be a money-injection team for the ruby core team - the moment this happens is the moment things no longer work here. And ruby isn't merely the part designed by the core team; it also isn't just rails - you had many more people who contributed to ruby in the form of the ecosystem. Granted, many projects are abandoned (this is also a problem for rubygems.org by the way) but at the least this used to be true in the past.
In a way this is all a bit rubbish, because we see MIT/BSD licences, so people could just fork ruby (not that this is likely; I haven't seen anyone object to matz being an excellent language designer. I also don't think it is a problem if matz and the core team profit from this financially, that's perfectly fine. But the whole ecosystem shouldn't be in such a top-down control where corporations just buy their way into things, with DHH making snide remarks on his blog ("we got rid of the boys controlling the infrastructure now") all of the time while on Shopify's payroll - that is no longer a fair playing field here. Everyone can see this.)
Also, if matz made the decision weeks ago and told Hiroshi to do so, HOW was this fair to Mike McQuaid? The latter said he tried to act as man in the middle. But if the decision was made to finalize on this already prior to that, was Mike told that? If not, how is that fair? Either way I guess Mike gets the most praise from all sides simply for trying.
We'll see what happens, whether people love the new corporate-controlled rubygems.org or prefer gem.coop (which, admittedly, still have to deliver). I favour the latter, like the rising phoenix from the ashes - in part because I hated the new corporate rules that was installed onto rubygems.org, including the crap 100.000 download limit, but in part also because I feel that if gem.coop gets enough momentum overall, they can actually begin to solve NUMEROUS issues in the ruby ecosystem, from documentation to namespaced accounts (users and the ruby code as such, see duckinator's proposal) and so forth. Considering the damage shopify caused while wanting to control more of the ruby ecosystem, I expect them to now send more workers to go and improve rubygems.org as much as possible - and not ruin things in the process. Otherwise they would have only caused damage without any real gains.
The biggest loser in this are actually the folks at RubyCentral. Because ... what have they really ever done for the ruby community? Which high profile gems have they maintained? Just throwing fancy parties isn't going to cut it - Titanic was also sinking when it hit an iceberg. RubyCentral may still celebrate while sinking ...
gls2ro|4 months ago
> Now this is confirmed - it was a matz directive.
I did not see any confirmation in this annoucement, do I miss something?
GreenWatermelon|4 months ago
Speaking of Phoenixes this whole debacle made me start diving into Elixir/Phoenix. My first impression is that I much prefer Ruby as a language, however I'm struggling to even think of using Rails currently.
dorianmariecom|4 months ago
joeldrapper|4 months ago
They were stolen from André Arko, Colby Swandale, David Rodríguez, Ellen, Josef Šimánek, Martin Emde and Samuel Giddins.
rich_kilmer|4 months ago
CaptainOfCoit|4 months ago
As long as Matz is involved, I have a lot of faith things will get better, not worse, unless you have some strong indication of otherwise. If anything, because things will be nicer.
dluan|4 months ago
claudiug|4 months ago
[deleted]