My Journey into Open Source: From fixing Typos to Maintainer

The biggest lie developers tell themselves is: 'I'm not good enough for Open Source yet.' I told myself this for two years. When I finally made my first PR, I realized that Open Source isn't a club for elites—it's a massive collaboration where help is desperately needed.

How I Started (The Timeline)

Here is exactly how I progressed. Use this as your roadmap.

• Month 1: The 'Typo' Phase
  I found documentation errors in libraries I used. My first PR was literally fixing 'recieved' to 'received'. Maintainers merged it in 1 hour. That green 'Merged' badge gave me confidence.
• Month 3: The 'Reproducer' Phase
  I didn't fix bugs, I found them. I would create minimal reproduction repos for issues reported by others. Maintainers love this because it saves them hours of debugging.
• Month 6: The 'Bug Fix' Phase
  I tackled a `good first issue` in a UI library. It was a one-line CSS fix for a z-index issue.
• Year 1: The 'Feature' Phase
  I implemented a new hook for a state management library. This involved discussing the API design with the core team.

Imposter Syndrome and Rejection

It wasn't all smooth sailing. My 3rd PR was closed without merging. The maintainer said, 'This feature is out of scope.'

I felt crushed. But then I realized: Rejection is part of the engineering process. It forces you to align with the product vision. I learned to open an Issue before writing code to discuss the idea first.

Tools to Find Issues

Don't just browse random repos. Use these tools:

• GoodFirstIssue.dev: Curated easy issues.
• Quine.sh: Finds repos matching your language skills.
• CodeTriage: Sends you one issue a day.

Actionable Steps for You

1. Pick a tool you use daily. (e.g., Tailwind, React, a VS Code extension).
2. Read the CONTRIBUTING.md. This file is the law.
3. Filter issues by 'good first issue'.
4. Don't ghost. If you claim an issue, communicate.