A contribution to a project you do not own reads as credible work on a CV when the entry names exactly what you did to it: a specific pull request that merged, a bug you tracked down and fixed, a review you gave that shaped someone else's change, or a maintainer role you hold in the project, rather than just a repository name sitting next to a link. Open source work differs from a project you built yourself in one important way: your name sits inside a commit history alongside other people's names, on a project that had its own maintainers before you showed up and kept running after your change landed, so the entry has to state your specific part precisely rather than letting a reader assume you own the whole thing.
Why an open source line needs different phrasing than a project you own
For a project you built and control end to end, presenting side projects on a software engineer CV covers describing what it does, what you built it with, and what changed because you built it. An open source contribution asks a different question first, not what the project does, since the reader can usually look that up in seconds if the project is well known, but what you specifically did inside a project that already existed and already had its own direction. A vague line next to a well-known project's name, with nothing describing your actual involvement, can read as an attempt to borrow that project's reputation rather than a description of real work, which is the opposite of what the entry is meant to achieve.
Contribution types worth naming specifically
A merged pull request is the clearest unit of contribution to name, and naming what it changed matters more than naming that it exists: a fix for a specific bug, a new feature, a performance improvement, or a piece of documentation that was missing. Code review is real, valuable work on an active project and is worth listing separately from your own merged changes when you have done enough of it to matter, particularly on a project where review quality is part of how the maintainers judge a contributor's standing. A maintainer or triage role, where you have commit access, review other people's pull requests, or manage issues for a project, is worth its own line rather than folding it into a generic "contributor" mention, since it says something a single merged fix does not: that other maintainers trust your judgment on an ongoing basis. Recurring contributions to the same project over months are also worth describing as a pattern rather than only listing the single most impressive merged change, since a pattern of activity reads as sustained involvement rather than a one-off.
Illustrative example: an open source contribution bullet
Illustrative example, vague to specific. Vague: "Contributor, open source project (github.com/example/project)." Specific: "Contributor, an open source command-line tool used for local development environments. Fixed a bug causing the tool to hang on large configuration files, and reviewed several other contributors' pull requests for the same repository over six months." The second version names the project's purpose in one clause, states what the merged change actually fixed, and separates the reviewing work from the fix itself instead of implying the whole line describes a single contribution.
Crediting shared work without overclaiming
Every merged change on an active open source project usually passed through someone else's review before it landed, and a CV entry that implies sole authorship of a feature several maintainers actually shaped together reads as overclaiming the moment anyone checks the commit history, which for a public repository takes seconds. Naming your specific contribution, one fix, one feature, one area you review regularly, rather than describing the whole project's functionality as if you built it single-handedly, keeps the entry both honest and, in most cases, more specific and more credible than a broader claim would have been anyway. Where several of your contributions cluster around one area of a project, such as its build tooling or its test suite, naming that area is often more informative to a reader than listing several small pull requests individually.
Where this differs from a project you own outright
A side project you built from scratch earns a line describing its purpose and outcome because you made every decision about what it does and how. An open source contribution earns a line describing your specific part inside someone else's decisions, since the project's overall direction, its architecture and its scope were usually set well before you arrived. Both are legitimate technical work worth a place on a CV, but conflating the two, describing an open source contribution the way you would describe your own project, tends to either overstate your role in the shared project or understate the real, specific work you actually did.
Where it belongs on your CV
A single significant open source contribution, or a maintainer role held over time, commonly earns its own line inside a projects section alongside personal projects, since both describe technical work outside a paid role. Several smaller contributions across different projects are often better grouped under one heading, such as "Open source contributions", naming each project briefly rather than giving four thin, near-identical lines the same visual weight as a single well-described entry. The Developer template is built with a projects area alongside the work history, which suits this kind of entry whether it grew out of a job or stands entirely apart from one.
Add it to your CV
An open source contribution, described specifically and credited honestly, is real evidence of technical judgment that a reader can often verify directly. Start from a template built for engineering work and add your contributions in the builder, where you can keep refining the wording as new contributions land.