Split View: 오픈소스 거버넌스가 무너질 때 — 루비 센트럴 사태와 세 개의 축

When Open Source Governance Breaks Down — The Ruby Central Dispute and Three Axes of Control

• Introduction — A Dispute That Ten Months Have Not Settled
• The Ruby Central Affair — A Verifiable Timeline
• What Both Sides Claim — Fact Versus Characterization
• The Shutdown of Artichoke Ruby — Same Period, Different Reasons
• Three Axes — Trademark, Package Infrastructure, and Funding
• The Same Pattern, Recurring
• What Engineers Should Actually Check
• Conclusion — What Can Be Forked and What Cannot
• References

Introduction — A Dispute That Ten Months Have Not Settled

On July 30, 2026, André Arko, the creator of Bundler, published Ruby Central's Destructive Legacy. It reached Hacker News the next day, drawing 43 points and 23 comments.

When Yukihiro Matsumoto (Matz) and the Ruby core team took over management of the RubyGems and Bundler repositories in October 2025, several outlets reported that the dispute had ended. That reporting was only half right. Control of the code was settled, but the dispute itself was not. By Arko's account, Ruby Central's lawyer reported him to the FBI in March 2026, and a settlement proposal he put forward in April went without a substantive response for more than 30 days.

This post is not an attempt to rule on who is right. Both sides have published primary statements, and there are clear points where the facts themselves diverge. Instead, the aim here is to read the structure of the episode, because the same shape of crisis keeps recurring — in core-js, in event-stream, in xz-utils, in Nix, in Redis and Terraform. The reason is that three axes of control end up scattered across different parties.

The Ruby Central Affair — A Verifiable Timeline

Let us start with the facts both sides largely agree on. Sources are Ruby Central's September 25, 2025 statement, its own post-incident report from late March 2026, and Arko's October 9, 2025 rebuttal.

Some background first. Ruby Central is the nonprofit that runs RubyConf and RailsConf and operates the rubygems.org infrastructure; in 2021 it absorbed Ruby Together, which had funded Bundler and RubyGems development. Heading into 2025, Sidekiq's annual sponsorship (reported at roughly $250,000) had lapsed, and the organization had grown financially dependent on Shopify.

• June 3, 2025 — Arko resigns from his advisory role at Ruby Central. The intent was to continue advising on the open-source side without representing the organization.
• August 18, 2025 — Samuel Giddins, whom Ruby Central had hired full-time as its security lead, resigns with two weeks' notice.
• August 25–26, 2025 — Arko publishes the Ruby version manager rv and the Spinel organization. Ruby Central's own report explicitly names this moment the triggering incident.
• September 9–10, 2025 — GitHub's RubyGems enterprise account is renamed "Ruby Central," and admin access is removed for Arko (indirect), Giddins (segiddins), and Martin Emde (martinemde).
• September 15, 2025 — The move is publicly described as a "mistake," and some access is briefly restored. That same week, a large-scale phishing supply-chain attack targeting the npm ecosystem occurs; Ruby Central later cites it as context for its security rationale.
• September 18, 2025 — The three people above, plus Ellen Dash (duckinator), are removed entirely from the GitHub organization. The same day, the board formally votes to revoke production access and commit privileges.
• September 18–19, 2025 — Six people resign in protest: Arko, David Rodríguez, Ellen Dash, Josef Šimánek, Martin Emde, and Samuel Giddins.
• September 30, 2025 — Arko discovers that he still has AWS root access to rubygems.org production and emails Ruby Central to report it.
• October 5, 2025 — Martin Emde announces gem.coop, a cooperatively governed gem host modeled on Homebrew's governance, initially operating as a live mirror of rubygems.org.
• October 17, 2025 — A ruby-lang.org announcement confirms the split: Matz and the Ruby core team take over management of the RubyGems and Bundler repositories, while Ruby Central continues to operate the rubygems.org infrastructure.
• Late March 2026 — Ruby Central publishes a post-incident report written by Richard Schneeman.
• April 19, 2026 — Ruby Central's executive director is removed, and the organization, citing a financial crisis, cancels its PR agency contract and CFO position, lets go of outside contractors, and converts its board into an unpaid working board.
• July 30, 2026 — Arko's latest post appears.

