Almost Went Down the Wrong Path: Open Source Contribution Is Not Stamp Collecting
Contributed for the sake of contributing, without deeply studying the repos, and got 20 PRs rejected. Until a veteran developer woke me up.
I almost went down the wrong path.
I say “almost” because I managed to turn back in time. But if you’re doing open source contributions, I hope you don’t step into the same traps I did.
Stamp-collecting contributions
Here’s what happened: after I started doing open source, I developed an illusion — that PR count equals contribution quality.
So I started filing PRs everywhere like stamp collecting. See a project, browse its issues, find something to change, write a few lines of code, submit. Then move on to the next project. At my peak, I had PRs open across four or five different repos simultaneously, and I hadn’t read more than 20% of the code in any of them.
The result? Twenty PRs got closed.
Not because the code was bad — honestly, there was nothing technically wrong with most of those changes. The rejection reasons were all over the place: wrong direction, meaningless change, maintainer didn’t need it, style mismatch. But at the root, it came down to one thing: I didn’t understand these projects.
I was filing PRs on codebases I’d never read deeply. It’s like a stranger walking into your house and saying “I think your sofa should be moved to the other wall” — technically not wrong, but who are you to say that?
What rejected PRs look like
Looking back at those rejected PRs, the pattern is clear:
Fixed a typo. In a project I’d never contributed to before, I fixed a spelling error in the README. The maintainer closed it without even leaving a comment. Not because the fix was wrong, but because this kind of PR was worthless to them — they don’t need typo hunters, they need people who truly understand the project.
Fixed formatting. A project had inconsistent function naming style. I filed a PR to unify the naming. The maintainer said, “This is legacy. It doesn’t affect functionality. Not changing.” I hadn’t even read the project’s code style guide.
Proposed a “better” approach. In a Rust project, I refactored a chunk of code according to my own aesthetic sense. The maintainer looked at it for two seconds and closed it — “We have our own style guide, please read it first.” I had never opened their style guide.
The common thread in all these PRs: I was measuring other people’s projects by my own standards.
A veteran developer woke me up
Later, I got chatting with a developer on GitHub and mentioned in passing that I’d had a lot of PRs rejected. He didn’t mock me, but he said something that made my face burn:
“What you’re doing right now is firing one shot and then moving to the next spot. You barely scratch the surface of each project, make a shallow change, and leave. This isn’t contribution — it’s farming for visibility. If you really want to do open source well, pick one project and dive in. Read its code. Read its issue history. Read its design decisions. Read until you can answer questions for newcomers. By the time you’re at that level, the PRs you submit — maintainers won’t reject them.”
Those words stung. Because he was right.
What I’d been doing, at its core, was taking shortcuts. Fixing typos, formatting, naming — these changes don’t require truly understanding a project. They just require knowing how to use grep. I was picking the “easiest to touch” problems, not the “most in need of solving” ones.
The shift
After that, I changed my approach:
Go deep on one project. No more casting a wide net. Pick a project I’m genuinely interested in and spend time reading its code. Not just the lines I plan to change — read the entire architecture, the entire test suite, the entire CI pipeline. Read until I can answer questions from newcomers in the issues.
Master one language. Before, I dabbled in everything — Java, Python, TypeScript, Rust — “able to write” in all of them but “proficient” in none. Now I focus on truly mastering one language — not just writing hello world, but understanding its design philosophy, its best practices, its community culture.
Be a user first, then a contributor. Before filing any PR, use the project first. Build something with it, step on its landmines, feel its pain points. Only when you’ve been bitten by a bug yourself does your fix carry any weight.
Help in issues first. Don’t rush to write code. Go into the issue tracker and answer questions, help reproduce bugs, discuss design proposals. Let the maintainers get to know you, let them see you’re serious.
The result
After the shift, my PR acceptance rate changed noticeably. Not because my code got better, but because I was picking the right problems.
Looking back now, those 20 rejected PRs weren’t wasted. They were the best tuition I’ve ever paid. Without those rejections, I might still be out there farming PR counts, thinking I was awesome, while actually learning nothing.
Open source is not stamp collecting. One truly meaningful contribution is worth more than a hundred changes nobody cares about.
— Jiahao Ren, May 2026