Organizing an open source contributor community starts with knowing what motivates your contributors. Understand that, and you'll be able to match the needs of your contributors with those of your project.
But even the best-organized communities would struggle to get to know every potential contributor individually. Instead, you can group people according to what they have in common.
One way of doing that is to think about the different roles people are likely to play in your project. Here we'll look at three ways of defining those roles:
- what the contributor wants to achieve
- their experience level
- and the social role they play.
Each of these will help you think about and plan for the motivations, needs, and experiences of the people who engage with your project.
Contributor motivation deserves an article of its own. However, it's worth touching on here as motivation has a specific bearing on the role someone plays in a community. And if you understand a little about why a person wants to contribute to your project, you can organize your contributor experience to help them succeed.
What draws people to your project won't be the same as other projects. Nonetheless, most open source contributors either want to make the world a better place or make something better in their own lives. Let's break down some of the deeper motivations in each category:
Make the world a better place
- Belief in the mission of the project
- Belief in open source
- Correcting a perceived problem in the market for that type of software
Make my own life better
- Fix a specific issue
- Learn useful skills
- Build reputation/enhance career
- Contribute as part of their day job
- Make friends
- Have fun
Suppose you know that people contribute to your open source project to learn new skills. In that case, you might gear your GitHub pages, issues tagging, project wiki, and other materials to make it super easy for people to make entry-level contributions.
On the other hand, knowing that a proportion of contributors will show up, make a PR, then effectively disappear will prevent you from too much disappointment.
Someone's experience as a developer, or specifically with the technology involved in your project, naturally influences how they will participate in your community.
Even if you don't dive deeper into the other ways of thinking about the roles people adopt in your project's community, experience is a useful proxy. In particular, someone's experience level will determine what they need from your project's contributor onboarding.