The organization that keeps Ruby’s community infrastructure running — its conferences, its package registry, its developer relations — just lost most of its board. And the circumstances surrounding those departures have exposed long-simmering tensions about how open-source institutions should be governed, who gets a say, and what happens when trust erodes between a community and the nonprofit that serves it.
Ruby Central, the 501(c)(4) nonprofit that operates RubyGems.org, organizes RubyConf and RailsConf, and manages the Google Summer of Code program for Ruby, published a message from its board in late June 2025 acknowledging that four of its seven board members had resigned. The departures included high-profile figures in the Ruby world: Jonan Scheffler, Courteney Ervin, Valerie Woolard, and Coraline Ada Ehmke. The remaining board — Adarsh Pandit (executive director), Samuel Giddins, and Allison McMillan — said they were working to stabilize operations and recruit new directors.
The statement was measured, careful, institutional. It acknowledged the departures without detailing the disputes behind them. But in the Ruby community, the reaction has been anything but measured.
Coraline Ada Ehmke, widely known as the creator of the Contributor Covenant code of conduct adopted by thousands of open-source projects, was among the most vocal departing board members. In posts on social media and her personal channels, Ehmke described a pattern of governance failures she said had driven her and others away. She pointed to a lack of transparency around financial decisions, an executive director who she alleged operated with insufficient board oversight, and what she characterized as a culture of conflict avoidance that prevented the board from addressing problems directly.
These aren’t trivial allegations. Ruby Central controls RubyGems.org, the central package repository that virtually every Ruby and Rails application depends on for dependency management. It’s critical infrastructure — not in the abstract sense, but in the very concrete sense that a failure or compromise of RubyGems.org would ripple across millions of production applications worldwide. The organization also runs the two largest Ruby conferences in North America, events that serve as the primary gathering points for the community and generate significant revenue.
The board’s public message emphasized continuity. “Ruby Central’s operations continue without interruption,” it read. RubyGems.org is running. Conference planning proceeds. The Google Summer of Code program is active. The message framed the departures as an opportunity to “reflect on our governance practices and strengthen our organization for the future.”
But four out of seven directors walking away isn’t a routine board transition. It’s a crisis.
To understand why this matters beyond the Ruby community, consider the structural problem it illustrates. Open-source nonprofits like Ruby Central sit at an awkward intersection of volunteer governance, community expectations, and real operational responsibility. They’re often small — Ruby Central has a handful of paid staff — yet they manage infrastructure that large enterprises depend on. Their boards are populated by community members who may have deep technical expertise but limited experience with nonprofit governance. And their funding models, typically a mix of conference revenue, sponsorships, and donations, create dependencies that can distort priorities.
Ruby Central’s situation is not unique. The Python Software Foundation, the Rust Foundation, and the Node.js Foundation (now part of the OpenJS Foundation) have all faced governance controversies of varying intensity. What makes Ruby Central’s episode instructive is the specificity of the complaints and the stature of those making them.
Ehmke’s criticisms centered on what she described as an executive director who had consolidated decision-making authority beyond what the board had formally delegated. She alleged that financial information was not shared with board members in a timely or complete manner, that strategic decisions were made without adequate board input, and that efforts to raise these concerns internally were deflected or ignored. She said the culture of the board made it difficult to hold leadership accountable — that dissent was treated as disruption rather than governance.
Adarsh Pandit, who serves as both executive director and a board member, has not publicly responded to these specific allegations in detail. The board’s official statement did not address them directly, instead offering general commitments to improved governance and transparency. This dual role — executive director sitting on the board that is supposed to oversee him — is itself a governance structure that many nonprofit experts view with skepticism, though it’s common in smaller organizations.
The Ruby community’s response has been fractured. Some developers expressed alarm and called for structural reforms, including external audits, term limits, and clearer separation between operational leadership and board oversight. Others argued that the departing board members should have worked harder to resolve issues internally before going public. A smaller but vocal contingent questioned whether the controversy was being amplified beyond its actual significance.
On X (formerly Twitter) and in Ruby community forums, the discussion has been heated. Several prominent Ruby developers called for Ruby Central to publish detailed financial statements and governance documents. Others pointed out that the organization had been relatively opaque about its operations for years, with limited public reporting beyond what’s required for its tax-exempt status.
The timing adds another layer of complexity. RailsConf and RubyConf are both major revenue events, and sponsorship relationships depend on organizational stability. Enterprise sponsors — companies like Shopify, GitHub, and Heroku that have significant Ruby codebases — need confidence that their sponsorship dollars are being managed responsibly. A governance crisis, even one that doesn’t affect day-to-day operations, can erode that confidence over time.
There’s also the question of RubyGems.org security. Package registries have become prime targets for supply-chain attacks. In recent years, incidents affecting npm, PyPI, and other registries have demonstrated the real-world consequences of compromised packages. RubyGems.org has invested in security improvements, including multi-factor authentication requirements for popular gem maintainers, but the security posture of any infrastructure depends partly on organizational stability and adequate funding. A nonprofit in governance turmoil is not well-positioned to respond quickly to emerging threats.
Samuel Giddins, one of the three remaining board members and a longtime contributor to RubyGems and Bundler, has been relatively quiet publicly about the internal dynamics. Allison McMillan, another remaining member, similarly has not made extensive public comments beyond the official board statement. This silence may reflect legal caution, a desire to avoid escalation, or simply the reality that the remaining board members are overwhelmed with keeping the organization functional while recruiting replacements.
The broader Ruby community has been in a complicated place for several years. Ruby’s popularity peaked in the early 2010s, driven largely by Ruby on Rails, and while the language remains widely used — particularly in web development — it has lost mindshare to Python, TypeScript, and Go. The release of Ruby 3.x brought significant performance improvements and new concurrency features, and Rails continues to evolve under David Heinemeier Hansson’s leadership. But the community is smaller and arguably more insular than it was a decade ago, which makes governance failures more consequential. There are fewer people to absorb the work, fewer alternative institutions to pick up the slack.
This isn’t just a Ruby problem. It’s an open-source governance problem. The pattern repeats across language communities and projects: a small nonprofit, often founded by enthusiasts, gradually takes on critical infrastructure responsibilities. Governance structures that were adequate when the organization managed a single annual conference become strained when the organization is responsible for a package registry serving millions of users. Board members burn out. Conflicts arise between people who see the organization as a community institution and those who see it as an operational entity that needs professional management. And when things go wrong, the community discovers that the guardrails were thinner than anyone assumed.
The Linux Foundation and Apache Software Foundation have addressed some of these issues through scale — larger staffs, more formalized governance, corporate membership structures that provide stable funding. But those models come with their own tradeoffs, including concerns about corporate capture and loss of community voice. Ruby Central has historically been closer to the grassroots end of the spectrum, which gives it authenticity but also vulnerability.
So what happens next? The remaining board has committed to recruiting new directors and reviewing governance practices. They’ve indicated they’ll seek input from the community, though the specifics of that process remain undefined. The immediate operational risk appears low — RubyGems.org has a dedicated team, and conference planning has its own momentum. But the medium-term risk is real. If the organization can’t rebuild trust, it will struggle to attract board members, sponsors, and volunteers. And if it can’t attract those resources, the infrastructure that millions of developers depend on becomes more fragile, not less.
One potential path forward is the model adopted by some other language communities: establishing an independent technical advisory board for infrastructure operations, separate from the organizational board that handles finances and strategy. This would create a clearer chain of accountability for RubyGems.org specifically, which is arguably Ruby Central’s most consequential responsibility. Another option is moving RubyGems.org under a larger foundation umbrella, though that would represent a significant shift in how the Ruby community governs its own tools.
Neither option is simple. Both require the kind of sustained organizational energy that is hardest to muster during a crisis.
The Ruby Central situation is a reminder that open-source infrastructure doesn’t maintain itself. Behind every package registry, every CI system, every language server protocol implementation, there are people — often volunteers, often underpaid, often operating without the governance structures that would be considered baseline in any comparable private-sector organization. When those people leave, or when the institutions they’ve built falter, the consequences extend far beyond any single community.
For now, Ruby Central continues to operate. The gems get published. The conferences get planned. But the foundation underneath has cracked, and patching it will require more than a carefully worded board statement. It will require the kind of honest institutional reckoning that open-source communities have historically been reluctant to undertake. Whether Ruby Central is up to that task remains an open question — one that matters not just to Rubyists, but to anyone who depends on open-source software, which is to say, everyone.
WebProNews is an iEntry Publication