Four steps toward building an open source community

Open source projects generally begin with a problem to be solved. If it’s a problem a lot of people have, it may gain traction. Eventually you might have many people contributing. Before you know it, your project might turn into more than just a project, but a community.

That requires you as a maintainer to think differently about what you’re doing. It’s no longer just about writing code, but about facilitating relationships.

In this article, we’ll explore four steps to take to help your open source project evolve into a healthy community.

1. Lay the ground work early

It’s never too early to start thinking about community. The Astro team had community building in mind from the very beginning of the project. “It was one of the first things we focused on once we had a minimum viable product (MVP) together,” Astro co-creator Fred Schott told us in a Q&A on open source community building.

There’s quite a bit you can do to prepare before people start showing up. Among the most important is creating contributor guidelines and adopting a code of conduct. “You’d be surprised at how early contributor guidelines come in handy,” Schott says. “You need to answer questions like ‘How do I clone the repo?’ or ‘How do I get the packages installed?'” These basic things might seem obvious. But maintainers have been in their codebases for so long that they forget how hard it can be for new people to get started.

Many maintainers think a code of conduct isn’t something they need to worry about when the project is small and conflicts between contributors have yet to arise. But it’s best to have clearly articulated expectations and a plan for what to do if someone violates them before they are needed. “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: If your goal is to build a community or encourage outside contributors on your project, then you’ll want a code of conduct. If your repo is meant to be a solo project, then I think you’re fine to skip it.”

2. Meet people where they are

Building your own community spaces on platforms like Discord, Slack, and GitHub Discussions is important, but in the early days you need to meet people where they are. Graphile co-maintainer Jem Gillam says the team used F5bot to watch for mentions of Graphile across the web and social media so the team could answer questions and join conversations where they were already taking place. Eventually, as a project grows, a community will cohere in a particular place.

Think offline, too. Conferences and meetups are a great way to meet current and potential users and contributors. “I go to conferences and let people know that we’re looking for contributors and that we’ll walk anyone through submitting their first pull request,” says dbatools creator and maintainer Chrissy LeMaire. “I entice people by letting them know they can safely cut their teeth with us.”

3. Lead by example

Having a code of conduct is one thing. But it’s more important to conduct yourself the way you want your community to act. Schott emphasizes the importance of being patient with new users. “If you’re dismissive of the problems people face, they’ll leave,” he says. “First impressions are important.”

It’s important to set the right tone. “If there’s something that has come up that’s really negative, we tend to give it time—we don’t react in the moment,” Gillam says. The team strives to assume good intent because often people might come across more harshly than they intend, especially if they’re not writing in their native language. “It’s very easy for people to think they have a silly question, but we encourage people to ask them anyway because if one person has a particular question other people probably do as well,” Gillam says.

LeMaire recommends being open about what you don’t know and where you personally struggle. She livestreamed her work on Twitch to show people that even as a Microsoft Most Valuable Professional and GitHub Star she still struggled and made 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.

4. Spotlight your contributors

Be sure to show your appreciation for your contributors. You can thank them in the README file on your repo. LeMaire set up a LinkedIn company for dbatools and told contributors they were welcome to add themselves. It helped contributors spotlight their contributions outside of GitHub, and even helped some find jobs.

Don’t forget to recognize the non-code contributors as well. “Our documentation used to assume that core contributors were technical contributors, so we had some technical requirements,” Schott explains. Initially, the Astro project required someone to make “significant code contributions” to become a core contributor. Now the team evalutates non-code contributions when considering whether to promote someone to core contributor status.

“People contribute in lots of different ways, from documentation to community support,” Schott says. “We’ve updated our expectations accordingly.”

Written by

Klint Finley

@klintron