How I Fixed Bugs in 30+ Open Source Projects (And What I Learned)

Over the past few months, I've been contributing to open source as an independent developer. No big company backing, no team — just me, a laptop, and a lot of caffeine. Along the way, I've submitted pull requests to 30+ repositories across the Python, JavaScript, TypeScript, and Rust ecosystems.

Here's what I learned from the process — the good, the bad, and the "I wish someone told me this earlier."

Why Contribute to Open Source?

Let's get the obvious out of the way: it's not about the money (at least not directly). Most bounties pay $50-$500, and you'll spend 10-20 hours on a single PR if it involves deep codebase exploration.

The real value is:

1. Reputation — Each merged PR is a public signal that you can read, understand, and improve other people's code
2. Learning — You'll see how major projects are structured, tested, and maintained
3. Network — Maintainers remember helpful contributors. Jobs come from these relationships
4. Scratching your own itch — Fix a bug that annoys you? Everyone benefits

My Process: Finding Good Issues

Step 1: Pick the Right Projects

Not all projects are equally welcoming to new contributors. Here's my filter:

Signal	Good ✅	Bad ❌
Response time	< 7 days	> 30 days or never
Issue labels	good first issue, help wanted	None
CI/CD	Green, fast builds	Broken, 30min+ builds
PR merge rate	> 60% of open PRs merge	< 20% merge

Step 2: Find Issues You Can Actually Fix

I look for:

• Bug reports with clear reproduction steps — Someone already did the hard work of identifying what's wrong
• Issues labeled easy-fix or similar — The maintainer thinks it's approachable
• Issues in domains I know — Don't pick a C++ compiler bug if you've never written C++

Step 3: Before Writing Code

This is where most beginners fail. Don't start coding yet!

1. Read the CONTRIBUTING.md — Every project has different style, commit message format, and PR requirements
2. Look at recent merged PRs — What do good PRs in this project look like?
3. Comment on the issue first — Say "I'm working on this" so others don't duplicate effort
4. Set up the dev environment — Make sure tests pass before you change anything

Real Examples from My Contributions

Example 1: One-Line Fix (Pygments)

In pygments/pygments#3127, the CUDA lexer was inheriting from the C lexer instead of the C++ lexer. Since nvcc is a C++ compiler, modern CUDA code uses C++ features like constexpr and class.

The fix: One line change

# Before
class CudaLexer(CLexer):
# After  
class CudaLexer(CppLexer):

Sometimes the smallest fixes have the biggest impact.

Example 2: TLS Socket Leak (Tornado)

tornadoweb/tornado#3614 was trickier. When a TLS handshake times out in TCPClient.connect(), the underlying socket was leaking because ownership transferred to a new SSLIOStream that was then discarded on timeout.

The fix required:

1. Understanding Tornado's stream ownership model
2. Adding proper cleanup in the error path
3. Writing a test that reproduces the race condition

Total time: ~3 hours. Lines changed: ~15. But the learning about async socket handling was invaluable.

What Goes Wrong (And How to Handle It)

1. Your PR Gets Ignored 😴

This happens. A lot. Some maintainers are overwhelmed, some projects are understaffed, sometimes your PR just gets lost in the shuffle.

What to do:

• Wait 2 weeks before pinging
• When you ping, add value: "I noticed X merged recently, wondering if there's anything else needed for this one"
• If another month passes, it might be time to move on

2. Your PR Gets Rejected 🙅

Don't take it personally. Code review is about the code, not about you.

Common reasons:

• Missing tests — Always include tests when possible
• Style mismatch — Read the project's style guide
• Scope creep — Keep PRs focused on one thing
• Performance concerns — Your "fix" might be slower than the original!

3. You Get Blocked From a Project 🚫

Yes, this happened to me. Some projects have aggressive anti-spam filters, and submitting multiple PRs quickly can trigger them.

What to do:

• Don't panic
• Move on to other projects — there are millions of repos
• Maybe reach out to maintainers via other channels (Discord, email) to understand why

Tools That Helped Me

• GitHub CLI (gh) — Essential for everything: creating PRs, checking statuses, managing forks
• git-worktree — Work on multiple issues simultaneously without stashing
• pytest / jest / go test — Whatever the project uses, master it
• IDE with good git integration — I use VS Code with GitLens

By The Numbers (So Far)

Metric	Value
PRs submitted	30+
Repos contributed to	15+
Merged (so far)	Still waiting on most...
Average wait time for review	2-8 weeks
Biggest lesson	Patience matters more than code quality

What's Next?

I'm continuing to contribute to projects I use daily. The goal isn't to hit some number — it's to become the kind of developer who can jump into any codebase and make meaningful improvements.

If you're thinking about contributing but haven't started: open an issue right now. Find a project you use, look at their issue tracker, and pick something small. Your future self will thank you.

---

Have you contributed to open source? What's your experience been? Let me know in the comments!