This article was written by Vincent Russo, the author of Educative’s beloved course Data Structures and Algorithms in Python. Vincent has a BS, MS, and Ph.D. in computer science and is a full-time security software developer and runs LucidProgramming, a YouTube channel to help individuals improve their software skills and value as developers.
Vincent is an experience Python developer and has extensive experiences with natural language processing, data structures, web scraping, and more.
Perhaps we are all driven by the desire to contribute to something bigger than ourselves. To me, contributing to open source software, software that is used and built by collections of humans, is a way to fulfill that desire.
Contributing to an open source software project can be a rewarding experience in and of itself. It can be a way to demonstrate your software sophistication and to share your experience. Alternatively, it can be a gateway to opportunity.
Whether it’s leveling up your own software skills through the experience or demonstrating your value to a company for future employment, contributing to open-source software has a multitude of benefits.
In this post we are going to break down some of the essential parts of how to effectively contribute to an open source Python project. Many of these tips and pieces of advice are applicable to contributing to open source projects in general (and not limited to Python).
Today we will cover:
A note on this article:
This post is quite broad in scope in the sense that contributing to open source is a large subject that has many moving pieces depending on your skills, interest, domain, etc. In order to reduce that scope, I will assume the reader is approaching this post as a beginner.
That is, the reader should be a Python programmer who has an interest in contributing to open-source software, but perhaps has not taken the time to do so. The motivations and specific domain can vary, but the programming language and level of the reader should more-or-less align with that description.
If you are completely new to Git and GitHub, I recommend reading the article Git and GitHub in a Nutshell: Definitive tutorial for beginners before continuing here.
This is going to be largely dependent on your own and presently existing set of interests and skills. For instance, if you’re a physics student who enjoys a certain area of astronomy, perhaps you would search on GitHub for existing open source software projects that cover this niche.
GitHub has certain repositories with the “awesome-projects” badge that serve as a collection of open-source projects pertaining to a certain category. For instance, here is the “awesome-projects” repository for the subject of astronomy.
This curated list of projects aggregates not just open-source astronomy software but also entities like blogs, datasets, etc. Under the Codes section, we see a list of astronomy projects categorized by astronomical projects focusing on certain sub-fields.
For instance there are general purpose projects, projects that focus on spectroscopy, projects that serve as tools for visualizing astronomical data, etc. An added benefit for the purpose of this article is that the majority of these projects are Python.
Again, depending on your specific inclinations and domain knowledge, the specific open-source projects you stumble upon will vary, but the process for perusing through the existing catalog of options will remain consistent. The “awesome-projects” badge is given to many other projects in other domains, and it’s worth checking out the other projects on GitHub that have this badge.
These are all organized on the primary “awesome-projects” repository and have projects under a variety of other categories.
Once you find a project that aligns with your interests and skills, the next step is to get a sense as to how large and how active the project is.
A good way to get a sense of the pulse of the codebase is to look at the right-most column of the project. This gives an indication as to when certain files were last updated.
Let’s look at an example of an inactive project. Note that the last time most of these files were modified was 4 years ago. This is a project that perhaps at one time was more active, but is currently either in a stable enough place to not require updates or is a project that may have been abandoned or replaced by another project.
Alternatively, here is an example of a more active project. Note that some of
the files have not been updated. This is common, especially for certain files
that are not expected to change drastically over the course of the project lifespan like the
However there are many files in this repository that indicate that the last time they were modified was either 4 days ago or 9 days ago. So, it seems as if the pulse of this project is a bit more active and perhaps more suitable to contributing to.
While it’s certainly fine to take an inactive project and build upon it with your own features and extensions, it can serve a benefit to a newcomer to be part of an active community.
Once you’ve found a suitable project that is of interest to you and ideally is somewhat actively maintained, perusing the source code and looking through the project structure can be a good way to see the intent, style, and other attributes of the existing project.
Depending on the size of the project, this can be more or less involved task, but the “meat” of the project can usually be isolated to just a few spots. Spending your time here and reading through the source code like you’re reading this article can be an insightful and surprisingly enjoyable task.
Make yourself a cup of strong coffee and do some reading!
The issues tab contains known bugs as well as feature and enhancement requests. Certain projects will also tag certain bugs or features with specific labels indicating that they would be an ideal “first PR (pull request)”.
These tasks are usually considered to be low hanging fruit that serve as a good way to ramp up your familiarity with the way in which the project is structured. If no such issues exist, another tact would be to attempt to use the open source project yourself.
If you notice some feature that is lacking or something that could be enhanced or made more efficient, you can propose this to the project admins in the issues tab. Depending on how active the project is and how responsive the admins are, the response time can vary quite a lot, so it’s a good idea to temper your expectations on the schedules of others.
When you find a suitable issue via the issues tab, or, decide to tackle an issue that you found to be reasonable yourself, you can move onto the next step.
Once you’ve isolated the task you want to contribute, the next step is to submit your code and make a pull request to the project to incorporate your code into the master branch.
Before doing so, it’s typically a good idea to see if the project has any contributing guidelines. These guidelines typically include things like code style to maintain in your branch and what information to include in your pull request. If such a template exists, ensure you abide by it.
Once your local branch to the project is at a point where it implements the feature or solves the issue, it’s time to make a pull request.
You can either make a pull request via the command line or through GitHub. As this is a topic onto itself and is well beyond the scope and intent of this post, more information about how one should make a pull request can be found on the official documentation page for GitHub.
Once you have submitted your pull request, it’s up to the project maintainer or maintainers to review your submission. Depending on the scope of the task, the scrutiny of the project maintainers, etc., this can take a bit of back-and-forth discussion.
This perhaps should go without saying, but throughout this back-and-forth review process, it is important to dissociate yourself from the code you submitted. Any criticisms or suggested changes are (or at least should be) delivered to you in a constructive and helpful manner. You should respond to these in turn with professionalism. After all, the shared goal is to work together to enhance the existing code to improve.
Once the reviewers are satisfied with your code and any follow-up changes, they will typically merge it into the master branch of the project.
Congratulations! You’ve hopefully used this process to contribute your unique set of skills and knowledge to make the world just a little bit brighter. Or, perhaps you dove in head-first into making your first pull request for what will be an interesting career path ahead.
In any case, welcome to the world of open-source software development!
Join a community of 270,000 monthly readers. A free, bi-monthly email with a roundup of Educative's top articles and coding tips.