The Q&A Aftermath: Ruby Central's Governance Crisis Deepens

UPDATE (September 21, 2025): The Q&A happened. Read the breaking developments: Board Member Confesses, Maintainer Rebuts - A board member breaks ranks to explain, and a maintainer exposes the lies.

ORIGINAL (September 20): Written before the Q&A to predict what would happen.

In three days, Ruby Central holds their Q&A to explain the September 9th governance changes that removed RubyGems maintainers without warning. Behind the corporate speak about “strengthening stewardship” lies a more complex story about conflicting philosophies, communication breakdowns, and the human cost of institutional change.

The maintainers didn’t just lose access on September 9th. They lost trust in the process.

The Timeline: Funding, Philosophy, and Fracture¶

January 14, 2025: Ruby Central secures Alpha-Omega Project funding from Microsoft, Google, Amazon, and Citi for security improvements. Marty Haught’s position becomes permanent. Samuel Giddins continues as Security Engineer in Residence.

August 2025: Community tensions surface. According to Slack discussions, maintainers express concerns about Ruby Central’s direction and leadership relationships.

September 9, 2025: Ruby Central implements abrupt governance changes, removing maintainer access without prior communication.

September 14, 2025: Maintainers respond constructively by creating RFC #61 for formal governance structure.

September 19, 2025: DHH endorses Ruby Central’s approach: “Ruby Central is making the right moves to ensure the Ruby supply chain is beyond reproach both technically and organizationally.”

This timeline reveals competing philosophies about how critical infrastructure should be governed.

Community Perspectives: A Divided Response¶

Ruby community discussions reveal multiple viewpoints on the governance changes:

Mike Perham (Sidekiq author) suggests the changes resulted from maintainer departures related to leadership concerns, though Ruby Central has publicly denied claims about additional external funding.

byroot notes tensions around recent community events, particularly RailsConf, while acknowledging Ruby Central’s corporate structure requires formal access controls.

Kevin Newton defends the security-first approach, arguing that removing access without warning is standard practice when trust relationships change.

Will Clark emphasizes Marty Haught’s 20-year community history, suggesting benefit of the doubt while acknowledging poor execution.

Nate Berkopec (PUMA) frames it as a “do-ocracy” where both code contributors and funding providers have legitimate interests.

The community is genuinely divided between those who see necessary security measures and those who view it as unnecessarily destructive to long-standing relationships.

The Alpha-Omega Project: Supporting Open Source Security¶

Ruby Central’s partnership with the Alpha-Omega Project provides crucial funding for security improvements. Alpha-Omega, funded by Microsoft, Google, Amazon, and Citi, supports security work across critical open source projects with a hands-off approach that respects project autonomy.

The funding enabled:

• Full-time security-focused positions
• Professional security auditing capabilities
• Resources for sustainable maintenance
• Transparent reporting through public updates

As Martin Emde notes, Alpha-Omega “only advocates for genuine security and they understand open source.” They’re “very hands off” and all engagement details are publicly documented.

The question isn’t about Alpha-Omega’s valuable support, but how Ruby Central chose to implement governance changes alongside this security funding.

The Security Paradox: Process vs People¶

The tension between security processes and security expertise is evident in recent events:

July 2025: When malicious gems with credential-stealing behavior were detected, the response came from experienced maintainers like Maciej Mensfeld who understood both the technical and community aspects of the threat.

September 2025: Ruby Central’s governance changes, justified by security audits, removed longtime maintainers including Ellen Marie Dash, who had been handling security vulnerabilities through HackerOne.

The tension: Institutional security processes may conflict with the human expertise that provides actual security. Formal governance can’t replace deep technical knowledge and community trust.

The question isn’t whether security matters—it absolutely does. The question is whether formal corporate governance provides better security than experienced, trusted maintainers.

The Governance Response: Maintainers Try to Fix What Ruby Central Broke¶

Ellen Marie Dash provides crucial context about how maintainers responded to the September 9 actions:

“I never saw any maintainers speak against formal access controls. In fact, the unexpected changes made by Ruby Central prompted a discussion where we decided we needed a formal governance structure. The team explicitly acted in the open, tried to keep Ruby Central in the loop, and solicited feedback from both those directly involved and third parties. Our end goal was to make a governance structure that was acceptable to Ruby Central, the maintainers, and the community at large. The work for this is still ongoing on GitHub, in spite of nobody involved even having the ability to integrate suggested changes: rubygems/rfcs#61.

