In the ongoing efforts to create a sustainable free and open source software ecosystem—one where projects receive the attention they need without burning out their maintainers in the process—a lot of attention has justifiably fallen on increasing the number of FOSS contributors.
Much of the discussion around increasing contributors assumes that the primary goal is to get contributors who will stick around and become community members and maintainers. It's certainly true that many hands make light work, and the more maintainers a project has the less likely it is that any one of them will bear the brunt of the work and burn out. But, this isn't the only way to support project sustainability through contributions. Another approach is to optimize your project for drive-thru contributors.
Welcome to the Drive-Thru
When you go to a fast-food drive-thru, you show up, get what you need out of the transaction, and then leave to go about your life. The same is true of drive-thru contributors in FOSS projects. These people show up to the project, make a single contribution, and then leave, never to contribute there again. The majority of these contributions are "itch scratches": a bug the contributor needs fixed, a feature they need added, or a quick edit to make in the documentation. Once the contributor has solved their particular problem, they move on.
Some maintainers get irritated by drive-thru contributors. Rather than being grateful for the new contribution, the maintainers resent the cycles they spend getting that contribution landed. These maintainers state that it can take a lot of time and effort to help someone make a contribution—time and effort that's wasted if that contributor has no intention of sticking around to become a community member.
Improved Contributor Experience
Rather than getting mired in resentment, it can be helpful for maintainers to put themselves in the shoes of new contributors—drive-thru or otherwise. As frustrating as it may be for a maintainer to invest a lot of time and effort into onboarding a new contributor, imagine how frustrating it must be for the contributor not to be able to step in and make a difference quickly. The shared element here is a contribution process that's undocumented, high-touch, arcane, cumbersome, or any combination of the lot. Many potential new contributors have shared with me that they're more willing to walk away from a contribution than deal with the frustration of a poor contributing process.
This is where a metric of "number of drive-thru contributors" is a good proxy for the overall health of a project's contribution process. In many ways, a drive-thru contribution can be seen as ideal for an open source project. If a project is able to get dozens or even hundreds of new improvements and additions with minimal friction for project maintainers, not only does the project benefit from those improvements but it’s also ensured that its contribution process is effective.
Any process that can support a swift and pleasant drive-thru contribution is also guaranteed to improve the experience of any new contributor who might happen by. This leads to a positive first impression of the project, increasing the chances of a new contributor wanting to repeat that experience and join the community. Over time, this builds into an overall positive reputation for the project, which itself can lead to more visitors, users, and contributors.
Check Out the Specials
For most projects (unfortunately), it's pretty easy to find ways to improve the new contributor experience. Documentation is often the best place to start. Things like quick start guides and detailed step-by-step "how to contribute" tutorials can help new contributors answer a lot of their own questions without needing to interrupt a maintainer. Having a public project roadmap can show contributors whether their planned addition is likely to be accepted and, if so, when it's likely to be released.
Maintaining documentation of project jargon, inside jokes, and history can make it easier for someone new to the project to understand what the team is saying. It also helps to make a new contributor feel more included and welcome, so they're more likely to want to return to the project after they land their first patch. For some projects, it can be helpful to provide a container or VM image of a development environment. This can allow new visitors to start contributing after minutes of setup rather than hours. Finally, setting up mentoring sessions, such as maintainer office hours, can make the question-asking process more efficient for new contributor and maintainer alike.
Total Number Served
In the past, tracking something like the number of drive-thru contributors would have meant creating, running, and maintaining a lot of data-munging scripts. Considering how much you need to do already on your project, you're unlikely to have the time to develop and maintain something like that. Mercifully, you no longer need to, thanks to Cauldron, a free software project from the data wizards at Bitergia.
Cauldron collects and analyzes project data so you don't have to. Although you could install your own Cauldron instance, part of how Bitergia gives back to the FOSS community is by providing an instance of Cauldron that's free to use for all FOSS projects. The powerful Kibana-based visualization tool allows you to slice and dice project contribution and community data to surface things like the average time to close an issue or review a patch, the number of contributions broken down by organization, and, yes, even the number of drive-thru contributors.
Thank You, Come Again
Once you've started tracking the number of drive-thru contributors in your project, you've also opened the door to contacting them. Although it's likely that a contributor made only a single contribution because that's all they needed, don't be afraid to ask them for feedback about the contribution process. You can learn a lot from their perspective, and you can apply that knowledge to make it easier for the next drive-thru contributor to donate their time and expertise to help improve the project.
Ready to find a job? Check out the latest job listings at Open Source JobHub.
Comments