This article is cross-posted from The Lead Dev.
When you think about it, open source is a fundamentally weird concept.
‘Hey, I’m going to go create a community garden, want to join? Oh, no one asked me to do it. No, I’m not getting paid for it. No, it’s not in my neighborhood, why do you ask? I just have some good ideas for the layout of a garden and want to test them out. If people like it, cool! They can use or change the garden if they like. Or, use it as inspiration for creating new community gardens; that would be really neat.
You’re in? Awesome. You’ll have to bring your own dirt, shovels, plants, etc… If you know of anyone else that wants to do some planting, send them my way too. The more the merrier!’
Tending the open source garden
It is a bit odd. And yet, it works and _has_worked for the past 30-70 years (depending how you count). The community garden metaphor is pretty apt, given how much care and attention open source requires in order to be effective and useful.
Just like no two gardens are the same, no two open source projects are the same.
The social model of open source aims to capture the sociotechnical aspects of how we tend the open source garden. While developing this model, we explored how identifying the purpose of your open source project is important in setting expectations for your community, as well as for yourself. We added on how being upfront and transparent about how your project runs allows people interacting with it to make well-informed decisions. Last time, we ventured into the critical topic of empowerment and how to break down barriers to open source participation.
Welcoming and sustaining contributors
Most of those previous articles focused on both users and contributors, but this time we’re going to put contributors at the center. And to be clear, when we reference ‘contributors’, we mean anyone who files an issue, writes documentation, fixes a test, creates a feature, reviews code, manages the budget, does user testing, writes a blog post – you name it. Contributions take many forms and most of them are underrecognized.
A crucial part of how a project gets off the ground and keeps itself from languishing is cultivating a healthy contributor community. While much of that is more of an art than a science, maintainers can sow the seeds for success by highlighting the ways that people can become involved in and grow within an open source project.
Here are five ways to welcome and retain contributors:
1. Bringing in new contributors
Maintainers have a number of tools at their disposal to make onboarding to a new project easier. The good first issue label (or tag) has provided a way for newcomers to identify tasks that are suitable for them. Other projects go further and designate issues by area of expertise, such as design, UX, technical writing, samples, and others. This allows new contributors to find issues that align with their talents or interests, and indicates that the project welcomes those types of contributions.
Adding a list of labels or tags in use by your project to the contributing documentation helps people looking for a project to contribute to identify if your project is right for them.
For example, the static site generator Hugo labels its issues for easy filtering and the Python code formatter Black uses many labels to indicate intersections of interests.
2. Guiding potential contributors
Open source has the potential to be scary for newcomers, as working in the open can be nerve wracking. Many people who are active in open source today credit their involvement to the person or people who sat down with them to walk them through their first contribution. Some projects try to scale that experience by creating mentoring programs to help potential contributors understand the dynamics of the project and the mechanics of open source.
These programs aim to give first-time contributors a positive experience in open source, which will hopefully increase the probability that they will continue with the project. That said, many of these mentoring programs are hidden away and not obvious to potential contributors. Make them obvious and easily discoverable!
The Open Mainframe Project has an established mentorship program to help people learn not only about contributing to open source, but also to learn about mainframes themselves. Kubernetes also has various mentoring avenues, from one-off to participation in larger programs.
3. Recognizing contributions
So much of the day-to-day work in open source isn’t captured in version control. Yet, much of how we measure impact in open source is mined from git logs or other metadata, which winds up skewing towards code contributions. This leads to people who make other invaluable contributions feel not as appreciated. Identify the ways that your project recognizes all contributions and contributors – and how contributors can expect to see it.
Projects such as p5.js and Snipe-IT use All Contributors to recognize a plethora of contributors and contribution types.
4. Leveling up your contributors
How does someone gain trust in an open source project? How does a contributor become established enough to review code, edit a blog post, to merge a patch, to triage issues, or moderate a discussion platform? This is where contributor roles and ladders come into play. Define the roles and their responsibilities, as well as paths between them. The Cloud Native Computing Foundation has a template for contributor ladders that you can use as a starting point, though it is primarily focused on code-related responsibilities.
However you define your roles and responsibilities, make sure that your ladder is prominent and easily accessed by all contributors.
Apache Maven clearly documents its roles, their responsibilities, and how to ‘graduate’ from one level to another. Gitea not only differentiates between contributors, maintainers, and owners and how to progress between them, but also recognizes previous owners of the project.
5. Encouraging healthy contributor interactions
Every open source project has its own norms and culture, and that can pose a barrier to people unfamiliar with them. This is complicated by the fact that a contributor may never meet the people they are collaborating with, which makes tone difficult to assess. To provide guardrails for participation, open source projects turn to instituting codes of conduct. These codes of conduct set expectations for community members as well as ways to peacefully resolve conflicts when they arise. Having a code of conduct – and sticking to it – creates an environment where people can be the best versions of themselves.
Everyone who wants to participate in the Warehouse (the software that underpins PyPI) community agrees to abide by the Python Software Foundation’s code of conduct. The Julia Programming Language has a set of standards that govern all community contributions and discussions.
Caring for your contributors
Open source relies upon so many different skills, and its increasing importance in the world means that we need to increase the amount of care we dedicate to welcoming and sustaining our contributors. Many in the open source community are doing amazing work in this area, such as Outreachy, SustainOSS, Season of Docs, and Otter Tech, to name a few. The social frameworks we discussed above are key aspects in encouraging contributors – and yes, empowering them to succeed within your project.
When thinking about your open source project’s social model, make sure to identify the ways that you are caring for your contributors and tending your open source garden.