Start Contributing to Open Source: Advice From a Maintainer 

If you’re trying to get into tech, you’ll often hear the advice: “Contribute to open source!” Participating in open source is a great way to practice your coding and collaboration skills while adding to your portfolio. Plus, there are lots of businesses built on open-source software, so being familiar with how the ecosystem works and having exposure to working in the community can be an asset in your career.  

But where do you start? What if no one responds to your pull request? For answers to these common questions and more, we talked to Tyler Williams, Lead Software Engineer at WalterPicks and maintainer of the open-source project MobX-State-Tree, which they use for state management in their React Native application. A maintainer is like a project manager who’s responsible for handling a project’s big-picture vision as well as ensuring its day-to-day operations run smoothly.  

Choose a beginner-friendly issue 

You could start by focusing on projects that power the technology you’re most interested in exploring, or those behind software you already use. If you have a dream company you’d love to work for, find out if they’re using any open-source software in their stack and see if you can contribute. Make sure to filter for projects that are actively seeking contributions by checking for GitHub issues labeled “Good First Issue” — this means those issues have been identified as approachable for project newcomers. GoodFirstIssues.com is a handy source for the latest issues tagged with the label.  

Chat with maintainers 

Popular open-source projects may have hundreds (or even thousands) of open issues, and it’s not always clear how to reproduce or otherwise get started on tackling a specific issue. “If you’re not plugged into the core maintainer team, it may be challenging to figure out things like which issues are a priority or if someone is actively working on an issue,” says Tyler. “In many cases, if you can find a Discord or Slack community where the maintainers hang out, you might be able to get their attention or at least read more about how they’re considering these initiatives.”  

If you’re not sure if you have the skills (yet) to work on a particular issue, it’s wise to ask for clarification. Some issues look simple but are hard, and vice versa. Here’s an example of a comment you could leave on the issue or ask in the community: 

I’d love to take on this issue. It looks like I would need to … does that seem right to you? Otherwise feel free to point me in the right direction.  

If this still sounds too daunting, you could focus on issues labeled “first-timers-only”— just like the label says, these are exclusively for brand new open-source contributors and should be very straightforward. The label also signals that the project owner is willing to coach you through your first PR to address the issue. Be ready to follow through: “When people show a good amount of interest, energy, or commitment, I will endeavor to spend synchronous time with them to ensure they can be successful,” says Tyler. 

Explore the project repository 

Many open-source projects have their own, bespoke folder structure, which can make navigating the project repository difficult—especially if you’ve been using a framework with a well-defined folder structure in your personal projects, says Tyler. Take, for example, this simple portfolio template project versus MobX-State-Tree. How do you know where the important files are? It’s worth taking some time to explore the repository and see if you can make sense of what different folders and files contain. Don’t get discouraged if you’re lost. “It’s a responsibility of maintainers to help people figure out the lay of the land,” says Tyler. Once you’ve poked around a bit, asking for help in GitHub discussions or the project’s community can help you get better oriented.  

Fork and clone the project repository 

If you’ve managed to snag a good issue, plan your work, and get your bearings in the project, your next step is to get coding, so you need to get the code on your local machine. Many people are used to cloning a project directly, says Tyler, which works when you work for the company, or if it’s your own project you’re pulling down. “But if you don’t have maintainer permissions on a repository, you won’t be able to push your branch back up from a clone,” Tyler says. 

“Instead, you need to fork the repository to your own account, then clone that locally, and make a PR from your fork over to the origin. This workflow isn’t very intuitive, and it’s not something you usually encounter at your day job.” Build up your confidence with our Git and GitHub course.  

Don’t get discouraged if your pull request isn’t merged right away 

If you believe you’ve fixed the issue, it’s really exciting to push the code up, create the pull request, and submit it. When is it time to celebrate? According to Tyler, most open-source maintainers are volunteers, and those who do it as part of their day jobs probably maintain very active projects with a lot of issues and PRs to review. In either case, it’s tough to know: 

Who will review your pull request? When they will do it  Will they ever do it?

“Some PRs can languish for years,” says Tyler. “It’s a hard problem to solve, and maintainers feel badly about it when it happens. It’s not a reflection of you or your work, it’s just the nature of a highly distributed, mostly-volunteer ecosystem.” (Editor’s note: I personally have had a simple update to a project README file sit for four months before someone merged it in.)  

You can preempt this problem by picking up recent issues in projects that show a lot of activity. If it’s too late for that, and your PR is already gathering dust, don’t get discouraged. You can see who of the maintainers are actively merging code by looking at recently merged PRs, and consider mentioning them on your PR to ask if they can review or suggest someone else.  

Release cycles can delay your code 

Open-source software commonly follows semantic versioning, which specifies rules for what kind of code changes can be published in certain versions, says Tyler. “Not all changes are backwards compatible, which means your code might get approved, or even merged, but not ‘released’ until the project is ready to ship a version that’s compatible with your changes.”  

What this means for you: 

It may take some time before your code gets out there in the wild.  As your PR lingers, you may be asked to rebase your code against an ever-changing main branch. Keep an eye out on your notifications for those requests. It’s always easier to rebase frequently, rather than try and manage a rebase over the course of months of changes. 

You can learn more GitHub best practices in this free Codecademy course. 

You can (and should) highlight OSS contributions in your portfolio 

Plenty of open-source contributors do so simply because they enjoy it, but your contributions can also show your skills to potential employers. “LinkedIn has a really nice integration with GitHub now,” says Tyler. “If you update your LinkedIn projects section, you can usually import a lot of data directly with a GitHub link.”  

If you want to draw attention to a specific contribution, you can include it in a portfolio website or write a blog post explaining what issue you fixed and how you went about it. Writing about your contributions gives you a chance to share more context about why you chose to approach the problem in a certain way (great practice for technical interviews).  

Ready to take the plunge? “MobX-State-Tree is a great place to start contributing, because we have a small, but active community,” Tyler says. “The maintainers are very accessible and love to coach folks through their first or early open-source contributions.” Brush up on your open-source terms with Codecademy’s free Introduction to Open Source course.