I submitted my first open source PR two weeks ago. By my third, I'd learned more about professional engineering than months of working alone.
Here's what actually happened and what I took away from it.
Finding the Right Issues
My first instinct was to look for "good first issue" tags. That works, but I found better luck with a different approach: use the tool, hit a bug, fix it.
For my first PR on the MCP TypeScript SDK, I was using the library and discovered that empty object schemas broke OpenAI's strict mode. The error message was clear, the reproduction was obvious, and the fix was straightforward. Perfect first contribution.
The lesson: don't go hunting for issues to solve. Solve the issues you actually have.
Understanding Codebases Quickly
The MCP SDK is tens of thousands of lines. Reading it all would take forever. So I didn't.
Instead, I:
- Found the file where my bug lived (error messages help)
- Traced the relevant code path (just that one path)
- Understood the immediate context (the function, its callers)
- Ignored everything else
You don't need to understand a whole codebase to fix a bug in it. You need to understand the minimum viable context.
The hardest part was resisting the urge to explore. Stay focused on your specific change.
Submitting Quality PRs
My first draft got immediate feedback asking for changes. Not because the code was wrong—it worked fine—but because it didn't match the project's patterns.
What I do differently now:
- Read recent merged PRs to understand the expected style
- Match existing patterns even when I'd do it differently
- Keep the scope tiny — one fix, one PR
- Write the description for someone with no context
That last point matters more than I expected. Maintainers review dozens of PRs. They don't remember your issue. Make the PR description self-contained.
Code Review Feedback
Getting feedback on my code from experienced maintainers was genuinely valuable. Some things I learned:
On error handling: I was throwing generic errors. The maintainer asked for specific error types with clear messages. Seems obvious in retrospect, but I'd never had someone push back on my error messages before.
On API design: My first approach worked but didn't compose well with the existing API. The suggested alternative taught me to think about how code fits into the larger system.
On documentation: I thought the code was self-explanatory. It wasn't. Now I add comments explaining why, not what.
What I Wish I'd Known Earlier
The maintainers are people. They're not gatekeeping—they're trying to keep their project coherent while managing hundreds of contributions. Be patient. Be respectful. Make their job easier, not harder.
CI will fail. Probably on something stupid like a lint rule you didn't know about. Run the full test suite locally first.
Small PRs win. My 50-line PR got merged in a day. I've seen 500-line PRs sit for weeks because no one wants to review them.
Follow up, but not too much. If there's no response in a week, a polite bump is fine. Asking daily is not.
The Unexpected Benefits
Beyond the learning, OSS contributions give you:
- Proof of ability that anyone can verify
- Connections with experienced engineers
- A forcing function to write cleaner code
My GitHub now has merged PRs on real projects. That's not just a resume line—it's evidence that I can work with existing codebases, follow coding standards, and collaborate with other engineers.
For anyone early in their career: do this. Find a tool you use, find a bug, fix it. The learning is worth more than the code.