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.
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.
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).
They're not the original authors of Rubygems so it's doubtful they have anything more than copyright on the code they contributed.
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.You'll have to take me on my word about it...but if I saw this as a driver of the issue I would have included it. I think saying "shopify was involved" is sort of like saying "people talked about RV at Rails World." Shopify is huge and hugely invested in Ruby's OSS ecosystem. I have my own critiques of the company, but not here. I think they're a net positive for Ruby OSS. I wish the general response was "more companies need to step up, I'll go talk to my leadership" rather than knocking these volunteers for their involvement. I've said elsewhere that if I were in the committee or in their shoes...I don't think the outcome would have been different (even if details would have). Also, you are welcome to disagree and have a different opinion.
I agree that it's best not to have situations like this. PSF bylaws "Section 5.15. Limits on Co-affiliation of Board Members." and similar rules are generally good at preventing the perception of conflict of interest (which is also important...that the perception alone can be damaging).
Right now, the committee is 100% one company (me). Because I'm the only one on it. Which is also a problem. Also, we're in a rebuilding/re-prioritizing phase with all of this...so it's hard to onboard while things are in flux.
Mike works at Basecamp (now and then). Based on comms I don't believe any of them acted on behalf of their employer i.e. no "team orders." Or if they did, they did so in ways that aligned with my perception of what I believed to be the correct read of the situation.
I also think that we (as humans) are much less incapable of knowing what things sway and influence our opinions than we think. We are much less capable of correcting for conflicts of interest than we would like. The study "tappers and listeners" is about adjusting for knowledge (curse of knowledge), but I think it applies to influence as well. Which is to say...I'm sure that everyone was influenced in many ways, but I felt they acted as individuals and reacted in real time.
There are other details of affiliations that I omitted from the former maintainers as well, that are true to state, and likely had some impact on their decisions ... but I used judgment to omit what I didn't think was fair or didn't think was immediately relevant. Not saying I got it all right all the time, but sort of chiming in to say "I'm not only omitting information in favor of one party." Yes, I'm biased...but I'm trying to correct for that bias. (A funny thing to state after just saying humans are bad at it, I know).
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.
My biggest takeaway from this is the intermingling of opensource work/foundations/companies and employees/contractors/volunteers needs to be incredibly explicit. It sounds like everyone had very different expectations about what this group of people was (ranging from an exclusive club of influential ruby developers to a very formal, business-like foundation) and, as a result, each other's actions seemed hostile/strange/confusing.
[1] I actually think the comments about the proposal of selling the user data does a disservice to the postmortem. I think it invokes a much more emotional reaction from the reader than anything else and, while potentially interesting, seems like dirty laundry that doesn't change the lesson the postmortem teaches.
I seem to remember there were some threats of legal action related to unauthorized access after this kerfuffle but I a) don't know what is going on with that, b) don't know what the law actually says about that and c) don't know if that is what you are referring to. If so, I think it is different than what the original comment alleged which was more about moonlighting/using proprietary information/competing. I think that topic is extremely complicated (e.g. I am not so sure moonlighting for a competitor while an employee is necessarily protected in California...) but that wasn't alleged in the postmortem anyway.
As far as arguments about community, Shopify IS the community by virtue of being the ones putting up pretty much all the money to keep this ship afloat.
If you don't have skin in the game your positions won't be taken seriously.
Depending on your point of view, Sidekiq either turned their back on the community or tried to start a coup by pulling funding just so they could morally grandstand.