What One Meaningful Open Source PR Can Actually Do
I had raised only four open source pull requests.
Just four.
So when someone from Shipd.AI reached out to me about joining the Olympus Quest, it genuinely caught me by surprise.
I had not applied.
They had discovered me through my open source work, and one contribution in particular, my PR to Gitea, showed enough depth for them to approach me.
That moment completely changed how I looked at open source.
Because until then, I also believed that having more contributions automatically meant having a stronger profile. Ten PRs looked better than four, fifty looked better than ten, and a completely green GitHub graph felt like the final goal.
But apparently, four PRs were enough.
A little context about Shipd.AI
Shipd is a contributor platform by Datacurve (YC W24). It brings developers into technical projects across software engineering, machine learning and data science.
These projects are called quests. Contributors work on challenging engineering problems, submit their solutions and earn bounties for approved work.
Olympus was one of those quests.
Getting approached for it felt great, obviously. But the part that stayed with me was why they had reached out.
It was not because I had hundreds of open source contributions. It was not because my GitHub profile was filled with badges.
It was because one contribution showed that I could enter an unfamiliar codebase, understand a real engineering problem and stick with it long enough to solve it properly.
That contribution was my Gitea PR.
The Gitea issue that made the difference
The issue was related to the job lifecycle inside Gitea Actions.
The task was to introduce a transitional cancelling state between a cancellation request and a job actually stopping.
It initially sounded simple: add a new status, update a few conditions and write the tests.
Classic this should not take too long moment.
But once I started reading the codebase, I realised that the status affected much more than one field. It was connected to the overall workflow state, running jobs, cleanup behaviour and several parts of the Actions system.
Before writing the change, I had to understand how the complete lifecycle worked and which existing assumptions the new state could break.
That was what made the PR valuable.
The code was only the visible result. Most of the actual work happened while reading, tracing, getting confused, understanding a little more and repeating the process until the system finally made sense.
One PR can represent a lot
GitHub counts every merged pull request as one, but the depth behind each contribution can be completely different.
One PR might change a small condition in a single file. Another might require understanding a state machine, tracing behaviour across multiple modules, reading existing tests and handling edge cases without breaking the rest of the system.
Both still increase the PR count by exactly one.
That is why the number alone rarely tells the complete story.
My Gitea PR taught me how to enter a large codebase I had not built, understand an unfamiliar subsystem and make a change that fitted into its existing architecture.
It also made me realise that writing code is often not the hardest part.
Understanding where to make the change, why the existing system behaves that way and what else could break usually takes much longer.
That depth was enough for someone at Shipd to notice my work and reach out.
Small contributions are not the problem
This does not mean every open source contribution needs to be extremely complex.
Small contributions matter too. A documentation fix, a UI improvement or a small bug can be a great way to understand a repository, learn its contribution process and interact with maintainers for the first time.
Everyone has to begin somewhere.
The problem starts when increasing the PR count becomes the only goal.
It is easy to begin treating open source like a game: find the easiest issue, raise the PR, get it merged and immediately move on to the next one.
You might end up with a large number on your profile, but not every contribution will give you a meaningful story to tell.
With my Gitea PR, I could explain the problem, the system around it, the assumptions that could break and what I learned while solving it.
That gave the contribution weight.
Not because it was the most difficult issue ever solved, but because I had gone deep enough to genuinely understand what I was changing.
This is why contribution depth matters
This experience also connects closely with why I built Flux.
GitHub is great at showing activity, but activity and impact are not always the same thing.
A contribution count cannot explain that one PR required you to understand the lifecycle of an entire system. It cannot show the hours spent reading code, the edge cases discovered during testing or the feedback that improved your thinking.
It simply shows one more merged pull request.
Flux is my attempt to help contributors present the actual story behind their open source work, not only the number attached to it.
What did you work on?
Which part of the system did you understand?
What challenges did you face?
What did that contribution teach you?
Those details often say far more about a developer than the number of green squares on their profile.
Because I had only four PRs.
I never applied to Olympus.
Someone saw my work, understood the depth behind it and approached me.
So, do not contribute only to make your GitHub graph greener.
Start small. Learn the process. But eventually, choose an issue that forces you to slow down and properly understand the system in front of you.
Find a problem worth solving.
Go deep enough to solve it well.
And make sure every PR leaves you with more than just another number.