Live data from Hacker News

Ruby core team takes ownership of RubyGems and Bundler

ruby-lang.org

71–80 of 407 posts

Re: Ruby core team takes ownership of RubyGems and Bundler

#71
post #6

This is a fascinating and seemingly unusual development that will look obvious in history. I find “BDFLs” and open source communities so incredibly interesting. Especially in the context of geopolitics and state entities. Linux! This stuff is PHD material for sociology and polisci post-grads and I’m so interested in following the progression of history with these types of things.

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

Re: Ruby core team takes ownership of RubyGems and Bundler

#73
post #45
post #38

Earlier quoted context omitted.

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.

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.

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

Re: Ruby core team takes ownership of RubyGems and Bundler

#74
post #44

Earlier quoted context omitted.

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.

>Go has decentralized package hosting and it works reasonably well. All go package imports are proxied via Google. https://drewdevault.com/2022/05/25/Google-has-been-DDoSing-s...

> (you can set GOPROXY=direct to fix this)

https://drewdevault.com/2021/08/06/goproxy-breaks-go.html

Not that defaults don't matter, just offering the extra detail. And, as the post goes on to explain, this change seems to cause its own set of dependency issues.

Re: Ruby core team takes ownership of RubyGems and Bundler

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

Re: Ruby core team takes ownership of RubyGems and Bundler

#76
post #35

Earlier quoted context omitted.

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

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,…

Thanks, that was a superb summary! Appreciate it.

Re: Ruby core team takes ownership of RubyGems and Bundler

#77

Really appreciate Matz stepping up to take on this difficult situation. As a Japanese developer, I’ve been worried about the direction things were going, so it’s reassuring to see this.

Stepping up how? It was always clear that Hiroshi Shibata didn't act solo without approval. I am not saying he knew the outcome before that, but WHEN was the decision made to take over gems + bundler? I have a slight suspicion that this may have been decided upon months ago already.

> As a Japanese developer, I’ve been worried about the direction things were going, so it’s reassuring to see this.

I am actually much more worried now. I don't live in the USA; I don't live in Japan. To me it seems as if Japan and the USA are totally over-dominating in the ruby ecosystem. While this is understandable that it is Japan (local community, I get it, this is different to english-speaking ones), I am absolutely upset that the USA has so much proxy-influence here. But I guess there is nothing that can be done. I guess in Python the USA also over-dominates. I just think this sucks really.

Re: Ruby core team takes ownership of RubyGems and Bundler

#78

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 pac…

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

Re: Ruby core team takes ownership of RubyGems and Bundler

#79
post #38

Decentralized package hosting is the only way.

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.

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.

Re: Ruby core team takes ownership of RubyGems and Bundler

#80
post #3
post #2

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.

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

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?

Post reply on HN