- Final Word: Yukihiro “Matz” Matsumoto Ends Dispute in Ruby Community
- Reckoning and New Beginning
- Hostile Takeover
- Suspicion, Mistrust, Escalation
- Between Control and Trust
- Lessons from the Crisis
After a weeks-long dispute between Ruby Central and parts of the community over control of the RubyGems package repository had kept the Ruby community on edge, a de-escalation is now apparent.
On October 17, 2025, Ruby creator Yukihiro “Matz” Matsumoto personally published a statement on the official Ruby website: the R…
- Final Word: Yukihiro “Matz” Matsumoto Ends Dispute in Ruby Community
- Reckoning and New Beginning
- Hostile Takeover
- Suspicion, Mistrust, Escalation
- Between Control and Trust
- Lessons from the Crisis
After a weeks-long dispute between Ruby Central and parts of the community over control of the RubyGems package repository had kept the Ruby community on edge, a de-escalation is now apparent.
On October 17, 2025, Ruby creator Yukihiro “Matz” Matsumoto personally published a statement on the official Ruby website: the Ruby Core Team would henceforth take over responsibility for RubyGems and Bundler. The projects would return under the umbrella of the language itself, while Ruby Central, as a non-profit organization, would ensure operational management of infrastructure and RubyGems.org.
This decision brought calm to the community. Many saw it as a compromise: control and stability with Ruby Central, open development under the umbrella of the Core Team. Ruby Central welcomed the move and spoke of a “shared commitment to the future of the Ruby ecosystem.”
Reckoning and New Beginning
After the heated weeks, Ruby Central has made efforts to regain lost trust. In the Source of Truth series, the organization published weekly reports and Q&As in which it answered community questions. The operators admitted mistakes: communication had been too slow, the tone too formal. Now they want to “create visibility and consistency.”
Ruby Central repeatedly emphasized that sponsors—especially Shopify—had no operational influence on decisions. At the same time, new contracts for maintainers and operators were introduced to clearly regulate responsibilities.
While Ruby Central worked on its new governance, former maintainers founded the project gem.coop, an alternative mirror and later independent gem server. This created a decentralized approach in the Ruby ecosystem for the first time: multiple locations, one common goal—keeping software secure and open. However, it currently looks very much like rubygems.org will remain the central point of contact for packages.
Hostile Takeover
The dispute arose when Ruby Central revoked the access rights of the long-time maintainers of the central projects RubyGems and Bundler in mid-September 2025. This marked the beginning of one of the biggest conflicts in the history of the Ruby community. The organization justified its move with security concerns and the need to protect the ecosystem’s supply chain. But for many developers, this sounded like a pretext—a power shift behind the scenes, not about security.
For years, RubyGems.org has been a central component of the Ruby universe—it hosts over 175,000 freely available libraries, without which many applications would not run. Behind the service was a small, largely voluntary group of maintainers. They kept servers running, wrote code, and took care of security. Ruby Central financed infrastructure and hosting, but operational control had previously rested with volunteers.
That changed abruptly in September when Ruby Central took control of the GitHub repository and revoked all rights from the admins. Well-known names in the community, such as Ellen Marie Dash, Samuel Giddins, and André Arko, disappeared from the organizations overnight. The explanation: they wanted to create “formal responsibilities” and “secure critical key positions.” But according to many, it was a disempowerment.
The outcry was not long in coming. Developer Joel Drapper spoke of a “hostile takeover” and revealed internal procedures that cast doubt on Ruby Central’s communication. Arko himself, the face and voice of Bundler for years, reacted indignately.
Suspicion, Mistrust, Escalation
The situation escalated when new details came to light. According to internal emails, Ruby Central had considered revoking access weeks earlier—out of concern that individual maintainers might have too much control. Arko was the focus.
According to Ruby Central’s report from October 10, 2025, Arko still had root access to RubyGems.org’s AWS systems even after his dismissal. The account was used in the early morning hours. Although there were no indications of data manipulation, the incident revealed security processes “that urgently needed improvement.”
Arko denied the accusations. He stated he acted because he feared the infrastructure could be compromised without his access credentials. According to his account, he eventually informed Ruby Central and orderly returned access. The organization, in turn, saw this as a clear violation of responsibilities.
In retrospect, it became clear that both sides had made mistakes. Ruby Central kept a sensitive security and governance issue internal for too long; Arko acted without a mandate, but according to his statement, with the conviction that he was preventing damage.
Between Control and Trust
At its core, the issue was about who bears responsibility for open source. For years, Ruby Central had borne server costs, managed grant money, and acquired sponsor funds. But the development itself remained a community project—legally, but also ideologically. When Ruby Central took control in September, two self-perceptions clashed: operational security versus community ownership.
The debate intensified when it became known that Arko had previously registered the name Bundler as a trademark. He wanted to prevent Ruby Central from using the name for its forks. From a legal perspective, this was legal, but from a community perspective, it was a symbolic break. Ruby Central spoke of an “unacceptable appropriation.”
For regular Ruby developers, all of this resulted in a situation for several weeks where no one could be sure how things would proceed. It often felt like a dramatic telenovela, but with the bitter aftertaste that all Ruby developers depend on a functioning RubyGems infrastructure.
A special characteristic of the Ruby community is also the involvement of very different cultural circles. A significant portion of the community comes from Asia and solves problems very differently than North American developers. Europe has been and continues to be underrepresented in the Ruby Core Team.
A special feature in this universe remains the Canadian company Shopify, which has relied entirely on Ruby on Rails from the beginning. Even if the company itself does not exert direct influence, the sheer number of Ruby developers there is an important factor of power. Furthermore, Shopify is currently the largest sponsor. Shopify needs Ruby, and Ruby needs Shopify.
Lessons from the Crisis
The RubyGems affair showed how fragile open-source projects are when trust and transparency are lacking. At the same time, it proved how adaptable a community can be. Peter Zhu, Ruby Core member and himself formerly at Shopify, put it aptly: Open source is “the most fragile and at the same time most resilient ecosystem.” This has been confirmed here.
Today, a few weeks after the storm, Ruby Central’s communication frequency is higher, the documentation is better, and the Core Team has taken over the codebase. The maintainers who once left are working on new projects. And the community is discussing funding, responsibility, and governance more openly.
The crisis has left its mark—but also created structures that can cushion future conflicts. Perhaps this rupture was painful but necessary: a wake-up call that open-source lives not only from code but from the trust between those who write, finance, and protect it. (wpl)
Don’t miss any news – follow us on Facebook, LinkedIn or Mastodon.
This article was originally published in German. It was translated with technical assistance and editorially reviewed before publication.