Ruby core team takes ownership of RubyGems and Bundler

293 pointsposted 4 hours ago
by sebiw

138 Comments

white-moss

3 hours ago

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.

shevy-java

an hour ago

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.

xg19837

an hour ago

Yes. At least Ruby was always strongly Japanese though. In Python European and Asian developers are overtly exploited, with U.S. corporations and their employed stooges holding the reins of power.

I'm considering switching to Erlang, which was developed at a corporation from the start and appears to be drama and cancel free.

nxor

an hour ago

Or Europeans choose to work for US corporations. What am I missing? I know Europeans who only want to work for American companies.

busterarm

an hour ago

Different money and different attitudes. Trying to get paid more than your peers if you're appropriately skilled isn't social kryptonite here in the states.

dudeinjapan

an hour ago

Shopify is pretty much dominating the Ruby ecosystem. It’s Canadian tho :)

dismalaf

an hour ago

> I am actually much more worried now

Why? Japanese culture is more conservative, less prone to knee jerk decisions, and Ruby is their biggest home grown programming language.

I'm also not American nor Japanese and I think this is the best possible outcome.

nxor

an hour ago

More people live in the US. What is overdominating Python?

sebiw

3 hours ago

I think this is the right move. Thank you to Ruby Core and Matz for stepping up and providing stability to the language and community as a whole.

delichon

3 hours ago

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

shevy-java

an hour ago

Is that a religion now?

The pickaxe guys coined it. People repeat it without thinking about it.

If matz were to say "jump from the bridge", people would do it, because matz is nice?

Just to point out: I do think matz is nice and a great language designer. That in itself doesn't mean anything. Why would I proxy my own decisions based on any mindless slogan? That makes no sense. Why do people in the ruby ecosystem keep on repeating those pointless slogans?

ubercore

an hour ago

I think it's pretty obvious to see the difference between being nice and jumping off a bridge? Curious why this cute phrase bothers you so much.

delichon

an hour ago

I know what you mean about mindless aspirational slogans. "No child left behind" is logically the same as "no child gets ahead". But trying to convince the Ruby community to be nice, by the example of their founder, isn't in that category. And if Matz told me to jump off of a bridge, he has enough stored up credibility that I'd at least consider it.

cortesoft

23 minutes ago

Not necessarily. Your logic only holds if you assume the "behind" refers to other children.

The statement is ambiguous. I interpret it as "no child left behind THE STANDARD FOR THEIR AGE". In that interpretation, other kids being ahead of that standard doesn't mean the other kids have to be behind the standard. Every kid could be not "left behind" the standard even if some are ahead of the standard.

Of course, NCLB has a lot of other issues, but I think the name isn't the issue.

gmac

an hour ago

> "No child left behind" is logically the same as "no child gets ahead"

If by both statements you mean "all children must be in exactly the same position", yes ... but that's a wilfully obtuse interpretation.

delichon

an hour ago

It seems to be to be literal rather than obtuse to observe that it is necessary for some children to fall behind in order for others to get ahead. The slogan on its face is a wish for equality of outcome. But it's catchier than ”no child failing to meet minimum standards”.

saghm

20 minutes ago

I'm not convinced that yours is the only literal way to read it. The question of who exactly is doing the "leaving behind" is implicit, but it always sounded to me like it was the adults, not the other children. I don't think it's any less literal to interpret it as making sure some adults linger behind with the children who are behind rather than all of them running ahead with the children who go faster. The phrase isn't "no children are behind", which would be the literal representation of what you're saying; "left behind" is a bit ambiguous, and while I think you can make the case that the ambiguity is a problem, I don't think it's nearly as clear-cut as you're saying that there's only one literal way to read it.

kamranjon

an hour ago

Is being nice equivalent to jumping off a bridge? I think it's relatively simple to comprehend and also harmless. The guy who built this thing is nice, let's try to continue that tradition so that our community doesn't turn to shit.

dudeinjapan

an hour ago

Matz wouldn’t say jump from a bridge because he is nice.

mcphage

an hour ago

> If matz were to say "jump from the bridge", people would do it, because matz is nice?

As always, there's a relevant xkcd: https://xkcd.com/1170/

...but seriously, what on earth do you think you're saying here?

dluan

3 hours ago

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.

neya

2 hours ago

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

