Our Stewardship: Where We Are, What's Changing and How We'll Engage
Posted3 months agoActive3 months ago
rubycentral.orgTechstory
heatednegative
Debate
85/100
RubyOpen-SourceGovernance
Key topics
Ruby
Open-Source
Governance
Ruby Central announces changes to Rubygems stewardship, sparking controversy and mistrust among the community, with concerns over governance, security, and potential corporate influence.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
44m
Peak period
29
2-4h
Avg / period
7.4
Comment distribution59 data points
Loading chart...
Based on 59 loaded comments
Key moments
- 01Story posted
Sep 30, 2025 at 5:16 PM EDT
3 months ago
Step 01 - 02First comment
Sep 30, 2025 at 6:00 PM EDT
44m after posting
Step 02 - 03Peak activity
29 comments in 2-4h
Hottest window of the conversation
Step 03 - 04Latest activity
Oct 1, 2025 at 1:29 PM EDT
3 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45431367Type: storyLast synced: 11/20/2025, 3:01:49 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
He posted on the rubygems slack that he left and is conditioning his return on all other maintainers being reinstated.
Based on previous posts, they did revoke everyone GitHub access, but with the intent to give it back to some maintainers after they signed some sort of contributor agreement.
However on the package publishing side, you can see that on Sept 20 3 people had access [0], hsbt, deivid and colby.
If you compare to aug 24, there was also andre, sebgiddins and rubymorillo (no idea who that is).
So that leads me to believe they had the intention to keep him, even more so because he was still contracting with them. AFAICT the intent was to remove accesses to former employees who left to start their own consultancy.
So to me, that post from RC checks out, and I think they were very well aware of who was contributing what.
[0] https://web.archive.org/web/20250920140646/https://rubygems.... [1] https://web.archive.org/web/20250824033341/https://rubygems....
Edit: answering myself on who rubymorillo was, it's someone who didn't commit in that gem since 2018: https://github.com/rubygems/rubygems/commits?author=rubymori...
So yeah, permission management at Ruby Central did indeed seem to have been a huge mess. Not excusing the extremely poor rollout, but some cleanup was definitely overdue...
My understanding is that having a legally enforceable contract help dissuade malevolent actions (easier to sue for breach of contract? But IANAL).
As for copyright attribution, I doubt it. That ship has sailed, that code base already contains contributions from hundreds of people, and I can’t really imagine a business model that would rely on relicensing.
That sounds like someone or some people spontaneously deciding they're going to become gatekeepers, without any kind of warning and/or Community discussion/agreement first.
> Not excusing the extremely poor rollout, but some cleanup was definitely overdue...
While true, what they should have done is discuss it with the maintainers _first_ and agree to a plan. Not just seize control, especially from active contributors. :(
Are they offering warranties?
What new privacy laws demand them signing some handcrafted legal document?
Is what they did legal?
Couldn't they fork to provide a secure version.
That one guy maintaining so many rubygems is the same guy who is offering a competing software solution that could reduce their profit stream is that the real reason?
https://github.com/rubygems/rubygems/blob/master/LICENSE.txt
a. THE SERVICE IS PROVIDED STRICTLY ON AN “AS IS” AND “AS AVAILABLE” BASIS, AND PROVIDER MAKES NO WARRANTY THAT THE SERVICE IS COMPLETE, SUITABLE FOR YOUR PURPOSE, RELIABLE, USEFUL, OR ACCURATE.
Just stop trying to make excuses for these people. They screwed up, and based on this press release, don't seem to have any interest in actually correcting those mistakes.
THE SERVICE IS PROVIDED STRICTLY ON AN “AS IS” AND “AS AVAILABLE” BASIS, AND PROVIDER MAKES NO WARRANTY THAT THE SERVICE IS COMPLETE, SUITABLE FOR YOUR PURPOSE, RELIABLE, USEFUL, OR ACCURATE.
What warranty are they providing exactly?
I still don't understand the mistrust of Andre though. Also, the second point seems a bit disingenuous when their own board member speaks about a specific deadline[2]. He says it's something they agreed to, so it's necessarily external. That and the teams of reports of other people saying they've heard it's Shopify putting pressure for this specific point makes me look for a higher standard of rebuttal than "dude trust me". Explain why it was urgent. Explain what the deadline was.
[0] A recent access review had revealed that many systems were under the control of a single individual, which we determined presented a risk to the security and operational sustainability of those systems.
[1] The Board acted independently, and financial support was NOT conditioned on taking these steps.
[2] https://apiguy.substack.com/p/a-board-members-perspective-of...
[0] https://gist.github.com/simi/349d881d16d3d86947945615a47c60c...
[1] https://joel.drapper.me/p/rubygems-takeover/
(To be clear, I am not stating my own opinion of DHH or Shopify. I'm just saying I suspect this is why a lot of Rubyists are not OK with RubyCentral being under the thumb of Shopify.)
[1]: https://www.shopify.com/news/david-heinemeier-hansson-board
[2]: https://davidcel.is/articles/rails-needs-new-governance
They certainly have the capacity to run their own full on mirror service, but I doubt they have serious incentive to do so given exciting controls and culture re: Ruby and OSS contributions.
I think what is most likely is that Shopify is trying to achieve some security goals in rubygems through Ruby Central. That they put a deadline on funding based on some security guarantees.
Shopify knows they are a high value target. I bet they thought they could muscle for whatever they want using funding money, and didn’t anticipate the mishandling and then blowback.
Red Hat -> IBM -> CentOS is an example of this to me.
Sounds like it’s either some enterprise, or a bunch of volunteers that see an opportunity to be little tyrants.
Love how they simultaneously decided that this had been going on for years, that nothing bad had happened, and that they had to act now without any prior consultation.
But worse, there’s just some random things thrown in that make no sense. Like “the README says rubygems code is managed by RubyCentral”. “Managed” does not mean owned. And how it should be managed ought to be up to the community, not board members acting in secret.
And this shows just remarkably poor editing: “some maintainers had long periods of inactivity (Least Privileged Access), changed the timeline.” Is that parenthetical a reminder to the original drafter to expand on that topic? Because it makes no sense in context.
Then there’s this line: “We could have communicated earlier and in more detail. And we won’t stop apologizing for the confusion that caused.”
That’s the closest they ever get to admitting they did anything wrong, and although they say “we won’t stop apologizing”, I’ll note that they never do apologize.
But, absolutely everything they’ve done since this started has been wrong, and ultra defensive. Just own up to your mistakes and start from scratch.
Well, technically true that they haven't stopped.
I'm not sure if this was LLM-written because I don't think an LLM would write a missive almost entirely in bullet points - but it has many of the hallmarks. Like, these sentences almost sound reasonable, but don't actually make sense or represent a coherent train of thought:
You may not agree the conclusion, but there is a complete train of thought.
> A recent access review had revealed that many systems were under the control of a single individual, which we determined presented a risk to the security and operational sustainability of those systems. We had intended to resolve this over time.
and:
> ... the departure of key maintainers and contribution data showing that some maintainers had long periods of inactivity (Least Privileged Access), changed the timeline.
As the 2nd doesn't really change anything about the 1st. If that "single individual" has been acting maliciously or similar then it might, but they don't present evidence of that being the case. So there's nothing about the 2nd statement which has anything to support changing any kind of timeline.
ie this all seems to be bullshit
Press releases/open letters like this one have existed long before LLMs for that reason.
They should stop whatever it is they're doing, and work with the other Community members to resolve _the actual problem_ constructively.
Otherwise they'll probably just cause an alternative to Ruby Central to emerge and/or be adopted widely.
It seems like they're concerned about rv taking off and becoming that alternative, and it's hard to imagine anything else they could have done to make that more likely to occur.
This is poor, even by corporatese standards.
Is this contradictory to what others involved have said? It also implies the first set of actions were taken outside of business hours which seems odd.
Joel Draper says as much (see the penultimate section of https://joel.drapper.me/p/rubygems-takeover/) although that would be more of a motivation for RubyCentral than for Shopify.
I think it’s pretty hard to avoid acknowledging this, which gives the distinct impression that the post (and by extension Ruby Central’s current leadership) are not particularly committed to transparency on the issue. I’d love to be wrong about that.
1 more comments available on Hacker News