Open source has never been bigger, and it has never been more confusing to break into. GitHub reported roughly 1.12 billion contributions across its platform in 2025, up 13% year over year, with March 2025 alone producing 255,000 first-time open-source contributors — the largest single month on record. At the same time, 81.5% of all contributions on GitHub now happen in private repositories, which means the public, collaborative side of software — the side most developers associate with "open source" — is a smaller slice of a much larger pie than it used to be, and it's more competitive for attention.
If you've been putting off your first contribution because you're not sure where to start, this guide walks through the real mechanics: how to find a project worth your time, how the pull request workflow actually works end to end, and what separates a contribution that gets merged from one that gets ignored.
Why bother in 2026
The case for contributing hasn't really changed, but a few things have sharpened it. First, hiring managers and technical interviewers increasingly look at public contribution history as a signal — not a replacement for a resume, but a tiebreaker. Second, the developer population contributing to open source is globalizing fast: GitHub's data shows India overtook the United States in total contributor count for the first time in 2025, and Africa, the Middle East, and Latin America collectively added millions of new developers. The barrier to participating from anywhere in the world, with nothing but a laptop and a GitHub account, keeps dropping.
Third — and this is the less comfortable part — AI-generated pull requests are flooding maintainers' queues. GitHub's own "what to expect in 2026" post flags maintainer burnout and low-quality, AI-authored PRs as a real sustainability problem for the ecosystem. That's actually good news for a human contributor who puts in a small amount of real care: a well-scoped, well-tested, clearly explained PR now stands out more than it used to, precisely because so much of what maintainers are wading through is noise.
Step 1: Set up your tools
You need three things before you touch any project:
- Git installed locally, with your name and email configured (
git config --global user.name/user.email). - A GitHub account — free, and the account you'll use for essentially every contribution, since GitHub hosts the overwhelming majority of public open source activity.
- A code editor. VS Code is the most common choice and is itself open source, which makes it a fitting (if not mandatory) starting point.
If you've never used Git beyond git add/git commit/git push on your own repos, spend twenty minutes on forking and branching specifically — that's the part that trips people up first.
Step 2: Find a project and an issue that fit
The single biggest mistake new contributors make is picking a project first and an issue second. Do it the other way around. Start with the issue.
Curated beginner-issue search engines. Sites like GoodFirstIssue.dev aggregate GitHub issues across thousands of repositories that maintainers have explicitly labeled good-first-issue, help-wanted, or similar. This is a far better starting point than browsing trending repos and hoping for the best — you're filtering for issues maintainers have already flagged as approachable.
GitHub's own search. You can search is:issue is:open label:"good first issue" scoped to a language or topic you know. Combine it with a language filter (e.g., language:python) to stay in your comfort zone for a first attempt.
Projects you already use. If there's a library, framework, or tool you use regularly and have opinions about, check its issue tracker. Familiarity with the codebase's purpose (even without deep code knowledge yet) makes the contribution process much less intimidating, and you're more likely to notice small things worth fixing — a confusing error message, a missing example, a broken link in the docs.
Non-code contributions. Fixing a typo, clarifying a confusing paragraph in a README, adding a missing code example, or filing a clear, reproducible bug report are all legitimate first contributions — and they tend to merge fast, because they carry low review risk for the maintainer. Don't let "contributing to open source" collapse in your head into "writing a complex feature." A surprising share of valuable open source work is words, not code.
Step 3: Read the contributing docs before you write anything
Before writing a single line, find and read the project's CONTRIBUTING.md and CODE_OF_CONDUCT.md if they exist. These files tell you:
- The exact branch naming and commit message conventions the maintainers expect
- Whether they require signed commits or a Developer Certificate of Origin (DCO)
- How to run the test suite locally
- Whether they want you to open an issue and get a maintainer's go-ahead before submitting a PR (many projects do, especially for anything beyond a trivial fix)
Skipping this step is the fastest way to get a PR closed with a polite "thanks, but please see CONTRIBUTING.md" — a frustrating outcome that's entirely avoidable.
Step 4: The pull request workflow, start to finish
Here's the mechanical sequence, the same one underneath nearly every open source contribution on GitHub:
- Fork the repository — click "Fork" on the project's GitHub page to create your own copy under your account.
- Clone your fork locally:
git clone https://github.com/your-username/project.git - Create a new branch for your change:
git checkout -b fix/broken-readme-link. Never work directly onmainin your fork — a dedicated branch per change keeps things clean if you want to contribute again later. - Make your change, then run the project's test suite and linter if one exists. This is the step people skip and regret; a PR that fails CI on the first push makes a worse first impression than one that arrives clean.
- Commit with a clear message:
git commit -m "Fix broken link to API docs in README". Specific, descriptive commit messages and PR titles matter more than people expect — "Fix race condition in WebSocket reconnection handler that causes duplicate messages" tells a reviewer exactly what to expect before they open the diff; "fix bug" tells them nothing. - Push to your fork:
git push origin fix/broken-readme-link - Open the pull request — GitHub will usually show a "Compare & pull request" button automatically once you push a new branch. Write a short description: what you changed, why, and how you tested it. Link the issue number if there is one (
Fixes #123). - Respond to review feedback. Almost no non-trivial PR merges on the first pass. Maintainers may ask for changes — treat this as normal, not as rejection, and push additional commits to the same branch to address them.
The first-contributions project on GitHub is literally built as a sandbox for practicing this exact sequence with zero risk — it exists solely so people can make a real PR against a real repo without worrying about doing it "wrong" on a project that matters.
What makes a PR get merged vs. ignored
Maintainers are volunteers, or at best a small paid team, reviewing far more submissions than they can deeply engage with. A few things reliably separate a mergeable PR from one that stalls:
- It does one thing. A PR that fixes a typo and refactors a function and adds a new feature is three PRs pretending to be one, and it's much harder to review and approve.
- It includes tests when the codebase has a test suite, or at minimum shows evidence the change was actually run and verified.
- It matches existing code style, even if you'd personally format things differently. Consistency reads as respect for the maintainer's codebase.
- The description explains the "why," not just the "what." Diffs show what changed; only you know why it matters.
- It's small. A 15-line fix gets reviewed in a maintainer's spare five minutes between meetings. A 2,000-line PR gets left in the queue for weeks, because reviewing it properly requires blocking out real time nobody has.
Where AI fits — and where it doesn't
It's worth addressing directly, given how much of the current open source conversation centers on it. Using an AI assistant to help you understand an unfamiliar codebase, draft a commit message, or debug a failing test is a legitimate and increasingly normal part of how contributors work. What maintainers are pushing back on is a different thing: PRs that are clearly auto-generated en masse, submitted without the author actually understanding or testing the change, often in response to bounty programs or hackathon incentives. GitHub's own outlook for 2026 names this as a real strain on maintainer time and trust.
The practical takeaway: use AI tools the way you'd use any other tool in your workflow — to move faster on work you understand and stand behind — not as a way to generate PRs you haven't personally verified. A maintainer can tell the difference within a few review comments, and it affects whether they trust your next submission.
A note for teams building on top of open source
If you're a business running a website or product built partly on open source tooling — which is most businesses today — there's a quieter benefit to having your engineers contribute upstream: bugs you report and fixes you submit get reviewed by the people who know the codebase best, and issues you flag are far more likely to get prioritized when they come with a working patch attached rather than just a complaint. It's a small investment that compounds, especially for infrastructure your product actually depends on.
None of this requires an AI widget or a chatbot — it's fundamentally a human process of reading code, understanding intent, and communicating clearly with strangers who are also volunteering their time. But if your team's own site fields a lot of technical questions from visitors — "does this library support X," "how do I integrate your API," that kind of thing — a support-oriented assistant on your own docs pages (the kind of thing a tool like Techvea's Support Bot widget handles) can take the repetitive Q&A off your plate so your engineers have more hours in the week for the contributions that actually move a codebase forward.
Getting started this week
Pick one small thing. Not a project — one issue, one typo, one missing test. Read the CONTRIBUTING.md. Fork, branch, commit, push, open the PR, and wait for feedback without taking a request for changes personally. That's the entire loop, and the only way it gets easier is by running it once.
Sources:
Get new posts as they publish
No spam — just the next post, straight to your inbox.