That covers what is confirmed, with dates attached.

What Both Sides Claim — Fact Versus Characterization

Ruby Central's account runs roughly as follows: with two people (Arko and Giddins) already having left the organization, retaining their admin access to production infrastructure was hard to accept given a growing supply-chain attack surface, and the goal was to move to an access model consistent with least privilege under the board's fiduciary duty. The failures its own report admits cluster on execution — there was no documented offboarding process or checklist, the fact and reasoning behind the access changes were not properly communicated to the people affected, and decision-makers understood the link between GitHub permissions and production server access to differing degrees. The report closes on a note of "this was a mistake we all share." That said, on the September access removal specifically — which outside observers framed as simple error — Ruby Central's report reframes it once more: the real problem was timing and internal communication.

The account from the maintainers who left differs. Arko frames this as a hostile takeover and sees it as action targeted specifically at him. His evidence is that Ruby Central's own report names the rv and Spinel launch as the triggering incident. He writes that he discovered and responsibly reported the leftover AWS root access, only to be threatened with legal action over a "hacking" allegation, and that three separate audits confirmed no harm occurred. What he is asking for: withdrawal of the legal threat, a public confirmation that no harm occurred, reimbursement of his legal costs, and an apology for public accusations made without evidence.

There are distinctions worth drawing honestly here.

Where the two sides substantially agree. Ruby Central's own September 25 statement said there was no indication that rubygems.org data had been copied or retained without authorization. This lines up with the direction of Arko's own audit claims.

What exists only in one statement. The FBI report, and the content and progress of settlement negotiations, are entirely Arko's account. I could not find public material from Ruby Central confirming or denying them.

Unproven context. The narrative that Shopify used its funding as leverage to demand Arko's removal recurs across multiple secondary reports and posts from community figures, but I could not find a record of Ruby Central or Shopify officially confirming or denying it. Ruby Central's public documents cite the board's fiduciary duty and supply-chain security as their basis and do not name any specific sponsor. This part should be read as a claim.

Where interpretations diverge. It is what rights Ruby Central actually secured over Bundler and RubyGems through the 2021 absorption of Ruby Together. Ruby Central's account presumes stewardship; the other side holds that those assets were never Ruby Together's to begin with, so nothing was transferred. This is not a matter of sentiment but a matter of legal ownership, and it is what the next section of this post takes up.

The Shutdown of Artichoke Ruby — Same Period, Different Reasons

Something frequently mentioned alongside this affair is the shutdown of Artichoke Ruby, a Ruby implementation written in Rust that Ryan Lopopolo first unveiled at RubyConf in 2019.

Here is what checking turned up, stated plainly. The shutdown post is Winding Down Artichoke Ruby, published February 15, 2026; the repository itself was archived earlier, on November 3, 2025. And this post contains no mention whatsoever of Ruby Central or the RubyGems dispute. Every reason the author gives is personal and internal to the project — priorities shifted toward work and family with age, his current job (OpenAI) is engaging enough to hold his focus, the opportunity cost of maintaining a language runtime is large, the burden of continually tracking MRI Ruby compatibility is endless, and there is no user base large enough to justify that burden.

Hacker News exposure was minimal too. The one submission I found, from July 25, 2026, had 5 points and zero comments. The two events merely overlap in timing; there is no causal link between them. The reason to spell this out is that events adjacent to a governance-crisis narrative commonly get woven together after the fact.

Still, there is one passage in the Artichoke shutdown post that connects to this post's theme: what keeps maintenance going is not funding alone but a user base and personal motivation. This comes back later.

