December 2020
I was in my first year at IIIT Lucknow and I had the repository open in one tab and the contributing guide in another, and I did not push anything for about three weeks.
The fear is specific and I suspect common. Not "will this be rejected" so much as "will a stranger read this and conclude I don't know what I'm doing." Which, at the time, would have been a fair conclusion.
What eventually got me past it was realising the first contribution didn't have to be code. Plenty of things in a project are broken in ways that don't require you to understand its architecture.
Internet Archive
My first real contribution was to the Internet Archive. I'd gone in expecting to work on the library itself and instead spent my time on the part I'd just struggled with: getting set up.
Their onboarding had the usual accumulated friction — instructions written for an environment two years out of date, undocumented steps that everyone already there had internalised. I wrote Docker configurations that got a new contributor running in minutes rather than an afternoon, rewrote the contributor guide with actual step-by-step setup, architecture diagrams and troubleshooting for the failures people kept hitting, and tidied the GitHub Actions workflow so feedback on a PR arrived faster.
None of this was difficult. It was just work nobody had got to, which describes a large share of what open source needs.
AnyWrite and CircuitVerse
AnyWrite is a collaborative writing platform built around privacy and simplicity. I worked on the user-facing side — responsive behaviour, accessibility, performance.
CircuitVerse is an educational platform for designing and simulating digital circuits, used by students who are meeting logic gates for the first time. I worked on bugs and features in the simulation experience, including a race condition in the simulation engine.
That race condition is the contribution I learned the most from. It only appeared under specific timing, it was intermittent enough to be dismissed as a fluke, and finding it meant understanding a codebase I hadn't written. Reading unfamiliar code carefully is a skill, and it's not the same skill as writing code.
Hacktoberfest 2022, from the other side
I took part in Hacktoberfest as a contributor in 2021. In 2022 I was on the maintaining side, and the change in perspective was sharper than I expected.
I wrote contributor guidelines, reviewed and assessed 100+ PRs, and ran virtual office hours for people making their first contribution.
Reviewing at volume teaches you something being reviewed never does: how much a maintainer is inferring. A PR arrives with no context about what the contributor was trying to do, why they chose that approach, or what they tried first. The good ones explain themselves. I had been writing the other kind for two years without noticing.
We ended October with 200+ contributions, and 15 people kept contributing after the event ended. That second number is the one that meant anything — Hacktoberfest generates a lot of activity in October and most of it evaporates on November 1st.
Four things that stuck
Reading code is harder than writing it. And reviewing well is harder still, because you're trying to improve the change without discouraging the person who made it. I got this wrong for a while in the direction of being too agreeable.
Communication outweighs code. In async collaboration across time zones, a clear issue description saves more time than a clever implementation. The contributors who got the most done were rarely the strongest programmers.
Shipped beats perfect. I sat on my first few contributions polishing them. The polish was worth very little, and the review would have caught the real problems anyway.
A lot of valuable work isn't code. Documentation, issue triage, answering someone's question. Some of my most useful contributions contain no code at all — which is worth saying, because "contribute to open source" is usually heard as "write features," and that framing keeps people out.
If you're about to start
Start small — fix a typo, improve a doc, add a test. This isn't only about building trust with maintainers; it's about learning the project's review culture on a change where the stakes are nothing.
Read before you write. The CONTRIBUTING file, recent PRs, how the maintainers talk to people. Every project has opinions, and most of them aren't written down.
Open an issue before a significant change. The worst outcome in open source is a large PR that gets closed because it moves in a direction the maintainers had already ruled out.
Be patient. Maintainers are volunteers with jobs. A slow review isn't a verdict on your work.
Where it's left me
- Projects contributed to: 8+
- Pull requests merged: 50+
- Issues opened: 30+
- Contributors mentored: 15+
- Codeforces Specialist (rating 1411), Google Summer of Code 2022
The counts matter less than the habit. Open source is where I learned to work with people I've never met, in code I didn't write, on problems I didn't choose — which turns out to be an accurate description of most engineering jobs.