How to Make Your First Open Source Contribution on GitHub (2026)
W
Writer
Published: 16 Jun 2026
12 min read
A complete beginner's guide to contributing to open source — finding good-first-issue projects, the full git fork-clone-branch-PR workflow, writing a PR that gets merged, and qualifying for GSoC.
Open source contributions are one of the most powerful career moves a developer can make — and one of the most intimidating to start. The good news: your first contribution does not need to be a brilliant algorithmic improvement to the Linux kernel. It can be a typo fix in documentation. What matters is understanding the workflow, getting a PR merged, and building the confidence to contribute again. This guide walks you through every step — from zero to your first merged pull request.
7.2MIndian developers on GitHub — second largest in the worldIndia is GitHub's second-largest developer community after the US and is projected to become the largest by 2027. Yet less than 3% of Indian developers have made a contribution to an open source project outside their own repositories.
Why Open Source Contributions Matter for Your Career
Verifiable proof of skill — A merged PR in a real project is more credible than a personal project. The maintainer's approval is a third-party stamp of quality that any recruiter can verify.
Real codebase experience — Contributing to a large, established codebase teaches you things that no tutorial can — reading unfamiliar code, following style guides, understanding CI/CD, working with maintainers.
Network effects — Maintainers and frequent contributors are often senior engineers at major companies. A relationship built through good contributions can lead to referrals and job opportunities.
GSoC and LFX eligibility — Google Summer of Code and Linux Foundation Mentorship programs require a prior contribution history. These programs pay ₹3L–6L for summer projects and are career-defining for students.
GitHub green squares — A consistent contribution graph signals activity and professionalism to every recruiter who looks at your profile.
Step 1 — Finding the Right Project to Contribute To
The biggest mistake beginners make is picking a project that is too large or too unrelated to their skills. The ideal first contribution is to a project you actually use, written in a language you know, with an active community and beginner-friendly issues.
Tools for Finding Beginner-Friendly Issues
✓goodfirstissue.dev — Curated list of good first issues across popular repos, filterable by language
✓up-for-grabs.net — Projects actively looking for contributors with beginner-friendly tasks
✓GitHub search:label:"good first issue" language:python is:open — Replace python with your language
✓GitHub Explore → Topics → your technology — shows trending repos with active communities
✓first-contributions on GitHub — a repo specifically designed for first-time contributors to practice the workflow
What Makes a Good First Project
Criteria
Good sign
Warning sign
Issue activity
Issues responded to within days
Last response was 6+ months ago
PR merge rate
Recent PRs being merged
Many open PRs with no reviews
Contributor guide
CONTRIBUTING.md exists
No contribution guide at all
Community
Discord/Slack linked, friendly tone in issues
Aggressive maintainer responses
Issue labels
'good first issue', 'help wanted' labels used
No labels or only 'bug' labels
Test coverage
Tests exist and CI passes
No tests, frequent CI failures
How to evaluate an open source project before contributing
Start with documentation, not code
Your first 1–2 contributions should be to documentation or tests — not core code changes. Documentation PRs are easier to get merged, help you understand the project, and build a relationship with maintainers. Once maintainers know your name from a good docs PR, they are far more likely to review and mentor your code contributions.
Step 2 — The Standard Open Source Git Workflow
Every open source contribution follows the same Git workflow: Fork → Clone → Branch → Change → Push → Pull Request. Understanding this flow is the foundation of all open source work.
1
Fork the repository — Click 'Fork' on the GitHub repo page. This creates a copy of the repo under your GitHub account that you have full control over.
2
Clone your fork locally — git clone https://github.com/YOUR-USERNAME/repo-name.git. This downloads the code to your machine.
3
Add the upstream remote — git remote add upstream https://github.com/ORIGINAL-OWNER/repo-name.git. This lets you sync your fork with the original repo.
4
Create a new branch — git checkout -b fix/typo-in-readme. Never work on the main branch directly. Branch names should describe the change.
5
Make your changes — Edit files, fix the issue, add tests if needed. Keep changes focused — one issue per PR.
6
Commit with a clear message — git commit -m 'fix: correct typo in installation guide'. Follow the project's commit convention if specified.
7
Push to your fork — git push origin fix/typo-in-readme.
8
Open a Pull Request — Go to the original repo on GitHub. A banner will appear prompting you to open a PR from your branch. Fill in the PR template carefully.
bash
terminal — complete workflow
# 1. Clone your fork
git clone https://github.com/yourname/awesome-project.git
cd awesome-project
# 2. Add upstream (original repo)
git remote add upstream https://github.com/originalowner/awesome-project.git
# 3. Sync with upstream before starting work
git fetch upstream
git checkout main
git merge upstream/main
# 4. Create a feature branch
git checkout -b fix/update-nodejs-version-docs
# 5. Make your changes, then stage and commit
git add docs/installation.md
git commit -m "docs: update Node.js version requirement to v20"# 6. Push to your fork
git push origin fix/update-nodejs-version-docs
# 7. Go to GitHub and click 'Compare & pull request'
Step 3 — Writing a Pull Request That Gets Merged
The quality of your PR description is as important as the quality of your code. Maintainers review dozens of PRs — a clear, well-documented PR gets reviewed and merged faster than a technically superior but poorly described one.
plaintext
Good PR description template
## What does this PR do?
Fixes the Node.js version requirement in the installation guide.
The docs mentioned Node 16 but the package.json requires Node 20+.
## Why is this change needed?
New contributors following the docs were failing installation
because they installed Node 16 per the instructions. Issue #342.
## Changes made
- Updated docs/installation.md line 23: Node 16 → Node 20
- Added note about using nvm for version management
## How to test
1. Follow the updated installation guide from scratch
2. Confirm installation succeeds with Node 20
Closes #342
✓PR title follows the project's convention (often: type: short description)
✓PR description explains what changed and why, not just how
✓Reference the issue number being fixed (Closes #123)
✓All CI checks pass — do not open a PR with failing tests
✓Changes are focused — one logical change per PR, not a dump of unrelated fixes
✓Read CONTRIBUTING.md before submitting — many projects have specific requirements
Step 4 — After Submitting Your PR
Submitting the PR is not the end — it is the beginning of a conversation. Maintainers may request changes, ask questions, or suggest alternative approaches. How you handle this feedback determines your reputation in the project.
Respond promptly — Reply to review comments within 24–48 hours. Maintainers abandon reviews on PRs that go silent for weeks.
Never argue defensively — If a maintainer requests changes, implement them or ask a clarifying question. 'I disagree with this approach' without context is the fastest way to get your PR closed.
Push updates to the same branch — Additional commits to your PR branch automatically update the open PR. Do not open a new PR for the same change.
Mark conversations as resolved — After addressing each review comment, mark it resolved so the maintainer can see progress clearly.
Be patient — Maintainers are volunteers. A response within 1–2 weeks on a popular project is normal. Do not ping daily.
Getting a PR closed is not failure — it is a learning
Every experienced open source contributor has had PRs closed. Common reasons: the change is out of scope, the approach differs from the project's vision, or a similar change was already being made. Read the closing comment carefully, thank the maintainer, and apply the learning to your next contribution. The relationship you build matters more than any single PR.
Step 5 — Building a Contribution Streak
One merged PR is a start. A consistent contribution history is a career asset. Here is how to build momentum after your first contribution:
Pick 1–2 projects and go deep — Shallow contributions across 20 projects look like resume padding. Deep, consistent contributions to 2 projects show genuine commitment and build real relationships with maintainers.
Tackle progressively harder issues — After 2–3 doc/test fixes, attempt a small bug fix. After a few bug fixes, attempt a feature. Each level builds your understanding of the codebase.
Review other PRs — Reviewing pull requests from other contributors is one of the fastest ways to learn and get noticed by maintainers. You do not need to be a core contributor to leave helpful comments.
Write about your contributions — A LinkedIn post about a specific open source problem you solved and what you learned gets 10x more engagement than a generic 'I got a PR merged' post. Recruiters read these.
Apply for GSoC or LFX with your history — Google Summer of Code and Linux Foundation Mentorship both require prior contributions as part of the application. Even 3–5 merged PRs put you ahead of 80% of applicants.
Indian Open Source Projects Worth Contributing To
Contributing to Indian-origin projects is an excellent way to start — maintainers are in your time zone, issues are often well-documented for beginners, and the community is welcoming to Indian developers.
Project
What it is
Tech stack
Beginner-friendly?
Razorpay's open source tools
Payment infrastructure SDKs
Multiple languages
Yes — good first issue labels
FOSSASIA
Open tech for Asia, India-active community
Python, JS, Android
Yes — dedicated mentorship program
Hasura
GraphQL engine on PostgreSQL
Haskell, TypeScript
Moderate — good docs issues
Appsmith
Low-code app builder
Java, TypeScript, React
Yes — active Discord, good first issues
Plane.so
Project management tool
Next.js, Django
Yes — very active community
OpenStreetMap India
India map data contributions
Various
Yes — non-code contributions welcome
Indian-origin or India-active open source projects for beginners
Google Summer of Code — The Ultimate Open Source Opportunity
Google Summer of Code (GSoC) is a global program where students and early-career developers are paid to work on open source projects for 12–22 weeks. India consistently produces the most GSoC contributors of any country. The stipend for Indian contributors in 2026 is approximately ₹3–6L for a full project.
✓Applications open every year in January–February at summerofcode.withgoogle.com
✓You must have prior contributions to the applying organisation — start in October–November
✓Write a detailed proposal: what you will build, timeline, milestones, and why you are the right person
✓Indian acceptance rate is higher than average — strong proposals from Indian developers are well-regarded
✓GSoC on your resume signals open source ability, English communication, and remote collaboration to any global company
Frequently Asked Questions
Do I need to be an expert developer to contribute to open source?
No. The most useful first contributions are often the simplest: fixing a broken link in documentation, improving error messages, adding a missing test, or translating README content. These require basic Git knowledge and the ability to read code — not advanced programming skills. Every large project has dozens of these small issues open at any time.
My PR has been open for 3 weeks with no response. What should I do?
Leave a polite comment on the PR: 'Hi, just checking in on this PR — happy to make any changes needed.' Do this once after 2 weeks, once more after 4 weeks. If there is still no response after 6 weeks, the maintainers are likely inactive on that issue. Close your PR gracefully and move your contribution to a more active project.
Can I contribute to open source while working full-time?
Yes — and most contributors do. Start with 2–3 hours per week. One small, focused contribution per week is more valuable than a marathon session once a month. Set up GitHub notifications for the projects you follow so you can respond to review comments quickly without checking daily.
Do open source contributions count as work experience on a resume?
Significant open source contributions absolutely count. List them as: 'Open Source Contributor — ProjectName (github.com/link)' with bullet points describing what you built, the impact, and tech used. Merged PRs in well-known projects are immediately recognisable to technical recruiters and hiring managers at product companies.
My first open source contribution was a one-line README fix. My 50th was a core feature in a project used by 200,000 developers. The distance between those two points was nothing but repetition.
— Indian developer, Google Summer of Code alumnus
Key Takeaways
Key Takeaways
Start with documentation or test contributions — not core code — to build relationships with maintainers first
Use goodfirstissue.dev and GitHub's label:"good first issue" filter to find beginner-friendly tasks
The standard workflow: Fork → Clone → Branch → Change → Push → Pull Request — learn this until it is automatic
A well-written PR description gets reviewed faster than a brilliant but poorly explained code change
Contribute consistently to 1–2 projects rather than shallowly to 20 — depth builds reputation and relationships
GSoC applications require prior contributions — start contributing in October to be ready for January applications
100+ tools included
GitHub Education Pack — Free for Students
Verified students get free access to GitHub Pro, Codespaces, GitHub Copilot, and 100+ developer tools worth $200,000+. Includes free private repos, CI/CD minutes, and advanced GitHub Actions. Apply with your college email.
