How to make Contributions ?
A practical guide to making real open source contributions - not just fixing typos, but shipping actual value.
Over the years, labeling yourself as an open source contributor has become part of the average developer’s identity. With AI’s second coming, everyone with $20 in their pocket is able to make changes to their favourite tools - or in the worst-case scenario, change the README file for Node.js. I almost was one of those developers. Being in my twenties and thinking that I should be better and keep up with the industry - this feeling haunts most of us daily. “Not doing enough.” But I’d argue that in 90% of cases we are doing pretty well, and sometimes more than enough. Still, what can stop a developer from making their favourite tool better, right?
The Wrong Way to Contribute
This is how I created my first PR to an Open Source tool - OpenCode.
Before you say anything - no, it was not a random AI-prompted PR that would be dead forever. I wanted to add a scrollbar by default instead of enabling it manually, and made some small tweaks that I genuinely liked. My PR never got reviewed for a very simple reason: developers are doing contributions wrong, and it makes you look worse. Creating thousands of useless PRs that will never be merged just to say in an interview “I contribute to OSS”? Great idea! Very bad - I can verify this in one minute and check whether you really did something or just edited the README.
Find What Actually Bothers You
So how should we contribute then? Obviously we can use AI - everyone does - but what should we tackle? This is where my story of a first merged PR comes in, and it goes to Theo and Julius - T3code. I was super skeptical about it since everything I heard from Theo on streams and videos was that it’s in Alpha and vibe-coded. I tried it, didn’t like it, forgot about it. Then I returned later because I was annoyed by Claude Code and wanted a better UI/UX. I found a small bug that was real and valid, decided to patch it up, and it actually got merged. You never forget your first merged PR to an open source project, and I’d probably never be that happy again.
That brought me the motivation and the idea that I can improve the tool for everyone and genuinely make it better. Now I have around 10 PRs open and a couple of them merged. Some were closed - and this is the default lifecycle of any PR in the wild. You need to accept that not everything should be merged, and you don’t need to tag people 100 times.
Small Repos, Real Impact
This brings us to DPcode. Emmanuel forked T3code to create his version of the app that matches my vision much more, and by that time it had around 100 stars. That was the moment I started contributing to both apps and got the understanding that you don’t need to work on the biggest repos on GitHub. You don’t need to try to patch up Node.js or React - you can go for your favourite tool that you use daily. You can always fork it and create your own version. You can be useful, and by being useful you will climb higher in your dev career.
Just Start
Still in my 20s, a couple of months after my first OpenCode PR, I’ve created PRs and issues for Codex, DPcode, T3code, and BetterAuth - all because I use these tools and found things that could be improved for all users. I advise you to do the same. Use open source tools, fork them, build for yourself, and spend your tokens building a better world with us!
Pro tip: When interviewers ask about your open source contributions, being able to point to actual merged PRs with real code changes beats saying “I contribute to OSS” every time.