Notice I’ll use some specific terminology.
For full context check Ruby Central’s role, my role, and what officially happened.
Ruby Central acted with a deus ex machina approach — coming down like a “hand of God” to forcibly reset the situation. That is not how you contribute to a community. That is not how open source works.
Originally, I had planned to write down everything I collected and share it publicly — because I strongly believe the community deserves transparency.
However, Joel Drapper has already done a quicker and better job of writing this up. I recommend reading it first before continuing: 👉 Rubygems Takeover.
I can personally confirm all information in that post related to Ruby Central, from multiple independent sources.
To be clear:
- I am not here to blame individuals.
- My critique is directed at the process, not at people.
- I am intentionally not naming names, because what matters is how governance was handled, not who pushed the buttons.
- The only exception is Shopify, since it is publicly listed as the main sponsor on Ruby Central’s website and is the company everyone refers to in this context. Personally, I like Shopify — I appreciate and admire all the work they have done (and continue to do) for Ruby over the years. What I do not understand is this push in governance that seems so disconnected from the community.
In short: Ruby Central, operating the service through operators (like me), unilaterally took control of the entire RubyGems GitHub organization — something that has always belonged to the maintainers. They justified it by claiming that some operators were dangerous. But in reality, they used this as cover to remove people from all projects at the maintainer level — including projects they never owned (RubyGems/Bundler/RubyGems.org (code)) — and now claim ownership themselves.
Over the past days, I have done my very best — even though it has been a rollercoaster of constantly uncovering new information (some of it reaching back as far as 2013). My focus was on keeping the community unified, listening to all sides, and trying to bring everyone back to the same table to resolve this.
After reaching out to various people on all sides of this conflict, having multiple conversations and meetings, listening carefully to counter-arguments, and trying to explain what is really happening, I have unfortunately reached the conclusion that one side — Ruby Central — is not willing to do this.
- The fact that the RubyGems GitHub organization was effectively taken over and is not being released back to the original community and maintainers (myself included) is a no-go for me.
- This is not how open source works.
- I did my best to explain that the right path forward was to restore original permissions, since this kind of unilateral takeover cannot be justified without cause.
The clear path was already there:
- Finalize the governance model (RFC #61)
- Invite everyone — especially those who had been historically sidelined — to restart the community co-op together
Instead, Ruby Central chose a different path. They acted like a dictator, deciding unilaterally what was “better for the community” and using their violent control to enforce it. In my view, this was reinforced by pressure from sponsorship arrangements (notably Shopify), which came across as a kind of blackmailing technique.
This is not the open, collaborative, community-driven model we’ve been working toward for years.
This situation did not happen in a vacuum. It is, in my view, a failure of Ruby Central and its board.
- They pushed the community into this state, while claiming to act in its best interest.
- They acted in the opposite way of protecting the community, despite being explicitly informed that such actions would put RubyGems.org into a dangerous state.
- No maintainers or operators were consulted. Nobody was informed in advance.
The composition of the Ruby Central board itself is also concerning.
- Shopify-affiliated people are everywhere, combined with others who have little understanding of how the community works, or what MINASWAN was supposed to stand for.
- People I admired for years for their contributions were revealed to be just that — people, not superheroes.
- The funniest person turns out to be grumpy whenever not everyone is aligned with them.
- The most “community-oriented” person is simply paid to play that role — it’s a contract, not conviction.
- The friendliest face spends their time throwing dirt on others when challenged.
- Some are greedy. Some cannot withstand criticism, or rejection, even after a decade.
The truth is painful:
- There is no MINASWAN. It was a lie — a golden cage that the community lived in.
- Ruby is not really exceptional in this regard, even though I believed it for over a decade.
- The same good people who helped build this community have, in the end, also played a role in breaking it.
All of the official Ruby Central statements so far are, frankly, lies.
- The results of their actions did the opposite of what they claimed.
- Instead of strengthening stewardship, they put the system in danger — and that danger continues today.
- RubyGems.org is now in a state we can consider mostly un-maintained.
- Rather than admitting failure, they chose to publish corporate-grade nonsense (likely even AI-generated in tone) instead of simply saying the truth: “we failed, please help us”.
And if we apply their own justification consistently, then I should have been removed as well.
This was not a neutral cleanup of “dangerous operators” — it was a well-targeted action aimed not at operators, but at set of maintainers (who happened to be also partly operators).
The Ruby Central board’s response exposes another problem: who sits on it.
- The super-naive post of board member is a perfect example. The only qualification on display is: “I love Ruby.”
- Loving Ruby is not enough. Thousands of people love Ruby. That alone does not qualify someone to secure and steward critical infrastructure for the community.
- The board is stacked with Shopify affiliates alongside people who lack deep community understanding or the perspective of MINASWAN.
What the board should have been composed of are people with:
- Strong community feelings and long-term investment in its health
- A real understanding of open source governance and trust
- The courage to protect the community, not corporate interests
Instead, we were left with decisions that betrayed the community and endangered the ecosystem.
In the end, it has become clear that Ruby Central prefers to prioritize its own position and corporate requirements over the needs of the community. The recent actions are the best proof:
- They threw the community overboard to satisfy corporate demands.
- This is unacceptable. It is a mockery in the face of the community.
- The message is loud and clear: you can be part of the community only if you follow our rules — otherwise, we will act unilaterally, regardless of the community’s or maintainers’ agreements.
Even worse, they have preferred to leave RubyGems.org mostly unmaintained and largely unoperated, with core projects left without real maintainers, rather than risk sponsorship money or compromise on personal demands and goals.
To make it even worse, Ruby Central kicked out the only maintainer directly involved with security — labeling him a “security threat” — and replaced him with exactly nothing.
That is not stewardship. That is control at the expense of the very people who built and sustained these projects for years.
I want to be clear: I understand there have been real problems in the community over the years. Some of the maintainers who were removed had conflicts, and there were reasonable reasons why a demand for change existed.
But this is not the way to fix those problems. Ruby Central acted with a deus ex machina approach — coming down like a “hand of God” to forcibly reset the situation. That is not how you contribute to a community. That is not how open source works.
So while I can acknowledge some of Ruby Central’s concerns, their actions have left me no choice.
- I am leaving any cooperation with Ruby Central.
- And since they will most likely require a CLA (Contributor License Agreement) for future work, I will no longer be able to contribute at all.
I do not believe RubyGems.org is in danger long-term — the service will continue to operate, just under different people. It will take some time to stabilize, but new operators will be hired, new maintainers will be found. Maybe even some of the old, disappointed maintainers will return (it is slowly happening, guess which company they do work for)...
But the underlying problem will remain: community is diverged. Nothing truly changes. There is no official effort to put it all back together.
It is time to show the strength of the community. Let’s build something new together!
For my part, I will continue to contribute to community tools as much as I can. In fact, I already have something in progress — just a few weeks old — and I hope to share it with you very soon.
The future of Ruby’s ecosystem should remain in the hands of the community. Let’s make sure it does.