Gem.coop
gem.coop
gem.coop
As I see it, there is the original rubygems, which has lost all of it's maintainers, and this new one, that has most of the original active maintainers? (how many were there before? it has most of the ones I think about, but I didn't know who was active over there. I mostly saw activity from deivid and didn't know about most of the others to be honest).
It kind feels like this fork is the better maintained piece of software now.
Does anyone have any thoughts on this? Are any people thinking of moving over soon?
Is there any information on what the funding model will be? Also @joeldrapper/anyone is there anything you can share about how the hosting is being covered?[0]
They can win me over with a gem distribution site that requires code signing out of the box and a bundler that enforces it out of the box.
Does the original have many maintainers left?
History has shown over and over that when a for-profit org takes over public infrastructure, maintenance is cut to the bone.
I honestly can't tell if this is satire.
You think no commits for 10 days for a piece of software that has existed for around 20 years is a sign that it's dead?
What kind of code churn do you think this project requires? Perhaps the old development was too unstable if there wasn't a single 10 day window without a commit in 15 years, for what is essentially a solved problem and a tool that people depend on to be stable.
Package management cannot be a 'solved problem' or there would be no innovation there, and you don't have to look far to find is not the case.
As for the idea that rubygems is 'dead' (not what mperham said), that is still too early to say for sure, as I imagine mperham would also agree, but it is definitely not a good sign. If we only get a trickle of changes to something that was once a very vibrant and lively community repo then that is to the detriment of the whole Ruby ecosystem. That would also be a bad sign.
Oh, how times have changed. If Oracle were to close source OpenSolaris today, many here would likely rally behind it, especially if Larry Ellison appeared to align with the right. Submissions about Illumos would have been heavily flagged, much like this one has been for a while.
André is a better man than I. I wouldn't be able to resist making threats about turning off prod.
Fortunately he’s a standup guy and not a real security risk, so he emailed them immediately to let them know.
I'm unsure on who is better placed to handle that stuff now. My view is that the people that were doing that are now with gem.coop, but rubygems still has the infra (i.e. you'd email security@rubygems.org still for now).
I'm unsure about what to think about longer term (my personal approach is currently "wait and see").
Similarly, I'm perfectly happy with bundler for now, but if `rv` turns out to be like `uv`, I'd happily switch (drop-in replacement, but faster/some better features).
[0] https://www.bleepingcomputer.com/news/security/60-malicious-...
[1] https://blog.rubygems.org/2025/08/08/malicious-gems-removal....
Given the rise in supply chain attacks, I'd also like a private rubygem instance where I can whitelist gems and even versions for my company in a way that doesn't let anything else install. I'm not sure if they're taking that on or not, but I'd like it.
the rv thesis is here: https://andre.arko.net/2025/08/25/rv-a-new-kind-of-ruby-mana...
that was always possible https://guides.rubygems.org/run-your-own-gem-server/
(there's also "gem server")
Seems like you're the ideal consumer for this new service, since it actually has people who can do that.
This does not bode well for the team having the socio-technical savviness to see this project through.
The reason is spam. Before these can get wide spread "normal" adoption they can be heavily used by spammers. Its hard to say if that is because they have desirable look-a-likes available, or if its because the first year is offered at a deep discount. So, systems will get flooded, and on inspection they will see that they don't have any legit traffic from those tlds and will whole sale block them.
.xyz is kind of infamous for being in this situation. https://news.ycombinator.com/item?id=28554400
I have no idea if that applies to .coop though.
Though there's no way that this is something you care about, cmon.
But thinking that they can disregard all prior Internet history and just slam into the situation with no concern about what came before is pretty on-brand for a project in the Ruby ecosystem.
Maybe, but I feel the value of the index is the storage and bandwidth and not the software itself, isn't it?
Could an index work by just being a search engine for gems, storing the hashes, but pointing to external resources, like GitHub repos, for the download itself?
Can you explain what the issue is?
Honestly, after "tweet" caught on as a verb, I've given up on thinking that we have any sort of crystal ball when it comes to names.
https://en.wikipedia.org/wiki/Cooperative
It's a word that nicely captures their objectives.
Think about all of the organisational structures you know of.
Then ask yourself how is a cooperative fundamentally untrustworthy?
Again, a domain name is pretty minor in the scope of this whole fiasco, and I wouldn't have bothered with bringing up this point, but on balance I agree with it.
Of course, it's also true that many people won't have the spare time to find that out.
This is so funny to hear after 18 years in the west coast silicon-valley lead tech industry. All of the app, io, tv, tech, guru, and now ai I've seen and only when it's "coop" does anyone complain.
94.3%: Original 7 TLDs + .io (which is common enough these days that I consider it no less trustworthy than .com).
2.0%: Shortlink TLDs (e.g. .co, .it) that I usually only see when they are clearly associated with one of the TLDs above. Most of the time spent looking at these sites are when I right click -> open image in new tab, e.g. i.redd.it.
0.7%: ccTLDs used as intended (sites associated the country's government, or personal websites that I don't put much trust into regardless of TLD).
0.6%: twitch.tv; well-known enough that I don't have to think about its TLD.
0.4%: .club; from a board game site my friends made me use. I inherently distrust this site regardless of TLD.
0.2%: .wiki and .gg sites that are from a wiki moving away from fandom.
1.8%: Remainder. Mix of things like .app, .xyz, .fun, etc.
I only found a few websites that are official/authoritative for a substantial community or organization, but don't have one of the top TLDs: twitch.tv, arduino.cc, nouns.wtf, expo.dev, osu.ppy.sh, trackmania.exchange, dev.to, teenage.engineering, minecraft.wiki, *.wiki.gg, stackoverflow.blog, nebula.tv, perplexity.ai, and a few mastodon servers are the only sites in this category that I spent more than 60 seconds on in the last 3 years. Excluding twitch.tv, they combined represent <0.1% of my total browsing.
Thank you for making me look into this, I now trust my heuristic even more!
Neither the current authorized registrar list (https://identity.coop/register) nor the archived 2013 list (https://web.archive.org/web/20131019082806/http://www.nic.co...) includes register.coop. Where did you find this site?
Gaslight much? "coop" implies intention and direction...you know, that thing that rubygems.org could have used?
But to your comment: I'm not arguing the same, I'm arguing that the results are the same. If I'm consuming packages from a repo, and I care about the security of the thing I'm running, I need to think about how I know I'm getting legitimate code that does what I expect it to do. One of the risks to that is malicious developers at the package level (either outright malicious or stolen publish credentials). Another is malicious substitution by the package repo. The detection strategies and next steps are different but as a consumer of code, bad code is a risk regardless of who injects it.
Also, you don't secure a package repository through hostile takeovers, and you certainly don't build trust with such an obvious lie. Claiming that the current rubygems.org is in any way trustworthy is utterly absurd.
I remember some complaints about the traffic that it produced[0] (though I don't think it's a bad idea. Basically federated downloads).
Or maybe radicle as well if someone is okay with swapping in a custom software but the hiccups can be too much imo so tangled.sh is the most interesting thing to me right now
What is stopping something like gem.coop to exist with the at protocol/tangled.sh??
> “Since Ruby Central has informed us they will never allow us to continue working on the projects they now claim they own, that we successfully maintained and operated for the last ten years, the former RubyGems team is launching gem.coop today.”
[1]: https://socket.dev/blog/gem-cooperative-emerges-as-a-communi...
Some people might consider that a dick move.
1. It must depend on RubyGems in order to stay in sync, because people publish to RubyGems.
2. It has no UI to search or view gems, so still depends on RubyGems for that.
Ignoring any question about technical detail or implementation: there is zero practical reason or motivation to switch unless I am ideologically aligned with the maintainers and their reasoning.
As such, there is zero reason to even entertain the idea of switching in a professional context. At best I’d have to care enough to remember it for personal projects.
So it is with almost any fork. It’ll either converge with the mainline after achieving its goals, take over as the new status quo, or fade into obscurity. If I don’t have any direct stake in that then I’m going to wait it out.
This isn’t to discredit or discount the work or the reasoning, of course. It arguably has a far better standing than forking Rails because of DHH.
The suckiest thing is if the fork pans out, it will look a lot like JS: "Which package manager do you want to use?". That beautiful simplicity of "just use bundler and ruby gems" will be gone.
One thing I will give them massive credit for is walking-the-walk. There wasn't really that much complaining for the aggrieved maintainers of RubyGems. They made a public statement describing their grievances, then quietly got to work on a fork. Taking on a fork of RubyGems seems impossible and foolish, but they now have a non-zero chance of succeeding because they're doing it.
Most people I've talked to inside of big orgs are going to stick with the "safe boring" thing, which will probably be RC backed by Shopify. They will probably throw security bureaucracy at the problem, which will make SOC 2, ISO 270001 auditors. I don't think we'll see a lot of innovation coming from RC since the executive director is non-technical and has demonstrated a very ham-fisted approach to running the organization that seems to be out of touch with developers.
On the flip side, I think if gems.coop takes off, it will be because it's a "better mousetrap". One of the people behind it, André, is working on https://rv.dev, which promises to be a faster, "all-in-one", tool for managing ruby versions, gem dependencies, and even has an "npx-like" run this from from the CLI, the right version of Ruby will install, the gems will install, and it will run. That's a much better DX that I could see developers going for.
I've seen discussions on the periphery of adding namespaces to gems, bringing in checksums, and overall taking a more aggressive technical approach to security. I could see that "winning" over a long enough timeframe if RC continues on their current course.
From a fund-raising PoV, I'm starting to put together the clues that André believes organizations with the means to pay for OSS infrastructure should pay for it. I think I agree with this point-of-view and think it's a path for funding that's more transparent than "A group of donors". I hope we start to see infrastructure run in a manner where the costs are accurately estimated, then divided by the number of companies with the means to pay to arrive at the price.
There's absolutely on consensus on my final point, but I think the root cause of RC's catastrophic failure is having too much of a concentration of funding from a few donors. If you're new to this drama, a major donor pulled funding from RC because they didn't ideologically agree with a conference guest. The details are out there if you want to dive into it, but to keep this thread on point, I hope Ruby Co-op figures out how to spread out their funding model across 100's or 1000's so this doesn't happen again.
It's fine. Keeps all the complainers away from the larger ecosystem.
I personally trust Ruby Central, 37signals, Shopify, DHH, Tobi, Matz and others over the guy who was launching a startup to compete with rubygems while being a maintainer for rubygems.
Which fork of what software..?
> We’re excited to introduce gem.coop – a new server for gems in the Ruby ecosystem.
This is a new hosting service for gems, not a fork of bundler. Or is there missing context?
This a fact. By this alone I don't think Andre Arko is an honest person.
André is absolutely a standup individual.
I have tried to stay in good terms with the other people involved in this (except DHH), but this claim was always ridiculous.
[1] https://web.archive.org/web/20150919025358/https://rubytoget...
[2] https://web.archive.org/web/20150919025603/https://rubytoget...
Frankly that page is even more clear than I remembered. All of this happened so long ago.
Since no /teams page was archived before March 2015, here's the Github commit of the overly vague team page https://github.com/rubytogether/rubytogether.org/blob/9a03c4.... This page was linked from https://web.archive.org/web/20150425040538/http://RubyTogeth... which stated "We pool funds from corporate and individual members to pay our team[github link]"
Altogether, it demonstrates how Andre misled his audience on who was getting the money. IMO, I see a distinct pattern of him crossing boundaries and then covering it up using his social skills & friend group.
At the time I'd sent the email I was unaware Ruby Together was on HN front page (and that's why people were pinging me)
I absolutely wouldn't want people to think that I'd be getting the money, so I think clarifying it was a good thing, regardless.
> This resulted in a nonzero number of donors believing they were funding the work of people like Steve Klabnik, Aaron Patterson, and Sarah Mei, when in fact only Andre was being paid at the time.
Steve said "that didn't happen to me" and then Aaron said "that definitely did happen to me". Seems pretty relevant. I don't think he was claiming steve was wrong in not having heard that, but Aaron was saying it did happen to him, so the claim is true.
(and in terms of evidence, do you want him to share the emails he got? A first hand account seems enough evidence to me)
Seems pretty unambiguous, and a good reason to chime in.
- uv is a cool tool, but Astral has signaled their intention to have it tie in nicely to paid services.
- that's a nice moat!
- Andre & friends saw that in the Python community (and uv's success) and decided they could do the same for Ruby
- Their collective announces rv and now wants to make us dependent on them & friends for Ruby Gems.
- After Hashicorp and others, I'm extremely wary of orgs luring me in with free shit. Hashicorp is maybe the lightest example of this but they're very intentional about enterprise-walling business-essential features.
- I don't want the Ruby ecosystem dependent on one party or even a tiny collective of people. This is just as bad to me as the Ruby Central situation right now.EDIT: Misread the comment and thought it was only about `rv`, not both `uv` and `rv`
This entire post is practically the case in point, except I’m not clear on how they got real time sync with RubyGems and if any other competitor would have the same capability.
To use Astral and uv as an example, they would have to fork PyPI and maintain all the infra for that and not just the tool that manages the dependencies.
https://rubycentral.org/news/rubygems-org-aws-root-access-ev... discusses that a precipitating event was Andre asking for a copy of the http access logs to monetize them.
I think this is confirmed by Mike Perham's comment in https://www.reddit.com/r/ruby/comments/1o2bxol/comment/ninn6...
> In this case I have first hand knowledge since he pitched me on the idea: would Sidekiq, being a big sponsor of Ruby Central in the past, be interested if rubygems could somehow use the remote IP to identify the companies downloading the sidekiq gem so I could use that to upsell those companies
The benefit to being centralized is... everything is in one place. Everything scales at once. Every update is available at the same time.
We did this back in the day using artifactory and co. to proxy NPM and a few other package managers as well as docker containers and some other things. No third party service going down could keep us from deploying.
Not everyone does it because as a solo developer or a small team, as it feels like pointless overhead.
having a decentralized, and maybe sometime unavailable, infrastructure would make more people think about the problem and maybe brings us more stable solutions than we have now.
Single-file archives are much easier to distribute.
Digests and signatures have standard algorithms, not unique to git. Key/identity management is the hard part, but git doesn't solve it for you (if you don't confuse git with GitHub).
1. Heavy dependency on Github. AKA Microsoft owns much of the golang ecosystem. Not just the source... The package distribution as well!
2. Many packages are referencing a git (short!) commit hash instead of a version. It still boggles my mind that this is an acceptable practice. Not to mention that git tags can be deleted and recreated... A pinnacle of secure package distribution practices.
3. Stuff like ambiguous imports because apparently nothing enforces proper go.mod files? They are not packages to be compiled after all, they're just repos with some conventional structure (optional)...
Mind you, this is popular production-grade software...
I think this is much worse than even node packages, let alone bundler and rubygems...
2. You complain about commit hashes while simultaneously noting that tags can be deleted and recreated. Hashes are precisely the solution to mutable tags. The "short hash" concern is a red herring; Git uses sufficient entropy that collisions are not a practical concern for dependency resolution.
As for "secure package distribution," go.sum files verify files verify consistent downloads. What additional security do you believe centralized registries provide?
3. Can you provide a concrete example of an ambiguous import you've encountered? I'm not familiar enough with Go to understand this criticism.
Exactly. This 'social phenomenon' should have been taken into account when designing a packaging system so that the language's ecosystem does not end up entirely dependent on Microsoft due to 'social reasons'.
> The go.mod file you linked references ~14 different Git hosts
Of which the non-github ones account to what... 15% of the deps in the file?
> You complain about commit hashes while simultaneously noting that tags can be deleted and recreated
Yes. Not using versions (semver) is a bad call, and having people be able to mutate the code of a version is a very bad call. Once a version has been tagged, the only viable choice must be to pull that version and push a new higher version.
> As for "secure package distribution," go.sum files verify files verify consistent downloads
Based on git's hash.
> Git uses sufficient entropy that collisions are not a practical concern
Unless crafted by an adversary? Git's sha1 hashes are not a security tool and must not be used in place of code signing.
They are also not good for versioning, as you can't deduce whether a commit introduces breaking changes. Rubygems has the ability to reference git repos. It's always a pain to update these compared to other semver deps -- you have to go to github and do a comparison between the old and new hashes to try and deduce whether bumping this will break you.
> Can you provide a concrete example of an ambiguous import you've encountered
See end of linked go.mod
> This 'social phenomenon' should have been taken into account when designing a packaging system
I'm unsure how this would be accomplished in practice without banning certain Git hosts, which seems untenable. Even Maven/Gradle ecosystems concentrate around a few major repositories (Maven Central, JCenter historically). This appears to be an inherent social dynamic rather than a solvable design problem.
> Of which the non-github ones account to what... 15% of the deps
Same question: what's the solution? Developers publish where it's easiest and most popular, creating a positive feedback loop. I don't see how package system design can prevent this.
> Not using versions (semver) is a bad call, and having people be able to mutate the code of a version is a very bad call
Agreed on both counts. However, how do we enforce immutability beyond operational controls? Even systems with "immutable" version policies ultimately rely on the registry operator honouring that policy. The only technical guarantee would be embedding content hashes alongside version numbers (which is effectively what go.sum does, albeit awkwardly).
Sidebar: how should we handle vulnerable versions? Allow pulling with warnings, or remove them entirely?
> Git's sha1 hashes are not a security tool and must not be used in place of code signing
Fair point. I was under the impression that Git had moved to SHA-256, but it seems there's no practical way to use it yet. While Git moved to a hardened SHA-1 implementation (not vulnerable to the SHAttered attack) in v2.13.0, SHA-1 remains weak for security purposes [1]. The transition to SHA-256 has been in the works for some time, but as of 2022 it appears to be a partial implementation with no support from major Git hosts [2].
What would ideal package security look like to you?
> They are also not good for versioning, as you can't deduce whether a commit introduces breaking changes
Completely agree. Repository references are useful for development and testing, but painful in production. I avoid them in published packages.
> See end of linked go.mod
Thank you, I see it now. I'm still deeply unfamiliar with Go but this feels like a legitimate criticism.
Glancing at github.com/tencentcloud/tencentcloud-sdk-go: is this import ambiguous because there's no top-level `go.mod`? If so, that feels like a significant oversight. I'm a fan of monorepos myself but I'm surprised Go doesn't have better support for them. I'll be doing some research to understand this better.
[1] https://git-scm.com/docs/hash-function-transition [2] https://lwn.net/Articles/898522/
I hope they find financing to cover hosting costs.
In open source too.
My 2c is that 95% of ruby developers aren't aware of the drama going on around Rubygems.org right now. They have probably seen emails from Ruby Central but largely ignore them and move on with life. Most people have no idea there are issues and they will just continue using Rubygems.org. Getting a project like this to critical mass is incredibly challenging.
This is massively flawed thinking. So called "market rate" is actually a tool for value extraction from the workers and is not connected in any shape or form with what they create for company they work at. As corporations refer to this as if it was a consensus (as in developer should earn $x an hour), they pay this much and workers have no choice but to accept (if someone has working class background and no trust fund, it is rather impossible to throw the towel and start own business, sometimes there are even regulations designed to keep workers captive).
In such a project, "founder level" people should pay themselves as much as they think their worth is. Simple as that.
I often hear VC talking that if founder takes too much money, it's a bad look. They just want to shame people into not taking the slice they deserve.
It's interesting that IT is full of intelligent people, yet they can't grasp how they are being played by the market frames set by the rich.
It's almost like removing money from the equation stops all the nasty stuff that happens inside organizations. Who'd have thought?
Flat salaries do not remove politics. With unequal equity and control, a flat wage simply disciplines workers while investors keep uncapped upside. If money is the poison, start by flattening carry, liquidation preferences and board vetoes. Otherwise you have only flattened one side.
Capping founder pay is class gatekeeping. It selects for people with savings or family safety nets and pushes working‑class founders out. Shaming those who take cash once they create surplus protects investor optics, not fairness.
Equal pay only makes sense when ownership, risk and power are equal. Without that, "equal pay" is theatre.
The fash problem in the Rails ecosystem is next on the list, and I hope there is community consensus to fork this as well.
https://www.benjaminfleischer.com/2013/11/08/how-to-sign-you...
Here's some fun facts:
- DHH enforced a "No Politics at Work" policy.
- DHH wrote a post expressing that he wouldn't want to live in London anymore because it's "no longer full of native Brits", and expressed support for a Tommy Robinson march he called "heartwarming". Tommy Robinson is described as "an anti-Islam campaigner and one of the UK's most prominent far-right activists.". The march DHH praised featured speakers calling for ethnic cleansing via "remigration" and banning all non-Christian religions.
- DHH also promoted "demographic replacement" conspiracy theories and used language connecting immigration to crime, particularly regarding "Pakistani rape gangs" and street theft.
- DHH has been publicly critical of Diversity, Equity, and Inclusion initiatives. This one isn't backed by facts, so take it with a grain of salt.
And no, I'm not saying that Danes are racist.
As a Norwegian I respect Denmark for putting its people first.
Saying what he said about London is, at the very least, a fascinating example of failure to stay in his lane. In fact, if one were of the mindset to be denigrating immigrants, one could, perhaps, raise questions around what business a Dane has telling Brits which members of their former colonies do and do not count as British or, indeed, what it means to be British.
Hey.com is 37Signals' Gmail, not the company's private domain.
The Ruby community in general, and the Rails community in particular, likes to style itself as people who care about people. "Matz is nice so we are nice" (MINSWAN) is a cornerstone concept that the community passes around. As a result, they have a tendency to care about this sort of thing; community standards of behavior didn't get bolted-on later, they were there at the start.
I once watched a Rails community member pretty well pillory someone for entertaining the thought experiment that if ReiserFS were more technically competent, the software-engineering community wouldn't care the creator murdered his wife and would still invite him to speaking engagements telecast from jail. It is therefore interesting to watch how the Rails community is reacting to the Rails creator having concerns not nearly as bad as killed-his-wife, but extremely disquieting nonetheless.
People really like to misuse terms like fascism these days, huh…
How the hell is any of that facism
Racism could be a much better fit. The blog post in question: https://world.hey.com/dhh/as-i-remember-london-e7d38e64
The interpretation that raises some pretty interesting points about the inherent racism in the expressed worldview: https://jakelazaroff.com/words/dhh-is-way-worse-than-i-thoug...
There is, however, an interpretation that explains how this specific kind of racism can be seen as at least fascism-adjacent: https://davidcel.is/articles/rails-needs-new-governance
The question of whether he wants politics in the workplace is moot when he's making public blog posts like this. For the open-source community, the open Internet is the workplace. People aren't just going to pretend DHH didn't say what he said (in public, of his own free will, using his own megaphone) because he didn't post it to ruby-core@ml.ruby-lang.org.
I'm done letting these labels deter my rational thinking.
The racist part was him asserting he could walk down the streets of London and guess who was British. Given the disparity between his estimated number and the actual percentage of Brits by census (and the remarkable similarity to his number and the probable skin color of Brits by census), it is real hard to find the generosity to assume that he doesn't just mean "When did the Brits stop being white?" And that kind of thinking has nothing to do with immigration control and everything to do with believing that there's a right skin color to have.
I'm Norwegian by the way and I belong to quite a small ethnic minority, but because of the color of my skin, people assume a whole lot of things about my background which isn't true. And I don't get to be proud about my heritage for some reason. Weird that.
It doesn't take much 4D-chess reading of his actual words to infer, I think correctly, that he's saying it's not ethnic British... And that's wrong. At least wrong for him (and wrong for the Brits, since he goes on to assert that "it's tough to blame the Brits for being pissed").
"I thought I might move there [London] one day.
That was then. Now, I wouldn't dream of it. London is no longer the city I was infatuated with in the late '90s and early 2000s. Chiefly because it's no longer full of native Brits."
... I mean, I'm having a real hard time finding a reading for those sentences that isn't "I was more comfortable when Britain was full of native Brits and I am not comfortable now." If I assume your assertion that he means ethnicity, not culture or citizenship-birth... What the hell, DHH? What is it about "non-ethnic Brits" that is giving you the heebie-jeebies?
> can be a Japanese citizen but I cannot be Japanese.
That's going to be a difference of definition. If I may, "I can be a Japanese citizen but I cannot be ethnically Japanese."
And whether that's true or not: this is perhaps a thing that Japanese people can have traditionally, or Danes. It would be the height of hypocrisy, given the Empire's history, for the Brits to do this, and DHH is swimming way outside his lane opining on how Britain should be or what makes him, a non-Brit, most comfortable in London.
Do you want to know when the Brits stopped "looking British?" Around the time Victoria crowned herself Empress of India, creating a country of about 28.9 million "ethnic Brits" (I'm going to speak loosely here, and my Irish and Welsh cousins will give me a proper thrashing for it later) and 250 million "ethnic Indians." And the fact India later gained its independence again has no bearing on the people who are Brits who look "non-ethnic" because of 90 years of British rule of a subcontinent. If DHH, or the British, or anyone want someone to blame for Britain suffering a "demographic nightmare" (whatever the hell that means)... They can probably blame the Widow of Windsor.
> Why is that?
Because some nations were expansionist and some were isolationist. Ethnic and national identity lack 1-to-1 overlap, and that matters more in some nations than others. I'm not in the business of telling the Japanese how they should see themselves (if I were, I would be making meaningful harumphing noises about the easiest possible way to curb their apparent birthrate crisis...). But DHH has put himself in the business of telling Brits how they should be seen, and in so doing he decided to wade into a conversation that makes him, yeah, the racist in the story.
He's free to walk it back any time he wants to stop causing controversy in the Ruby community so people can focus on the tech again.
> I'm Norwegian by the way and I belong to quite a small ethnic minority
Oh, you've opened quite a door. I want to guess but guessing feels rude so I will refrain. For what it's worth, every person I ever met while visiting Norway had a lot to be proud of (hell, waking up every day in that climate and giving death herself a middle finger is damn impressive to me!), so whoever is making you feel like you don't have a right to be proud of your heritage can probably pound sand.
Yes, but… https://www.smbc-comics.com/comic/arthur
I agree they should post the whole source, regardless.
> This leads me to think this project is not about the code but about the people.
Trust is of utmost importance to a package repository. Even more so than code. A hostile takeover, like the one that occurred with RubyGems, fundamentally undermines that trust. In contrast, an alternative run by the original maintainers who have built years of trust, represents a positive shift.
Unfortunately, it seems that your conclusion was drawn before your justifications. When you invent justification though, at least make sure you don't undermine your own position. Where's the prominent link to the Git repo on rubygems.org top page?
https://web.archive.org/web/20251003112525/https://rubygems....
I'm not saying they aren't, but there are a LOT of conflicting opinions about what happened, why it happened, and who was right/wrong.
This it what tends to happen when money gets involved in a project without a clear structure/business plan/guarantees put in place. People just did whatever and made assumptions, and now suddenly the whole community is rocking and rolling thanks to the actions/view points of a select few.
Of course I do, because the original maintainers earned that trust over the course of years. That's not an issue.
As long as people are aligned on advancing the Ruby ecosystem, I think it should be possible to cooperate even if there are disagreement in other areas [which political party you support, differences in personal opinions, etc].
Maybe it'll be resolved eventually, just like Merb <> Rails, Bundler <> RubyGems and RubyTogether <> RubyCentral were eventually merged. That's what I'm hoping for!
https://old.reddit.com/r/ruby/comments/1nzxgb9/buckle_up_the...
In the event the ruby-reddit moderators remove it, the comment had this content verbatim at the time of linking to it here:
"I have tried so much. It’s Ruby Central that won’t talk. They’re hiding behind lawyers at this point."
Now, we have to concede that this could be wrong; or incomplete. Personally I believe him though, but in theory it could be a wrong statement. Nonetheless ... just think about this for a moment ...
The organisation that claims it is all about the community, refuses to be transparent and now hides behind lawyers, after having been caught with making several incorrect statements before already. Does this look more like a community-centric organisation or possibly a front for corporations? Just think it through for yourself what it means when they suddenly have to hide behind lawyers.
In my opinion they are now deliberately making the community angry. But, even without this, I believe we can conclude that by far the biggest fault for all of this lies on Ruby Central.
This is one thing I think hasn't been talked about explicitly enough within the community (that I see at least) yet, Ruby Central seems to be actively trolling the 'other side' of this situation. It reads to me like they know they have the lawyer power to defend their castle and are enjoying pissing down on people and telling them it's raining. Oh and you should enjoy that because it means there will be flowers soon... or something.
I think the dialogue of 'are they acting in good faith' only works in so far as they even care about the rest of the Ruby community at all. If they are indeed bad actors (motivated purely by greed, ambition, ego, etc) then they are not ever going to come clean and they would let the whole Ruby community die before they admit defeat or wrongheadedness. My favorite term for these types of actors is SCUM - Sufficiently Clever and Uncaring Malefactors.
Imagine if someone came into your house and changed all of the locks on you/your family, because "security". You had built that house from your original designs but the other party claims they own it now because they happen to manage a series of rental listings for houses built to your design. You had even made it so the plans could be copied and modified in private; if "security" were a real concern with about 10 minutes effort to do so.
Would you agree that it is right, do nothing? Or would you rebuild something new, given how little time it takes to copy the plans.
Swap "house design" for "software project" and "rental listings" for "running an instance of your software project" and you have the current situation.
Developers are free to choose the party they trust more.
Yes the manner in which it was handled was really bad but given the supply-chain attacks we're seeing against the Python and JS worlds, I think auditing contributor access and consolidating certain privileges is prudent.
Again, handled poorly. But a lot of money rides on stuff like Bundler. We need a strict security posture.
edit- I am an artist; I get the concern and distaste. But at a certain point your art grows bigger than you. If you as a private individual build a bridge used from a public roadway and you don't do the necessary maintenance or management your shit gets shut down. Not sure how this is much different.
I honestly find it ridiculous that this situation happened to begin with, and I also have no clue why people are hating on DHH.
The easiest way to kill an open source project is drama and forking like this. Ruby has been around forever, obviously, however it is far from the most used languages, and drama like this just hurts the ecosystem as a whole.
As a former Ruby dev, it makes me sad.
As for DHH, he's a far-right racist.
https://jakelazaroff.com/words/dhh-is-way-worse-than-i-thoug...
Silencing and excluding such people from open source is the right thing to do because failure to do so means forcing others to interact with people who are hostile to their very existence.
What I'd really like to see is a whole bunch of people acting more professionally. Who you pray to, who you vote for, and who you sleep with are irrelevant to a professional context - and open source development is a professional context. So everyone needs to keep their professional and personal lives separate. I know that at best I would be disciplined, and at worst sacked if I made comments on the lines that some of the lead players in this sorry saga have made. And that's not pointing the finger at any one person.
(neither the "me" nor the "you" here refer to you or me personally ofc.)
This whole "DHH situation" with Rails has put my mind in weird position. I admire the Rails creator, the business man, the speaker. I admire what he builds, how passionate he is about his work and open-source software. But I very strongly disagree with his vision of immigration, nationalism, parenting, well most of his vision of society.
I was made aware about these opinions because people talked about it. Thanks to these people, I read and listen to him with more nuance, more critical thinking. That does not necessarily mean I would discard Rails, cancel the dude or write shit about him, but that surely means that I will be more careful about how the opinions of this 1 person could impact mine, the ecosystem I work with and the larger ecosystem I live in that is society.
No it’s not. Indifference is not approval.
Open source is global and someone in a university in Argentina contributing some features does not “approve” of anything because she didn’t participate in some bickering about US identity politics.
There actually is a binary view on your stance against things when you see unfettered hate spread by others and choose (at some level) to not have an opinion. We've seen it before, we see it now, we'll see it again. Not everyone has the same privilege as you to remain head under sand until there's no commotion left to dodge.
No, the world does not revolve around your pet problems.
I do not know the regional politics of Bulgaria and if people started spewing Bulgarian politics in my open source community, my lack of participation is not acceptance of the status quo. I don’t even know what the status quo is and there are just two sides screeching at each other.
I disagree. We don't have to have an opinion on everything. And what worries me is those (both on the left and on the right) who think that silence is a form of opinion or approval. It's getting very close to "those who are not with us are against us". And that's a worldview I have very little time for.
I was answering a comment about a vote that would put you in a torture camp, so a vote on which you are certainly opinionated about.
In other words, don't self-censor when you think something is not right.
Close by where I live is a monument for civilians who were taken from their houses and shot by the German occupiers during the last months of WWII. Simply because they were suspected of having distributed pamphlets. There wasn't even evidence to that claim, and retribution was a thing.
I passed that monument countless of times during my youth, giving me pause to contemplate.
It's a tangible reminder of what ultimately happens when people stay silent about something as final and poignant as one group denying the existence of another group for whatever reasons.
I have no problem with expressing differences over world views. I take issue when that world view entails denying the other side's existence because of differences, and a fervent intent to act on that notion.
It's a matter of boundaries, and speaking up.
Definitely definitely. When a racist paramilitary is disappearing my neighbors my primary concern is whether people will consider me complicit for publicly stating that I have no duty to interfere.
You don't have to have an opinion on everything but you do have to have an opinion on some things. Or I mean, obviously you don't, but then you have to accept the social consequences of cowardice.
If you believe we shouldn't have borders than just say so.
Only people who already live in a position of privilege get to have "little time" and settle for worldviews which advocate for a sort of bland tolerance of extremism. I can assure you, for people who are being actively harmed by hateful rhetoric and political policies, "those who are not with us are against us" is absolutely a reality.
Short of that, it's NBD right? Not really comparable.
There may very well simply be political eras where the floor of trust isn't there for open source to spring forward by leaps and bounds.
This situation is eerily similar to the Freenode takeover[1] and the subsequent formation of Libera Chat[2] a few years ago, even down to the political leanings of those behind the takeover. Except if the Freenode incident occurred today, there would be a vocal portion on HN vehemently siding with Freenode solely based on the perceived political affiliations of its owners. Submissions about Libera Chat would face heavy flagging, much like this one has.
It seems the Freenode team may have advanced their plans just a bit too early.
The most likely reason it was flagged from my perspective is that David Heinemeier Hansson (who created rails) is kind of the figurehead of this community and he has controversial opinions[1] which people believe make him unfit to represent their community. The controversy has manifested as people speaking out against DHH in his position. So this post seems to have been flagged for being "political" because it is seemingly in opposition to rubygems for the DHH reason.
0: https://hn.algolia.com/?dateRange=pastMonth&page=0&prefix=fa...
1: https://davidcel.is/articles/rails-needs-new-governance (this article has a lot of examples from DHH's blog)
Personally, I think the reason this post about gem.coop has been flagged is that we've reached the point at which new HN threads about things related to the recent RubyGems shake-up quickly devolve into people rehashing the DHH "aspect" of it all. So it has become less about flagging the actual target of the post and more about flagging the parts of the discussion that seem to go nowhere.
EDIT: expanded
Edit:
> flagging the parts of the discussion that seem to go nowhere
This is and isn't what actually happens, though. People do flag the parts of the discussion that don't go anywhere but then people also flag the post itself because they think there's no reason to discuss it at all for the fact there's a vocal part (minority or majority doesn't really matter) that wants to discuss a topic that's not going anywhere.
People shouldn't flag the post itself just because it's likely to gather or even has gathered a crowd that will discuss such directionless topics when there are better topics to discuss, even (especially?) if they're not currently being discussed.
Basically just a blog post from some guy aghast that DHH has different political opinions to him. I'm politically on the left too but I can't imagine getting so incensed about someone else having right-leaning views.
Do these people never leave the house to meet anyone outside their echo chamber? The mind boggles.
It is said the underlying cause is that devs push rv which is threatening RubyGems.
https://bsky.app/profile/rmfranca.bsky.social/post/3lz7alpob...
"Spinel develops rv, the next-generation Ruby version manager"
If Rubygems was a company, they'd have a trademark, they'd have patents, they'd have lawyers to protect the money they were making from their brand and product. But we are speaking about not-for-profit open-source projects, not for for-profit corporations!
Doesn't it seem like a bit of a security risk to you?
It was sparked after Ruby Central chose to platform an extremist figure prominently for their last RailsConf against the wishes of the sponsors, losing them a lot of sponsorship money, as well as community support.
This is so incredibly one-sided that it misleads more than it informs.
The person they are talking about is DHH. Inviting the creator of Rails to speak at RailsConf – a conference for Rails – is not the outlandish behaviour this comment makes it sound like.
The whole DHH argument, for instance, as well as some people having a vendetta about him, is not, or not directly, related to the hostile take-over of rubygems.org. There is a slight partial overlap, but it is a separate discussion (even if DHH was involved with the take-over via Shopify because he does not like Arko or Shopify wanting more power-control to bully the independent developers at rubygems.org with more corporate rules and restrictions; and, by the way, DHH never mentions Arko's name, but even this is a separate discussion still. For instance I specifically do not care about rails nor DHH really, but the hostile take-over was a complete no-go. Ruby Central really pissed off too many people here and unfortunately there are still many open questions that ruby-core has to think about. I am not necessarily saying all came with malicious intent, because I think there is an english language barrier too in regards to Hiroshi Shibata, but even then it may be better to have someone with better knowledge about the english language in charge of gems; there seems to be some strange disconnect or translation going on between english, into japanese and japanese culture, and it is super-confusing.)
That's entirely unsubstantiated.
We don’t have multiple first hand accounts. All we have is second hand account being relayed by someone with a massive axe to grind against Shopify.
There are a lot of truly committed Rubyists at Shopify, particularly the one handling the relationship with Ruby Central.
The idea that Shopify had done what Joel aledges without a single one of the involved parties on the Shopify side blowing the whistle is preposterous.
Let's add here that YOU also worked at Shopify, until recently.
IF we are going to be critical, then let's be complete here.
I actually think there is a lot of validity to the statement made that Shopify is NOT a neutral party here. We can dispute how much Shopify was involved, but to assume "all is unsubstantiated" while not even disclosing one's own work at Shopify, feels super-strange here.
Did he point out how it ended, and how he spent the better part of two years having public tantrums about it on Twitter?
Disclosing that you worked somewhere isn't relevant. Worse, it can easily give the impression that there is some insider knowledge involved.
What is relevant is how the relationship ended.
> Let's add here that YOU also worked at Shopify, until recently.
Yes, and I left over some major disagreements, hence if I have a bias, it would be against Shopify, not in favor.
There is a conversation around this which needs to be had. Maybe on bsky or x?