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:

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)

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!