shadowgovt

2 hours ago

The broad-strokes story is:

* DHH said some things on his blog that some people believe to be deeply racist / fascist (not going to unpack whether they were or not because answering that question is irrelevant to the fact pattern; consult other threads for that debate).

* A Ruby conference run by Ruby Central was asked to deplatform him. Since he's the creator of Rails, they declined.

* In response to their decision, a major sponsor (Sidekiq) pulled out of supporting the conference and Ruby Central in general, to the tune of $250k a year.

* This created a "blood in the water" situation where Shopify hit Ruby Central with an ultimatum: they would back-fill the lost sponsorship for oversight control of Ruby Central (and the gem repository they maintain, rubygems.org). And if Ruby Central didn't take the deal, Shopify was going to pull their funding also, leaving them in dire straits (this, BTW, is a fairly common corporate tactic when multiple partners share support of a service that doesn't independently generate revenue. Look for it in your own business, startup company, and nonprofit dealings!).

* Shopify now de-facto controls rubygems.org and people immediately started backing towards the exits because corporate takeover tends to be a harbinger of enshittification. As if to prove the point, Shopify's folks immediately ham-fisted the access controls, yanking several gem creators from the admin roles of the gems they created. They claim this was a mistake; several in the community do not want to give them a benefit of the doubt they are not believed to have earned.

* Community members are standing up gem.coop as an alternative gem repository.

ameliaquining

an hour ago

This is missing an important part of the story that makes the Ruby Central side look relatively better, which is that one of the existing maintainers offered to help fill the funding gap in exchange for being allowed to monetize the server logs. https://rubycentral.org/news/rubygems-org-aws-root-access-ev...

saghm

11 minutes ago

Your addition also misses an important part where the only reason he was able to do that was because the servers were forcibly taken from the previous owners for the ostensible purpose of security, but the new regime forgot to change the passwords as part of that.

At this point, it's probable that any attempt to just list the pertinent events isn't going to end up being as neutral as one might hope because even the choice of what context to include or exclude is itself editorial. This is the same lesson people might learn in a high school history class, just applied to something much more recent.

ameliaquining

a few seconds ago

That's not accurate; the monetization proposal happened before the revocation of permissions. The controversy about various accesses that may or may not have been unauthorized came later.

Perfect neutrality is unachievable but that doesn't mean that every possible way of presenting the facts is equally valid, or even that it's impossible to distinguish presentations that are or aren't missing important context (see, e.g., the surprising success of Twitter's Community Notes).

brigandish

an hour ago

That puts the gem.coop repo in a new light.

kragen

10 minutes ago

But Ruby Core is not the same thing as Ruby Central, apparently? This blog post says, "To provide the community with long-term stability and continuity, the Ruby core team, led by Matz, has decided to assume stewardship of these projects from Ruby Central. We will continue their development in close collaboration with Ruby Central and the broader community." What, if anything, is the relationshp between Ruby Core and gem.coop?

shevy-java

an hour ago

This is not 100% correct though; I mean, your summary is good, don't get me wrong so I upvoted it. But it conflates a few issues that are not 100% related.

