How to Contribute to Open Source at Big Tech (What Actually Gets Merged)

The queue nobody mentions

The first good first issue I ever picked already had three open pull requests against it. The second one got fixed by the person who reported it, two days after I started reading the code. Nobody tells you this part: in any repo popular enough to impress a recruiter, the labeled easy work is a queue, and you are at the back of it.

Since then I have had 31 pull requests merged across NVIDIA, IBM, and HuggingFace repos, plus fixes in simdutf, GTSAM, and other libraries big companies depend on. Not one of them came from a good first issue label. This is the process that replaced it.

Stop hunting good first issues

I tracked this across repos I wanted to contribute to: LeRobot, PyTorch Geometric, HELM, lm-evaluation-harness, llama.cpp, MoveIt. Well-described bugs with a friendly label had one to five competing PRs within days. Reporters self-fix. Regulars swoop in. The label is an invitation to a race you will usually lose.

The merge rate lives in the opposite direction: bugs nobody has labeled yet, found by reading and running the code.

Every merged PR I have started the same way: reproduce something broken myself. A Python kernel in NVIDIA's cuda-quantum accepted math.ceil but crashed on np.floor. A compiler warning in GTSAM traced back to a genuinely uninitialized matrix. An example in NVIDIA's warp crashed on import because it reached into a private module. None of these had labels. All of them got merged, because I showed up with a reproduction instead of a claim on someone else's triage work.

Pick repos that actually merge external PRs

Before writing any code, look at the last 15 merged pull requests in the repo. Two numbers matter: how many came from forks (outsiders) rather than maintainers, and how long they sat before merging. This takes ten minutes and saves you weeks.

The spread inside one company is wild. I have measured sibling repos at the same company where one merged almost every external PR and the other merged none of its last fifteen. Same company, same logo on the repo, completely different odds. No public scoreboard tells you this. You have to count.

Also check the paperwork before you start, not after. DCO-only repos (like NVIDIA's warp) just need git commit -s and you are done. CLA repos can leave a finished PR sitting for weeks waiting on a signed agreement or an email to a legal alias. I had a correct fix to a Triton repo stall exactly this way.

Comment before you code

Maintainers at these companies triage constantly, and an unsolicited PR on an issue someone is already assigned to reads as noise. I have had a working fix closed because a maintainer preferred to route the issue differently. Now I always do two checks: is anyone assigned, and did the maintainers signal how they want it fixed.

If it is unclear, I leave a short comment first: here is the root cause, here is the fix I propose, want a PR? That comment costs nothing and converts your PR from a surprise into something they asked for.

The PR habits that get you merged

• One fix per PR. I once bundled an unrelated performance tweak into a simdutf fix. Daniel Lemire requested changes, and the PR only moved once I rebased the extra commit out. Scope creep reads as risk.
• Run the repo's formatter before every push. Some NVIDIA repos run the format check as the first CI job. A formatting failure means the reviewer sees red before they see your fix.
• Add a test that fails without your change. The single strongest argument a stranger's PR can make.
• Never delete a failing test to make CI green. Maintainers notice.
• Respond to every review comment, including the bot ones. Silence stalls PRs longer than disagreement does.
• Batch your changes before pushing. Big repos rerun full CI on every push, and reviewers see the churn.

The loop, start to finish

• Pick a company you want on your resume, then measure which of its repos merge fork PRs.
• Build and run the project. Read the parts you understand least.
• Find something actually broken and reproduce it. Unlabeled beats labeled.
• Comment on or open an issue with the root cause. Ask if a PR is wanted.
• Send the smallest correct fix with a test. Signed commit if DCO.
• Respond fast, format before pushing, keep scope frozen.

One serious contribution per week is enough. In a few months that compounds into a contribution trail at NVIDIA, IBM, Microsoft, or whichever company you want across the interview table, and unlike a side project, every line of it is code someone at that company reviewed and chose to ship.

That's the whole playbook. Go read some code, break something on purpose, fix it for real. See you in the repos.