In last month’s Lab Note I installed gstack on a fresh mini PC and watched it ship a feature end-to-end. This one is the small sequel: I found a bug in /ship, fixed it, and the patch landed in gstack v1.30.0.0 with credit in the changelog.
I want to talk about why open source is having a moment again, and why solo consultants like me can finally participate in it — not as a hobby, but as part of the day job.
Quick context
gstack is Garry Tan’s opinionated stack of Claude Code commands — twenty-three tools that act as CEO, designer, eng manager, release manager, doc engineer, and QA, all bundled into a single cohesive workflow. It’s the closest thing the AI-coding world has to a “default” right now. 92.5k stars on GitHub. I’ve been using it across every project for a few sprints.
The bug was in /ship — the step at the end of a sprint that’s meant to verify everything in PLAN.md actually got built. The gate was supposed to catch deliverables that didn’t ship. It didn’t, and one of mine slipped through on a recent sprint. My PR added four structural fixes to the gate, locked them in with a small test suite, and shipped.
That’s the technical story. The interesting story is what happens around it.
Open source is having a moment
For most of the last decade, the centre of gravity in software shifted away from open source. SaaS won the developer-mindshare war. The default place to put a tool wasn’t a public repo with a permissive licence — it was a managed product behind a credit card and a usage tier. Open source kept shipping in the background (it always does), but the cultural energy moved elsewhere, and contributing to a project you didn’t already work for started to feel like a thing other people did.
That’s flipping. The tools defining the AI-coding wave — Claude Code, Codex, gstack, OpenClaw — are open or open-friendly by default. Public repos are where the interesting work is happening again. PRs land, changelogs get written, maintainers say thank-you in public. It’s reminiscent of the early-2010s GitHub era, except the contributors aren’t all full-time engineers anymore.
Open source never went away. But the gravity is returning to it, and that matters — for the durability of the tools we depend on, and for who gets to shape them.
The default move is silence
If you’re a solo consultant and a tool you depend on has a bug, the default move is one of three things:
- Work around it. Quietly. You’ve got billable work to do.
- File a bug report. Maintainer might pick it up in three months. Or never.
- DM the maintainer. They might thank you. Nothing changes.
None of these are bad. They’re the path of least resistance. The default mode of consulting is consumption — you use the tools, you bill for the outcomes, you move on.
The fourth option — fix it yourself and submit a PR — used to be reserved for people with the time, the language fluency, and the appetite for navigating a stranger’s codebase. Most consultants don’t fit that description. Most of us have built our careers around steering ships, not soldering wires.
But that’s changed.
The economics flipped
Here’s the bit worth internalising: Claude Code wrote most of the patch. I diagnosed the failure mode (the part that needs the consultant brain), told it which guardrails the fix needed to enforce, and handed it off. Five test assertions, no LLM dependency, runs in 60 milliseconds. The whole thing took an afternoon.
Five years ago this would have been a weekend job. Reading through a stranger’s TypeScript codebase, finding the right hooks, writing the test harness, learning their conventions — it all adds up. Today, the cost of being a contributor instead of just a consumer has collapsed.
This is the quiet thing the new generation of AI coding tools has actually given me back: code itself. I’ve been a CTO and a fractional CTO for long enough that “still ships code” was edging out of the honest answer. With Claude Code and Codex I can guide the work line by line, ship it, test it, and stand behind it. The barrier to participating in someone else’s project — really participating, not just reporting things — collapsed at the same time.
That changes the calculus. If the fix is going to take an afternoon and the alternative is working around the bug forever — of course you ship the patch.
Why bother — the consultant’s angle
There’s a narrow self-interest version of this: a CHANGELOG mention is better positioning than any number of “thought leadership” posts. It’s verifiable. It’s external. It says you live inside the tools your clients are deciding whether to adopt.
But the broader version is more honest. If you’re going to spend the next decade building inside someone else’s stack, the relationship can’t be one-way. You owe the people maintaining your tools the same diligence you owe your clients.
Solo consulting can feel transactional in a way that quietly corrodes — you’re always the supplier, the deliverable comes from you, the dynamic flows one direction. Pushing code upstream is one of the few moves that breaks that pattern. It’s small. It costs you a few hours. And it puts you back in the position of being a participant in the ecosystem, not just a vendor charging for outcomes within it.
The practical takeaway
If you’re a solo consultant or a fractional CTO and you’ve been quietly working around the same bug for months: write the issue. If you’ve got a fix in mind, write the PR. The barrier is roughly an afternoon and a bit of conviction.
The maintainers will thank you. The changelog will have your name on it. And the next time a client asks whether you actually ship code, you’ll have something better than a portfolio. You’ll have a commit history.
PR #1302, if you want to see what an “afternoon” looks like in 2026.