How to Start Contributing to Open Source (And Make It Show on Your GitHub Profile)
I want to start with an honest observation. The reason most developers don't contribute to open source isn't that they don't know how. It's that they look at a large codebase for the first time, feel completely lost, and close the tab. That feeling is normal. Every experienced open source contributor had it on their first few attempts. The question is what to do with it.
The short answer is: start smaller than you think you should. Not because you're not capable of more, but because understanding a new codebase takes time, and the fastest way to get a PR merged is to start with something small enough that you can fully understand the change you're making before you submit it.
Why Open Source Contributions Matter for Your GitHub Profile Specifically
If you're reading this on ReadmeDesign, you're probably thinking about your GitHub profile. So let me be specific about why open source contributions help with that, beyond generic advice on what recruiters look for.
None of this happens from submitting PRs that get rejected or sitting in review limbo for months. It requires getting contributions actually merged, which is what the rest of this guide is about.
How to Find the Right Project
Most advice says "contribute to projects you use." That's good advice but it needs a filter. The project also needs to be actively maintained, welcoming to newcomers, and have issues at a complexity level you can actually handle right now.
A project you use that hasn't had a merged PR in six months, has 200 open issues with no responses from maintainers, and no CONTRIBUTING.md file is not a good starting project — even if you love it. Your PR will sit there indefinitely and you'll learn nothing about the contribution process.
Here's what to look for before choosing a project:
- Recent activity. Look at the "Insights → Contributors" tab. If the last commit was two years ago, move on. You want a project where maintainers are actively reviewing and merging code.
- A CONTRIBUTING.md file. This means the maintainers have thought about the contribution process. Projects without one are often less organized about reviewing PRs.
- Issues with the "good first issue" label. Go to the Issues tab and filter by label. Every GitHub project has an issues page at
github.com/org/repo/issues?q=label%3A"good+first+issue". Projects that actively use this label are signaling they want to help newcomers in. - A reasonable PR merge rate. Look at the repository's "Closed" pull requests. If most closed PRs say "merged" (green) rather than "closed" (red), that's a project where contributions actually get accepted. If most are closed without merging, proceed carefully.
- Response time in issues. Comment on a "good first issue" asking if it's available to work on. If you get a response within a few days, the maintainers are active. If you hear nothing for two weeks, that tells you something.
Finding Issues You Can Actually Fix
Here's a URL pattern that works on any GitHub project — add /contribute to the end of the repository URL:
This page shows beginner-friendly open issues specifically curated for new contributors. It's better than searching the main issues list because it's already filtered by maintainers who have actively tagged things as approachable.
Beyond the /contribute page, search for these labels in any project's issues:
good first issuehelp wantedbeginner friendlydocumentationbug: confirmed(means the bug is real and reproducible, not speculation)
Don't limit yourself to code. Documentation fixes, typo corrections, and improving error messages are real contributions that get merged. A typo fix in the React documentation is a merged PR in a repo with 200,000+ stars. It shows on your profile. It's real.
The Actual Process — Step by Step
Before you fork anything, leave a comment on the issue saying you'd like to work on it and asking if it's still available. Something like: "Hi, I'd like to take a look at this. Is it still open to contributions? Happy to ask questions before submitting."
This does two things. It prevents you from spending two hours on a fix that someone else is already working on. And it starts a conversation with the maintainers, who may give you guidance that saves you hours of confusion about the right approach.
Fork the repository to your GitHub account, then clone your fork locally. This is the standard process but read the project's CONTRIBUTING.md before you run anything — some projects have specific setup steps, required Node/Python versions, or environment variables you need before the test suite will run.
This is the most important piece of advice in this entire guide. Your PR should change the minimum number of files and lines necessary to fix the specific issue. Do not refactor unrelated code while you're in there. Do not "improve" things that weren't mentioned in the issue. Do not rename variables for consistency in files you had to touch anyway.
Every extra change you make is something a maintainer has to review and potentially argue with you about. It slows down your PR and reduces the chance it gets merged. Make one change, make it well, explain it clearly. That's it.
Before submitting, run the full test suite. If you broke something, you need to know now. If you fixed a bug, check whether the project's contribution guidelines expect you to add a test that would have caught the bug. Many projects do — the CONTRIBUTING.md will tell you. A PR with a new test alongside the fix is significantly more likely to be merged quickly than one without.
The PR description is not a formality. Maintainers on large projects review dozens of PRs a week. A clear description means they can understand your change in 30 seconds instead of digging through your diff to figure out what you were trying to do.
What to Do When Your PR Gets Feedback
This is where a lot of first-time contributors disappear. You get feedback from a maintainer — sometimes critical, sometimes asking for changes you didn't expect — and you either abandon the PR or get defensive. Both responses kill the contribution.
The right mindset: maintainers leave feedback because they want to merge your code. If they didn't, they'd close the PR without comment. Feedback is a good sign. Respond to it promptly, implement requested changes without arguing (unless you have a genuinely good reason to push back, in which case explain your reasoning calmly), and push the updated commit.
Your first PR will probably not be perfect. That's fine. The maintainer's job is to help you get it to a mergeable state. Your job is to be responsive and not take the feedback personally.
If your PR gets closed without merging and you're not sure why, it's okay to politely ask: "Thanks for reviewing. Could you help me understand what would have made this approach work? I'd like to contribute to this project again." Most maintainers will tell you.
How to Make Your Contributions Visible on Your Profile
Once you have merged PRs, make them visible. Add a section to your README:
The project name links to the repo. The description says specifically what you did — not "contributed to" but what the actual change was. The PR number links directly to the merged PR so anyone can verify it.
This section is one of the most credible things you can put on a developer profile. Personal projects show you can build something. Open source contributions show you can navigate someone else's codebase, follow their conventions, respond to code review, and get your code accepted into a real production project. Those are different and more advanced skills.
The Contributions That Are Most Underrated
I want to specifically mention a few types of contributions that new developers overlook because they don't feel like "real" contributions — but they are, and they get merged faster than most code PRs:
Documentation fixes. Missing examples, outdated API references, unclear parameter descriptions — every popular project has these. They're often not getting fixed because the maintainers are focused on code. A well-written documentation PR is genuinely valuable and often gets merged same-day.
Improving error messages. When a library throws an error, the message often says something cryptic like "TypeError: undefined is not iterable." A PR that makes that message say "TypeError: the items array is empty — pass at least one item or use the emptyState prop" is a tiny code change with a big user impact. Maintainers love these.
Adding missing type definitions. If you work with TypeScript and use a library that has incomplete @types definitions, fixing a missing or incorrect type is a straightforward PR that affects a lot of users. The DefinitelyTyped repository accepts exactly these contributions.
Reproducing and confirming bugs. Sometimes an issue says "my app crashes when I do X" and the maintainers can't reproduce it. If you can reproduce the bug, write a minimal test case that demonstrates it, and add it as a comment — that's a valuable contribution even without a fix. You've done the hard part.
Programs That Help You Get Started
If the self-directed approach feels too unstructured, these programs provide guided entry points into open source:
- Google Summer of Code (GSoC) — paid program where you work on a specific OSS project for a summer under a mentor. Highly competitive but well-regarded. Applications open each year around January.
- Outreachy — paid internships for people underrepresented in tech. Three-month paid contribution periods with a formal mentor.
- Hacktoberfest — runs every October. Make four PRs to any participating open source projects and get a digital badge (and sometimes a t-shirt). Lower quality threshold than GSoC but good for getting started with the PR process.
- first-contributions repository — github.com/firstcontributions/first-contributions. A repo specifically designed for your very first PR. You follow the instructions, add your name to a list, and submit. Trivial technically, but useful for running through the fork-clone-branch-commit-PR workflow the first time without any pressure.
The Honest Timeline
Your first PR will probably take longer than you expect. Reading the codebase, setting up the environment, figuring out the right change, writing the description — it might take a full weekend for what ends up being a three-line fix. That's normal. Your second PR to the same project will take two hours. Your fifth will take forty-five minutes.
Open source contribution is a skill that compounds. The first one is the hardest. After that it gets significantly easier, and the profile signal it creates — verified, linked, public evidence that you can work in real codebases — compounds too.
Add your contributions to your README
Once you have merged PRs, make them visible. The sandbox editor lets you write and preview your contributions section exactly as it'll look on GitHub.