Contributing to Open Source: Your First Real PR

Your first real open source contribution feels like trying to join a band you have never met by walking on stage mid-song. The codebase is huge. The conventions are unwritten. The maintainers seem busy. You open a PR and then nothing happens for two weeks, and you start to wonder if you said something wrong.

I have been on both sides of this. I have opened PRs that got merged in an hour and PRs that died in silence. The difference is almost never the code. It is everything around it.

This is a guide to the parts they do not teach you.

Why most first PRs fail

Most failed first PRs share the same pattern: a brand new contributor picks the biggest, most famous project they can find, opens an issue with no context, and submits a 600-line refactor for a problem the maintainers never agreed was a problem.

The maintainers do not respond. The contributor concludes open source is unwelcoming. Both sides walk away frustrated.

The fix is not more skill. It is better aim.

Pick a project that wants you

Famous projects are saturated. Junior issues get scooped in minutes. Maintainers are overworked. You are competing with hundreds of other people for the same “good first issue” labels.

Better picks:

• A library you actually use. Even a small one. You already know the API, the pain points, and the docs.
• A project under a thousand stars with active maintainers. Less competition, more attention to your PR.
• A project run by a single person or a small team that publicly says they want contributors.

Check the issue tracker. Are issues being closed regularly? Are PRs being reviewed within a week? Are maintainer comments friendly or curt? You can tell a healthy community from a hostile one in 10 minutes of scrolling.

If a project has 30 stale PRs from 2022, do not open the 31st.

Find the right first issue

The classic advice is “look for good first issue labels.” Fine, but those are picked over. Two better strategies:

1. Fix something that bit you. If you used the library and hit a confusing error, the fix to that error is your first PR. You already have context.
2. Improve docs that confused you. Doc PRs are unsexy and almost always merged. They build trust with maintainers. They count as real contributions.

A merged doc PR is worth more than ten unread code PRs. It puts your name in the contributor list and starts the relationship.

Read the codebase like a detective

You do not need to understand the whole project. You need to understand the slice around your change.

The fastest path:

• Run the tests. Make sure they pass on main before you touch anything.
• Find the test for the area you are changing. Tests are usually the best documentation of intent.
• Use git blame on the relevant files. Who wrote this? When? Why? Read the linked issues and PRs.
• Search for similar PRs. Has anyone done a similar fix before? How was it reviewed?

This is also where strong fundamentals help. You will need to reason about whether a change is correct under load or scale, which means thinking in terms of big-O notation and core data structures from what is DSA. Maintainers notice when a contributor reasons clearly about cost, not just correctness.

Open an issue before you open a PR

Unless the project explicitly says otherwise, do not surprise the maintainers with a 400-line PR. Open an issue first.

Hey, I noticed X behaves unexpectedly when Y. Would a PR that does Z be welcome? Happy to draft it if so.

Three sentences. You have given them context, asked for buy-in, and offered to do the work. Maintainers respond to this. They ignore drive-by PRs.

If they say “go for it,” you have a green light. If they say “we are not interested in changing this,” you saved yourself a week of work.

Write the PR like a professional

This is where most first-timers self-sabotage.

• Keep the diff small. One change per PR. Don’t reformat unrelated files. Don’t add a dependency unless asked.
• Follow the existing style. If the project uses 2 spaces, you use 2 spaces. If they use snake_case, you do too.
• Add a test. If the project has tests, your PR has a test. No exceptions.
• Write a real description. What, why, how. Link the issue. Mention any tradeoffs you considered.

A well-written description signals that you respect the maintainer’s time. That alone moves you to the top of the review queue.

Handle the silence

You open the PR. Then nothing happens for 10 days. This is normal. Maintainers have day jobs.

What to do:

• Wait at least a week before nudging. Anything less reads as impatient.
• Nudge politely. “Hey, just wanted to bump this in case it slipped by. Happy to make any changes.” One sentence. Never demanding.
• Keep your PR mergeable. Rebase if main has moved. A PR with conflicts is much easier to deprioritize.

If two weeks pass with no response, it is fair to assume the project is not active. Move on without bitterness.

Handle the rewrites

A maintainer might come back and ask for major changes. Do not get defensive. They know the codebase better than you do.

Read the feedback charitably. Ask clarifying questions if anything is unclear. Push back only if you have real evidence, and frame it as a question, not an argument.

If they rewrite half your PR before merging, that is fine. Your name is still on it. Take the win.

Building a real OSS track record

One merged PR is a great start. Five merged PRs in the same project gives you a story. Becoming a regular contributor in one community is worth more than scattering ten PRs across ten projects.

This pays off in your career in concrete ways. It gives you real production code to point to in interviews. It builds a public portfolio that is more honest than any side project. It also gives you stories to use in behavioral rounds when paired with the broader prep in dev interview prep basics, and you can name the contributions directly on your resume with links recruiters can verify.

What open source actually teaches you

Beyond the resume value, contributing teaches you things a private codebase cannot:

• Reading other people’s code. This is most of senior engineering.
• Negotiating design with strangers. No shared context, no shared boss.
• Writing for an unknown audience. Your commit messages and PR descriptions are read by people who have never met you.
• Receiving feedback without getting hurt. A public review feels different from an internal one. You grow a thicker skin.

These are skills you cannot easily learn at work. Open source is one of the few places they get practiced in the open.

Wrap up

Your first real PR is not about the code. It is about picking the right project, building the right relationship, and respecting the maintainer’s time. Small diffs, clear descriptions, real tests, polite nudges, charitable responses to feedback.

Do that on a project where the maintainers are actually present, and your first PR will get merged. The second one is easier. By the tenth, you are a contributor. By the fiftieth, you might be the maintainer.

Start small. Stay around. The rest takes care of itself.