• Why Contribute?
• Determining Where and What to Contribute
• Making the Contribution
• Make an attempt before requesting too much feedback on your implementation
• It’s going to take longer than you expect
• Be Courteous
• Keep Going

This article is cross-published on Medium.

Being relatively new to the process of contributing to Open Source Software (OSS), I thought it would be helpful to others who are considering becoming contributors to share my experiences. This article will provide insight on why you might want to do contribute, what you might expect the process to be like, and how you can make your first contribution.

Why Contribute?

Contributing to open source is rewarding in a variety of ways. For many, there is a sense of satisfaction in creating something useful, and with sharing it with others. But there are less altruistic reasons to contribute to OSS as well, and the motivation doesn’t diminish the value of the contribution. Fixing a bug or adding a feature that would benefit a library you are currently using can be a way to add functionality that you need, while also providing value to the broader community. Additionally, contributing to OSS can signal your level of expertise with a library. With regular, significant contributions over time, you can establish yourself as an expert with a library, and perhaps become a part of the formal governance structure as a core developer, maintainer, etc. All or nearly all major companies rely on open source software, and many of them employ developers of open source projects they care about.

Determining Where and What to Contribute

For those seeking to contribute to open source for the first time, there are a few strategies which can help you get the most out of contributing. First, choose a well-established project that you already use. By choosing a package that you already use, you’ll jump start your ability to contribute. Learning a new code base is not trivial, and the insight from having used a library previously is valuable when jumping in for the first time. By choosing a library you’re familiar with, you’ll be able to contribute more effectively with less effort. You’ll also improve your mastery of a library that you already use.

Contributing to well established projects as a first-time contributor is useful as well-established projects tend to have better documentation on how and where to contribute. These documents make it easier for you to be effective. Search around for something along the lines of “Development Guidelines” within the project’s website and/or repository. This documentation will contain code style standards, channels of communication to communicate with the project’s other developers, best practices, etc. If you want your contribution to get accepted, you’ll need to follow these guidelines.

As far as determining what to contribute, if you have a feature you’d like to add or bug you’d like to fix, then open an issue, and get some feedback from the maintainers. For feature requests, other developers will help determine if the feature is within the scope of the project, and possibly give guidance on how it might be implemented. If you aren’t sure what you’d like to commit, check out the project’s issues. This is a list of identified fixes and enhancements that the community has identified. Many well-established projects have specific labels such as “good first issue” which have been identified by the core developers as an approachable issue to start with.

Making the Contribution

When you’ve found what you’d like to contribute, the next steps are to fork the repository, make your changes, and then submit a pull request. This article doesn’t cover the mechanics of those steps. If you haven’t done them before, then a quick Google or YouTube search will fill you in. There a few things to keep in mind as you make your contribution.

Make an attempt before requesting too much feedback on your implementation

It can seem easier to ask many questions of the core developers before starting on your contribution. Some questions can be useful initially, but it’s usually better to jump in and actually attempt to work on the issue at hand before seeking too much feedback. Once you’ve coded at least a proof of concept addressing the issue, you can submit a PR and seek feedback. The core developers and maintainers are busy, and I’ve found they’re much more willing to give feedback once you’ve shown willingness to invest some time into creating and submitting something. It’s also much easier for them to critique code than it is to critique an written explanation of how you plan to proceed. Making and submitting your proof of concept attempt before seeking too much feedback will help ensure you get useful feedback.

It’s going to take longer than you expect

Making your first contribution to open source is almost certainly going to take longer than you expect, and there are a few reasons for that. First, even if the user facing documentation is complete, the internal documentation is often much less so. This can make it difficult to understand the implementation details that you might need to modify or use for your contribution. The debugger in a good IDE is your friend here for particularly tricky sections of code, but don’t get too bogged down. While understanding all the implementation details is ideal, it’s often sufficient to merely understand internal functions at a high level. Additionally, you may need to learn some of the libraries the library you are contributing to depends on. This can take some time if you aren’t familiar with them.

Finally, you’ll likely need to make several rounds of edits as you get feedback from the core developers. Although it might seem clear how to proceed, there may exist a better way to implement what you’ve done. You may have missed an edge case that wasn’t apparent to you. Whatever the reason, you’ll likely need major edits for your first contribution. However, you’ll also improve your understanding with each edit, and produce a higher quality result as well.

Be Courteous

Finally, be courteous as you go through this process. Remember that many of the core developers are volunteers. Being rude is not going to help anyone get what they want. It may take a few days for the core developers to review your pull request. If you’ve waited a few days and haven’t heard anything, politely reach out again and request a review so that your efforts don’t go to waste. In my limited experience, courtesy has been the norm. Help keep it that way.

Keep Going

After your pull request is successfully merged, congratulations! You’ve given back to the community, made a valuable contribution, and learned something in the process. After you’ve overcome this hurdle, keep going. Know that your next contribution will be easier as you leverage what you’ve learned. With consistent effort, you can continue to make valuable contributions, increase your overall skill, and improve your mastery of that library.