Three Axes — Trademark, Package Infrastructure, and Funding

The asset that actually confers power in an open-source project is not the code. Code can be forked at any time the license permits. There are three things a fork does not replicate.

1. Trademark. Who legally owns the name. This is what determines whether a fork can use the original name.
2. Package registry. Who operates the infrastructure where distribution actually happens. Even after you fork the repository, what a user pulls down with gem install or npm install still comes from the original registry.
3. Funding. Who actually pays the maintainers.

When these three sit with a single party, that party's character becomes the project's character; when they are scattered, coordination costs appear. A crisis happens when, in that scattered state, one of the three tries to use another as leverage.

Looking at Ruby's row, the problem is right there. Trademark, registry, and repository management span three different parties, and one of them — the Bundler trademark — sits with an individual. The contrast with Python's row is stark. The PSF holds both the trademark and PyPI together, so there is at least an answer to the question of who gets to decide.

Let me attach data on the third axis, funding, too. Tidelift's 2024 maintainer survey, based on 437 respondents, found that 60 percent are unpaid, that roughly 60 percent have quit or seriously considered quitting a project they maintain, and that 44 percent cited burnout as the reason. The same survey also found that paid maintainers spend more time on security and fix vulnerabilities faster. On the other side of the ledger, GitHub Sponsors announced that as of July 21, 2026 it had passed $100 million in cumulative payouts, supporting more than 70,000 maintainers and organizations. Set the two numbers side by side and the situation becomes visible: funding is growing, but distribution still concentrates on a handful of projects, and for most maintainers the funding axis is effectively nonexistent.

The Same Pattern, Recurring

Looking back at past cases through the lens of the three axes, they sort themselves into categories.

Absence of the funding axis. core-js is the textbook case. On February 14, 2023, Denis Pushkarev, effectively its sole maintainer, posted "So, what's next?" arguing that free open source is fundamentally broken. The gist was that he was absorbing tens of millions of downloads a week while sponsorship ran a few hundred dollars a month (specific figures vary by source and should be treated with caution), and he said he was considering going paid. In the end, the post going viral drove a surge in sponsorship, and core-js is still maintained independently by him today. When the funding axis is absent, it does not necessarily explode — it can simply and quietly erode.

Capture of the maintainer axis. event-stream (2018) and xz-utils (2024) share the same shape. In event-stream, original author Dominic Tarr, having stepped back from maintenance, handed commit and npm publish access to a volunteer account, and that account added a dependency called flatmap-stream that planted malicious code targeting the Copay bitcoin wallet. In xz-utils, there was two and a half years of social engineering — multiple fake identities pressured burned-out original maintainer Lasse Collin on the mailing list over slow releases, and the co-maintainer who was let in that way planted a backdoor targeting sshd in March 2024. There is no telling how far it would have gone had Microsoft's Andres Freund not caught it through the incidental observation of delayed SSH logins. Both cases connect to the previous one in that the absence of the funding axis is what created the vulnerability on the maintainer axis.

A legitimacy crisis on the governance axis. Nix belongs here. In April 2024, an open letter signed by more than 100 people called for founder Eelco Dolstra's resignation. The issues raised were that he had undermined community moderation procedures, a conflict of interest with the company he worked for, and a decision to accept defense contractor Anduril as a NixCon sponsor. Dolstra stepped down from the NixOS Foundation board. Nothing was wrong with the code; what collapsed was the consensus over who has the authority to decide what.

Exercise of the ownership axis. Redis, Terraform, and Elasticsearch are all cases where the copyright holder changed the license, and all led to major forks. Redis moved from BSD to a dual RSAL/SSPL license in March 2024, and the Linux Foundation forked Valkey. HashiCorp switched Terraform to BUSL in August 2023, and within three weeks the OpenTofu fork was organized, joining the Linux Foundation in September. Elastic moved to SSPL in 2021, and AWS forked OpenSearch.

