Ben Pfaff, Researcher, VMware
People new to open source often ask how they can get involved. One good way to start out is by addressing a problem in some open source software that you already use. For example, from time to time I find myself using a new piece of open source software. As I work through the instructions for installing and building it, I often notice some little issue, which might be as small as a typo in the instructions. To help the next person have a better experience, I try to contribute back a fix or, if I’m not able to do that, report the bug to the authors. New users of a piece of software are the ones most able to find this kind of bug, since long-time users and developers rarely re-read the instructions and can easily miss problems.
The way that one contributes to open source software varies widely from one project to another.
Most open source software is maintained in a version control system, with Git the most popular and GitHub the most popular hosting platform, and GitHub “pull requests” the most common way to propose contributions. Most projects have their own policies on how to contribute, often in a file named CONTRIBUTING. It’s best to carefully read this policy before submitting your contribution, so that your proposal doesn’t get rejected out of hand because it violates some rule, which never feels good.
These days, most projects require some legal formalities to accept contributions. The Developer Certificate of Origin (DCO) is the simplest. It consists of a single line of text at the end of your commit message that certifies that you are willing and able to make your contribution under the project’s license. Other projects require signing a legal document called a Contributor License Agreement (CLA), either online or on hard-copy. Some projects, mainly those whose code is controlled by a charitable foundation, require the developer to assign copyright to the project’s owner. In any case, it is important to understand what rights your employer has to your contribution, if any.
Some people assume that only developers can usefully contribute to open source software, but this is true only in a very narrow sense. Non-developers can write and edit documentation, test software, report and triage bugs and verify their fixes, build and maintain websites and wikis, and help answer users’ questions about the software. Depending on their skills, they may also be able to build distributions of the software for users to install. The latter is valuable for builds on systems that the software’s main developers do not use, which is especially important since open source software developers often use Linux-based systems even though many of their users do not.
The final entry in this series will talk about how to start a new open source project.