You’ve poured months into your open-source project. The code is clean. The architecture is elegant. The tests pass. But your GitHub issues are empty, your pull requests are ghost towns, and your project is dying in obscurity.
You’re not alone. And the problem isn’t your code.
The real killer is something far more insidious: the way you’re managing your community. Every platform you add is another barrier to contribution. Discord for real-time chat. Discourse for long-form discussions. GitHub for code. Zulip for threaded conversations. Each one demands a context switch. Each one fragments your community’s attention. And each one pushes potential contributors away.
I’ve been there. I built Earde because none of the community tools I was using felt like it was designed for open-source projects. Discord is great for real-time banter, but its ephemeral nature means any latecomer misses the entire history. Discourse preserves knowledge, but it’s disconnected from the daily pull request workflow. You end up with conversations scattered across silos, and your project’s institutional memory lives in six different places — none of which are linked to the code.
The best code in the world is useless if no one can find the conversation that explains why it was written.
Here’s the dirty secret of open-source maintainership: the friction of participation is inversely proportional to the health of your project. Every extra click, every new tab, every login to a different platform is a tax on goodwill. Your job as a maintainer isn’t just to write great code — it’s to remove every obstacle between a curious developer and their first pull request.
That’s where the traditional approach fails. We’ve been told that real-time chat is essential for community. But it actually excludes potential contributors who join later — they can’t scroll back through hours of Discord history. Forums preserve knowledge, but they’re disconnected from the pull request workflow. The result? A maintainer spends more time jumping between platforms than actually building the project.
Every platform you add is another barrier to contribution.
The solution isn’t another silo. It’s a unified space that lives inside your GitHub repository. Imagine a community where every discussion is tied to a specific issue or pull request, where real-time chat coexists with searchable archives, and where a newcomer can read the entire history of a decision while looking at the code that decision produced. That’s the idea behind Earde.
I’m not saying this is the only way. But I am saying that the status quo is broken. We’ve normalized the fragmentation of open-source communities as if it’s inevitable. It’s not. It’s a design failure. And it’s costing us contributors every day.
The future of open source isn’t more tools. It’s fewer, better-connected ones.
If you’re a maintainer, stop adding tools. Start connecting them. Your project’s survival depends on it.
FAQ
Q: Isn't this just another tool? Why would I add yet another platform?
A: Earde isn't a separate platform — it's a layer that lives inside your existing GitHub workflow. It replaces the need for Discord, Discourse, and other silos by providing real-time chat, threaded discussions, and searchable archives all tied directly to your issues and pull requests. You're not adding a tool; you're consolidating the ones you already have.
Q: What's the practical benefit for a maintainer?
A: Reduced context-switching. Instead of monitoring Discord, checking Discourse, and reviewing GitHub separately, you manage everything from one place. New contributors can instantly see the conversation history behind any decision without leaving the repository. This lowers the barrier to entry and increases the likelihood that someone will submit a pull request.
Q: Couldn't fragmentation actually be a good thing — it filters out casual contributors who aren't serious?
A: That's an elitist take that hurts open source. The whole point of open source is inclusivity. Fragmentation filters out people who are willing to contribute but lack the time or patience to juggle multiple platforms. You're not 'filtering' — you're gatekeeping. The best projects remove friction, not add it.