Why Discord Sucks for Developer Communities

Disclaimer: This post is not meant to talk bad about Discord. It's a great messenger app for casual groups and communities. This is a post with a POV of an open source library maintainer trying to figure out the right way to use it.

If you’re maintaining an open-source library or building a community around a project, you’re eventually going to look for a place for that community to live. I’ve spent the last few years navigating this as a core maintainer of Tiptap —an open-source framework for building rich text editors.

Four years ago, we thought Discord was the answer for the Tiptap community . Fast forward to today, and I’d honestly tell any maintainer to stay away.

Discord is Great for Chat, Terrible for Everything Else

Discord claims to be the best place for online communities. That’s probably true if you just want a closed-off corner of the web where people can chat about your project in real-time. If that’s all you need, you’ll be fine.

But if you have a real-world use case—like collecting feature requests, providing support, or building a searchable knowledge base—Discord is a significant hurdle.

Don’t get me wrong: as an app for real-time messaging, voice rooms, and screensharing, Discord is excellent. It’s still the best at those specific things. But for us at Tiptap, the wheels fall off the second you try to use it as a "one-size-fits-all" Chat+Forum hybrid.

A linear chat is an inefficient place to hold specific technical discussions. Bug reports, feature requests, and random questions all bleed into each other. You end up with a single stream of messages where five different people are talking about five different things at once. It’s exhausting for both users and maintainers.

Discord tried to fix this with Threads and Forum Channels. On paper, it sounds like a solution. In reality, the implementation lacks the depth required for professional OSS management.

Threads and Forum Channels Just Aren't Good Enough

At Tiptap, we hit this exact wall. People were constantly talking over each other in one big mess. To fight the chaos, our team started asking people to use Threads.

Threads work if your server is tiny and you can manually police every message. But once you grow to the scale of a popular library, enforcing that rule is impossible. Discord doesn’t give maintainers the permissions to handle this properly—you can’t, for example, force a "threads-only" mode in a standard text channel. People just keep using the chat for what it is: a chat.

I spent way too much time wondering how to fix this, and eventually, we pulled the trigger on Forum Channels. These are basically mini-message boards that force people to create a thread. At first, I was happy—the noise went down and the structure improved. But then I realized: user interaction completely cratered.

By trying to fix the noise, we accidentally stifled the community. The casual small talk vanished. People only show up to our Discord now when they have a specific problem. Because the "vibe" is gone, other developers don't hang out there anymore, which means there’s no one left to help answer the questions.

The Moderation is a Nightmare

To make matters worse, managing Forum channels is unnecessarily difficult. For example, we have channels for community job postings and hiring profiles. People ignore the rules and post in the wrong spot constantly.

In a real forum, I’d just move the post to the right category, edit the tags, or merge it with a duplicate. On Discord? You can’t move anything. You can’t merge threads. If someone spends 20 minutes writing a great post in the wrong channel, our only options are to delete their hard work or let the channel stay polluted. It’s counter-productive.

We ended up with the worst of both worlds: a "community" that doesn't talk, and a forum that is hard to manage, impossible to search, and a pain to moderate.

The Death of a Community

Now that the Discord is effectively "dead" as a social hub, it’s just a closed-off support board. It’s not a place people visit to hang out or learn; it’s just a place to drop a question and leave. For any user who doesn't have a problem right now, there is zero reason to be there.

Because of that, we are planning to reopen the chat channels and move our actual "knowledge base" and forums away from Discord entirely.

The Walled Garden Problem

This is the biggest issue of all. On an open forum, anyone can use a search engine to find a solution to a problem. Discord, however, is a walled garden. Everything is locked behind a login.

Search engines can’t index the thousands of helpful answers and discussions happening in your community. That means every time a user has a question, they can't find the answer on the web—they have to join your server and ask it all over again. It’s a massive waste of everyone's time.

In 2026, this is even more critical. It’s not just about Google SEO anymore; it’s about LLM traffic. AI crawlers and agents can’t learn from your community’s collective wisdom if it’s trapped inside a Discord channel. You are effectively hiding your documentation from the tools that developers use every day to find answers. You lose out on public traffic, you hurt your project's discoverability, and you force your maintainers to repeat themselves for eternity.

What are the Alternatives?

This is where the Tiptap team is currently stuck. We want to keep the Discord server for its original purpose (quick, real-time chatting), but we need a more structured, public solution for support and feature requests.

We are looking at two main options:

Option 1: GitHub Discussions

Since Tiptap already lives on GitHub, this is the "low friction" choice. Right now, it's underutilized because attention is usually split between Discord and GitHub Issues.

The Pros: It’s where the code lives. It integrates perfectly with Issues and Releases—you can turn a discussion into an issue with one click.

The Cons: We don’t own it. If GitHub goes down or changes their terms, we’re at their mercy. Also, the SEO and crawler traffic stays on GitHub rather than our own project site.

Option 2: Self-hosted Discourse

This is the "pro" route. A self-hosted Discourse instance gives us 100% control over the theme, extensions, and moderation.

The Pros: All that search and AI-agent traffic lands on our own domain. It makes the community feel like a "home." We can moderate exactly how we want.

The Cons: It requires maintenance, updates, and server management. Plus, asking users to create another account on a third-party site is a significant barrier to entry.

So what’s the verdict?

We’re still torn, but we’re leaning toward GitHub Discussions. From a maintainer's point of view, the integration into our existing workflow is just too good to ignore. It keeps everything in one place and doesn't add "server maintenance" to an already busy schedule.

As for Discord? We’re going to pivot it back to what it was meant to be: a chat community. We’ll be more approachable there for direct messaging and quick chats, but the "knowledge" will live in the open.

I’ll keep you posted on what we decide. Hopefully, this gives you some insight into the messy reality of community building in the open-source world.

If you liked this post, feel free to follow me over on Bluesky or on Github .