Matz is a pillar. Remember "Matz is nice and so we are nice"? s/nice/nice and responsible/gc.

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.

Any summary of what exaclty unfolded please (if you don't mind)? Sorry haven't been following the Ruby news for sometime.

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

Agreed.

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

>multiple sources is safer

It tripples the attack surface making it more vulernable to having security vulnerabilities.

For context, also check out their previous statement from September 19, which also "reflects our shared commitment to the long-term stability and growth of the Ruby ecosystem" [sic]: https://rubycentral.org/news/strengthening-the-stewardship-o...

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.

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.

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

People aren't upset because Matz hasn't chimed in on immigration laws yet.

cannot?

How so?

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.

So this whole thing stems from a dislike of DHH?

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.

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.

By not addressing HOW the project ended up in RC's hands, Matz is effectively whitewashing the move.

by thanking Ruby Central who is the aggressor but not thanking the maintainers for their decade plus of work?

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.

What languages do you use that have adopted this well?

I'm not counting something like C++ where there's effectively no "packages" to speak of.

Is this written by a spy from a hostile country?

See this thread for context: https://news.ycombinator.com/item?id=45299170#45300774

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.

probably nobody can, no. Other than: a shitshow.

Seems so yes https://rubycentral.org/news/ruby-central-statement-on-rubyg...

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.

Ruby Central has literally ALWAYS hosted rubygems.org.

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.

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.

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

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:

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.

Yeah, certainly tickles a few neurons.

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.

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.

I think because of this, which started this whole thing

> Shopify demanded that Ruby Central take full control of the RubyGems

https://joel.drapper.me/p/rubygems-takeover

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

[0] https://xkcd.com/1053/

[1] https://world.hey.com/dhh/as-i-remember-london-e7d38e64

[flagged]

Ruby Central also announced it on their site.

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.

Can you elaborate on sources about this:

> Now this is confirmed - it was a matz directive.

I did not see any confirmation in this annoucement, do I miss something?

> like the rising phoenix

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.

This is a question that I have, HSBT was the one who flipped switches, and it's been unclear to me how those decisions were made.

[flagged]