If you’ve never contributed to open source (and don’t know how to get started), here’s your step-by-step guide.
Here’s What We’re Going To Cover:
- Removing Blockers to You Actually Contributing
- Picking a Project That’s Right For You
- How To Prep For Your First Contribution
- How To Practice On a Real Project With Real Issues – Risk-Free
- Doing The Pull Request
- Handling Criticism
- Next Steps – Use Open Source to Get New Jobs
You’ve heard that contributing to open source is great for your career.
You can make your GitHub account portable proof that you have what’s needed to succeed:
- You have technical skills
- You have people skills
Besides that, it feels great.
But (and here’s the problem) it’s hard to get started. Open-source has its own foreign language. Too, if you’re not familiar with git version control, it’s even worse.
If you don’t know how to use the git command line, fix that now. It’s not hard. Here are two resources you need:
Open-source needs you, and in a way, you need open-source. I’ve already mentioned it, but the satisfaction isn’t all. Keep at it. Doing so builds true job security because you build a reputation. That’s the power of an active commit history.
Removing Blockers to You Actually Contributing
Not knowing where to start isn’t your fault, and we’ll get you unstuck now.
Any of these sound familiar?
- How or where do I get started?
- I don’t see many beginner issues.
- Lots of projects look too intimidating or complex.
- What if I commit to a bug fix and then can’t do it?
- What actually is the step-by-step process for a contribution?
Let’s address each one.
How or where do I get started?
Keep reading. I address this step-by-step.
I don’t see many beginner issues.
You can ignore this concern. It’s not real. Suspend your disbelief if you need to, but when you follow the plan I’d laid out below, this doesn’t matter.
Lots of projects look too intimidating or complex.
It’s true. Some issues will be beyond you. Yet, most are not. They only look like that as you haven’t dug into the project and run the code and learned how it works. Keep reading, I address this too.
What if I commit to a bug fix and then can’t do it? You contact the project maintainer and tell them you will not be working on that bug fix anymore. The project maintainer will be thankful. You didn’t disappear, and they can now have someone else look at that issue. No problem.
What actually is the step-by-step process for a contribution?
Now, for that step-by-step instruction…
Picking a Project That’s Right For You
I’m sure you’ve heard the standard advice, “work on the open-source projects you already use.” Not the most useful advice.
Instead search google for “top open source projects in [language or framework]”. Don’t overthink what language to use. Go with what you know best.
Look at bigger projects with clear docs about contributing and working with them. If the project maintainers aren’t active and open to beginners, it’s not for you.
If you pick a project that is lacking documentation about contributing, move on. Pick a different project.
How To Prep For Your First Contribution
Set up your development environment, if you haven’t. (Get Visual Studio for working on DotNet projects; get Eclipse for working on Java, etc.)
Next, fork the repo to your GitHub account.
Then clone it down to your development machine.
Next, look at the Contributing.md file and find the getting started doc.
What if you don’t find one?
Double check, but if you don’t find one, you have found your first contribution opportunity. You should make a “getting started” doc for the project. Side note: most projects need help with documentation in some capacity.
First, ask the maintainer if he or she wants the documentation you want to add. The best way to do that is to open an issue stating that there isn’t a getting started doc.
If the contributor agrees that this is something that would be of value, boom! Dig into the code, debug through it, document what you do, and submit a pull request with the doc.
But I’m getting ahead of myself.
So, you’ve got the code. And now you know how to use it. How do you feel?
Feeling confident? Jump in, and go find an open issue. Start chatting with the maintainers about taking it, and start coding.
But what if you’re not feeling quite ready yet?
How To Practice On a Real Project With Real Issues – Risk-Free
No worries if you’re not quite ready yet. Here’s how to bootstrap your own self-confidence right now.
Look at the closed issues on the project you’ve chosen.
Then, pull the code commit right before the fix checkin. To do that:
- Click the link of the commit that fixed the bug.
- Copy the first 6 letters of the commit SHA
- Go to the list of all commits
- Find the commit in the list, and copy the SHA of the commit just before the bug fix
- Execute the git checkout command with that shaw. You’ll now have the code pre bug fix, and you are ready to do your own fix. (see video below)
Repo the bug per the issue yourself. (If you can’t, select a different closed issue.)
Then, practice fixing the bug.
No pressure. You are practicing. Even if you end up over your head (not likely), it doesn’t matter. You can look at the solution to see how the fix committer coded the fix, if you want. (The commit to the master branch that fixed the issue.)
Besides, you can do this kind of practice as much as you’d like.
And now, you are ready.
Doing The Pull Request
The steps are the same as above.
- Fork the repo to your GitHub account (because you don’t have permission to make a branch on their GitHub account)
- Clone the repo to your machine
- Take an open issue or open a new issue (if you are contributing something that isn’t a bug fix)
- Make a branch for your work
- At the same time, you are chatting back and forth with the project maintainer about the work you are doing.
- Submit the pull request. For a walk through with screenshots, have a look here: mechanics of making a pull request
When the contributor accepts your pull request, congrats! You are apart of the open source community!
Not everything is perfect in the OSS world. You are dealing with normal humans who are volunteers.
There will be criticism. By making a pull request, you invite public inspection. Not everyone is going to love what you’ve put out there. The good news is that some feedback is useful, and you’ll grow as a coder. Yet, some will be toxic, and you need to be ready and understand that upfront.
In a similar vein, you might never get a response to your pull request. This is far, far less likely on a mature, community-maintained project. That’s why I steered you towards the larger projects above.
But enough of the negative. Let’s look at the big picture.
Next Steps – Use Open Source to Get New Jobs
Want to build up a reputation?
Making a single contribution and nothing more is no good.
Very sporadic contributions will not work for you either.
Instead focus on one tech stack and be active with contributions in that stack to become known.
You may want to even start your own open source project too.
The key here is simple. Be consistent. Stay on it. Keep making pull requests. Develop deeper relationships with project maintainers. It’s that simple.
When you do, you’ll begin to notice two things:
One, recruiters will contact you. Nothing is new there. Recruiters contact developers all the time. But this time it will be because of your GitHub profile (not because of your LinkedIn account). That makes these are higher quality connections as they already can see what you can do.
Two, if you go looking for a new job, you can point to your GitHub account. Your profile will prove you work hard. It’ll prove you know your stuff, and you are a team player (due to getting all those pull requests accepted). Boom! Money.