Scrolls
5 min read
On this page

Communication Channels

A community needs places to talk. The question is not whether to have communication channels, but how many and which ones. The most common mistake is launching too many channels too early, fragmenting a small community across GitHub Discussions, Discord, Slack, a forum, a mailing list, and Twitter. Five people spread across five channels is one person per channel, and that feels dead. Start with one channel, and add more only when the existing one is genuinely overwhelmed.

GitHub Discussions

GitHub Discussions is the best starting point for most open source projects. It lives where the code lives, requires no additional accounts, and is indexed by search engines.

GitHub Discussions categories that work:

  Announcements     — maintainers post releases, breaking changes, roadmap updates
  Q&A               — users ask questions, answers can be marked as accepted
  Ideas             — feature requests and brainstorming
  Show and Tell     — users share what they built with the project
  General           — anything that does not fit the above

Why Start Here

Advantages of GitHub Discussions:
  - No new account required (anyone with a GitHub account can participate)
  - Searchable by Google (answers help future users)
  - Threaded conversations (unlike linear chat)
  - Integrated with the repo (can convert discussions to issues)
  - Notifications use the same system as issues and PRs
  - Free forever

Limitations:
  - Not real-time (not designed for live conversation)
  - No voice or video
  - Less casual than chat (some people find it intimidating)
  - No channels/rooms for subtopics

Next.js, Vercel's AI SDK, and Tailwind CSS use GitHub Discussions as their primary community channel. For projects under a few thousand users, it handles everything: questions, feature requests, announcements, and general conversation.

Real-Time Chat: Discord & Slack

When your community grows large enough that GitHub Discussions feels slow for quick questions, adding a real-time chat channel makes sense. Discord and Slack are the two dominant options for open source communities.

Discord

Discord has become the default choice for open source communities. It is free, supports unlimited members, and has no message history limits on free plans.

Recommended Discord channel structure for a medium-sized project:

  INFORMATION
    #announcements      (read-only, major releases and news)
    #rules              (read-only, code of conduct and guidelines)

  COMMUNITY
    #general            (casual conversation)
    #help               (support questions)
    #showcase           (share what you built)

  DEVELOPMENT
    #contributing       (discussion about contributing)
    #development        (maintainer discussion, open to everyone)

  Do NOT create at launch:
    #off-topic          (wait until community is large enough)
    #jobs               (attracts spam)
    Per-feature channels (premature fragmentation)

Astro, Tailwind CSS, Prisma, and Bun all run active Discord servers. The key to their success is active moderation and maintainer presence. A Discord server where maintainers never show up becomes a ghost town or a complaint forum.

Slack

Slack was the original open source community chat platform, but its free plan limitations have pushed most communities to Discord. The free plan limits message history to 90 days and restricts the number of integrations.

When Slack still makes sense:
  - Enterprise-focused projects where users already live in Slack
  - Projects sponsored by companies that provide a paid Slack workspace
  - Communities that started on Slack before Discord became popular

When Discord is better:
  - Consumer-focused or developer-focused projects
  - Communities that need unlimited message history
  - Projects where voice channels are useful (pairing, office hours)
  - Any new community starting from scratch

Kubernetes uses Slack because its community predates Discord's rise and its enterprise audience is comfortable there. Deno uses Discord because it launched when Discord was already the standard for developer communities.

Chat Anti-Patterns

Problems that kill chat communities:

  The Support Graveyard
    Users ask questions, nobody answers.
    Fix: maintainers must commit to answering questions regularly.
    If you cannot commit, do not open a chat channel.

  The Firehose
    So much conversation that newcomers are overwhelmed.
    Fix: add channels gradually, pin important messages,
    create a FAQ channel or bot.

  The Inner Circle
    A small group dominates conversation, newcomers feel excluded.
    Fix: actively welcome new members, ask questions that invite
    participation, rotate who answers questions.

  The Ghost Town
    Channel exists but nobody talks.
    Fix: close or archive it. An empty channel is worse than
    no channel because it signals a dead community.

Blogs & Long-Form Content

A blog serves a different purpose than discussion channels. It is for polished, intentional communication: release announcements, migration guides, project retrospectives, and technical deep dives.

Blog content that drives community growth:

  Release announcements
    "Astro 4.0 is here. Here is what changed and why."
    Include: headline features, migration guide, credits to contributors

  Technical deep dives
    "How we reduced build times by 70%"
    Shows technical depth, attracts contributors who care about internals

  Roadmap updates
    "Our plans for 2026"
    Gives the community visibility into the project's direction

  Retrospectives
    "What we learned from the v3 migration"
    Builds trust through transparency

  Contributor spotlights
    "Meet the contributors behind the new plugin system"
    Recognizes contributors, encourages others to contribute

Where to Host

Blog hosting options:

  GitHub Pages + static site generator
    Free, lives next to the code, contributors can submit posts via PR.
    Used by: Rust (blog.rust-lang.org), Go (go.dev/blog)

  Project website
    Part of the official docs site. Feels professional and integrated.
    Used by: React (react.dev/blog), Next.js (nextjs.org/blog)

  Dev.to or Hashnode
    Free, built-in audience, but you do not own the platform.
    Good for: cross-posting to reach more developers

  Substack or Ghost
    Email-first distribution. Good for projects with a strong personal brand.
    Good for: solo maintainers building a following

