The RubyGems takeover from the perspective of an open source developer
On 23 September, I revealed that Shopify was behind Ruby Central’s sudden takeover of the RubyGems open source projects, and I followed this story up by fact-checking Ruby Central’s claims about the situation.
I tried to keep my own opinions and interpretation out of these pieces and focus on the facts — things I could verify through first-hand accounts, documents, screenshots, meeting recordings and public records.
But today, I want to talk about what happened from my personal perspective as an open source maintainer.
What does “ownership” mean?
“Ownership” is a tricky word when it comes to open source software. When you license your work as open source, you essentially relinquish control.
The only stipulation in the MIT license, for example, is that the original license must be included with copies of the work. I’ve licensed some software with the MIT No Attribution license, which doesn’t even require this.
At the end of the day, anyone can come along and make a copy, modify it (or not) and take your code in whatever direction they like. And for the most part, they don’t even need to acknowledge you.
But as the original developer, you do typically have ownership of more soft parts of the project: the GitHub repository, the package name, the domain name and project website, the main deployment of the documentation (even if the documentation is itself open source), the community forums — GitHub issues, discussions, pull requests, a Discord server. To some extent, you also own the reputation associated with the project.
Most importantly, you own the mandate to move the project forward — to decide what goes in and what comes out and even to include new maintainers who share your vision.
Most successful open source projects start out with one person having the ultimate control over these soft things. Some projects get so large that the original creator establishes a more cooperative governance system to ensure long-term success and reduce the “bus factor”.
Remember, at any point in time, anyone can come along and fork the source code and take the project in an entirely new direction. That’s an essential part of all this. But if they want community support, they have to put the work in to convince people that their new direction is better.
Sponsoring a project doesn’t confer ownership.
Since open source software is free to use/copy/modify, contributing to useful open source — either directly or financially — is a public good.
Some developers accept financial sponsorship as a way to fund their work. And some non-profits pay people to work on open source projects.
When allocating funds for open source, a non-profit could decide to create its own projects or it could decide to contribute to existing projects. Alternatively, it could fork existing projects, taking them in a new direction controlled by the non-profit.
Ruby Together decided to contribute to existing projects, which I believe included Bundler, RubyGems, Ruby API and Ruby Toolbox. When Ruby Together merged with Ruby Central, Ruby Central took over these sponsorship programs.
What can you do when you don’t agree with the direction of an open source project?
If you don’t agree with the direction of an open source project, you essentially have two options:
You can negotiate with the maintainers and try to convince them to change course. You can give examples and use-cases, present prototypes, use reasoning and persuasion.
Alternatively, you can fork the project and take the source-code in a new direction with your own modifications. And you can decide whether to keep this fork private for your own use or publish it and try to attract wider community support.
What you can’t do is find your way onto the maintainers team on the original project and then unilaterally kick all the other maintainers out.
It doesn’t matter how bad the other maintainers ideas were, or how “mean” or “lazy” you think they are. This is just not something you can do.
Ruby Central’s move sets a dangerous precedent that should concern all Rubyists.
This is exactly what Ruby Central did. Ruby Central used its illegitimate GitHub permissions to remove the active maintainers of the RubyGems open source projects — people who had been maintaining them for over a decade.
It was not about security. Anyone who’s ever deployed code to a server knows this. It was not because they had the right. Ruby Central never owned the RubyGems projects.
All they had was the capability and the will.
Why this matters so much
To execute the RubyGems takeover, Ruby Central used its illegitimate access to the RubyGems GitHub organisation and the packages on the RubyGems.org Service.
They had the capability, they had the will and they justified it as being “for security”. A claim we can prove from first principles is blatantly false.
Since Ruby Central runs the RubyGems.org Service, they have the capability to takeover any package published to that service.
Ruby Central uses Rails, so what would stop them from taking over the rails package on the RubyGems.org Service? They also use my gems, phlex and phlex-rails. What stops them from taking over these packages?
If it’s true (which it isn’t) that simply using a package someone else wrote is a security risk then that would justify a takeover of my packages.
The Ruby community placed so much trust in Ruby Central and they shattered it into a million pieces.
This wasn’t a mistake.
I watched a 57 minute meeting between the RubyGems maintainers and Marty Haught, recorded on 17 September. This recording proves that Ruby Central knew what they were doing before they did it. It proves that they knew there were other options, such as making a fork or restricting who could deploy.
Conclusion
Ruby Central have acted in bad faith — not just towards the RubyGems maintainers, but also to the wider Ruby community, who they have ignored and misled over the last week.
The RubyGems repositories and packages are compromised. The RubyGems.org Service is compromised, because we cannot trust the organisation running it to act with integrity in good faith on behalf of the Ruby community.
We cannot stand for this. We must demand that Ruby Central make this right.
Disclosure
I was employed by Shopify between 2017 and 2022.