Open source — from contributor to maintainer

A merged PR to a project that real engineers use is worth more than three side projects on your resume. This is not a controversial take among hiring managers; it is the actual take, said quietly. The reason is mechanical: a real OSS contribution proves you can read someone else’s codebase, follow conventions you didn’t invent, write code that survives review by strangers, and ship without any of the usual student crutches. Almost nothing else on a resume signals all four at once.

And yet most CS students never make a single non-trivial OSS contribution. They think they’re not “good enough yet,” or that it’s a thing senior engineers do, or they got intimidated by a 50-comment PR thread once and never went back. This module is the antidote. Your first real PR is two weeks away. The path is mechanical. Walk it.

Set up — pick your target this week

You will pick one project. Not five. The whole point is to become a recognised face in one community, not a drive-by typo-fixer in twelve.

The target project must satisfy three rules:

1. You use it daily, or close to it. If you don’t use it, you won’t intuit which issues are worth fixing, and you’ll burn out. The project you reach for in your terminal every Wednesday is the right one.
2. The maintainers are alive. Look at recent merged PRs. If the latest one is from 3 weeks ago and a maintainer commented on it, healthy. If the latest is 8 months old, dead. Skip.
3. The issue tracker has good-first-issue or help-wanted labels with at least 5 open. If maintainers haven’t curated entry points, you’ll waste days on issues they secretly didn’t want fixed.

Five reasonable starting points by language. Pick one:

You spend time in…	Try contributing to
Python web / APIs	fastapi, pydantic, httpx
Python data	polars, duckdb, scikit-learn
TypeScript / web	next.js, htmx, astro
ML systems	vllm, llama.cpp, transformers
Dev tooling	ruff, uv, neovim

Don’t pick linux or cpython or rust for your first contribution. They’re great projects, the bar is high, and the iteration speed is glacial. Earn that bar at a smaller project first.

Read these first

Three sources, in this order, then stop:

1. How to Contribute to Open Source — GitHub’s guide. Boring, correct, the canonical baseline. 30 min.
2. Drew DeVault — How to learn to code. post · 10 min · ignore the title, the section on how to enter an open-source project is the best 800 words on this anywhere.
3. Charity Majors — The engineer/manager pendulum has a stray paragraph about reading code that’s worth more than the rest of the post. post · 10 min.

Stop after these three. Do not read “10 ways to contribute to open source” listicles. They will tell you to fix a typo in a README, which fails property 4 from module 06.1 (it doesn’t generate a follow-up).

Why OSS contribution beats most resume signals

A common GPT-shaped resume in 2026 looks like this: GPA, three coursework projects, two internships at companies nobody’s heard of, “passionate about distributed systems.” Recruiter glances, files. Indistinguishable from 400 other resumes from this week’s batch.

Now imagine the same resume with a single line: “4 merged PRs to FastAPI (one feature, three bugfixes); recognised contributor on the project’s release notes.”

That line moves you from 400 to 4. Specifically because:

• It proves you can read a real codebase. Coursework code does not prove this.
• It proves you can write code that strangers, with no obligation to be nice to you, decided was good enough to merge.
• It proves you don’t need hand-holding to be productive in an unfamiliar repo — exactly the bar you’ll be measured against in your first job.
• It’s verifiable in 30 seconds. Your interviewer can pull up your GitHub and read the PR descriptions before the meeting.

That’s the asymmetry. Most students never collect this signal because the first PR feels intimidating. Past that wall, it’s not.

Finding a good first issue — the actual mechanics

Open the issue tracker. Filter to is:issue is:open label:"good first issue" (or whatever the project uses — help wanted, easy, beginner, etc.). Now do not pick the first one you see. Do this:

1. Sort by recently triaged. Maintainers triage in batches. A label added 6 months ago might be stale (already taken by a ghost contributor). A label added this week is fresh.
2. Skim the comments. If three people have commented “I’d like to work on this!” and gone silent, the issue is in zombie-contention. Skip — pick the next.
3. Look for issues with a clear repro. “Bug: when I do X, Y happens, expected Z.” Avoid issues that are still “we should redesign the foo module” — that’s not a first issue, that’s a six-week project.
4. Bonus: a maintainer has hinted at the fix. “Probably the fix is in src/parser.rs::tokenize around line 200.” That’s gold. Take it.
5. Comment first, code second. “Hi, I’d like to work on this. My plan is X. Reasonable starting point?” Wait 24 hours. If a maintainer thumbs-ups it, you have a soft claim. If silence after 48 hours, start anyway and mention it again in the PR.

The whole find-an-issue process should take 30–60 minutes the first time. If it’s taking longer, you’re being too picky.

Read the codebase before you comment

