One Vital Aspect to Growing a Contributor Base

What keeps contributors actively participating in your project and sticking with it? There are a number of different answers to this question, but probably one of the most important but rarely discussed would be speed.

Speed is quite influential when it comes to getting loyal and active contributors. Think about it: if you were in a contributor’s place, how at ease would you feel with a project when your submission goes unnoticed for a couple of days? A week? Chances are, the longer it takes for maintainers to take notice of the submission, the lesser the chances that contributor will ever contribute to the project again, let alone stick around.

This is why speed, particularly in recognizing submissions, is crucial when it comes to gaining and retaining contributors.

The Two Types of Contributors

Generally there are two types of contributors: the novice and the veteran. The novice, as you would expect, is someone who may have little to no experience contributing to open source projects and may therefore feel slightly more anxious about his or her submissions than most. Then there is the veteran, who because of his or her length and breadth of experience may not retain interest in one project for very long.

In both cases, speed in responding to submissions is of the essence. For the novice, it is necessary to respond within minutes or hours lest he or she think that the submission has been outright rejected. For the veteran you have some leeway, but not a lot. Beyond a week or so and the veteran may lose his or her interest in your project and move on. Getting these contributors back after some time has passed will be much more difficult than if you had just responded quickly in the first place. If you intend to have both types of contributors active and engaged with your open source project, you need to deliver responses as soon as possible.

The Two Types of Deadlines

Though responses to submissions need to be fast, they need not be thorough right away. Oftentimes, simply recognizing that you have received the submission even if you are not able to act upon it yet is enough to pacify contributors, at least for a little while longer.

In this sense, you actually have two deadlines you need to meet with every submission: the first response to the contributor, and the actual acceptance and merging of their contribution. The first response should be done within minutes or hours, while the second can be done within days to weeks though the shorter the timeframe, the better. The first response should include details such as your general thoughts on the submission and the most likely timeframe for its review. If it’s going to take a while longer because of certain events such as an ongoing major release or the unavailability of the maintainer, make sure to include this in your response. People will become much more patient when they know exactly why they have to wait.

The next deadline you have to deal with is in the merging, and this can be tricky. More often than not submissions require a lot of work and consequently a lot of time before they can be deemed acceptable. Fortunately however, there are ways to speed things up.

Increasing Speed

Continuous Integration (CI) is a practice that basically automates the acceptance and integration of patches as soon as they are able to pass established tests and evaluation. This often goes hand-in-hand with Continuous Delivery (CD), which is the release of new software versions whenever new and tested builds are ready.

CI and CD help tremendously in speeding up the merging of patches and delivery of software to users. However, it is not infallible. Sometimes automated testing isn’t comprehensive, builds aren’t completely automated and the CI/CD software itself can be difficult to set up. But there is one area of open source projects where these can be most useful and relatively risk-free: documentation. By using CI/CD in this area you speed up the review and acceptance of documentation with little to no risks.

There are many other ways that open source project maintainers can step up their speed, and these can vary from project to project. It’s important for projects to always find ways to increase their speed as it can affect how contributors view the project, and whether or not they will stick with it.

How about you? What has your project done to increase speed in recognizing and accepting submissions? Share your thoughts and experiences in the comments section below.


Write a Reply or Comment

Your email address will not be published.

You may use these HTMLtags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>