For instance, DHH and his fancy blog, are not 100% related or relatable to RubyCentral ousting long-term developers. There may be some connection (DHH on shopify's board, tons of ruby developers being paid by shopify and still writing "my opinion is totally unbiased" like byroot did), but there is no 1:1 overlap. For instance, I could not care what DHH writes on his blog any less. rubygems.org changing policies though - that affects me. And if shopify is in part responsible, and DHH sits on shopify and makes decisions, then yes, something changed here. But there are also people who have a vendetta against DHH and they leak into other spaces too. I am not among those people and they shouldn't try to hijack other communities either.

By the way, the Shopify ultimatum also does not explain why all other ruby devs were ousted. Ruby Central lost the narrative here. And, since they accuse Arko as the ultimate bad boy - why haven't they sued him? Why do they continue to refuse to do so? (Because they know their case would be rubbish nonsense and they would have to open up ALL emails, which may make many more people suddenly ... very funky.)

thayne

36 minutes ago

> For instance, DHH and his fancy blog, are not 100% related or relatable to RubyCentral ousting long-term developers.

It's related because it led to Sidekiq dropping their funding, which increased shopify's power over ruby central.

skywhopper

35 minutes ago

It’s related because from the outside it looks like DHH is pulling strings to spitefully oust the folks who brought up concerns about his radical, hateful views. So you may not care what he has to say, but if he uses his influence to exclude folks who do care, and it causes you a problem, maybe it is related after all.

neya

an hour ago

Thanks, that was a superb summary! Appreciate it.

runjake

an hour ago

It's news to me that the RubyCentral event had anything to do with DHH at least directly.

You are alleging that Shopify was retaliating. Do you have any reliable context that Shopify was acting in a retaliatory manner?

overfeed

22 minutes ago

I'm sure it's a total coincidence that Shopify (on whose board DHH sits) coincidentally became an actice participant on toppling the maintainers soon after they criticized DHH.

Given the power dynamics, the burden of proof is on Shopify to prooave it wasn't retaliating at the behest of, or in a misguided attempt to defend DHH's honor.

runjake

10 minutes ago

What you believe and what you can document are two separate things.

Per the concept of "innocent until proven guilty", there is no burden on Shopify to prove they didn't do what you believe. The burden is on you to provide evidence for the motivations behind their actions.

I personally doubt Tobi got Shopify to where it was by making rash decisions based on emotions and drama.

shevy-java

an hour ago

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

busterarm

an hour ago

Even if you're not an old-timer and don't remember what Ruby Together was like, the AWS root password changing shenanigans, presumably done by Arko, is enough of a red flag that nothing he's associated with has any credibility.

No serious business with real (business) customers will accept that kind of risk and gem.coop will never be a thing outside of hobbyists.

lyu07282

3 hours ago

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?

rich_kilmer

2 hours ago

As a co-author of RubyGems and one of the original Board members of Ruby Central, they are not a hostile entity. They are the entity that we gave stewardship of RubyGems and we/they have hosted it for its entire existence.

shevy-java

an hour ago

I disagree. The actions are orthogonal to your claim - they eliminated everyone else from there. How is that not hostile? Duckinator has been 100% right here.

> we gave stewardship of RubyGems

I didn't sign anything.

I also remember the original creators of rubygems. How old is Ruby Central? 10 years? 15 years? There were several years before that.

rich_kilmer

an hour ago

Ruby Central started in 2001. I was one of the early Board members, along with Chad Fowler and David Alan Black. We put on every Ruby conference until Ruby became more popular to support multiple conferences. We started coding RubyGems (although the name originated in 2001 at the first RubyConf in Florida) in 2003 at the RubyConf in Austin TX. We sat around a table the first night with a CVS repo on a USB drive and passed it around and committed code until we had a functioning gem command. I demoed it in my talk the next day with the first "gem install". Gem versioning, gemspec, gem command, gem server were all built that first night. Obviously tons of changes since then!

lyu07282

2 hours ago

It goes without saying that Ruby Central doesn't think Ruby Central has ever lost any trust to begin with.

monooso

2 hours ago

I don't have a dog in this fight, but the discussion is about the phrase "hostile entity", not about a loss of trust.

dismalaf

2 hours ago

Hostile entity? The entity that has literally hosted them for their entire existence?

kragen

5 minutes ago

Apparently so. That shouldn't be a surprise; Amazon Web Services turned out to be hostile to WikiLeaks, CDDB's hosting turned out to be hostile to the community that built CDDB, coal mining company towns were hostile to miners' unions, and, in the final analysis, turkey farmers are hostile to the turkeys.

byroot

3 hours ago

gcr

2 hours ago

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

saghm

7 minutes ago

> As the nonprofit steward of this infrastructure, Ruby Central has a fiduciary duty to safeguard the supply chain and protect the long-term stability of the ecosystem. In consultation with legal counsel and following a recent security audit, we are strengthening our governance processes, formalizing operator agreements, and tightening access to production systems.

It took less than two weeks from this statement for them to put out an incident report from them forgetting to change the password on the infrastructure they took from the previous maintainers. I can't say I'm shocked that this didn't actually result in people's confidence in their ability as steward to provide long-term stability for the ecosystem.

shevy-java

an hour ago

They keep on using buzzwords. These Ruby central guys never maintained a single gem used by many people in their life. I have no idea what they are writing, but it feels as if AI is writing their statements. Even then it is of such a poor, repetitive quality that even AI may just accidentally write better "summaries". People lost all trust in Ruby Central - there is no way for them to win back trust here.

IMO it would be better to start from a clean slate; dissolve Ruby Central and bring back the community with a new policy, rules - but that's not going to happen. Ruby Central went the corporate way and that's it. It would just be ironic if, say in 10 years, gem.coop proves to be much more successful whereas Ruby Central still writes the same AI-generated text ("we care for the community even if everyone is now elsewhere already").

pebble

2 hours ago

Better Ruby core than Ruby Central but still leaves me wondering what the hell happened and slightly sours me on the whole ecosystem.

joshmn

2 hours ago

This is the only outcome that anyone who touches ruby cannot be upset with.

shevy-java

an hour ago

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.

baggy_trough

2 hours ago

cannot?

riffraff

2 hours ago

as a rubyist, I'd second "cannot"

joshmn

2 hours ago

my coffee hadn't hit—that was my intention, the "cannot"

mring33621

an hour ago

NGL, the drama is entertaining.

I'm sorry for Ruby people that are negatively impacted, tho.

Lastly, Matz is the best!

mring33621

an hour ago

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?

Mystery-Machine

30 minutes ago

It seems like it stems from dislike of André

saghm

2 minutes ago

As best I've been able to understand it, a dislike of DHH led to the opportunity for those with a dislike of André to do all the stuff under discussion. I doubt we'll ever know the whole story, but in the absence of any of the additional context that some people claim exists (but haven't made public), this seems to be the most coherent explanation for what happened.

mcphage

an hour ago

> So this whole thing stems from a dislike of DHH?

I don't believe this has anything to do with DHH.

gardnr

2 hours ago

Can anyone please explain this in simple terms for a relative outsider?

joshmn

2 hours ago

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.

binary132

3 hours ago

Decentralized package hosting is the only way.

ivan_gammel

an hour ago

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.

shevy-java

an hour ago

The supply chain attack is not the only argument here, though.

For instance, who effectively controls the ruby ecosystem? See ad-hoc restrictions such as 100.000 downloads - past that point you are disowned from your own gem. I always felt that was a direct attack on independent developers. They could have forked those gems just fine (the licence permits this for most gems after all), but nope, they forbid you to remove your own (!!!) code.

ivan_gammel

13 minutes ago

Decentralization is not the answer to that though.

__float

2 hours ago

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.

zrail

2 hours ago

Go, for some values of "distributed". The vast majority of go packages are hosted on GitHub, but nothing stops anyone from hosting elsewhere and Go has explicit support for indirection such that anyone can use a vanity domain that happens to point at GitHub or wherever.

cortesoft

15 minutes ago

Isn't this the same as ruby gems, then? You can use alternative sources in your Gemfile pretty easily.

shadowgovt

an hour ago

Go's one weakness is that the package source is baked into the package data in a not-automatically-fungible way. And if pkg.go.dev ever becomes a threat vector, we're gonna have a bad time.

dselect solved this ages ago with its mirrors, but at some point it seems every major package manager decided that was unnecessary complexity ("why bother? It's not like a package repo just goes down") and left it out when they built their alternatives.

So, from time to time, when a domain in the Internet goes sour it's a huge problem (whereas were a Debian mirror to go sour I'd add like one line to a config file and never notice the issue again, assuming dpkg doesn't automatically identify the problem and route around it).

pjmlp

an hour ago

Nowadays there are, as vcpkg and conan step by step win the earths of the C and C++ communities, and then there are the distro specific ones, if someone is happy enough with rpm/deb + pkg-config.

However I would say all ecosystems have issues, regardless of the approach, because 99% of the developers have no clue on what they depend on, and there are plenty of ways to mess up with ecosystem.

voxic11

2 hours ago

Go has decentralized package hosting and it works reasonably well.

Deno does also but I'm less clear on well how that is working out for them.

runjake

an hour ago

I think this is great news and the right move!

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.

james_marks

an hour ago

Matz' action and tone in the announcement is impeccable. Humbling reminder of what greatness looks like.

jcmfernandes

an hour ago

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

busterarm

41 minutes ago

Unless there is some yet-unnamed party with enough credibility and enough money to do a proper takeover from Ruby Central, this was always the inevitable way forward.

In my 17ish-year involvement with Ruby, I can't think of one.

jcmfernandes

29 minutes ago

I don't understand why the move wasn't undone. This is essentially kicking the can down the road.

dismalaf

2 hours ago

This makes sense, considering Gem and Bundler are shipped with Ruby.

shevy-java

an hour ago

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.

elliotec

3 hours ago

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.

shevy-java

an hour ago

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.

undecisive

an hour ago

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)

TheCraiggers

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

I think a lot of this is due to how so much is a scandal these days, for better and worse. (I'm obviously going to keep politics as much out of my response as possible.)

A few decades ago, people could have political views without ostracizing roughly 50% of the global population, or generally causing a ruckus at the holiday family dinner. (Obviously politics + holiday dinners has been an issue for a long time, but back then it was just something people tried to sweep under the rug. Now? Holiday dinners are getting cancelled or families are splitting up.)

It used to be that a scandal in the OSS community required you killing your wife (thinking back to ReiserFS). Now, a remark on Twitter is all it takes.

Again, I am absolutely not taking sides here. I'm just noticing a difference in the times, and agreeing that it is indeed interesting to watch.

undecisive

14 minutes ago

No, I agree. That said, I think a lot of that particular shift is down to a) increased individualism b) an emphasis on the healing power of personal boundaries and c) the rejection of unity as an overriding good.