Despite this still ongoing effort, in a single day: Ruby Central told us they were in favor of us adopting a formal governance structure but had concerns about specific details, never stated what these concerns were, and then revoked our access.”

Ellen’s quote correctly notes that Ruby Central’s actions “prompted” the governance discussion. The RFC #61 was created on September 14—five days after the takeover—as a constructive response to Ruby Central’s unilateral actions.

The RFC shows maintainers immediately trying to address the situation properly: Martin Emde created the proposal, Andre Arko tagged all maintainers for input, Ellen provided feedback, and Mike McQuaid (Homebrew) offered guidance. Even Ruby Central’s Marty Haught commented on September 15: “I’m committed to find the right governance model that works for us all.”

Yet Ruby Central maintained the lockout while claiming to support the very governance process the maintainers initiated in response to being removed. They expressed support but refused to restore access or specify their concerns.

Ecosystem Dynamics: Rails Foundation vs Ruby Central¶

The Ruby ecosystem has evolved into a more complex governance landscape with multiple organizations serving different constituencies:

Rails Foundation focuses specifically on Rails framework development, with corporate sponsors funding Rails-specific initiatives like Rails World.

Ruby Central maintains broader Ruby infrastructure including RubyGems, with responsibilities spanning the entire Ruby ecosystem.

DHH’s endorsement of Ruby Central’s approach—“making the right moves to ensure the Ruby supply chain is beyond reproach”—reflects a perspective that prioritizes institutional stability over community process.

This creates tension: Rails benefits from a stable, professionally managed Ruby infrastructure, while Ruby maintainers value community autonomy and informal governance.

The challenge isn’t that these perspectives are wrong—they’re different philosophies about how open source infrastructure should be governed in 2025.

What Monday’s Q&A Needs to Address¶

Ruby Central has scheduled a community Q&A for September 23 at 1-2pm EST. Board members, Executive Director Shan Cureton, and Director Marty Haught will discuss the governance changes and community concerns.

The community deserves clear answers to these questions:

1. Why maintain the lockout after maintainers created RFC #61?

   • Maintainers responded constructively with formal governance proposal
   • Marty Haught commented expressing commitment to collaboration
   • Why claim support while refusing to restore access?

2. What were the “specific details” you had concerns about?

   • Ellen reports Ruby Central said they supported governance but had unstated concerns
   • The RFC process was designed to address concerns through open discussion
   • Why not engage with the collaborative process instead of abandoning it?

3. How will you ensure community expertise isn’t lost?

   • Ellen Marie Dash handled actual security vulnerabilities through HackerOne
   • What mechanisms exist to retain this institutional knowledge?

4. What’s the governance roadmap for community involvement?

   • How do experienced contributors participate in the new model?
   • What’s the timeline for the promised “community-centered governance”?

5. How much funding is Ruby Central receiving from various sponsors?

   • Transparency about financial dependencies affects community trust
   • Understanding funding sources helps evaluate potential conflicts of interest

These questions deserve thoughtful, specific answers rather than corporate deflection.

The Communication Failure Pattern¶

The sequence of events reveals a troubling pattern:

1. Unilateral action: September 9 removal without warning or discussion
2. Constructive response: Maintainers create RFC #61 on September 14 to address concerns properly
3. Open process: Maintainers work transparently, inviting all stakeholders to participate
4. False support: Ruby Central claims to favor the governance work but maintains the lockout
5. Unspecified concerns: Ruby Central won’t specify what they object to in the RFC
6. Ongoing abandonment: Governance work continues despite maintainers lacking access to implement

Ruby Central created a crisis, then refused to engage with the solution while claiming to support it.

A Community Wrestling with Change¶

The Ruby community’s response reveals the complexity of modern open source governance:

Supporters of institutional approach: Kevin Newton emphasizes security standards, Will Clark points to Marty’s long community history, byroot acknowledges that corporate structures require formal access controls.

Critics of execution: Mike Perham questions the communication approach, Ben Sheldon seeks more transparency, JSwift wants better justification for the abrupt changes.