Social Media & Visibility

Social media is for visibility, not community. It is where you announce things, share wins, and attract attention. It is not where you have discussions or provide support.

Platform purposes:

  Twitter/X
    Best for: release announcements, short demos, engaging with the
    broader developer community.
    Frequency: 2-5 times per week when you have something to share.
    Do not: use it as a support channel.

  Mastodon
    Best for: reaching developers who left Twitter.
    Cross-post from Twitter if you want to cover both.

  Reddit
    Best for: reaching communities organized by topic (r/rust, r/golang,
    r/reactjs). Post major releases and interesting technical content.
    Do not: spam. Reddit communities will downvote obvious self-promotion.

  Hacker News
    Best for: major launches, significant technical achievements.
    Submit sparingly. Getting to the front page drives enormous traffic.
    Do not: submit every minor release.

  YouTube
    Best for: tutorials, conference talks, live coding sessions.
    Especially effective for complex projects that benefit from visual
    explanation.

  LinkedIn
    Best for: enterprise-focused projects. Decision-makers are here.
    Post about case studies, production usage, and enterprise features.

Bun's launch strategy is a good example: Jarred Sumner posted demos on Twitter showing Bun's speed advantages, which drove massive organic interest. The technical content spoke for itself.

Choosing Your Channel Strategy

The right number of channels depends entirely on your community size. More channels is not better. The right number is the minimum that serves your community without fragmentation.

Community size -> recommended channels:

  < 100 users
    GitHub Discussions only.
    Everything in one place. Easy to manage. No fragmentation.

  100-1,000 users
    GitHub Discussions + Discord or Slack.
    Discussions for async Q&A and announcements.
    Chat for quick questions and casual conversation.

  1,000-10,000 users
    GitHub Discussions + Discord + blog.
    Add a blog for polished announcements and technical content.
    GitHub Discussions remains the canonical Q&A platform.
    Discord handles real-time community interaction.

  10,000+ users
    All of the above + social media presence + possibly a forum.
    At this scale, you need dedicated community managers.
    Consider a community team, not just maintainers doing double duty.

The Fragmentation Problem

What fragmentation looks like:

  A user asks a question on Discord.
  The answer exists in a GitHub Discussion from 3 months ago.
  Nobody on Discord knows it exists.
  A maintainer answers the same question again.

  A feature decision is discussed on Twitter.
  Contributors who are not on Twitter miss the conversation.
  They feel excluded from the decision-making process.

  A bug is reported in Slack.
  It never gets filed as a GitHub issue.
  The bug is forgotten.

The fix is to establish clear purposes for each channel and cross-link aggressively. Every support answer in Discord should ideally become a GitHub Discussion or documentation update. Every decision made in chat should be recorded in an issue or RFC.

Moderation

Every communication channel needs moderation. Without it, spam, toxic behavior, and off-topic noise will drive away the people you want to keep.

Minimum moderation setup:

  Rules posted visibly
    Link to code of conduct in every channel description.
    Pin the rules in chat channels.

  Multiple moderators
    At least 2-3 moderators across time zones.
    Solo moderation leads to burnout and gaps in coverage.

  Clear escalation path
    Users need to know how to report problems.
    Provide an email or a private reporting channel.

  Consistent enforcement
    Apply rules equally regardless of the person's status.
    A core contributor who violates the code of conduct gets
    the same treatment as a new user.

Common Pitfalls

  • Launching five channels on day one. A new project with GitHub Discussions, Discord, Slack, a forum, and a mailing list looks ambitious but spreads a small community too thin. Every channel with zero activity signals a dead project. Start with one and add channels when the existing ones are genuinely crowded.

  • Using chat as documentation. Answers in Discord and Slack disappear into the scroll. If someone asks a question that will be asked again, the answer belongs in documentation or a GitHub Discussion, not buried in chat history.

  • No maintainer presence in chat. Opening a Discord server and then never participating in it is worse than not having one. Users show up, ask questions, get no response, and leave with a negative impression of the project.

  • Treating social media as community. Twitter threads are not community discussions. They are ephemeral and exclusive to people who follow you. Important decisions and conversations must happen in channels the whole community can access.

  • Ignoring moderation until there is a crisis. The time to establish moderation norms is before you need them. Retroactively moderating a toxic channel is much harder than setting expectations from the start.

Key Takeaways

  • Start with GitHub Discussions as your only community channel. It is free, searchable, threaded, and requires no additional accounts.
  • Add Discord or Slack only when your community is large enough that async discussions feel too slow for quick questions. Discord is the better default for most open source projects.
  • A blog serves a fundamentally different purpose than discussion channels. Use it for polished announcements, technical deep dives, and roadmap updates.
  • Social media is for visibility, not community. Use it to announce releases and share wins, not to have discussions or make decisions.
  • The biggest risk is fragmentation. Every additional channel splits your community's attention. Fewer, more active channels are better than many quiet ones.
  • Every channel needs moderation. Post rules visibly, have multiple moderators, and enforce consistently.