Hacker Newsnew | past | comments | ask | show | jobs | submit | drbragg's commentslogin

This isn't true according to this article: https://www.404media.co/how-ruby-went-off-the-rails/. Joel has a terrible habit of not citing his sources so I'm not sure if the post in question is the same but this seems to nullify that argument. TBF I do think there was pressure from Shopify to get compliance and security in order but saying "Shopify demanded that Ruby Central take full control of the RubyGems" is just plain not true.


The rubygems treasurer who is on the board said funding was conditional on doing this[0][1].

One interesting thing is that Ruby Central then said "Board decisions are independent and not contingent on funding."[2].

Doesn't inspire a lot of trust when there is a statement from a board member saying "we did this because of funding".

I'm more inclined to believe Joel's account.

[0] A deadline (which as far as I understand, we agreed to) loomed. Either Ruby Central puts controls in place to ensure the safety and stability of the infrastructure we are responsible for, or lose the funding that we use to keep those things online and going.

[1] https://apiguy.substack.com/p/a-board-members-perspective-of...

[2] https://rubycentral.org/news/our-stewardship-where-we-are-wh...


Ruby Central is making legal threats to its critics, so I hope you can see why people don’t feel safe to come forward on the record.

I can tell you that two people with direct knowledge of the situation told me that Shopify demanded that Ruby Central take full control of the RubyGems GitHub organisation and packages.

You can believe that I am lying if you want. But I can’t directly cite my sources in this case.


I never said you were lying. I said the quote that person pulled from your article isn't true. IIRC your article came out before the one I linked came out.


I believe the quote pulled from my article is true. Freedom’s original article lines up with what other people told me. I know he’s tried to retract it, but I don’t trust him to be truthful in this matter. He has lied about other things like the takeover being necessary for security.


Opposed to hiring someone with a technical background but no experience running a non-profit?


It's easier to learn to run a non-profit coming from a technical management background than it is for an MBA to learn to be an engineer.


As opposed to someone with experience with both?


I mean, that would be awesome. Got someone in mind?


Non sequitur. False dichotomy.


Ruby Central's whole thing is they maintain, develop, and secure bundler and ruby gems. Marty was previously a lead at Ruby Central and recently came back to RC as their Open Source Lead. It sounds like there was a clusterfuck getting the repo switched over but I'm not seeing how this is an attack on Ruby gems. Am I missing something?


I think the missing piece here is that almost every person publicly involved with RubyGems’ development has left the project in recent weeks. I don’t have any special insight here, but from an outsider’s perspective it seems as through Ruby Central is trying to turn a former “host” relationship into a “control” relationship.


I think you're right, but I suspect the root here is one of legal liability - if rubycentral is operating as a nonprofit that hosts _a recurring attack vector on other companies_, they'll have legal obligations to secure that service against those attacks. I assume they are continuously deploying out of that repository, and took the simplest route to controlling the attack vectors?

I'm not sure how anyone familiar with open-source communities would fail to predict the backlash though. They really should have forked the repository and switched the deployments over to their downstream fork (if I'm right about the root cause here).

(I'm mostly thinking in terms of supply-chain attacks, like this one: https://blog.rubygems.org/2025/08/25/rubygems-security-respo...)


That would be a pretty broad assumption of liability: I'm not very involved in Ruby but I am involved in Python packaging, and to my knowledge there's been no similar discussion around the PSF's keys-to-the-code control over PyPI (which is in a similar position in terms of supply chain attack vectors).

In other words: that argument is interesting, but it feels strained to me :-) -- I don't think RubyGems or Ruby Central is actually legally liable in this way (or if they are, it suggests a failure of clarity in their EULA/TOS).


Well.. "legal liability" is kind of complex topic. Usually what really matters isn't "what the courts will actually determine if such a case is brought" it's "how much will it cost to prove that lack of liability, and what is the risk that we are wrong?". I also don't believe that such an organization is liable for anything beyond negligence, but whether the lack of an action constitutes negligence is .. well, one can rarely be totally confident in the outcome of that kind of proceeding.

The (mostly PR) explanation they produced seems to express roughly the same thing I was guessing though: https://rubycentral.org/news/strengthening-the-stewardship-o...


Well, there's more information out and it seems pretty.. damning. I wasn't convinced by "power grab", but "economic pressure from our sole remaining major sponsor" is _way_ more believable, and the chain is events is getting fairly clear. Check out Joel's explanation for a coherent delve into the events: https://joel.drapper.me/p/rubygems-takeover/

Now I just have to hope the fallout from this includes a less centralized replacement for the tools I'm used to - I haven't found anything solid yet, but I imagine andre will be examining this problem space with rv now.


there is no contract to assign liability

and I doubt you could ever get negligence to stick, given you are downloading code from some website and running it, on your own accord, entirely unprompted

(but IANAL)


Who? Everyone I recognize is continuing to contribute. https://github.com/rubygems/rubygems/graphs/contributors?fro...


Your comment reminds me of this video: https://youtu.be/R3gef1Wn9BE


Can't wait for the Android version ;)



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: