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.
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.
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.
> 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.
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.
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.
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.
> 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.
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 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.
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.
43 comments
[ 3.4 ms ] story [ 68.2 ms ] threadThey were stolen from André Arko, Colby Swandale, David Rodríguez, Ellen, Josef Šimánek, Martin Emde and Samuel Giddins.
Edit: Seems like maybe a hostile take-back actually.
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 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'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.
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.
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."
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!).
I'm sorry for Ruby people that are negatively impacted, tho.
Lastly, Matz is the best!
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...
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.