Concerned observers: Many community members express worry about losing experienced maintainers while acknowledging legitimate security concerns.

Affected maintainers: Andre Arko focuses on new projects like rv, Ellen Marie Dash transitions to other work, community contributors seek clarity on future involvement.

This isn’t a simple good-vs-evil story. It’s a community grappling with how to balance security, sustainability, and community values.

The Broader Pattern: Professionalization vs Community¶

This situation reflects a broader tension in open source: the shift from informal community governance to professional institutional management.

Ruby Central’s changes mirror transformations across the open source ecosystem. The Alpha-Omega Project supports security improvements at many critical projects including Python Software Foundation and OpenJS Foundation.

The question isn’t whether this professionalization is inherently wrong—many projects benefit from institutional support. The question is whether the transition can happen without destroying community relationships and institutional knowledge.

Different projects will answer this differently. Some prioritize institutional stability, others value community autonomy. Ruby Central chose stability; the cost was community trust.

Monday’s Opportunity: What to Watch For¶

The Q&A represents Ruby Central’s chance to rebuild community trust. Watch for:

Specificity over generalities: Concrete details about security concerns rather than vague “supply chain” references.

Accountability for process: Acknowledgment that the communication could have been handled better.

Clear roadmap: Timeline and mechanisms for community involvement in the new governance model.

Transparency about funding: Open discussion of how financial arrangements affect decision-making.

Human recognition: Acknowledgment of the contributions and concerns of departed maintainers.

If Ruby Central provides these elements, they may begin rebuilding trust. If they default to corporate speak and deflection, the community divide will likely deepen.

Questions That Could Drive Meaningful Discussion¶

If you attend Monday’s Q&A, consider asking:

1. “Can you share specific findings from the security audit that led to these changes?”
2. “What’s the timeline for implementing the promised community-centered governance?”
3. “How will you ensure institutional knowledge from experienced maintainers isn’t lost?”
4. “What funding transparency can you provide to help the community understand financial influences?”
5. “What lessons have you learned about communication that will guide future changes?”
6. “How can community contributors meaningfully participate in the new governance model?”

These questions focus on moving forward constructively rather than relitigating past decisions.

The Path Forward: Reconstruction or Reconciliation?¶

The Q&A will likely determine Ruby Central’s relationship with the community going forward.

Ruby Central now has the institutional backing, funding, and formal governance structure they believe critical infrastructure requires. The Alpha-Omega Project funding provides security expertise. Industry leaders like DHH endorse their approach.

But they’ve lost something harder to replace: community trust and the institutional knowledge that comes from long-term maintainer relationships.

The question isn’t whether Ruby Central will survive—they will. The question is whether they can rebuild the human connections that make open source communities more than just infrastructure management.

What Happens After the Q&A¶

I’ll update this article on Monday with analysis of:

• How specific Ruby Central’s answers are
• Whether they acknowledge communication failures
• What concrete steps they outline for community involvement
• How the community responds to their explanations

The Q&A’s success will be measured not by corporate messaging, but by whether it begins rebuilding trust.

The Real Choice¶

The Ruby community faces a fundamental question about open source governance in 2025: Can professional institutional management coexist with community values?

Some will choose to work within Ruby Central’s new model, believing that security and sustainability require institutional structure.

Others will build alternatives, prioritizing community autonomy and informal governance. Andre Arko’s rv project represents one such path.

Both approaches have merit. The tragedy is that this choice had to be made through conflict rather than collaboration.

To the maintainers who built what we depend on: Thank you for years of maintaining critical infrastructure. Your contributions created the foundation we all build upon.

To Ruby Central: Monday’s Q&A is your opportunity to rebuild trust. The community is watching to see whether you choose transparency or deflection.

To the Ruby community: This governance crisis reflects broader challenges facing all open source projects. How we resolve it will influence the future of community-driven development.

Captain Seuros, Building the Liberation Stack

“The strength of open source lies not in its code, but in its community. Lose one, and you’ve lost both.”

POST-Q&A UPDATE SECTION¶

[This section will be updated after the September 23, 2025 Q&A with full analysis of Ruby Central’s responses, community questions, and what questions were avoided.]