Before you write a single line of code or even a substantive comment, spend 1–2 hours reading the codebase around the issue. This is the step that separates contributors maintainers remember from contributors they tolerate.

Specifically:

• Run the test suite end-to-end on your machine. If you can’t get tests passing on main, fix that before you fix anything else.
• Find 3 recently merged PRs that touched the same area. Read the diffs and the review comments. You’ll learn the project’s conventions, what reviewers care about, and the style of commit message they want.
• Read the file you’re about to change top to bottom. Not just the function. The file. Notice naming, error handling, what’s tested vs not.
• Check if there’s a CONTRIBUTING.md. Read it. Twice. Most rejected PRs fail something written explicitly in CONTRIBUTING.md.

If the project has a Discord or a #dev channel, lurk for an hour. You’ll learn more about the project’s culture from one hour of lurking than from any amount of READMEs.

The etiquette — what gets you remembered (positively)

Healthy maintainer projects all run on the same social rules. Violate them, even unintentionally, and your PR sits unreviewed.

• Issue first, then PR. Never open a surprise PR that adds a feature. Maintainers hate having to reject good code because the feature isn’t wanted.
• Small, focused changes. One PR fixes one thing. Resist bundling “and while I was in there I also fixed…”. Each “and while I was…” is a reason to delay merging.
• Don’t argue style. If a maintainer asks for tabs not spaces, you make the change without a debate. Pick your battles. Whitespace is not one.
• Tests, always. If the project tests its code, your PR adds tests. No exceptions for “this change is too small to test.” Maintainers are using “did they add tests” as a proxy for “are they serious.”
• Patient, not pushy. PR sits for a week? Polite ping. Sits for two? Polite ping again. Don’t @-name 5 maintainers in the same comment.
• Take review feedback gracefully. “Good catch, fixed in next commit” is the right response. Not “but actually I think…”. You can disagree, just do it after the easy stuff.

Writing a PR description that gets merged

A merge-ready PR description has four sections, in this order:

## What this changes
One paragraph, no jargon. What does this PR do?

## Why
Link the issue. One sentence on why this matters.

## How
Brief technical summary. The 1-2 design choices you made and why.
If you considered an alternative and rejected it, mention it.

## Tests
What did you add? What edge cases does it cover?
If manual testing was needed, the exact reproduction steps.

Put screenshots or terminal output for anything visible. Reviewers spend 10 seconds deciding if a PR is worth their attention; the description is your chance to win those 10 seconds.

Becoming someone the maintainer recognises by name

Here is the move almost no student knows about: after 5 merged PRs, ask the maintainers if they could use a triage helper.

That sentence, casually dropped in a Discord channel or a thoughtful comment, is the inflection point. Triage rights mean you can label issues, close duplicates, and apply milestones. It costs the maintainer almost nothing to grant. It costs you maybe an hour a week. And it transforms your relationship with the project from “occasional contributor” to “trusted regular.”

Six months in, you’re on the project’s release notes. Twelve months in, recruiters from companies that use the project are sliding into your DMs. This is a real, repeated pattern. The students who execute it are not exceptional engineers — they’re patient ones who picked one project and stayed.

The trap of drive-by typo PRs

A common piece of bad advice: “fix a typo in a README to get your first PR.” Don’t. Maintainers find these annoying, not impressive. They clutter the PR queue, they’re often duplicates, and they signal that you didn’t care enough to find a real issue. Hacktoberfest made this worse for years; many projects now explicitly reject typo PRs as their first contribution.

A spelling fix as your second contribution, after a real merged change? Fine. As your first? You’re skipping the actual work. The whole point is the work.

Going deeper

When you have specific questions, in this order:

1. First Contributions — a real repo specifically designed for your first PR. Use it as a dry run for git mechanics, not as your real contribution.
2. CodeTriage — sends you one open issue per day from projects you sub to. Better than scrolling GitHub.
3. Drew DeVault — Writing system daemons. post · 15 min · how to read project conventions before you write any code.
4. Open Source Friday — GitHub’s calendar of company-supported OSS days. Some companies pay employees to triage; you can join for free.

Skip the “make money from open source” content. You won’t, not for years, and that’s not why you’re here.

Checkpoints

If any one wobbles, reread the corresponding section.

1. Name the three rules a target project must satisfy. For your chosen target, score it on each.
2. What’s the difference between a healthy good-first-issue label and a stale one? How do you tell?
3. Walk through what you should do before writing code on a chosen issue. Why does each step matter?
4. List the six etiquette rules. Which one are you most likely to violate, and why?
5. What’s the move that turns you from “occasional contributor” to “recognised regular”? What’s the prerequisite for asking?

If you can answer all five, you’ve earned 06.2 — but the real test is the first merged PR. Get one within 2 weeks. Then move to 06.3, technical writing.