They 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'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.

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."

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 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 ...