GitHub added 36 million new builders in 2025, roughly one new account each second, pushing the platform previous 180 million builders complete. Almost a billion commits acquired pushed over the yr, up 25% from the yr earlier than, and 43.2 million pull requests (PRs) have been merged each month. Open supply has by no means been greater or extra accessible.
It is also by no means been beneath extra pressure. GitHub’s personal Octoverse report names a widening “contributor-to-maintainer hole,” made worse by what the trade has began calling “AI slop”: low-quality, auto-generated pull requests that devour maintainer time with out including actual worth. The Jazzband collective, a well known hub for Python tasks, shut down fully in 2025, with its lead maintainer citing the unsustainable quantity of AI-generated spam PRs and points as a main driver.
Each of this stuff are true without delay, and neither cancels the opposite out. Open supply is genuinely extra open to new contributors than it has ever been; 83% of organizations now contemplate it worthwhile to their future, and a verifiable historical past of actual, merged contributions is likely one of the few indicators that also cuts via a flooded hiring market. However the bar for what counts as a very good contribution has quietly gone up, exactly as a result of careless ones are all over the place proper now. This information walks the complete path: what contributing really covers, the right way to decide a undertaking that can really reply to you, the precise git mechanics, and — as a result of it issues extra in 2026 than it did even a yr in the past — the right way to use AI instruments with out changing into a part of the issue maintainers are drowning in.
# What Open Supply Contribution Really Covers
The most important false impression to clear up first: contributing doesn’t imply writing code. Contribution spans documentation, testing, design, neighborhood administration, situation triage, and code. Anybody who has added any of those to a undertaking is a contributor, full cease — no asterisk for “however actual contributors write code.”
A handful of phrases come up always and are value nailing down earlier than the rest.
- An situation is a tracked drawback, bug report, or characteristic request that the unit of labor a undertaking organizes round.
- A pull request (PR) is a proper request to merge a particular set of modifications into the undertaking, opened for overview and dialogue earlier than something really merges.
- A maintainer is somebody with the authority to overview and merge PRs and steer the undertaking’s course — often a small group, typically only one individual, nearly at all times volunteering their time.
- A fork is your personal copy of another person’s repository, which is the place you may really make modifications.
- Upstream refers back to the unique repository your fork got here from.
Documentation will get named repeatedly throughout contributor guides as the most effective place to begin: fixing a typo, clarifying a complicated setup step, or including an instance that was lacking. It is low-risk, genuinely helpful to hundreds of future readers, and it teaches you ways a undertaking’s overview course of really works earlier than you try something with actual logic in it.
# Selecting a Undertaking (The Mistake Virtually Everybody Makes First)
The one commonest mistake freshmen make is attempting to contribute to an enormous, high-profile undertaking — the Linux Kernel, React, one thing with a reputation everybody acknowledges — on day one. These tasks have hundreds of recordsdata, strict overview requirements, and maintainers who genuinely can’t afford the time to onboard somebody who hasn’t already learn the contribution information twice. It isn’t that they are unwelcoming. It is that the mathematics would not work at that scale.
The higher strategy is selecting a undertaking sized to truly provide you with a response. Earlier than committing actual time, a number of concrete indicators are value checking. Take a look at the undertaking’s closed PRs to grasp its tradition and what will get accepted versus rejected. Take a look at the contributors listing — a wholesome, sustainable undertaking has many contributors, not one or two folks quietly doing every part. Examine whether or not a CONTRIBUTING.md file exists in any respect; its presence is itself a sign that the maintainers have thought of onboarding newcomers fairly than assuming everybody already is aware of how issues work.
For discovery, a number of instruments exist particularly to resolve this matching drawback. GoodFirstIssue.dev is a curated search engine that pulls GitHub points labeled particularly for newcomers, filterable by language. Up for Grabs lists tasks with an express onboarding course of in-built, fairly than tasks the place you are anticipated to determine the tradition by trial and error. The first-contributions repository is value a separate point out; it exists purely as a zero-stakes follow floor for the fork-to-PR mechanics, with no actual codebase to fret about breaking — which makes it the correct place to get the workflow comfy earlier than you contact a undertaking that really issues to you.
# The Fork → Clone → Department → PR Workflow
That is the half that intimidates folks essentially the most earlier than they’ve carried out it as soon as, and feels fully mechanical the second time. The usual circulate is: fork the repository on GitHub, clone your fork to your machine, create a characteristic department, make your modifications, commit with a transparent message, push to your fork, then open a PR in opposition to the unique repository. The step most freshmen skip — and the one which causes essentially the most frustration later — is syncing your fork with upstream earlier than beginning new work: fetching the newest modifications and merging them in to keep away from stale-branch conflicts down the road.
Here is all the sequence, demonstrated in opposition to two native repositories standing in for “the unique undertaking” and “your fork,” absolutely runnable by yourself machine earlier than you ever contact an actual GitHub repo.
Conditions: Be sure you have git put in; no GitHub account or community connection is required. This demo makes use of two native folders to simulate “upstream” and “your fork.”
set -e
mkdir -p /tmp/oss-demo && cd /tmp/oss-demo
Step 1: Simulate the “upstream” undertaking — the repo you’d usually fork on GitHub.
rm -rf upstream my-fork
mkdir upstream && cd upstream
git init -q --initial-branch=important
git config consumer.e mail "maintainer@instance.com"
git config consumer.identify "Undertaking Maintainer"
echo "# Demo Undertaking" > README.md
echo "This undertaking does cool issues." >> README.md
git add README.md
git commit -q -m "Preliminary commit"
cd ..
Step 2: “Fork” on actual GitHub means clicking the Fork button. Regionally, we simulate it by cloning upstream right into a separate folder.
git clone -q upstream my-fork
cd my-fork
git config consumer.e mail "contributor@instance.com"
git config consumer.identify "New Contributor"
Add the upstream distant — that is the step most individuals neglect after forking on GitHub. With out it, you don’t have any approach to pull in new modifications the maintainers make after you forked.
git distant add upstream ../upstream
echo "--- Remotes configured ---"
git distant -v
Step 3: Create a characteristic department. By no means commit on to important.
git checkout -q -b repair/readme-typo
Step 4: Make a centered, single-purpose change.
sed -i 's/cool issues/genuinely helpful issues/' README.md
git add README.md
git commit -q -m "docs: make clear undertaking description in README"
echo ""
echo "--- Characteristic department created with one centered commit ---"
git log --oneline
Step 5: Simulate another person merging a change upstream whilst you labored.
cd ../upstream
echo "" >> README.md
echo "## Set up" >> README.md
echo "Run `npm set up` to get began." >> README.md
git add README.md
git commit -q -m "docs: add set up part"
cd ../my-fork
Step 6: Sync your fork with upstream earlier than persevering with or opening a PR.
echo ""
echo "--- Syncing fork with upstream ---"
git fetch upstream
git checkout -q important
git merge upstream/important --no-edit -q
echo "important department is now present with upstream:"
git log --oneline
Step 7: Verify your characteristic department is untouched by the sync.
git checkout -q repair/readme-typo
echo ""
echo "--- Characteristic department, nonetheless remoted and able to push ---"
cat README.md
Step 8: Push your department to your fork (that is what triggers the “Examine & pull request” button on GitHub).
git push -q origin repair/readme-typo
echo ""
echo "Department pushed. On actual GitHub, you'd now click on 'Examine & pull request'."
What this proves, step-by-step: your characteristic department holds precisely one centered change. When you labored, the upstream undertaking moved ahead with a commit you did not have but. Syncing with git fetch upstream adopted by git merge upstream/important pulled that become your native important with out touching your characteristic department in any respect. That separation is all the level of the workflow: your characteristic department stays clear and mergeable no matter what else is occurring within the undertaking, so long as you sync important usually fairly than letting it go stale for weeks.
On actual GitHub, the one distinction is that “fork” means clicking a button within the UI as a substitute of operating git clone in opposition to a neighborhood folder, and “push to origin” triggers an precise “Examine & pull request” banner as a substitute of a print assertion. The git mechanics beneath are similar both approach.
# Studying the Codebase Earlier than Writing Something
That is the step nearly each rejected PR skipped, and nearly each information glosses over. Earlier than opening something past a typo repair, three issues are value doing so as.
Learn the CONTRIBUTING.md file if one exists; most established tasks have one, and it often solutions questions on coding fashion, take a look at necessities, and commit message conventions earlier than it’s a must to ask and watch for a reply. Learn a handful of not too long ago merged PRs — not simply open ones — to see what “acceptable” really seems to be like on this particular undertaking’s tradition: the dimensions of typical diffs, how a lot clarification maintainers anticipate within the description, and whether or not they’re strict about take a look at protection. And for something past a trivial repair, open a problem or touch upon an current one earlier than writing the code.
Opening a PR with out prior dialogue is okay for small, apparent fixes — a typo, a damaged hyperlink, or an off-by-one error. Something extra substantial must be mentioned first, so the work would not find yourself wasted if the maintainers had a distinct strategy in thoughts. This single behavior prevents the only commonest type of contributor frustration: spending a weekend on a characteristic, opening a PR, and being informed the undertaking would not need it in that kind or in any respect.
The “good first situation” label deserves a particular be aware right here. It is a deliberate sign from maintainers {that a} specific situation has been scoped to be secure and approachable for somebody new to the undertaking — not a assure that the duty is trivial, simply that it has been deliberately sized for a primary try. Deal with the label as an invite to ask questions within the situation thread if something is unclear, fairly than a promise that you simply will not must.
# Writing a Pull Request Maintainers Really Need to Evaluate
A handful of habits separate PRs that get merged from PRs that sit untouched or get closed with a well mannered “thanks, however” remark.
Preserve the diff centered on one factor. A PR that fixes a bug and in addition reformats three unrelated recordsdata is more durable to overview than two separate, smaller PRs — and “more durable to overview” interprets immediately into “takes longer to merge, if it merges in any respect.” Write an outline that explains why, not simply what the diff already exhibits. What modified is seen within the code; the outline ought to clarify the reasoning a reviewer cannot get from the code alone. Embrace checks that reveal the repair or characteristic really works, matching no matter testing strategy the undertaking already makes use of. Observe the undertaking’s current fashion and conventions, even while you’d personally do it in another way — consistency issues greater than your choice right here. And maintain your commit historical past readable: a handful of clear, logical commits beats fifteen “repair,” “repair once more,” and “really repair” commits squashed collectively on the final second.
The scale level is value backing with a quantity, as a result of it is not simply etiquette — it measurably impacts overview high quality. Analysis from SmartBear and Cisco on code overview discovered that defect detection accuracy drops from 87% for PRs beneath 100 strains to simply 28% for PRs over 1,000 strains. A smaller, extra centered PR is not simply simpler on a maintainer’s persistence; it will get reviewed extra totally and merges sooner, as a result of a human reviewer’s means to truly catch issues collapses as diff measurement grows.
# Utilizing AI Instruments With out Changing into A part of the Slop
That is value its personal part as a result of the panorama has shifted meaningfully within the final yr, and most current contributor guides have not caught up.
AI coding instruments at the moment are a very regular a part of how most contributors write code. Copilot, Cursor, and Claude make writing code and opening PRs trivially simple — which is strictly what’s flooding maintainer overview queues with what the trade has began calling AI slop: half-baked options that do not observe the undertaking’s current conventions, duplicate implementations of performance that already exists some place else within the codebase, and PRs that technically cross lint and checks however do not really remedy the issue the problem described.
The road that separates a superbly cheap use of AI tooling from contributing to this precise drawback is easy to state and straightforward to violate with out noticing: maintainers report they’ll spot AI-generated PRs nearly immediately when the contributor cannot clarify their very own change as soon as questioned — verbose, oddly phrased descriptions, a contributor who goes quiet or obscure the second a reviewer asks “why did you strategy it this fashion” or “what occurs if this enter is empty.“
Utilizing AI to draft a primary cross, debug an error message, or discover how part of the codebase works is okay. The requirement that really issues is that this: learn each line earlier than you submit it, perceive why it is right fairly than simply trusting that it runs, and be genuinely capable of reply follow-up questions on your personal PR within the overview thread. If you cannot clarify a line of your personal diff, that is the sign to go perceive it earlier than submitting — not after a maintainer asks and it’s a must to admit you do not know.
# After the PR (Critiques, Iteration, and What “Merged” Really Means)
Set the expectation truthfully now, so it would not sting later: a primary PR not often merges on the very first cross. Requested modifications from a maintainer are the conventional subsequent step within the course of, not a rejection, they usually’re often the quickest approach to really study a codebase’s actual, unwritten conventions — the issues that by no means fairly make it into CONTRIBUTING.md regardless of how thorough it’s.
It is also value realizing that the contributor-to-maintainer hole referenced earlier on this information means overview queues are genuinely lengthy on many tasks proper now. A PR sitting unreviewed for per week or two is, most of the time, a quantity drawback on the maintainer’s aspect — not a verdict in your contribution particularly. A well mannered, single follow-up remark after an affordable wait is acceptable. Repeated pinging isn’t.
The factor nearly no one mentions a couple of first merged PR: the second is dramatically sooner. The friction in a primary contribution is sort of fully the workflow mechanics lined on this information — the fork, the sync, the department, discovering the correct place to ask earlier than coding, studying what the undertaking really needs. None of that friction exists the second time. The precise coding isn’t the bottleneck for a brand new contributor; the unfamiliarity with the method is, and that unfamiliarity is gone the second you have carried out it as soon as.
# Conclusion
Open supply in 2026 is larger and extra accessible than it has ever been, and extra strained than it has ever been — each without delay, with neither truth canceling the opposite out. The pressure is strictly why a cautious, well-scoped, clearly defined contribution stands out greater than it used to: a significant share of what maintainers are wading via proper now could be the other of cautious, they usually discover the distinction instantly.
Begin small. Learn earlier than you write. Focus on earlier than you construct something substantial. Preserve your modifications centered sufficient {that a} human reviewer can really catch issues in them. And whether or not a line of code got here from your personal fingers or a instrument’s suggestion, have the ability to clarify why it is right when somebody asks. That mixture — greater than any particular language, framework, or technical ability — is what turns a primary contribution into an ongoing one, and an ongoing one into the form of GitHub historical past that genuinely means one thing to the subsequent individual reviewing it.
Shittu Olumide is a software program engineer and technical author captivated with leveraging cutting-edge applied sciences to craft compelling narratives, with a eager eye for element and a knack for simplifying complicated ideas. You can even discover Shittu on Twitter.
