How to Build an Open Source Community
Note: For the purpose of the post, I’ll be talking about software communities in open source.
Building a community requires either an intrinsic understanding of humans (for example, folks like Nathen Harvey) or a commitment to learning how to engage those humans. When trying to teach other people how to do anything, we often try to identify patterns that we can use to build a structure. It’s been incredibly hard for a single standardized approach to the community to emerge over the last 15 to 20 years, but there are a few I like personally and have linked to at the end of this article.
The first thing to remember is that everyone connects with a community through different touchpoints and at various stages of an engagement cycle. The good news is that you can generally categorize those people into one of the stages in the following cycle:
- Awareness — this person has a general awareness or interest in your project, but you might not know they exist yet.
- Casually engaged — this person will read articles about your project, visit your website, interact with the content in your portals or on social media.
- Directly engaged — this person will interact with communication channels (click links, reach blog posts and share sign up for your community portal) and likely does something with the project but is not interacting with the people involved in your project.
- Actively engaged — having researched the project and your organization, this person decides to use the software you’re developing and engage with the community somehow by asking questions, answering questions and providing input. This step importantly involves a move to engaging the other people who use the software directly.
- Committer — this person sees a problem they can fix, submits a pull request in your project, and now qualifies as a committer. This step is essential because it allows a person to feel some amount of ownership or personal investment in the project.
- Deeply engaged — this person is completely committed to your project, is likely involved in one or more committees that help keep it afloat and acts as an evangelist that brings more people to your project.
A keen eye will recognize a similarity to a traditional sales funnel, but there’s a distinct and important difference between a sales funnel and a community cycle: People will leave your community for no fault of your own. They may not have the brain space, motivation or excitement to maintain engagement or become excited about another project. None of this means you are failing to engage properly. A member’s waning engagement shouldn’t be seen as a failure, or you risk starting to evaluate your community’s strengths incorrectly.
Engage the Right People
The first step in engaging the right people is finding the people! Awareness is a challenge for every organization (open source and business alike). Briefly, you will build awareness by finding the people who are most likely to need the solution that your project provides. For a deeper dive into building awareness, I recommend looking at this article on developing your strategy from Red Hat or this article on promoting at opensource.com.
While you start to build awareness of your project, you also need to keep the barriers to engagement as low as possible for your community. There are three practical ways to make sure that happens:
1. Design a culture that is welcoming for newcomers.
The most important thing is to make sure no one is ever ridiculed for asking a question of any skill level and that all new users have a place where they are encouraged to ask new-user questions.
2. Limit the number of new accounts to create.
Anything that requires a disruptive action before participation is a potentially limiting factor in engagement. When designing your ecosystem, keep in mind that you want to engage where people already are. For example, asking folks to have a GitHub or GitLab account in order to contribute might be a low bar, but asking them to register for a proprietary system might dissuade people from joining.
3. Define processes publicly.
If you want contributions to a project you’re excited about, keep things as clear and streamlined as possible for new contributors as confusion about what to do can quickly cause frustration.
4. Apply project management techniques to the work.
Your team likely has big ideas, but newcomers can immediately feel overwhelmed by vague or broad “goals.” If you start by breaking down a bigger project into smaller chunks and then define the goals of that work very clearly, new contributors can quickly find a way to get started without being asked for a large investment. It also enables them to participate as little or as much as they can, making them feel more welcome.
The next step is to identify and build relationships with the most highly engaged people. This will be easier than you think! Once people enter the community, watch for the folks who consistently ask questions, answer questions and provide feedback. Those people will stand out to you and be the people you want to empower. Empowering those people helps to move them to the deeply engaged stage.
Empower the Right People
It is massively important to empower people at the peak of their interest in your project. Empowerment in this context is encouraging an individual’s passion so it can take an active, physical shape as it relates to your project. Your job with these amazing humans is to give them what they need and then get out of the way. Things like ensuring they have the access they need to contribute in a productive and meaningful way, getting feedback on the contributions they’re making and how those contributions impact the project’s success and allowing them to provide support to help the project continue to grow long term.
Something as simple as helping those deeply committed individuals break their big ideas down into smaller tasks can help them see how their ideas or their work can be used to enable a new contributor.
Then once you’ve started the empowerment, keep those humans deeply committed by continuing to take their feedback and show them how they’re impacting the success of the project. Set up regular, prescheduled feedback sessions for a few people (3-5 at the most) at a time, show them what they’ve accomplished in the last month, half-year, or year, and ask them what you’re missing as a project. Once they get bored with submitting pull requests, it’s time to expand your approach. You can get creative here because this will be highly specific to your community. You might consider a mentor or buddy program, a highly visible feedback program (think ++ for IRC) or another way to recognize your community leaders.
Get Going
We didn’t talk much about tools to use in all of this. What you use will depend on what you’re trying to accomplish with your outreach goals, your community’s desires and your budget. The most important thing is to start with the simplest tool for the job and expand as you need to. A few examples of tools you might use for project management are OpenProject, Focalboard and honestly, anything that provides you a Kanban board.
Keep agile in your approaches, but remain laser-focused on empowering and serving your community, and success will be just around the corner.