People are far more happy to cling to the tribe they choose, and the tribe that has their back, over the tribe they were born to. Then, there are those who see that trend as dangerous to society (where, in many cases, society is really just a proxy for their own power or social status - ironically as viewed through their own chosen tribes more than the tribe they were born to)

That is to say, I don't think it's the political views that are splitting the families. Individuals have decided that care for each other should come secondary to those political views. I feel like there used to be a certain amount of care in the "sweeping under the rug" - it was the tribe against the world, it was protecting the family image as much as it was protecting the individual from society. These days, being a thing "in private" means being a thing alone, and that's no longer a compelling thought when external tribes are willing to embrace you.

Which probably applies to software tribes just as much as family ones.

gus_massa

an hour ago

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

shadowgovt

an hour ago

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.

itsnowandnever

2 hours ago

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.

shevy-java

an hour ago

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.

brightball

an hour ago

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.

wbronitsky

an hour ago

I don't know how this fits into the narrative you just posted, but DHH was a keynote speaker at RailsConf this year. I was there and heard him speak. He didn't speak about anything "political"; just his usual ranting and raving, this time about how long it takes to test and deploy things.

blasphemers

43 minutes ago

He was brought back for the last RailsConf since DHH started RailsWorld after he was removed as a speaker for previous conferences.

