For a long time, I thought open source was mainly about giving back.
I still believe that.
But after contributing to more production repositories, I've started looking at it differently.
Open source is one of the few places where your work speaks before you do.
This week I opened another pull request—this time for Nango—to improve how OAuth2 Client Credentials errors are handled.
Instead of returning a generic empty error, the implementation now preserves the provider's response so developers can actually understand what went wrong.
On the surface, it's a small improvement.
In reality, it removes hours of unnecessary debugging.
The Problem
The existing flow returned an opaque error similar to this:
unhandled_oauth2_cc_error
payload: {}
The actual provider response was available internally, but it never reached the developer trying to diagnose the issue.
That meant people integrating OAuth providers were left guessing.
The Fix
The pull request introduces a dedicated handled error for OAuth2 Client Credentials failures.
Instead of hiding the upstream response, it now returns useful debugging information.
Conceptually, the flow changes from this:
OAuth Provider
│
▼
Generic Error
│
▼
Developer has no idea what happened
to this:
OAuth Provider
│
▼
Provider Response Preserved
│
▼
Meaningful Error Payload
│
▼
Faster debugging
Sometimes the biggest improvements aren't new features.
They're making existing systems easier to understand.
What Open Source Really Gives You
Every contribution is public evidence of your engineering ability.
People don't have to guess whether you can work on production software.
They can see it.
Every pull request demonstrates things like:
Reading unfamiliar codebases
Understanding architecture
Writing production-ready code
Passing automated security reviews
Collaborating with maintainers
Explaining technical decisions
That's much stronger proof than listing technologies on a résumé.
Why I'm Building BashOps Radar
After contributing across many repositories, I noticed another problem.
Finding the right repository is surprisingly difficult.
Some projects have hundreds of open issues but inactive maintainers.
Others have responsive founders but poor onboarding.
Some repositories are excellent for learning.
Others have real potential to lead to consulting work or long-term contracts.
That's exactly why I started building BashOps Radar.
The platform helps developers identify repositories where a contribution has the highest chance of becoming something bigger.
Instead of randomly searching GitHub, developers receive signals such as:
✓ Opportunity Score
✓ Best First Issue
✓ Merge Probability
✓ Proof-of-Work Strategy
✓ Founder Outreach Direction
✓ Contract Potential
The goal isn't to automate engineering.
The goal is to help developers invest their engineering time where it creates the most leverage.
A Pattern I've Started Seeing
The developers I admire don't spend all day talking about their skills.
They leave a trail of work.
Issue
↓
Pull Request
↓
Code Review
↓
Merge
↓
Trust
↓
Conversation
↓
Paid Opportunity
That's a much stronger path than relying only on cold outreach.
Final Thought
The next contract you land probably won't happen because someone liked your portfolio.
It might happen because someone reviewed your code weeks before they ever spoke to you.
That's why I keep contributing.
Not because every pull request gets merged.
But because every pull request makes my work visible.
Links
🌐 BashOps Radar
⚙️ GitHub Action
https://github.com/marketplace/actions/bashops-radar
I'm documenting the journey of building BashOps Radar in public while contributing to production open-source projects. If you're using open source to grow your engineering career, I'd love to hear what's worked for you.
Top comments (0)