You’ve been in this conversation before. Maybe at a maintainer meeting, maybe on a mailing list thread that’s been running since 1998. Someone says: “We need to move to a forum. Real-time chat. Something modern.” And then someone else says: “But mailing lists are inclusive, archival, and everyone knows how to use them.” And then nothing happens. Again.
That’s the Fedora project right now. And it’s been that way for 30 years.
The hardest part of open source isn’t the code. It’s the people who refuse to change the way they talk about the code.
I’ve watched this pattern play out in a dozen communities. The technology for unified communication — threaded forums that mirror mailing lists, real-time chat with searchable archives — has existed for decades. Google Groups did it. Discourse does it. Even GitHub Discussions tried. But Fedora is still stuck, split between a mailing list that feels like a time capsule and a forum that feels like a ghost town.
Most people blame the tools. They say: “If only there was a FOSS platform that did both.” But that’s a convenient lie. The real bottleneck isn’t technology. It’s governance.
Fedora’s decision-making process is the same distributed, consensus-driven model that makes the project resilient. But it’s also what makes it virtually incapable of executing a painful but necessary migration. Every change requires buy-in from dozens of stakeholders. And when the choice is between a familiar pain (mailing lists) and an unknown pain (new platform), the inertia wins.
You can’t fix a culture problem with a better platform. The platform is just the mirror.
I saw this firsthand in a smaller project. We had two mailing lists, a forum, and an IRC channel. The community was fractured. Every attempt to unify was met with: “But we’ve always done it this way.” The solution wasn’t a new tool — it was a governance decision to deprecate the old list and force everyone into the forum. We lost a few people. We gained a lot more.
Fedora’s problem is that it’s trying to solve a political problem with a technical solution. You can’t negotiate your way out of a legacy attachment. You have to lead. And leadership means picking a side, making enemies, and living with the consequences.
Neutrality is death. Safe content dies in feeds. Safe decisions die in communities.
So here’s the twist: The Fedora project doesn’t need a better mailing list. It doesn’t need a better forum. It needs someone to say: “This is the way we’re going. If you don’t like it, you can fork the communication, but you can’t fork the community.” That’s hard. But it’s the only way forward.
If you’re in an open-source community that’s been arguing about the same communication tooling for a decade, ask yourself: Is this really a technical problem? Or is it a governance problem dressed up in a RFC?
FAQ
Q: Isn't this just a matter of choosing the right tool?
A: No. The tools exist — Google Groups, Discourse, GitHub Discussions — but they don't solve the underlying problem: a community that's afraid to make a decision. The real issue is governance, not technology.
Q: What can other open source projects learn from Fedora's struggle?
A: That you can't fix a culture problem with a better platform. Any migration requires a clear decision-making process, leadership willing to take a side, and a willingness to lose a few people along the way. Focus on governance, not tooling.
Q: Maybe mailing lists are actually better than forums for some projects?
A: They have strengths — archival, inclusive, asynchronous — but the problem is fragmentation. Having both a mailing list and a forum splits the community and dilutes discussion. The goal shouldn't be to pick the 'best' tool, but to pick one and commit.