This month on The Queue, josephj from LinuxQuestions.org asks:
How can I get programmers to join our project?
I inherited a project coded in $programming_language when the original developer quit and no one else stepped forward. It is currently hosted on GitHub and has a GPL 3 license.
It's a tool I use every day and I don't want to see it die. I know very little $programming_language and very little GUI programming, so I can't maintain it myself.
How do I go about finding one or more programmers who actually have some time to help out?
I found two or three programmers in the past, but, despite the best intentions, no one has stayed long enough to get a lot done.
The Answer
This is a question I hear asked quite a bit, so thank you for submitting it to The Queue. As programmers are both in intensely high demand and often have quite a few side projects themselves, getting them to participate in your project can be a challenge. The first suggestion I have for you is to set realistic expectations for participation. Unless you find another programmer who takes a deep interest in the project or desperately needs it for work, it's highly unlikely you'll be able to get someone to just step in as a maintainer. The time, dedication, and responsibility involved in being a maintainer should not be underestimated. That said, here are a few things you can do to ensure people who find your project and are interested in participating have a solid path to becoming regular contributors.
Introduction and messaging
It's critical that your project clearly outline:
- what it does,
- who it's for,
- why it's different,
- and when and where it should be used.
These items seem simple and, for someone who has been involved with the project for a while, forgetting that this information may not be obvious to others can be easy. Many projects, especially smaller ones, get overlooked as a result of this information being missing, impossible to find, or difficult to understand. You're using GitHub, so the README.md file is the place for this information. (Outside GitHub a README file serves the same basic purpose.) The information included should be concise, but lengthy enough to clearly articulate the information you feel is important about the project.
Contributing guidelines
You should also create a CONTRIBUTING file (or CONTRIBUTING.md file if you're using Markdown on GitHub) that contains information about actually participating in your project. This is the place for simple step-by-step instructions on cloning, detailed instructions on how the code should be built, any coding standards or formatting standards you may have, information on testing, the process for submitting patches, your pull request and review process, and any other information considered essential for contributing. GitHub puts it well: From a maintainer's point of view, the document succinctly communicates how best to collaborate. And for a contributor, one quick check of this file verifies their submission follows the maintainer's guidelines.
Easy and well-defined initial contributions
One of the most difficult decisions a new potential contributor likely will have is finding where to start their participation. Telling them to jump right into the issue tracker may be easy, but having a list of small, well-defined tasks can substantially reduce the friction in getting new contributions.
Have a call to action. Tasks such as minor UI issues, translations, and small simple fixes will encourage people to take the time to get familiar with your codebase to see whether participating is a good fit for them (and for you). Once someone has taken the time to delve into your code, taking the next step to submit a minor patch doesn't seem like such a large one. A few patches later and that person may be both willing and able to take on a larger task, such as a more substantial feature request. From there it's possible they will become a long term committer.
Code quality and documentation
Programmers tend to participate in projects that interest them for one reason or other. Another prerequisite for continued participation is working on a codebase that makes sense to them. Writing well-structured code that has quality documentation will help others get up to speed more rapidly and will ensure you don't lose too many contributors in the "getting familiar with your codebase" portion of the process.
Foster initial contributions
Especially for smaller projects, letting patches slip through the cracks can be easy. For new contributors, getting no response, even if it was due to a busy schedule and not poor code quality, is unlikely to lead to further participation. Additionally, although not all contributed code is going to be of acceptable quality, how you reject code in many ways sets the tone for the enter project. Having current contributors who are willing and able to identify and mentor potential contributors in a constructive way is critical here. Snarky hostile responses aren't going to result in higher quality code from a potential contributor, but rather in them contributing to a different project.
Look further than online
With fantastic tools such as GitHub available, it's easy to forget that potential contributors can be found elsewhere as well. Conferences, local user meet ups, and other meatspace options can be terrific resources here and should not be forgotten or overlooked.
The reality is that getting contributors for a new or small open source project isn't easy. Making sure you get the fundamentals correct is critical though. Having clear guidelines on how to participate, easy tasks to get started with, and a welcoming constructive feedback loop will foster the contributions you do get and will help ensure you get consistent sustainable contributors.
3 Comments