I’ve been thinking about what happens when open source organizations hit their breaking point… when funding dries up, relationships fracture, and everyone’s scrambling to make sense of what went wrong.
It turns out, the patterns look familiar.
The Organic Growth Problem
Open source projects rarely start with governance documents. They start with people solving problems. Infrastructure gets donated. Roles emerge organically. Someone’s AWS account becomes the infrastructure. Someone’s time becomes the bottleneck. Someone’s relationships become the organization.
This works remarkably well… right up until it doesn’t.
The moment you try to formalize what’s been organic, you discover all the implicit assumptions. Who actually owns this? Who’s been paying for it? What happens when the donor stops donating? When organizations merge, do they write divorce papers just in case?
Usually not. Because that feels pessimistic. And besides, everyone’s too busy keeping things running to plan for things falling apart.
This whole situation has left me thinking about Oh My Zsh. We’ve established some levels of governance, but we have such a simpler situation today than this one. It kind of makes me glad that I get to keep things lean. But we’ve also been participating in open source security trainings, and they’re highlighting a lot of policies we need to get in place. Things that I don’t think most of us ever should worry about until we need to worry about them in our projects.
Much in the same way that I don’t think a brand new startup should be worrying about their employee handbook before their first few hires. Just enough works enough until it just doesn’t. Most of us haven’t had to cross that divide ourselves.
When Multiple Pressures Converge
Here’s what makes these situations messy: everything happens at once.
Funding pressures don’t arrive neatly sequenced. They pile up. Employment situations change. Personal relationships deteriorate. Governance questions that seemed theoretical become urgent. And everyone’s making decisions with incomplete information, under time pressure, believing they’re doing the right thing.
No one’s operating with the full picture. Not the board. Not the staff. Not the donors. Not the community. Everyone’s got fragments and they’re trying to construct meaning from partial data.
Okay, Quick Side Quest.
At RailsConf 2024, Ruby Central announced the end of the conference, then committed to one final edition in 2025. They reached out about sponsorship from Planet Argon.
I had questions. They were committing significant resources to one more event… at a to-be-determined location on a to-be-determined date. If they were focusing on RubyConf going forward, this felt like an opportunity to refocus sooner rather than later.
I explained we were exploring ways to contribute more in the next fiscal year, but this particular decision didn’t resonate from a sponsor perspective. As a Rails developer, I appreciated the gesture. As a potential contributor, I saw resources going toward something undefined when regional conferences were already filling the void.
They explained they hoped the event would help recover losses through sponsorships and ticket sales. It was a bet that doesn’t appear to have paid off.
(I was honored to be invited to speak at the very last RailsConf and glad it happened!)
Here’s what’s interesting: I’m defending Ruby Central’s right to continue existing despite my questions about that decision. Maybe that reveals something about residual trust. About believing in a mission even when you question specific tactical choices.
Let’s be honest about sponsorships, too. They’re marketing. Logo placement has value… access to an audience, visibility on event pages, search engine rankings. When people call for sponsors to demand their logos be removed, they’re obviously not accounting for the downsides of not getting what you paid for. But I guess if you think Ruby Central is Goliath and irredeemable, then sure, I understand how your logic would arrive at that.
I just don’t think it’s that simple.
Anyway, that’s my commit to this story. Let’s get back to the main branch.
The Rewrite Temptation
When code gets messy, there’s always someone who wants to start over. Throw it all out. Rebuild from scratch. This time we’ll do it right.
I’ve spent years arguing against the big rewrite. I’m (almost always) firmly Team Refactor.
Why? Because rewrites discard something precious: the accumulated wisdom embedded in the system. Every line of code represents decisions made, problems solved, edge cases discovered. Someone spent time… their creativity, their care, their effort… building solutions that work.
Organizations are the same. Years of relationship-building. Trust earned through reliability. Lessons learned from mistakes. Systems developed through trial and error. That institutional knowledge has real value, even when the current state feels messy.
The rewrite impulse assumes the problem is the thing itself. But usually, the problem is that we’ve outgrown the original structure without evolving it. The answer isn’t demolition. It’s thoughtful renovation.
Organizations face the same temptation. When things get complicated, there’s a seductive simplicity to “defund and rebuild.” Start fresh. New governance. New people. This time with clear rules.
But that’s disconnected from how organizations actually improve. You don’t defund your way to better governance. You iterate. You refactor. You acknowledge the human effort that built what exists, even as you work to make it better.
The Stories We Tell
We love a good David versus Goliath story. But sometimes it’s just a bunch of Davids looking for a Goliath. Sometimes everyone thinks they’re the underdog.
I’ve been observing this whole situation unfold, and I’ve noticed something: some accounts leave certain details out. Others fill them in. Some people fact-check and never include those details in their telling. It’s a reminder of how often humans… consciously or unconsciously… leave things out that would help inform the rest of us.
I voiced this at the time during the fact-checking: there are employment policies and laws that mean some things can’t be disclosed. We’ll likely never be able to get the full story. And whether we like it or not… that’s just the world we live in when we’re dealing with organizations and people who are liable for what they disclose to the public.
Here’s what I think actually happened: funding got uncertain. Decisions got made under pressure. Different people reached different conclusions about the right path forward. Some of those decisions look questionable in retrospect. Some may have been mistakes. None of it required villainy.
As we seem to be learning, I’m not even convinced each of the actors understood the full context. When you’re dealing with funding pressures, employment changes, infrastructure ownership questions, and relationship breakdowns all at once… it’s entirely possible that no single person had the complete picture.
It’s healthy to ask ourselves, “what would I do in that situation?” But we don’t actually know what the situation was. And we probably never will.
On New Organizations
Someone might ask: if I’m against the rewrite, why do I support the Rails Foundation? Wasn’t it created in reaction to Ruby Central not inviting DHH to keynote one year?
That might have been the instigator. The catalyst that prompted DHH to step back and look at the bigger picture again.
But here’s the thing: the Rails Foundation focuses specifically on promoting and adopting Ruby on Rails itself… educational content, revamping public-facing resources, supporting Rails events, highlighting work within the community. That’s a different mission than Ruby Central’s stewardship of RubyGems, Bundler, and the broader Ruby ecosystem.
Planet Argon is a contributing member because that clarity of purpose resonates. I can see where our sponsorship dollars are going.
New organizations can emerge to fill genuine gaps. That’s not a rewrite… it’s recognizing that one organization can’t do everything, and sometimes focused missions serve the community better than trying to be all things to all people.
The question isn’t whether new organizations should exist. It’s whether we burn down what’s working to build them.
What Most Developers Actually Care About
Here’s something important to remember: the overwhelming majority of Ruby developers hardly know what to make of this situation. They’re focused on getting their work done. They’re going to stick with what feels familiar to them… until there’s a pain point that directly impacts them.
And here’s the thing: there are plenty of problems with dependency management. But the source of where we install our gems? That’s far from top of mind. It’s updating the dependencies themselves that we’re all struggling with. That’s where the opportunity is to get people to change how they think about dependency management.
Infrastructure drama doesn’t drive adoption. Solving real problems does.
Why Second Acts Matter
At Planet Argon, we talk a lot about how good software deserves a second act. Not because change is bad, but because smart, sustainable change respects what came before while building toward what’s next.
This isn’t nostalgia. It’s not clinging to the past. It’s recognizing that the systems we have… code or organizations… were built with real human effort. People put their creativity and care into making them work. That investment deserves respect, even when the result needs improvement.
Ruby Central has made decisions I don’t understand. But their track record, across their entire history, trends toward doing good. They’ve stewarded critical infrastructure that millions depend on. They’ve run events that brought the community together. They’ve invested in educational content and tooling.
They deserve accountability. They deserve tough questions. They deserve pressure to improve governance, communication, and decision-making.
But they also deserve a second act.
Not because they’ve been perfect. Because they’ve been consistently trying to do good, and that effort… that accumulated institutional knowledge, those relationships, that trust built over years… has value worth preserving and building on.
This isn’t about resisting change. It’s about making change that’s sustainable. That learns from what worked. That fixes what didn’t. That acknowledges complexity instead of pretending it away.
Splinter factions will emerge. New organizations will form with clearer missions. Some of those might be worth supporting too. That’s healthy. That’s how ecosystems evolve.
But I prefer the refactor. I prefer the second act.
Sitting With Uncertainty
Can we resist the clean narrative? Can we sit with not knowing the full story… and acknowledging that nobody involved probably knew it either?
Can we hold space for multiple people with legitimate grievances, reasonable disagreement about direction, financial pressures creating impossible choices, and decisions made with incomplete information by people acting in good faith?
This isn’t moral relativism. It’s recognizing that organizational complexity, like code complexity, doesn’t yield to simple explanations.
Let me be clear: I don’t think Ruby Central handled this well from a public communications perspective. But as a community member, I can accept their apology and move forward. I completely understand if those who had their access revoked don’t feel that way. They have every right not to.
And I can’t help but wonder: sometimes we make public statements, take positions, feel like we’ve burned bridges that can’t ever be repaired. But in the spirit of honoring where we’ve been… is there a path forward that doesn’t splinter so much?
Maybe there is. Maybe there isn’t.
I also understand if some people read this and think, “Robby, you’re a fucking coward.” Maybe sitting with uncertainty feels like fence-sitting. Maybe nuance feels like avoiding taking a stand.
But as just a Rails developer… I’ll applaud the effort and cheer them on to find their path. And hope the paths meet again.
The infrastructure we depend on was built by humans. Maintained by humans. Those humans put real effort… real creativity, real care… into systems that work, even imperfectly.
Maybe the most honest thing we can do is resist the rewrite impulse. For code and for organizations. Focus instead on thoughtful refactoring that respects what was built while making it better.
Give good things their second act.
Complicated things are complicated.
And that’s okay…
But what the fuck do I know.