BADBEEF

an hour ago

I am shocked, SHOCKED, to know that a person who loves to program and just wants to do it would be more productive than people bikeshedding about code of conduct and other matters ;)

busterarm

an hour ago

Good summary. Also the ask for politics to be kept out of company chats is often what I find cited as the _core_ reason for why "DHH is a Nazi" in online discussions. It's _weird_.

I think the real root of peoples' disagreement over what happened there is that rank-and-file employees wanted to assert a lot more control over what their company does than they actually could and they were informed that that wouldn't be acceptable. The six month severance was generous.

xbar

an hour ago

Thank you Matz.

mikemcquaid

3 hours ago

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.

Good luck to all involved on all sides.

ScotterC

an hour ago

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.

winterqt

3 hours ago

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.

dismalaf

2 hours ago

Ruby Central has literally ALWAYS hosted rubygems.org.

shadowgovt

2 hours ago

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

shevy-java

an hour ago

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.

busterarm

an hour ago

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

phoronixrly

2 hours ago

Thank you! I was hoping for this development! Now how about taking away rubygems.org from Shopify?

shevy-java

an hour ago

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

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

IshKebab

3 hours ago

Is this without the consent of Ruby Central? Sounds like some kind of hostile takeover!

Edit: Seems like maybe a hostile take-back actually.

dismalaf

2 hours ago

Ruby Central also announced it on their site.

joeldrapper

3 hours ago

These projects were not Ruby Central’s in the first place. They were stolen for Ruby Central by a Ruby Core insider, HSBT. This is horrible news.

They were stolen from André Arko, Colby Swandale, David Rodríguez, Ellen, Josef Šimánek, Martin Emde and Samuel Giddins.

