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.
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.
Related reading
Coding agents need verification, not better guessing
AutoDevs taught me that the most valuable part of an agent isn't its planner — it's the test runner that checks its work.
Local-first AI is a design constraint, not a compromise
Building Tatvik taught me that running models on-device forces sharper architecture. A few notes on why the constraint is a feature.
What 2,400 labelled images of supermarket shelves taught me
Building Retail Shelf Intelligence, the hardest part wasn't the model — it was the data. Lessons from annotating shelves, glare, and thermal paper.