The pitch for contributing to open source sounds great: build your portfolio, improve real software used by real developers, learn from maintainers who are very good at what they do. The reality involves a learning curve that the pitch usually omits.
Start With Issues, Not Features
The most common mistake is opening a repository, deciding to implement a feature, and submitting a pull request that the maintainers have no context for and cannot prioritize.
Start with issues labeled "good first issue" or "help wanted." These exist specifically because maintainers want external help with them. The scope is usually contained, the expected solution is often outlined in comments, and there is a higher probability of your PR being merged.
Small, Focused PRs Get Merged
A pull request that fixes one specific thing clearly is far easier for a busy maintainer to review and merge than a PR that refactors four files, adds a feature, and fixes two bugs simultaneously.
Fix one thing per PR. Write a clear description of what the problem is and what your change does. Include tests if the project has them — a PR with tests gets merged faster and with less back-and-forth.
Documentation Contributions Are Real Contributions
Developer culture sometimes treats documentation as a lesser contribution. This is wrong.
Good documentation is hard to write, high-value, and genuinely appreciated by maintainers who are often too close to the codebase to write it well. Finding a confusing section of docs, understanding what it should say, and rewriting it clearly is a real contribution.
The Time Problem Is Real
Most developers cannot contribute to open source after a full day of professional development. The energy is simply used up.
Short, focused sessions work better than planning dedicated blocks of time. Fix a typo you notice while using a library. Clarify an error message. These small contributions compound over time and build genuine familiarity with a codebase.