Community Building Starts With the Maintainer

Successful open source projects rarely stay purely technical for long. Once a project attracts outside contributors, the maintainer's role shifts from writing code to cultivating relationships. A project becomes a community when maintainers actively create the conditions for people to participate comfortably and productively.

Prepare Before You Need To

Community infrastructure should be in place early, even before outsiders arrive. The Astro team treated community building as a priority from the project's MVP stage, according to co-creator Fred Schott. Two pieces of groundwork matter most:

  • Contributor guidelines: Answer basic questions like how to clone the repository and install packages. What feels obvious to a maintainer who has lived in the codebase is often a barrier for newcomers.
  • A code of conduct: It's tempting to defer this until tensions arise, but expectations should be articulated in advance. "If you care about outside contributions at all, you should have a code of conduct, regardless of size," Schott says. "It's more about intent." A solo project may not need one, but any project seeking external contributors should adopt it from the start.

Go Where the Conversations Are

Standing up your own Discord, Slack, or GitHub Discussions space only helps if people know to find you there. In the early days, you need to seek out existing conversations. Graphile co-maintainer Jem Gillam says the team used F5bot to monitor web and social media mentions, allowing them to answer questions where they were already happening.

Offline venues matter too. Chrissy LeMaire, creator and maintainer of dbatools, uses conferences to recruit contributors directly, promising to walk newcomers through their first pull request. "I entice people by letting them know they can safely cut their teeth with us," she says.

Tone Is Set by Action, Not Policy

A code of conduct only matters if maintainers model the behavior it describes. Patience with newcomers is critical. "If you're dismissive of the problems people face, they'll leave," Schott says. "First impressions are important."

Graphile's team deliberately avoids reacting in the moment to negative interactions, giving situations time to cool. They assume good intent, recognizing that contributors may come across harsher than intended—particularly those writing in a non-native language. They also make clear that no question is too basic: if one person is wondering, others likely are too.

LeMaire embraces vulnerability as a leadership tool. By livestreaming her work on Twitch, she showed that even a Microsoft Most Valuable Professional and GitHub Star struggles and makes mistakes. "I show people that it's OK not to know everything and that they don't have to use the most intimidating or complicated tools to be effective," she says.

Make Contributors Visible

Recognition should extend beyond GitHub. LeMaire created a LinkedIn company for dbatools and invited contributors to list themselves, helping them highlight their work and even land jobs.

Non-code contributions deserve equal weight. Astro initially required "significant code contributions" for core contributor status, but has since revised that policy. "People contribute in lots of different ways, from documentation to community support," Schott says. "We've updated our expectations accordingly."

Thanking contributors in the README is a small gesture, but widening the definition of who counts as a contributor matters more. Projects thrive when maintainers make room for documentation, support, and other non-technical work alongside the code.