Getting started if you are completely new.
I am pretty open with my enthusiasm for open-source software (OSS) and, as a result, often receive questions from others on how they can get started contributing to projects. I’ve received enough questions to notice some trends in where people are starting from and what kind of problems they’re having. As such, I wanted to write this article to help anyone who is wanting to get started contributing to OSS projects, because getting started is the hardest part! To begin, let’s briefly talk about the advantages of contributing to OSS.
Contribute to the Community
One of the main reasons I like contributing to OSS projects is because I generally like being helpful. I enjoy fixing bugs that trip people up or adding features that help people get their work done more efficiently.
I also like contributing specifically to my field. As a PhD student and possibly future scientist, I have a vested interest in the quality of the software in my field–specifically, structural bioinformatics. I use several tools in this field and often find areas that can be improved, both for myself and others. As an example, consider this minor documentation change I added to the Biopython documentation.
This is admittedly a very small change, however I updated documentation that was incorrect because on two separate occasions, I landed on this page while trying to do something and got errors by following the provided example. In the future when I (or anyone else) arrive at this page, they will not have to go through the trouble of debugging the examples.
Develop or Hone new Skills
This is one of the primary direct benefits of contributing to OSS projects–the chance to work on significant projects with technologies you’re interested in working with. This can be fun for you and it can also help provide “proof” that you know how to work with certain technologies even though your work life might not provide you with exposure to them.
One personal example, doing this PR adding support for some operators to the autowrap project gave me the chance to learn a lot about Cython and work with a small bit of C++. Another example from the Biopython ecosystem is this PR updating the documentation-deployment process. This work was one of my first exposures to working with CI/CD systems, a topic I feel I excel in now. Being able to deliver this feature on a project that impacts many people was a very valuable and fun learning experience.
Develop a Name for Yourself
Another benefit to contributing to OSS projects is making a name for yourself in a certain area. For example, many of the frequent contributors to the CPython project become Python fellows or contributing members. This designation signals a kind of proven competence. Anyone who regularly contributes to CPython must be either an expert in Python, C, or both, right?
Being known as a helpful presence in some software community will garner goodwill for yourself, and that goodwill can go a long way.
Setting up your GitHub Profile
Now that we know why we want to contribute to open-source software, lets finally get to how. The very first thing you need to do, if you haven’t already, is set up your GitHub account. You can also additionally set up a GitLab account if you know the project you want to which you want to contribute is hosted there.
There’s really no beating the official documentation from GitHub on setting up your account, so I wont’ write out all the steps here. Follow the steps in that link so you can start contributing.
If you’re new to Git, feel free to check out my professional git series (part 1, part 2, part 3), which should teach you all you’ll need to know about working with Git and contributing to OSS.
Picking a Project
Perhaps the most important step is the first: picking a project to contribute to. This is where I see a lot of aspiring OSS contributors quit before they even start, but it’s not their fault! Often, the advice to people just finishing learning the basics is to find an OSS project in that language and “just start contributing!” Personally, I find this advice unhelpful because it can send inexperienced learners towards complex projects they’re likely not ready for.
As an example, when I first learned Python, someone suggested that I start contributing to Django. Django is a web development framework for Python and it’s incredibly popular, but it was way over my head at the time as I had just finished an introductory level book on Python development and had absolutely no experience. I didn’t even know how to use Django, let alone contribute to it. My inability to even figure out how to get Django running locally put me off OSS development for a long time. My point here is, don’t just browse GitHub and start trying to make sense of the most popular project written in your language of choice, find a project that really interests you.
I believe the trick to being a frequent contributor to a project is caring enough about it to stick with it. You will likely never make meaningful contributions to a project in just a few hours of work, you will likely spend days or weeks on fixing bugs and adding features; and that’s after you’ve spent a bunch of time figuring out how the software works as is. So, you need to find a project that you are interested in enough to work on for extended periods of time.
Caring about a project requires one of two things: investment in the problem being solved by the project, or an interest in the work itself. To illustrate the first point, consider Biopython. Most of the contributors to that project are bioinformatics researchers. For the second point, consider the fact that many contributors to open source programming languages (like CPython, Rust, and more) are language enthusiasts that contribute because they like the kinds of challenges language design presents.
Since finding a project to contribute to is so important, take your time doing it. There’s no reason you have to decide today what project you want to contribute to. Browse different topics in GitHub and see what sparks your interest the most.
Figuring out the Development Workflow
Once you’ve found a project to contribute to, the next step is figuring out how the project’s community builds their software. If you want to contribute to their work, you have to respect their process. Often, this will be explained in a file called CONTRIBUTING.md or something similar.
The kinds of things you want to look out for is how the community prefers to receive pull requests. For some, maintainers want all pull requests to be associated with a corresponding GitHub issue. For example, this pull request to the OBOFoundry home page removes a page from their website, but I only made this PR because one of the maintainers created issue 2590 in the “Issues” tab asking for that page to be removed.
The most common workflow I’ve encountered involves forking the main repository into your own profile, creating a branch based on some issue, making your changes, writing tests for the changes, and making a pull request to the main repo. Development workflows frequently include a CI pipeline with tests and checks your changes have to pass.
More often than not, the final step in the development workflow is a review process. This typically includes a project maintainer looking over your changes and making sure you’ve solved the problem and that your code code is in line with project’s standards. This is usually a back-and-forth process, especially for your first contribution, in which a reviewer may ask you for changes multiple times. Don’t get discouraged or take these reviews personally! This is someone else’s project after all, you are a guest (though a helpful one!).
Project’s sometimes have guidelines for tagging reviewers (mentioning their GitHub username so they’re notified that you’re awaiting their review) so your work can move forward. Don’t get impatient and tag reviewers constantly, but don’t be too shy to bump your PR if the guidelines allow for it.
The main takeaway here is to set yourself up to be a productive member of the project community by adhering to their process and not just diving in headfirst writing code and making changes that no one wants. Remember, software engineering is a collaborative process, even (or especially!) in open source development.
Conclusion
Contributing to OSS can be beneficial to you, project maintainers, and the general public alike. It can also be a lot of fun! Remember to carefully choose the projects you want to contribute to and respect the development process. Feel free to reach out if you have any questions.