RubyGems Fracture Incident Report (rubycentral.org)

by schneems 42 comments 94 points
Read article View on HN

42 comments

[−] matharmin 45d ago
I can see a lot of time was put into the report, and it helps to have the detail, but in my mind it glosses over one of the most important parts: The dispute in the stewardship of the bundler and rubygems open-source projects.

As I understand it, Ruby Central controlled the rubygems and bundler github organizations, but did not "own" the projects in the traditional sense - the individual contributers have copyright on the code, and potentially even trademark rights. By then removing access of core maintainers to those projects, they removed access to something they don't "own" themselves.

This is all complicated by the fact that controlling a github organization or repo is different from owning the trademark or copyright. But some of the original maintainers clearly felt they had more of a right to those projects than Ruby Central did.

I believe not clarifying this before making these access changes was the biggest mistake that Ruby Central made, and it's not even mentioned in this report.

[−] tuckerman 45d ago
I don't have much skin in the game but as a passerby, I agree that the report obviously was made with a lot of time/effort but wouldn't dramatically change someone's view of Ruby Central or assure anyone this won't happen again. This is like writing an outage postmortem without really getting to the root cause and identifying what can be done to prevent in the future.
[−] RhythmFox 45d ago
I think part of that is that it was written from the perspective of the bug that caused the outage ;)
[−] inopinatus 45d ago
There’s a ton of detail in the report so perhaps I missed it, but yes, the underlying structural/governance flaw of conflating a service, with the IP that runs that service, is a root cause here and seems insufficiently called out. The tragedy of misconception -> misconstruction -> misconfiguration is common when the bridge between governance and engineering is crossed.

The takeaway for the rest of is that separation of such concerns isn’t an abstract notion but needs to be reflected in the mechanical implementation of organisations, lest you get a train wreck later when perspectives don’t align and the whole picture crumbles.

[−] schneems 45d ago

> dispute in the stewardship of the bundler

This was never in dispute from the two parties. Ruby Central and "the maintainers" agreed from the beginning that it was collateral damage. The disagreement was what that meant and what to do with it. Hence the Sept 10 message from the Ruby Central Committee that they should move it to the Ruby core org (which IMO is long overdue).

The original plan (by the oss committee)was to move bundler to the Ruby org, that's what happened. When it did, the community generally like it (on HN and reddit comments).

[−] dismalaf 45d ago

> individual contributers have copyright on the code, and potentially even trademark

They're not the original authors of Rubygems so it's doubtful they have anything more than copyright on the code they contributed.

[−] riffraff 45d ago
this is a good write up, I hope this really helps put the whole mess to rest.
[−] mpalmer 45d ago

    This incident involved many people over a rather long time scale, and it was important to detangle how people perceived events from how they actually unfolded. The subject matter is deeply subjective, and multiple failed attempts at writing this doc came as a result of aiming for objectivity, for blameless representation. Therefore, those named in this report are:

    - Full-time employees of Ruby Central
    - Part-time consultants who were involved in access discussions
    - Anyone who made an access change from September 10th-18th, 2025
    - Those who have already been publicly identified in the discourse

    Volunteer groups, including the Ruby Central Board and the Open Source Software (OSS) Committee, are listed, but their actions are represented as a group. Individual quotes from the OSS Committee are used without direct attribution when they represent a general consensus.


    Some execution failures and mistakes are individual, but the purpose of having a foundation and having an institution is that it can rise above individual limitations and provide robust, fault-tolerant systems. Therefore, these are our mistakes, collectively. And collectively we'll learn from them, but only if we face what happened, what we meant to do, and where we fell short.

    The hope is that by sharing this, we can provide some closure to the community and increase transparency

The undeniable effect of masking specific comments made by OSS committee members is to protect three members (2 current, 1 former) of Shopify's technical leadership around Ruby and Rails, who have all since left the committee. The one who left Shopify went to 37signals after.
[−] thramp 45d ago
This is a disappointing look for Ruby Central. I have to get back to work, but their retroactive framing that Andre and Samuel's work on RV justified Ruby Central's subsequent actions is contradicted by their own admissions.

By their own admission, André is a contractor to Ruby Central. Contractors, especially under California law, have no contractual obligation of confidentiality to the other party unless there's a pre-existing agreement in place. They later admit in this "incident report" that they didn't have any legal agreements with André in place, so there's no basis for claiming André couldn't work on rv.

Samuel was an employee, not a contractor, but [California Bus. & Prof. Code § 16600](https://leginfo.legislature.ca.gov/faces/codes_displaySectio....) voids non-compete agreements—so even as an employee, he had every right to work on a competing project. There's no indication that he used Ruby Central's proprietary information to do so, and the report doesn't allege that. I have little doubt that if Samuel or André used proprietary information to develop rv, they would have already presented evidence of that.

Independent of the legalese, a "uv but for ruby" is a blindingly obvious thing to do, and Ruby Central doesn't get to lick the cookie and get upset when an independent contractor—Ruby Central's own characterization—does a thing they didn't fund.

My sourcing on this is that I run a 10-person business with employees in California. I'm not a lawyer, but I looked over enough of this paperwork that I feel confident opining on an internet forum.