I decided 2026 would be different, not in a “new year, new me” way. More like: I’ve been building in isolation for a long time. Side projects, client work, tools that sometimes ship and sometimes don’t. But I wasn’t doing one thing that actually makes you better:
Working inside someone else’s system.
Not my folder structure. Not my conventions. Not my assumptions. Someone else’s decisions, constraints, and tradeoffs. Plus the social layer: writing changes other people have to review, maintain, and trust.
So I started contributing to open source.
Why now
Part of it is selfish, in a good way.
I want to get sharper at reading codebases I didn’t write. I want to build the habit of shipping small changes that are correct and verifiable. I want to practice the kind of communication that makes collaboration easier, not harder.
And yes, there’s a career angle. Not “farming the contribution graph.” Just this: I want my public work to show I can operate like a professional on unfamiliar systems. Because that’s the job.
If you only build alone, you can tell yourself any story you want about your skills. Open source doesn’t let you do that. Your code either survives contact with other people… or it doesn’t.
What I picked (and why it matters to me)
I chose Open mSupply.
It’s an open source LMIS (Logistics Management Information System) for health supply chains. If you’ve spent time around healthcare delivery in West Africa, you know why this matters: the supply chain is the system. Vaccines, essential medicines, cold chain equipment, stock management, distribution. Everything depends on it.
Open mSupply is also built for realities I care about: intermittent connectivity, offline-first workflows, and environments where “it works on my machine” isn’t a useful standard.
And personally: mSupply’s work is relevant to Sierra Leone. That hits closer to home. It’s not just code in the abstract.
I’m also doing this alongside a full-time job, so I’m optimizing for consistency over intensity: one repo, steady contributions, real learning.
The rule I’m using
I’m trying to contribute in a way that signals one thing:
I can work like a professional.
Which, in practice, means:
- I can reproduce a bug (or baseline a problem) before touching code.
- I can keep scope tight: one PR, one purpose.
- I can explain what changed, why, and how it was tested.
- I can take feedback without ego and iterate.
What’s merged (so far)
These are my first five merged PRs in Open mSupply:
- #10253: Docs, add fork PR + CI notes
- #10219: Fix barcode scanning imports and Electron API null-safety
- #10220: Chore, remove Android IDE files and ignore .idea
- #10189: Add created date filters for internal orders and supplier returns
- #10190: Docs, fix CONTRIBUTING and README links
They’re not glamorous. That’s intentional. Early on, the goal isn’t “big features.” The goal is trust.
What I’m learning (the non-obvious parts)
“Good first issue” optimism is real. A lot of issues look easy until you try to reproduce them. Different OS, different database, different setup path. Sometimes the code moved. Sometimes your fix is “right” but breaks something else. My first real PR took longer to set up than to code. Fork CI doesn’t run the same checks. Yarn Classic v1 behaves differently than you expect. One initialization path throws ~3000 warnings that are totally normal. Don’t claim it’s fixed until you’ve reproduced it and proven it.
Tests aren’t a checkbox, they’re communication. In a shared codebase, a regression test is a message to future maintainers: “this behavior matters.” You learn systems faster by reading tests than by reading code.
The soft side is where PRs die. Most PRs don’t fail because the author can’t code. They fail because they’re annoying to review: too big, unclear “why”, no “how tested”, drive-by refactors.
Tooling friction is invisible from the inside. Maintainers have the right tools and the “magic incantations” in their heads. New contributors don’t. Removing friction (docs, onboarding, predictable workflows) is leverage.
What’s next
I’m going to keep contributing with the same approach: one repo, consistent cadence, small and correct PRs.
My next lane is sync and reliability, the offline-first backbone. If Open mSupply is going to work in the environments it’s built for, reliability work matters: reducing noisy failure modes, smoothing setup paths, improving debuggability without drowning people in logs, and making common workflows safer.
If you’ve been through this phase, learning to work in public, I’d love to hear what surprised you and what helped you stick with it.
Loading comments...