Most of the software I use every day is free. Not “free trial” free, but fully open, maintained by people who aren’t getting paid for it. For a long time, that didn’t make sense to me. Why would skilled developers spend hours writing, reviewing, and maintaining code for strangers on the internet?
So I decided to find out for myself.
I picked a project (OWASP), set up my environment, and attempted my first contribution. I expected it to be complicated, maybe even frustrating. And it was. But what surprised me wasn’t just the process—it was what I learned about why people keep showing up and contributing, even when there’s no paycheck involved.
Below, I'll share with you the things I learned from following open-source projects on social media, joining their communities, and ultimately making my first contribution.
1. Your Work Gets Recognized, Permanently
One of the most underrated perks of open-source contribution is recognition that goes far deeper than a LinkedIn endorsement. When you contribute to a public repository, that work is attributed to you on platforms where employers and collaborators are actively looking.
GitHub stars are one of the simplest and most visible signals of real-world impact. If a project you’ve built or contributed to has hundreds of stars, it shows that people are actually finding it useful—something a personal portfolio alone can’t easily demonstrate.
On top of that, tools like GitPOAP take recognition a step further by turning your merged pull requests into verifiable, shareable records tied directly to your GitHub identity. These show up as digital badges linked to specific contributions or events, making it easier to demonstrate not just what you’ve worked on, but where and how you’ve participated.
The most dramatic example of open source recognition, however, is the GitHub Arctic Code Vault. On February 2, 2020, GitHub captured a snapshot of every active public repository and encoded it onto archival film designed to last 1,000 years, then stored it beneath a mountain in Svalbard, Norway. If you contributed to any qualifying project before that date, your name is literally preserved in permafrost. GitHub marks this on contributor profiles with the Arctic Code Vault badge, visible to anyone who views your profile.
Contributing to open source doesn’t just build a resume. It builds a verifiable, public, and in some cases permanent record of who you are as a developer.
2. It Can Be a Hard Career Requirement
I used to think open-source was something you did after you got good. In reality, it’s often how you prove you’re good in the first place.
When I started exploring opportunities, especially in web3, I kept running into the same pattern: people who were getting internships, grants, or early roles almost always had some form of open-source contribution. Not massive projects. Just evidence that they had worked in public.
For instance:
Some internship programs (like those under OWASP) explicitly prioritize applicants who have made public contributions before
In many web3 communities like Ethereum, grants are normally given out to applicants that have open-source contributions in the ecosystem
And when I made my first few contributions, I realized that employers weren't asking for perfection. All they needed was proof that you can integrate into their current development workflow.
So while open source might look like “free work” on the surface, in practice it’s closer to:
- a public portfolio
- a collaborative interview
- and, in many cases, a gateway into opportunities
Even if you’re not targeting open-source-heavy roles, the habits you build while contributing are valuable. They include navigating large codebases, writing clear commit messages, and working asynchronously across time zones. These are professional skills most bootcamps and universities do not teach.
3. The Projects You Use Need You More Than You Think
There’s a tension at the heart of open source that most users never see. A handful of unpaid volunteers often maintains the tools that power trillion-dollar products. And when those volunteers get overwhelmed, entire categories of software become fragile.
The FFmpeg situation in mid 2025 illustrated this perfectly. FFmpeg is a multimedia framework that powers Google Chrome, YouTube, Firefox, VLC, and countless other products. It’s the silent backbone of internet video, maintained by just a handful of passionate developers. When Google’s AI security tool, Big Sleep, began filing vulnerability reports to the project without providing patches, FFmpeg maintainers fired back, arguing that Google’s AI tools were dumping reports without solutions on projects largely sustained by unpaid volunteers.
The community’s frustration was pointed and accurate: many in the FFmpeg community argue, with reason, that it is unreasonable for a trillion-dollar corporation like Google, which heavily relies on FFmpeg in its products, to shift the workload of fixing vulnerabilities to unpaid volunteers. You may not be a trillion-dollar corporation. But if you use a library every day and never contribute a bug fix, a documentation improvement, or a test case, you’re participating in the same dynamic on a smaller scale.
Since the earlier shown post on X, many companies like Spotify and Elevenlabs have contributed thousands of dollars to the project. You too can donate to the open-source projects you use by visiting their Sponsor page on GitHub.
4. You Get Free Mentorship From Senior Engineers
Open source is one of the few places where you can get your code reviewed by world-class engineers, for free, on real production software. That feedback loop is extraordinarily valuable, especially early in your career.
When you open a pull request, you’re submitting your work for scrutiny by people who have often spent years or decades on a codebase. They’ll tell you what you got wrong, how to fix it, and why the idiomatic approach matters. A review comment like “this causes an O(n²) lookup — consider a hash map here” teaches you something no tutorial video replicates, because it’s attached to code you wrote with real stakes.
Here’s what a simple but well-structured first contribution might look like:
# 1. Fork the repo on GitHub, then clone your fork locally
git clone https://github.com/your-username/some-project.git
cd some-project
# 2. Create a new branch — never work directly on main
git checkout -b fix/steps-in-readme
# 3. Make your edit, stage it, and write a clear commit message
git add README.md
git commit -m "fix: added missing steps in installation instructions"
# 4. Push your branch to your fork and open a pull request on GitHub
git push origin fix/steps-in-readme
This process, repeated across increasingly complex contributions, is how junior developers become mid-level ones. You’re practicing on real software, getting feedback from engineers who care about quality, and shipping real improvements. It’s structured learning with actual consequences — which is exactly what makes it stick.
5. You’ll Build a Network That Opens Doors
Open source communities are some of the most accessible professional networks in software development. You don’t need a warm introduction, a university connection, or a conference ticket. You just need to show up, be helpful, and be consistent.
Most active open source projects maintain a presence on platforms like Discord or Matrix, where contributors discuss bugs, debate design decisions, and share opportunities. These communities are global, and the people in them are often hiring, advising, or sitting on grant committees.
Contributing consistently puts you in direct contact with people who can change your career trajectory. You might receive an invitation to a paid open-source fellowship.
Programs like Outreachy or Google Summer of Code pay developers to contribute to open source full-time for a summer. You might get noticed by a maintainer who later becomes a professional reference or a startup co-founder. You might simply get a perspective-shifting conversation with a developer who solves problems very differently from anyone in your immediate circle.
This isn't hypothetical. Rich Harris, creator of the popular open-source JavaScript framework called Svelte, was hired by Vercel to work on it full-time.
The network effect of open source is slow and compounding. The developers who’ve been contributing consistently for two or three years have not just been building a stronger portfolio but also trust. In software, that trust is the hardest thing to build from scratch.
Where to Start
If you’ve never contributed before, the barrier feels higher than it actually is. You don’t need to fix a critical security vulnerability on your first pull request. Documentation improvements, test coverage additions, and bug reproductions are all legitimate, welcomed contributions. Most projects mark beginner-friendly tasks with labels like good first issue or help wanted, so you can filter to tasks that match your current skill level.
The best starting point is the tools you already use every day. If you find yourself wishing a library had better error messages, check whether there’s an open issue. If the documentation confused you the first time, you already know what’s missing. Your experience as a user is valuable context that maintainers don’t always have. Over time, these small contributions compound into real-world engineering experience that is hard to replicate in isolated practice.
Top comments (0)