Writing

Open source as a student: what actually works

Three years of small open-source contributions taught me that consistency beats scale. Notes on finding a niche, documenting, and shipping.

2025-01-18 · 5 min read
Open SourceProgramming

Open source as a student: what actually works

I've been contributing to open source since my first year of college. The pattern that works is embarrassingly simple, and it's not what the "get your first PR" guides tell you.

The two mistakes everyone makes

1. Contributing to whatever is trending. The PRs get lost, the maintainers are busy, and you learn nothing. Trends attract everyone — and you'll be competing with a thousand contributors for the same doc fixes.

2. Biting off an epic feature. Trying to rewrite a core subsystem as your first contribution ends the same way: a 3,000-line PR nobody reviews.

What actually worked

A small, consistent niche. I picked developer tools and ML infrastructure — things I use daily and could actually evaluate. Contributing where you're a user means your fixes are grounded in real pain.

Tiny, well-scoped, well-documented PRs. The ones that get merged are the ones that make a reviewer's job easy: a clear description, a reproduction, tests, and a small diff.

Own the boring parts. The unglamorous work — docs, flaky test fixes, dependency bumps — is chronically understaffed and reliably mergeable. It also builds trust with maintainers faster than anything flashy.

The habits that compound

  • Write things down. Every project I've shipped publicly has a real README and a changelog. Documentation is the feature that keeps your users.
  • Reply to issues on your own projects. Responsiveness is the cheapest community-building tool there is.
  • Ship small, ship often. A release a month that's useful beats a "1.0" that takes a year.

Why it's worth it

Open source has been my best classroom. It forces clean APIs, honest docs, and public accountability — and it's where recruiters can verify the work I claim. But the framing matters: it's not a résumé optimisation. It's how I learned to build.

A note for students

You have a genuine advantage: time and low stakes. The projects you maintain now don't need to be big. They need to be real — a tool you use, a problem you had, a repo that's actually maintained. That consistency is the whole game.

Start small

Pick one tool you use every day, find its flakiest test or worst doc, and fix exactly that. One merged PR beats a hundred intended ones.