What is interesting is that all three walked a good distance back. Elastic added AGPLv3 in August 2024, and Redis added AGPLv3 with Redis 8.0 in May 2025. In both cases, the decision came after the fork had already taken root. On the Terraform side, HashiCorp sent OpenTofu a cease-and-desist in April 2024 alleging code duplication, but OpenTofu rebutted it in detail, showing that the code in question descended from a pre-BUSL MPL-licensed ancestor, and it never went to litigation. HashiCorp was acquired by IBM in February 2025, and the matter ended there.

One observation follows from this. A license change can be reversed, but trust and people do not come back. Valkey, OpenSearch, and OpenTofu all remain alive today even after the originals reversed their licenses.

What Engineers Should Actually Check

Here is where this analysis connects to practice.

Count the maintainers when you look at a dependency. Download counts and GitHub stars are not indicators of risk. What core-js, event-stream, and xz-utils have in common is that downloads were high, not that they were low. The real metric is the number of people who have actually used commit access in the last 12 months, and if that number is one, it is a dependency that snaps the moment that one person burns out or is socially engineered.

Think of the registry and the repository as separate. A repository can be forked while the distribution path stays the same, and conversely the repository can stay the same while the distribution path changes. If your organization runs an internal proxy or mirror, it is worth confirming whether there is really only one upstream registry. As alternative hosts like gem.coop emerge, this distinction starts to carry real weight.

Relicensing risk can be read off the ownership structure. If a single company concentrates copyright and gathers rights through contributor license agreements, relicensing is an option available at any time. Conversely, when copyright is spread across many contributors, a change becomes practically impossible. Redis, Elastic, and HashiCorp were all the former.

Spend money on your core dependencies. What the Tidelift survey results say is not a sentimental story but risk management. Paid maintainers fix vulnerabilities faster. Line up what your organization spends on cloud costs every year against what it pays toward the core dependencies that code runs on, and the ratio is usually absurd.

Conclusion — What Can Be Forked and What Cannot

To summarize:

• The Ruby Central affair started with the September 2025 access revocation; the code layer was settled once repository management passed to the Ruby core team in October 2025, but as of July 2026 the dispute between the parties remains unresolved.
• Both sides have published primary statements, and Ruby Central has itself acknowledged some execution failures. The narrative of Shopify's involvement is repeated across coverage but remains a claim without confirmation from either party.
• The Artichoke Ruby shutdown in the same period is unrelated to this affair. The reasons given in its shutdown post are entirely personal and internal to the project.
• The structure behind recurring crises is that the three axes — trademark, package infrastructure, and funding — end up scattered across different parties.
• A license can be reversed, but forks and people do not come back.

In open source, code can always be forked. What cannot be forked are the name, the distribution path, and the people. If the word governance sounds abstract, writing down who holds each of those three things is concrete enough. If you cannot fill in that table for a project your own organization depends on, that means the crisis has not arrived yet — not that there is no risk.

References

• André Arko — Ruby Central's Destructive Legacy (2026-07-30)
• André Arko — The RubyGems "security incident" (2025-10-09)
• Ruby Central — Strengthening the Stewardship of RubyGems and Bundler (2025-09-25)
• Ruby Central — RubyGems Fracture Incident Report (2026-03)
• ruby-lang.org — RubyGems repository transition announcement (2025-10-17)
• gem.coop — a cooperatively governed gem host
• Ryan Lopopolo — Winding Down Artichoke Ruby (2026-02-15)
• core-js — So, what's next? (2023-02, Hacker News thread)
• Snyk — A post-mortem of the malicious event-stream backdoor
• Securelist — Social engineering analysis of the xz backdoor
• LWN — Nix governance open letter and Dolstra's resignation (2024-04)
• OpenTofu — Our response to HashiCorp's cease-and-desist (2024-04)
• Redis — Announcing AGPLv3 (2025-05)