GIT WORKFLOWS / LESSON 04
Contributing to Open Source.
Making your first open source contribution
Loading the lesson…
Loading activities…
Browse lessons
GIT WORKFLOWS / LESSON 04
Making your first open source contribution
Loading the lesson…
Loading activities…
You know how to fork a project and send in changes. Cool. But how do you actually FIND a project to contribute to? And how do you make sure you're being a good neighbor once you're in there?
This lesson covers the whole trip, from finding your first project to landing your first contribution.
Open source software is software anyone can see, use, change and share. The code is public. Think of it like a community cookbook where anybody can read the recipes and suggest improvements.
So why would anyone work on open source for free? Turns out there are plenty of reasons.
I get the giving-back thing more than I expected to. When I put out my free A2P checker and shared it in two Facebook groups, it pulled 744 page views in 5 days. Nobody paid a dime for it, and it still felt like one of the better things I'd shipped (free stuff that actually helps people tends to travel).
Not every project is beginner-friendly. Here's how to find the ones that are.
Lots of projects tag issues that are good for newcomers. Keep an eye out for labels like these.
good first issuebeginner friendlyhelp wantedeasystarterYou can search for these right on GitHub. Pop this into GitHub's search.
Swap javascript for whatever language you're learning.
A handful of websites help you find beginner-friendly projects.
The best first contribution is usually to a tool you already use. Found a typo in the docs? That's a contribution. Wish an error message made more sense? That counts too.
Before you sink time into a project, make sure it's still alive.
A project that's been quiet for months might never look at your contribution.
Most projects have a CONTRIBUTING.md file. Read it! It tells you stuff like this.
Contributing isn't only about code. There are a bunch of ways to help.
Documentation fixes are usually the easiest place to start, and they're HUGELY valuable.
Let's walk through the whole process of making a real contribution.
Look for an issue labeled good first issue. Read it carefully and make sure you understand what needs doing.
If something's unclear, it's totally fine to ask questions in the issue comments.
Leave a comment like "Hi! I'd like to work on this. Is it still available?"
That lets the maintainers know you're interested and keeps two people from doing the same work.
Fork and clone the project. Follow the setup instructions in the README or CONTRIBUTING guide. Make sure you can run the project locally before you change anything.
Name your branch clearly. Putting the issue number in there helps a lot.
Do the work! Keep your changes focused on just this one issue. If you spot other things to fix, jot them down for a separate contribution.
Run the project's tests.
Or whatever command the project uses. Make sure you didn't break anything.
Mention the issue number so it gets linked automatically. Bonus, a word like "fixes" in front of it tells GitHub to close that issue once your PR gets merged into the main branch.
Over on GitHub, open a pull request and write a clear description.
Maintainers might ask for changes. That's normal, and honestly it's a good sign! They're helping you make your contribution better. Make the requested changes, push again, and the PR updates on its own.
Open source communities have their own norms and expectations. Here's how to be a great person to have around.
Maintainers are often volunteers with jobs and families. They might take days or weeks to get back to you. That's okay. Don't ping them over and over.
Always be kind and professional, because there's a real human on the other side of the screen. Never do any of these.
Once you've got a contribution or two under your belt, help other people out.
If someone helped you, mention them. If you used someone's idea, give them credit. The whole open source world runs on goodwill.
After you send in a pull request, a few different things can happen.
| Response | What it means |
|---|---|
| Approved and merged | Success! Your code is now part of the project. |
| Changes requested | The maintainer wants you to fix something. Normal and good! |
| Discussion | They have questions or want to talk about the approach. |
| No response | They might be busy. Wait a week or two, then politely ask. |
| Closed | They decided not to include it. Don't take it personally. |
Start small. Your first contribution might be fixing one typo, and that's perfect. Every contribution teaches you something.
Over time you'll take on bigger stuff. Maybe you'll turn into a regular contributor on a project, and some people even end up as maintainers themselves.
good first issue labels to find beginner-friendly tasksWorking on projects, whether they're yours or open source, usually means long sessions spread over a few days. In our final lesson we'll get into session management, which is how you keep track of your work and pick up right where you left off...