community-building git:20260728.fac4544A

Immutable. This exact content is served forever at /api/v1/blob/442dab97a9fc1007.

---
name: community-building
description: Grow product and open-source communities through seeded value, working moderation, and contributor ladders. Use when starting a community or reviving one that went quiet.
---

# Community building

A community exists when members get value from each other, not just
from you. Until that flywheel turns, you are running a support
channel with ambiance; the work is seeding, structuring, and then
deliberately getting out of the way.

## Method

1. **Give the community one clear job.** Peer support,
   show-and-tell, contributor coordination, practice
   exchange (see the agent-role-definition' role-clarity
   instinct, applied to humans): the job decides the
   platform (forum for searchable knowledge that
   compounds: see technical-seo's durable-content logic;
   chat for velocity and belonging; both means two jobs,
   staffed as two). A community without a job is a logo
   with a lurker problem.
2. **Seed activity for the cold-start year.** Founders and
   team answer everything fast (first-response time is
   the early community's heartbeat), post the content
   that models the culture (build logs, questions,
   honest failures: see developer-marketing's
   practitioner voice), and personally invite the first
   hundred members one at a time; ghost towns repel:
   a small active space beats a large silent one, so
   start narrow (one channel, one forum category) and
   expand on pressure (see mvp-scoping's narrowing
   rule).
3. **Write the code of conduct and enforce it early.**
   Clear rules, named moderators, private reporting,
   and visible consequence for the first serious
   violation: the community's culture is set by the
   worst behavior tolerated (see
   open-source-review-board adjacency); moderation
   capacity scales ahead of growth or the loudest
   ten percent become the brand.
4. **Build the ladder from lurker to leader.** Most
   members read only (fine: they still get value);
   design the small first steps (introductions thread,
   easy questions channel, good-first-issue labels:
   see open-source-maintainer-role's contributor
   funnel), then recognize climbers visibly
   (contributor spotlights, early access, maintainer
   invitations: see mentoring-engineers' sponsorship:
   the same move at community scale). Titles and
   badges are cheap; genuine trust and scope are the
   real rungs.
5. **Feed the community's work back into the product.**
   Answered questions become docs pages (see
   docs-maintenance: the community is your
   staleness-detector), repeated complaints become
   roadmap evidence (see product-discovery,
   churn-analysis's leading indicators), member
   creations get amplified (their tutorials, plugins,
   templates): the visible loop "we heard, we shipped,
   credit to X" is what convinces members their
   participation matters (see
   roadmap-communication's change-loudly rule).
6. **Measure health, not headcount.** Active
   participants (weekly posters/answerers), answer
   rate and time-to-first-response, returning-member
   ratio, and the founder-independence ratio (what
   fraction of answers come from non-team members:
   the flywheel metric); member count is the vanity
   number (see product-metrics' vanity warning).
   Review quarterly with the same decide-or-adjust
   discipline as any product surface.

## Boundaries

- Communities are slow assets with real carrying
  costs (moderation, programming, attention);
  starting one you will abandon in six months is
  worse than none: the dead community is public
  evidence of neglect (see feature-sunsetting if it
  comes to that: close honestly).
- The community is not a free labor pool or a
  marketing broadcast list; extractive framing
  (posting only announcements, harvesting content
  without credit) reads instantly and kills
  reciprocity (see developer-marketing's trust
  economics).
- Platform choice creates lock-in for *members*
  (their answered questions, their reputation);
  migrations lose a real fraction of the community:
  choose durably and early (see
  managed-vs-selfhosted's exit-path thinking).