Although some people think open source projects only need programmers—and experienced ones, at that— open source project needs go beyond the ability to write code. They also require testing, technical support, documentation, marketing, and more. And contributing to projects also is a great way to improve technical skills and connect with people who share similar interests. One barrier to participating in open source projects is not knowing how to join and get started. In this article, I'll explain how to start contributing to an open source project.
Con Kolivas, an Australian anesthesiologist, developed his own task scheduler for the Linux kernel because the one that existed was adapted for servers and did poorly with user tasks. Alexey Kuznetsov, a theoretical physicist, became a Linux hacker and a system programmer. Peter Semiletov, an IT journalist, has been developing his open source text editor, TEA, for a decade. Lesya Novaselskaya, who studied to become an autopsist, now takes part in testing an open source project. There are many more examples like these of individuals united by pursuing their interests in open source projects, while gaining experience and having fun.
Write new code
You don’t have to be an expert to start working on a project. If you know the programming language used in the project, create a new feature and offer it to the project team. Some projects are easier on novices, and others are not. Developers in novice-friendly projects, veterans and otherwise, can help you iron out the code. In any case, if your code can help other people, your contribution won’t go unnoticed.
Each project has specific internal processes with which you need to familiarize yourself before you start contributing. For example, in PostgreSQL, all processes are strictly regulated; changes to the code are sent as patches to all primary developers for a thorough study. Other projects, like Parrot, allow commits to the master branch. If the project employs GitHub, pull requests are probably involved. In other words, remember that no two projects are alike.
Each time you change the code, have in mind that you’re part of a team, and do your best to have your coding style fit the one adopted in the project. The part of the code you add or edit must not stick out from the rest. You may have your own preferences in terms of code styling, but what you commit must follow the common rules. Otherwise, it’s like saying, “I don’t like your style. Mine is better, so do it like I do.”
Prioritize defects
Code is without a doubt the basis of any project; however, writing it is not the only thing you can do to participate. Technical support is often neglected because everyone is focused on adding new features and fixing bugs. But tech support is a great place for a new contributor to start.
For example, OpenVZ has a completely open bug tracker at bugs.openvz.org. The bug tracker collects all known issues—fixed and open—that the nearly decade-old project ever had. A bug tracker is one way of establishing communication between developers and users. Continuous work on current requests provides a great opportunity to contribute. Have in mind that you may need certain access rights provided by a project manager (often given on a meritocratic basis).
Test intermediate versions
Testers interested in working on open source software may have no idea where to start. And most open source projects, commercial or not, typically don't have enough testers. Finding and sorting bugs can save time that developers spend locating issues.
If a user comments something like, “The software doesn’t work when I do these steps,” testers can examine the issue and why it happens, before sending it on to developers. Testers determine whether the problem is reproducible (and what steps are required), and what triggers the behavior in specific environments. Even if you don’t know the actual reason behind a bug, an effort to narrow down the list of possible reasons may greatly help fix it. No matter what details you as a tester manage to find, add them to the bug for everyone to see.
In my experience, open source projects typically lack resources to test new features thoroughly. So before any serious changes are introduced to the master branch, the project attempts to involve as many testers as possible by issuing a call for testing. No project possesses the amount of hardware or software configurations rivaling those available to its entire community. Because of that, OpenBSD and OpenVZ, for example, announce new features and ask for help testing them.
You can help developers test how software works on a different platforms. Your feedback will be all the more valuable if you use some kind of nonstandard hardware. If you confirm that the build works even in such an environment, you make it much easier for the project managers to assess project’s current release state.
Create tests
Most projects use software suites for code testing and those usually allow addition of custom tests. Use tools like LCOV for C to locate parts of the source code, which cannot be checked by preset tests. Then create custom tests to have these parts of code covered, as well.
Fix bugs and add features
A patch with a bug fix or a new feature is a classic way of involving people into an open source project. James Bottomley, CTO of Odin, also recommends fixing bugs and adding features to people who are willing, but do not knowing how to join a Linux project. As an example, he usually cites a case when the functionality he needed from a SIP client on Android was missing, so he created a patch and send it to the SIPdroid project.
When you create new features, adding a test for the code you’ve changed is also good. Some projects require that all bug fixes are accompanied with tests. Take notes while you look into unknown code. Even if you can’t fix the bug, describe what you’ve found out in the ticket. Doing so will help the people who will deal with the bugs after you.
Help maintain project infrastructure
Does DevOps interest you? Good DevOps engineers are hard to find (I can say this from my own experience). A DevOps engineer can improve their skills in projects with open infrastructure development, such as Wikipedia and the Fedora projects. OpenVZ also is moving in this direction. Setting up continuous integration for project components, creating component packages for Linux distributions, and automatic configuration of developer environments are all DevOps tasks.
Write and localize documentation
Maintaining documentation is an important part of any project that is often neglected. Moreover, often documentation is written from a perspective of someone already familiar with the software, instead of that of a new user or novice. Reading such documentation, you might get the feeling that you’re expected to know how the software works already. Often the perspective of a new user finds shortcomings in the current documentation that went unnoticed by project contributors. Besides, documentation in rapidly evolving projects becomes obsolete fast, so it needs to be updated regularly.
Thinking that documentation is unimportant is a mistake. All contributions to an open source project matter. For example, Ingo Schwarze, an OpenBSD developer who also worked at CERN, created mandoc, which is now used to format manual pages not only in OpenBSD, but also in FreeBSD, NetBSD, and DragonFlyBSD. He also sorted out the formatting of existing man pages in the project. (For more details, read his BSDCan 2015 talk (PDF).) So if you’re interested in doing something important for the project, help improve its documentation.
Help community members
For a project to evolve, answering questions, those coming from new users in particular, is crucial. Time spent on this won’t be wasted, even if the answer is in the documentation already. As a result, you could end up with a grateful new, active contributor. Everyone has to start somewhere, and any project needs an inflow of people to advance.
Promote projects
If you have a blog, share stories about your experience in open source projects. Tell your readers about issues you stumbled upon while using open source software and how you solved them. This way you will kill two birds with one stone: You drive attention to the project, and you create a knowledge base for future contributors. A blog describing your technical achievements, research, and expertise is also a great way of sharing actual experience gained while contributing to the project, as well as solutions you found to technical issues (which might be useful if you look for new work opportunities). Many projects employ contributor blog post aggregators, often called planets, including:
- OpenVZ: https://planet.openvz.org/
- Linux kernel: http://planet.kernel.org/
- Perl: http://planet.perl.org/
- freedesktop: http://planet.freedesktop.org/
- Gnome: http://planet.gnome.org/
- Debian: http://planet.debian.net/
Posts from enthusiasts can be interesting to read, even the writer isn't formally contributing to the project.
Create design
Design is where many open source projects fail miserably. Boring websites and bland logos haunt projects, simply because contributors are focused on how the project should work, not also how it should look. So input from designers is welcome. Members of the StackExchange community tried answering questions like, “How can graphic designers contribute to open source projects?” and “How to motivate a graphic designer to join an open source project?,” but their views diverged.
Conclusion
If you want to contribute to an open source project, look for tasks that interest you and help improve the project. The process for contributing varies depending on the project, so you may want to start by reading pages dedicated to helping potential contributors join, for example:
The fact that a project has a page like this means it’s open for contributions.
Comments are closed.