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.
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 OSS software that runs that service is a root cause here and insufficiently called out.
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.
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.
That wasn't my read of what the postmortem is claiming. I didn't see a claim that anyone did anything illegal with proprietary information and the only legal question anyone raised was around a tangentially related proposal with user data[1]. I think the question about working on competing work is unfortunately more grey than most on HN would like, but even then nobody was fired/terminated for that. It sounds like people voluntarily left.
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.
The document didn't mention a lawsuit and I was just responding to the above comment with only the context of the postmortem and pointing out that this particular article didn't claim anything illegal happened. You and some others here might have much more context that I or other readers of this postmortem don't have.
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.
> The document didn't mention a lawsuit and I was just responding to the above comment with only the context of the postmortem and pointing out that this particular article didn't claim anything illegal happened.
You are correct that they did not make any claims, but the article did insinuate illegal behavior on the part of André and Samuel by selectively juxtaposing facts to imply wrongdoing without ever directly stating or saying that their behavior was illegal. For example:
1. André's first commit on RV is placed on the same bullet point as the Ruby Central-funded maintainer offsite, which implies Ruby Central's travel money subsidized a competing project's creation.
2. The `rubygems-github-backup` access token covering "all repos, including private repos" is introduced in the same timeline section as RV development, without any allegation it was used for RV.
3. The "Incident Lessons" section recommends adding an "Outside Business Activities" declaration policy, which only reads as a "lesson" if André's undisclosed side project is being framed as the problem in need of remediation.
4. The report states André "had intimate knowledge of the foundation roadmap" and "did not tell anyone in Ruby Central about this work until it launched". This frames nondisclosure of a lawful side project as a transgression. However, Ruby Central passed on this work, and even if they didn't, André has no obligation to tell Ruby Central about his work!
5. André's proposal to have his consultancy analyze RubyGems.org download logs is presented alongside an OSS Committee member raising PII and "reputational risk" concerns, casting a perfectly sensible rejected business proposal as something suspect.
By my count, Ruby Central makes roughly 10 insinuations throughout the report, but not once do they actually claim any of these constitute a transgression.
> 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...)
California is actually quite clear on this! Bus. & Prof. Code § 16600 voids non-compete agreements, and California courts have consistently read it broadly enough that working on a competing project during employment is protected. The line is whether you used your employer's proprietary information or resources to do it, not whether you competed. The report does not allege that Samuel or André used Ruby Central's proprietary information, and given how thoroughly they documented everything else, I'd expect them to have said so if they had evidence of it. Ruby Central is insinuating that working on RV in the first place is a problem, not that they crossed any legal or contractual line.
uv is Astral's onramp to paying customers. Without uv's tight integration with Astral's other tooling that they want to charge for, they wouldn't be able to sell anything. Building a business around doing the same for Ruby may be within their rights, but it's absolutely a conflict of interest working or contracted by Ruby Central. Removing them was an obvious move.
If this is a conflict of interest, then any Ruby core systems being controlled predominantly by members of the Shopify dev team is itself a conflict of interest. I am fine saying 'we need to make sure these libraries stay independent and community controlled', but that is so clearly not what was going on here. Believing that is just letting the RC FUD and PR control your thinking on the narrative.
I'm sorry but what are Shopify's business activities that directly compete with services provided/maintained by RubyCentral?
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.
That attitude is exactly the problem. Shopify does not 'keep the ship afloat' they are just a corporation using open source systems as the foundation of their business. Competition is not by definition the backing of a 'conflict of interest', it legally refers to a person or entity with a stake in a particular outcome having control of the means to achieve that which are not legally sound , ie compromise their judgment. I think Shopify's judgement of what 'is good for the Ruby community' is severely compromised by their corporate interests, and probably by their boards political interests as well. Hence, why they are trying so hard to justify removing Andre.
Do you have any idea how expensive it is to keep the infrastructure running? RubyCentral's operating expenses are in the millions every year and exceed their revenue.
Andre's removal is easily justifiable by his own (lengthy history of) sketchy behavior.
Since when is "open source" something businesses shouldn't be allowed to get value from or even have a stake in? These things are MIT licensed. That's free as in speech AND beer. If you don't like the freedoms of the license and how other people use them, don't use the license. If you don't like someone's stewardship, fork and maintain your own.
Responding to your first paragraph, the rest wasn’t constructive.
Shopify paying for infrastructure related to Ruby is an investment, not charity. Hosting gems costs money and a healthy community depends on that gem hosting. Spotify, in turn, depends on that healthy community to produce and maintain gems, train future employees, stuff like that. They’re not paying that money for fun, it is to protect their interests.
And all of the above would be true even if the OSS committee wasn’t 100% Shopify affiliated. That’s gravy.
> Do you have any idea how expensive it is to keep the infrastructure running?
Yes, I do. All hardware and bandwidth are donated by Fastly and AWS so it costs RC nothing. Their expenses were $20,000/mo for 24/7 ops coverage: $2000/mo for 6 people and $8000/mo for service maintenance (e.g. db and software upgrades). So $240,000/yr, not "millions".
Care to cite the dollar amount of Shopify's yearly contribution (not even counting the humans doing actual labor) and what Sidekiq pulled in funding while you're at it?
Those who write the code have more of a right than those who pay the bills. Anyone can write a check. A select few have the acumen and experience to actually write the code.
You can't unilaterally declare someone "sketchy" and then kick them out in the name of conveience.
No I'm calling him sketchy because that's the sentiment anyone who has been around in the community long enough and dealt with Andre has about him. This is very openly discussed and documented and not just in the aftermath of this event.
People having concerns about Andre's behavior around his money and his open source contributions can't even be called an open secret.
The narrative that one side of this is pushing that this is some little guys vs evil corporate overlords problem is short-circuiting so many peoples' ability to rationalize about this topic.
This is about the personal failings to communicate and organize among a very small group of highly skilled, highly productive people. It's also about how they have fallen into camps and try to apply institutional and social leverage in order to influence millions of bystanders in order to maintain/wrest control. Each credibly accusing the other of doing it for their own benefit.
Nobody is in the right here. If you can't engage with that as your starting point, you aren't serious about this conversation and are just spouting one side's propaganda.
In the aftermath us bystanders are left wanting either stability or revolution. Revolutions generally aren't good for anyone. Especially the people who want it the most.
> is short-circuiting so many peoples' ability to rationalize about this topic.
It appears unfair. That's the extent of my rationale. I've not seen any concrete evidence to draw any further conclusion than this. If you're managing a project and you're not cognizant of this, you probably shouldn't be managing projects; in particular, you should stay away from open source projects with a large base of volunteer contributors.
> Nobody is in the right here.
So, they went through all of this, made themselves look bad, cast tons of aspersions, and in the end, they weren't even in the right? This seems a shabby defense.
> are just spouting one side's propaganda.
I don't care about one side or the other. You see this giant crater left by these decisions though? Yea.. that's the problem.
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’d think that name, Shopify, would appear three times, once per employee/committee member. Or just once, to say the entire OSS committee was employed by Shopify, if we’re still identifying the group strictly as a group. Either would be fine.
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.
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 OSS software that runs that service is a root cause here and insufficiently called out.
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.
I think part of that is that it was written from the perspective of the bug that caused the outage ;)
> 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.
this is a good write up, I hope this really helps put the whole mess to rest.
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.
That wasn't my read of what the postmortem is claiming. I didn't see a claim that anyone did anything illegal with proprietary information and the only legal question anyone raised was around a tangentially related proposal with user data[1]. I think the question about working on competing work is unfortunately more grey than most on HN would like, but even then nobody was fired/terminated for that. It sounds like people voluntarily left.
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.
They are still trying to sue Andre, that is by definition claiming he did something illegal. The rest is just fluff to cover their insincerity (IMO).
The document didn't mention a lawsuit and I was just responding to the above comment with only the context of the postmortem and pointing out that this particular article didn't claim anything illegal happened. You and some others here might have much more context that I or other readers of this postmortem don't have.
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.
A couple of gentle corrections:
> The document didn't mention a lawsuit and I was just responding to the above comment with only the context of the postmortem and pointing out that this particular article didn't claim anything illegal happened.
You are correct that they did not make any claims, but the article did insinuate illegal behavior on the part of André and Samuel by selectively juxtaposing facts to imply wrongdoing without ever directly stating or saying that their behavior was illegal. For example:
1. André's first commit on RV is placed on the same bullet point as the Ruby Central-funded maintainer offsite, which implies Ruby Central's travel money subsidized a competing project's creation. 2. The `rubygems-github-backup` access token covering "all repos, including private repos" is introduced in the same timeline section as RV development, without any allegation it was used for RV. 3. The "Incident Lessons" section recommends adding an "Outside Business Activities" declaration policy, which only reads as a "lesson" if André's undisclosed side project is being framed as the problem in need of remediation. 4. The report states André "had intimate knowledge of the foundation roadmap" and "did not tell anyone in Ruby Central about this work until it launched". This frames nondisclosure of a lawful side project as a transgression. However, Ruby Central passed on this work, and even if they didn't, André has no obligation to tell Ruby Central about his work! 5. André's proposal to have his consultancy analyze RubyGems.org download logs is presented alongside an OSS Committee member raising PII and "reputational risk" concerns, casting a perfectly sensible rejected business proposal as something suspect.
By my count, Ruby Central makes roughly 10 insinuations throughout the report, but not once do they actually claim any of these constitute a transgression.
> 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...)
California is actually quite clear on this! Bus. & Prof. Code § 16600 voids non-compete agreements, and California courts have consistently read it broadly enough that working on a competing project during employment is protected. The line is whether you used your employer's proprietary information or resources to do it, not whether you competed. The report does not allege that Samuel or André used Ruby Central's proprietary information, and given how thoroughly they documented everything else, I'd expect them to have said so if they had evidence of it. Ruby Central is insinuating that working on RV in the first place is a problem, not that they crossed any legal or contractual line.
uv is Astral's onramp to paying customers. Without uv's tight integration with Astral's other tooling that they want to charge for, they wouldn't be able to sell anything. Building a business around doing the same for Ruby may be within their rights, but it's absolutely a conflict of interest working or contracted by Ruby Central. Removing them was an obvious move.
If this is a conflict of interest, then any Ruby core systems being controlled predominantly by members of the Shopify dev team is itself a conflict of interest. I am fine saying 'we need to make sure these libraries stay independent and community controlled', but that is so clearly not what was going on here. Believing that is just letting the RC FUD and PR control your thinking on the narrative.
I'm sorry but what are Shopify's business activities that directly compete with services provided/maintained by RubyCentral?
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.
That attitude is exactly the problem. Shopify does not 'keep the ship afloat' they are just a corporation using open source systems as the foundation of their business. Competition is not by definition the backing of a 'conflict of interest', it legally refers to a person or entity with a stake in a particular outcome having control of the means to achieve that which are not legally sound , ie compromise their judgment. I think Shopify's judgement of what 'is good for the Ruby community' is severely compromised by their corporate interests, and probably by their boards political interests as well. Hence, why they are trying so hard to justify removing Andre.
Do you have any idea how expensive it is to keep the infrastructure running? RubyCentral's operating expenses are in the millions every year and exceed their revenue.
Andre's removal is easily justifiable by his own (lengthy history of) sketchy behavior.
Since when is "open source" something businesses shouldn't be allowed to get value from or even have a stake in? These things are MIT licensed. That's free as in speech AND beer. If you don't like the freedoms of the license and how other people use them, don't use the license. If you don't like someone's stewardship, fork and maintain your own.
Responding to your first paragraph, the rest wasn’t constructive.
Shopify paying for infrastructure related to Ruby is an investment, not charity. Hosting gems costs money and a healthy community depends on that gem hosting. Spotify, in turn, depends on that healthy community to produce and maintain gems, train future employees, stuff like that. They’re not paying that money for fun, it is to protect their interests.
And all of the above would be true even if the OSS committee wasn’t 100% Shopify affiliated. That’s gravy.
> Do you have any idea how expensive it is to keep the infrastructure running?
Yes, I do. All hardware and bandwidth are donated by Fastly and AWS so it costs RC nothing. Their expenses were $20,000/mo for 24/7 ops coverage: $2000/mo for 6 people and $8000/mo for service maintenance (e.g. db and software upgrades). So $240,000/yr, not "millions".
Care to cite the dollar amount of Shopify's yearly contribution (not even counting the humans doing actual labor) and what Sidekiq pulled in funding while you're at it?
Those who write the code have more of a right than those who pay the bills. Anyone can write a check. A select few have the acumen and experience to actually write the code.
You can't unilaterally declare someone "sketchy" and then kick them out in the name of conveience.
No I'm calling him sketchy because that's the sentiment anyone who has been around in the community long enough and dealt with Andre has about him. This is very openly discussed and documented and not just in the aftermath of this event.
People having concerns about Andre's behavior around his money and his open source contributions can't even be called an open secret.
The narrative that one side of this is pushing that this is some little guys vs evil corporate overlords problem is short-circuiting so many peoples' ability to rationalize about this topic.
This is about the personal failings to communicate and organize among a very small group of highly skilled, highly productive people. It's also about how they have fallen into camps and try to apply institutional and social leverage in order to influence millions of bystanders in order to maintain/wrest control. Each credibly accusing the other of doing it for their own benefit.
Nobody is in the right here. If you can't engage with that as your starting point, you aren't serious about this conversation and are just spouting one side's propaganda.
In the aftermath us bystanders are left wanting either stability or revolution. Revolutions generally aren't good for anyone. Especially the people who want it the most.
> is short-circuiting so many peoples' ability to rationalize about this topic.
It appears unfair. That's the extent of my rationale. I've not seen any concrete evidence to draw any further conclusion than this. If you're managing a project and you're not cognizant of this, you probably shouldn't be managing projects; in particular, you should stay away from open source projects with a large base of volunteer contributors.
> Nobody is in the right here.
So, they went through all of this, made themselves look bad, cast tons of aspersions, and in the end, they weren't even in the right? This seems a shabby defense.
> are just spouting one side's propaganda.
I don't care about one side or the other. You see this giant crater left by these decisions though? Yea.. that's the problem.
You’d think that name, Shopify, would appear three times, once per employee/committee member. Or just once, to say the entire OSS committee was employed by Shopify, if we’re still identifying the group strictly as a group. Either would be fine.