How to pick an open source project to contribute to

Open source powers many of the tools that we rely on daily for our work. As developers, we have the privilege of being able to read, learn, and build from thousands of codebases at our fingertips. What better way to give back to the community that creates the software that powers our world than to contribute to those very same tools?

Contributing to the open source community can be daunting for a seasoned developer, let alone a novice. One problem I’ve had as an early-career developer has been figuring out how to find a project that aligns with my interests as well as the skills that I want to practice. One great resource I've found very helpful with finding answers to my questions is the book Forge Your Future with Open Source, by VM Brasseur.

In this article, I will show you what I’ve learned from VM Brasseur's book about what to consider when I’m determining what open source projects to work on.

Determine your goals

First, start by sitting down and writing a list of goals - what you hope to accomplish through contributing to an open source project. If any of your goals are vague, sit with that goal and flesh it out until it is specific and actionable. The more specific your goals are, it is easier to go back and determine whether you’ve accomplished it.

Please note, that these skills don’t necessarily have to be technical skills. Open source projects need all kinds of skills, from documentation, to graphic design, to QA and testing, to project management.

Here are some questions to help you determine your goals for your potential open source project:

  1. What skills do I have to contribute to a project?
  2. What skills do I want to contribute to a project?
  3. What are my interests/hobbies?
  4. How much time am I willing to commit to a project?

When I decided I wanted to work on an open source project, I knew I wanted to practice building new features on a full-stack Ruby on Rails application. I wanted to work on both my JavaScript and Ruby skills. I wanted to get familiar with a codebase and work on it long-term.

Finding potential projects

Finding a project doesn’t have to be a chore. If you don’t already know of a tool that you use that is open source and need some love and care, see if your company has some open source projects you can contribute to. Luckily I work for OmbuLabs (who is currently hiring!), a company that values contributing to open source projects. We consider it one way that we can share our knowledge with others, which is part of our core value of being Open by Default. My teammates and I are all in charge of maintaining our open source projects, and we get paid to work on open source projects. One open source project I work on is Points, OmbuLab’s open source blind estimation software, because that is the software that I use the most daily at work.

If you don’t have the luck of being able to work on open source through your employer (or want to practice different skills from what you focus on at work), here are some good places to look for interesting projects:

By technology:

  • Up for Grabs - You can search for projects by name, by label, or by tag. A tag can be the language that the project uses.
  • Good First Issues - You can browse by language

Don’t discount finding projects on your language’s subreddit - there are occasionally calls for maintainers for projects posted on on r/ruby and r/rails.

By interest:

You can also find projects by interest. The best way to do this is to first figure out what interests you, then searching the Internet (or GitHub) for open source projects related to your interest. Sometimes you will be able to find special interest groups that work on open source projects. For example, if you live in the United States and you are interested in civic engagement, you can work on open source projects that benefit your community through Code for America. If you are interested in volunteering with non-profits but are looking for Ruby specific projects, there is Ruby For Good. If you are interested in working with other women who code, you can contribute to the Women Who Code contributors team.

Once you have a list of potential projects that you can contribute to, now you can start narrowing down your list of choices. Good potential projects will fit into the goals that you determined above, as well as have the following characteristics:

  • An open source license
  • Signs of active development
  • Guidelines related to contributor activity

Open source licenses and you

Open source licenses might be easy to miss, but don’t neglect to look at this very important part of an open source project. Open source licenses dictate what you can and can’t do with a project. It’s worth taking a look at what license your potential project is using, if it has one, before you start contributing to it.

While there are many different open source licenses to choose from, there are two basic types of open source licenses: copyleft and permissive. Both types of licenses require that anyone who works with these licensed projects must be able to view, modify, and share the source of the work. But the two licenses differ when it comes to what the user can do with the work, and whether the derivative work should be under the same terms, or different terms than the original work.

Copyleft: A copyleft license protects a derivative work from being relicensed under a more restrictive license. Examples of a copyleft license include: The GNU Public License (GPL), the GNU Lesser General Public License (LGPL) and the Mozilla Public License.

Permissive: A permissive license allows someone who makes a derivative work to change the license of the derivative work. It also allows a creator to use the work released under a permissive license in a proprietary work, and the derivative can remain proprietary. A permissive license does not force the creator of a derivative work to release the derivative work under a free or open source license. Two examples of popular permissive licenses are the Apache License and the MIT License.

Determining signs of active development

Next, take a moment to examine your potential project’s history to determine whether the project is active, both in terms of conversation and development activity. Some questions to guide you in determining activity levels are:

  • Do people who ask questions receive answers?
  • Is the project friendly to current contributors?
  • What is the tone of the people who work on the project (i.e. are people friendly or does communication seem cold and standoffish?)

Guidelines related to contributor activity

Finally, determine whether your potential project has any guidelines in place currently for contributors. This is not required, but it can help you figure out whether the project is set up for other contributors in mind, and will help you note whether your first contribution will go smoothly or whether you might have some bumps in the road. Some questions to guide you are:

  • Is there information on setting up the project?
  • Are there issues that you can start contributing to?

Conclusion

Once you have considered the above points, now it’s time for you to sort your potential projects. When you've whittled your group of projects down to a few finalists, you can test the waters for each by picking an issue and creating a pull request.

I hope this guide gives you a better idea of what to consider in a potential open source project. These questions are not set in stone - you can refer to them regularly to determine whether you're going on the right path for your goals.