So, ignoring everything that got us here, what do people think about this?
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]
>It kind of feels like this fork is the better-maintained piece of software now.
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?
I personally cannot think of a new ruby gems or bundler feature from the past decade that I noticed or cared about. That isn't to say that there aren't any; I just don't know what they are.
I think right off the bat since they chose .coop as their TLD, a lot of corporate firewalls auto-block them and they have immediately decided to fight an uphill battle to get allow-listed to be a gem repo.
This does not bode well for the team having the socio-technical savviness to see this project through.
The main page itself provides little to no info so I’m going to make a few assumptions that, to me, seem logical:
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.
> So, ignoring everything that got us here, what do people think about this?
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.
I'm starkly opposed to this ridiculous fragmenting of the community. They can and should all go work out contribution agreements with RubyCentral and get over their egos.
- 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.
> 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
yeah, but still, the maintainers need to be paid for their time and expertise. not to mention, although bandwidth and storage is cheap, somebody still have to foot the bill. i suggest people donate to this project.
The git protocol is more complex and harder to scale. It's especially wasteful if people are going to redownload all packages every time their amnesiac CI runs.
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).
Someone has to run the git server. Then, someone has to find the git server to pull each gem from, since not every git server is likely to be up-to-date with the each gem, or the correct version. Since these are all decentralized, each individual owner of a git server has to independently scale as more people start using each one.
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.
If we isolate this from the recent controversy: in general, is an alternative (yet mostly compatible) package source, package manager, and/or language version manager neutral, good, or bad for an open source ecosystem?
Well the site is blocked on my company laptop (reason given: newly registered domain), so it will be a rocky start for them. I love a good vanity domain but using a traditional .org domain probably would have been better, 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.
> initially his own, but eventually others—by paying themselves a market hourly rate
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.
hard disagree. For a project like this, all members should be paid a fair, but not "get rich" sum. There are companies out there that pay EVERYONE the same salary, all the way from CEO to janitor. Mysteriously, those companies don't have folks trying to hijack things, because nobody benefits.
It's almost like removing money from the equation stops all the nasty stuff that happens inside organizations. Who'd have thought?
I hope they tackle the actual main issue with Rubygems -- lack of any sort of code signing... (I know the functionality exists, but it's not required to publish in Rubygems, and off by default on gem install. In other words it's as if it doesn't exist)
The fash problem in the Rails ecosystem is next on the list, and I hope there is community consensus to fork this as well.
It has code signing. It's just optional, inconvenient, and so unused because of Tragedy of the Commons and complacency. https://guides.rubygems.org/security/
Here's the thing. They could have put up link to a git repository where others can follow along with the maintenance of this project, but here isn't one. There is a list of maintainers explicitly mentioned on this page but no link to the git repository. This leads me to think this project is not about the code but about the people.
It's a package repository. A link to an Ansible repository or whatever doesn't need to be in the first announcement.
> 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?
I understand forking is sometimes needed, but it's also somewhat discouraging to see that the differences couldn't be reconciled.
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!
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.
-> In my opinion they are now deliberately making the community angry.
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.
The best "technical" benefit from this is that if one goes down, you could switch to the other in a pinch, so arguably better than the status quo even if you disagree with the organizational/"political" motives.
I feel like a change to the way gems are distributed/downloaded could fix this. Unfortunately, the very powers that could make that happen are the powers that control the software and infrastructure, and have the least incentive to improve things.
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.
Drama and forking aren't going to kill Ruby. This is a move like the one from Freenode to LiberaChat: hostile entities take over $thing, sensible people move on to $newthing, the new normal settles around $newthing.
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.
I'm really pleased to see this happening, but sad that it has come to this.
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.
If who you vote for will put me into a torture camp (or otherwise devalues my life or personhood), then I can't work with you, so no it is not irrelevant.
(neither the "me" nor the "you" here refer to you or me personally ofc.)
I've been in the "keep work and politics" separate camp most of my life. However, with the lines that have been crossed recently, where literal democracy and freedom are at stake, I don't think people have the luxury of keeping work and politics separate any longer. Fascism is bad and people cannot be silent.
Completely agreed. Sorry, other folks, but you have no right to gatekeep my speech in any way in a professional context. Are you a family member? Then sure, we can have a discussion. Am I a member of your private club or otherwise dependent on your approval of my thoughts or beliefs? Then let's talk. Otherwise, leave me alone. You (the collective you) don't get to decide what I am and am not allowed to think and believe.
So RubyGems has betrayed its community by ousting its maintainers. When a community-focused alternative created by the original maintainers is announced, it gets flagged on HN. What is wrong with people?
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.
I could be wrong but it may be that some have an additional agenda to try to make e. g. competition to Ruby Central fail. You can see this on ruby-reddit, e. g. by u/f9ae8221b - either way I think the by far best strategy for gem.coop is to address all concerns and statements made, including the wrong ones. Simply be better than rubygems.org - everywhere. (Also, u/f9ae8221b is super-impatient; why can't he wait for a while? Rome was not built in a day, it is strange how he thinks to know the future. I don't know the future - let's wait and see. In the worst case gem.coop will fail; in the best case it'll fix numerous issues, including, by the way, gem/bundler not having had the same functionality. And namespacing too; and inactive accounts, and so on, and so forth. There is a ton of things to do.)
Flagging is definitely getting abused more on HN lately. The consensus seems to be that politics and/or morals are irrelevant outside of personal affairs so we must not have these conversations here.
Remove flags 2025, all the best stuff is in https://news.ycombinator.com/active. I don't even use Ruby right now, have no dog in whatever drama is behind this, but I don't see what's so offensive about knowing Gem.coop is now a thing.
Just some background: there is a controversy in the Ruby community[0][2] around the governance of the rubygems project. It has been maintained for a long time by employees of Ruby Central but not in a corporate capacity. There was a recent hostile takeover of this project by the Ruby Central corporate arm.
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.
In short, a hostile takeover forced by Shopify through Ruby Central.
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.
As I understood it, to secure (their words) the supply chain, they took ownership of the code and repo (which others disputed as being owned by them) and kicked out users from Github.
It is said the underlying cause is that devs push rv which is threatening RubyGems.
The response you link to was published on September 30, 2025, so it's not the response to gem.coop? I'd say gem.coop is the response to Ruby Central's actions?
mijoharas|4 months ago
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]
[0] https://news.ycombinator.com/item?id=45490386
nomdep|4 months ago
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?
baggy_trough|4 months ago
phoronixrly|4 months ago
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.
mijoharas|4 months ago
[0] https://bsky.app/profile/indirect.io/post/3m2j2pcinz22j
shadowgovt|4 months ago
This does not bode well for the team having the socio-technical savviness to see this project through.
ljm|4 months ago
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.
bradgessler|4 months ago
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.
baobun|4 months ago
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?
joeldrapper|4 months ago
dismalaf|4 months ago
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.
x3n0ph3n3|4 months ago
directionless|4 months ago
busterarm|4 months ago
kimos|4 months ago
directionless|4 months ago
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
bloudermilk|4 months ago
lemper|4 months ago
salzig|4 months ago
pornel|4 months ago
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).
zdragnar|4 months ago
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.
dismalaf|4 months ago
phoronixrly|4 months ago
lr0|4 months ago
halicarnassus|4 months ago
I hope they find financing to cover hosting costs.
joeldrapper|4 months ago
thomascountz|4 months ago
MrDarcy|4 months ago
In open source too.
dcchambers|4 months ago
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.
varispeed|4 months ago
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.
eek2121|4 months ago
It's almost like removing money from the equation stops all the nasty stuff that happens inside organizations. Who'd have thought?
phoronixrly|4 months ago
The fash problem in the Rails ecosystem is next on the list, and I hope there is community consensus to fork this as well.
burnt-resistor|4 months ago
https://www.benjaminfleischer.com/2013/11/08/how-to-sign-you...
simianparrot|4 months ago
poorman|4 months ago
soraminazuki|4 months ago
> 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....
steveklabnik|4 months ago
sandstrom|4 months ago
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!
shevy-java|4 months ago
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.
RhythmFox|4 months ago
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.
ChrisArchitect|4 months ago
insane_dreamer|4 months ago
pdntspa|4 months ago
florkbork|4 months ago
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.
sergiotapia|4 months ago
CaptainOfCoit|4 months ago
eek2121|4 months ago
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.
bitwize|4 months ago
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.
steve_gh|4 months ago
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.
hiimkeks|4 months ago
(neither the "me" nor the "you" here refer to you or me personally ofc.)
tensor|4 months ago
wahnfrieden|4 months ago
nathanaldensr|4 months ago
unknown|4 months ago
[deleted]
soraminazuki|4 months ago
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.
[1]: https://news.ycombinator.com/item?id=27286628
[2]: https://news.ycombinator.com/item?id=27207734
shevy-java|4 months ago
sosodev|4 months ago
sleight42|4 months ago
lcnPylGDnU4H9OF|4 months ago
captn3m0|4 months ago
wahnfrieden|4 months ago
joeldrapper|4 months ago
veeti|4 months ago
lcnPylGDnU4H9OF|4 months ago
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)
2: https://news.ycombinator.com/item?id=45348390
splittydev|4 months ago
pil0u|4 months ago
wallmountedtv|4 months ago
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.
https://joel.drapper.me/p/rubygems-takeover/
KingOfCoders|4 months ago
It is said the underlying cause is that devs push rv which is threatening RubyGems.
SSLy|4 months ago
milliams|4 months ago
realty_geek|4 months ago
There is a conversation around this which needs to be had. Maybe on bsky or x?
https://x.com/africajam/status/1975206106738901110
https://bsky.app/profile/indirect.io/post/3m2iq5p7eoc2j
colechristensen|4 months ago
Mystery-Machine|4 months ago
NARKOZ|4 months ago
steveklabnik|4 months ago
dubbel|4 months ago