rich_kilmer

2 hours ago

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.

tommica

2 hours ago

You guys did an amazing job!

Mystery-Machine

10 minutes ago

First of all, thank you! It's unbelievable that you built the first version of `gem install` in a single night. It must have been an amazing feeling. I remember the drive when I was doing some hackathon with a few friends. It's the best feeling a software engineer can have.

When you left RubyGems and Bundler (let's call them "Projects") team, you handed over your authority to whoever was left and/or was added later. It doesn't matter in which order things happened. What matters is that Ruby Central _and the rest of the team_ were the stewards of Projects. The important part here being _and the rest of the team_. André had every right to keep being part of that team, and he was for a long time, together with many other team members, all of which were removed by "a representative from Ruby Central". What an inhuman way to remove someone from a Project. "Hire" someone to do the dirty job for you so you don't have to. The decisions in a team should be done by reaching a team consensus. Not by one actor. I believe it's for the better that André was removed from the team, but it shouldn't have been done like this. Ruby Central lost their trust in the eyes of many. They could've achieved the same goal in a much better way. How can I trust an organization with management of something if they failed to manage this whole situation? Claiming this is all in the name of security and then not even knowing how to properly remove access from someone. So much about security...

dluan

3 hours ago

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.

CaptainOfCoit

3 hours ago

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.

bhouston

3 hours ago

> So what? NPM wasn't originally owned by Microsoft, nor GitHub, but reality moves forward?

NPM was a company and it was acquired and it was voluntary. I don't think you can compare it to this situation - this is more of a messy situation with everything open source collaborations, rather than having clear ownership in a single entity:

https://github.blog/news-insights/company-news/npm-is-joinin...

Or are you referring to the pre-2014 situation where NPM wasn't VC Funded, but in a more nebulous state? It didn't last that long.

joeldrapper

3 hours ago

So it’s okay for Matz to get HSBT to steal people’s open source projects? What if Matz sponsors stole Ruby from him? WTF?

rich_kilmer

3 hours ago

I was one of the originating authors of RubyGems along with Jim (RIP), Chad, David and Paul. I hosted RubyGems from my home for the entire community for many years. We never asked nor received anything for that. We wrote RubyGems for the Ruby community. Matz and the Ruby Core team is the right place for RubyGems. This is great news.

sebiw

3 hours ago

Thanks for sharing. RIP Jim, I miss him being part of the community.

the_mitsuhiko

3 hours ago

> So it’s okay for Matz to get HSBT to steal people’s open source projects?

Where is the theft? The projects were open source, they are still open source.

bmacho

2 hours ago

The software is open source, not the project.

The name is not for the taking. You can download the code, modify and release it, but you can't just claim ownership over a product.

the_mitsuhiko

an hour ago

That is a question of trademark law and a much more complex topic. Many people contributed over the years.

baggy_trough

2 hours ago

Andre Arko was not the original author, so how did he get the name? Did he take it from someone?

bmacho

an hour ago

I don't know, and I don't care. I wonder if you try to imply something ridiculously strong, general, and obviously false here?

claudiug

an hour ago

jesus joel. you are really really upset person. I read your stuff on reddit/r/ruby. I understand your frustration but you are so biased. like really really biased.

jcmfernandes

28 minutes ago

What wasn't factual in Joel's comment?

claudiug

13 minutes ago

it paints all the stuff like is one person fault. omits to tell like stuff like

- gem.coop -> the person behind have a new tool rv that want to sell it

- they want to sell the rubygems logs to corporatins

- change the root pass at aws once they where remove from the project

small details like this.

Mystery-Machine

2 minutes ago

Oh, I didn't know that André wants to sell gem.coop and/or rv. Can you please point me to more info about where this intention to sell gem.coop and/or rv was mentioned?

They want to sell some RubyGems logs about corporations (not individuals) using RubyGems API, to...Ruby Central?

As André explained on his site, he was on-call at the time when they were removing him. He acted to protect the service by limiting access. No harmful actions done by him were ever discovered by Ruby Central. It's two entities fighting to remove the other. You can say Ruby Central was right, I can say André was right. But we do know that Ruby Central fired the first shot when they (could've been an actual hacker) removed literally everyone from RubyGems and Bundler projects.