The Q&A Before the Q&A: Ruby Central's Governance Crisis

UPDATE NOTICE: This article will be updated after Ruby Central’s Q&A session on September 23, 2025, with analysis of their responses and what questions they dodge.

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. This occurs despite ongoing collaborative work on 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: Legitimate Security or Institutional Capture?

Ruby Central’s partnership with the Alpha-Omega Project represents a significant shift in how open source security is approached. Alpha-Omega, funded by Microsoft, Google, Amazon, and Citi, aims to improve security across critical open source projects.

The funding provided:

• Full-time security-focused positions
• Professional security auditing capabilities
• Resources for sustainable maintenance
• Infrastructure for formal governance processes

This raises fundamental questions: Does professionalizing open source security require removing volunteer maintainers? Can informal community governance coexist with corporate security requirements? The Alpha-Omega model works for some projects—but at what cost to community autonomy?

Different projects will answer these questions differently. Ruby Central’s approach prioritizes institutional security over community continuity.

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 Work That Was Already Happening

Ellen Marie Dash provides crucial context that reframes the entire narrative around governance:

“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.”

This reveals that maintainers weren’t opposed to formal governance—they were actively working on it. Ruby Central’s September 9 actions interrupted collaborative governance work that was designed to address their very concerns.

The RFC #61 shows extensive collaboration: Andre Arko tagged all current maintainers for input, Ellen provided detailed feedback, Mike McQuaid (Homebrew) offered guidance based on their experience, and multiple reviewers engaged constructively. Even Ruby Central’s Marty Haught commented: “I’m committed to find the right governance model that works for us all.”

The RFC demonstrates exactly what Ellen described: transparent, inclusive work to create governance “acceptable to Ruby Central, the maintainers, and the community at large.” Ruby Central’s abrupt action abandoned this collaborative process.

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 abandon the collaborative governance process that was already underway?

   • RFC #61 shows maintainers were actively working on formal governance
   • Marty Haught himself commented on the RFC expressing commitment to collaboration
   • What changed between supporting the RFC process and revoking 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

Ellen’s clarification reveals an even more troubling pattern than initially understood:

1. Collaborative response: Ruby Central’s initial changes prompted maintainers to begin formal governance work
2. Open process: Maintainers worked transparently, keeping Ruby Central informed
3. Inclusive approach: Seeking governance structure acceptable to Ruby Central, maintainers, and community
4. Expressed support: Ruby Central said they favored formal governance but had unspecified concerns
5. Abrupt reversal: Same day Ruby Central revoked all access without stating their concerns
6. Ongoing abandonment: Governance work continues on GitHub despite maintainers lacking integration ability

This wasn’t just poor communication—it was the abandonment of active collaboration in favor of unilateral action.

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.]