❯ The open-source advantage: what to share, what to keep

2026-09-24 ·5 min read

by Priya Anand — the product desk, Side Quest Studios September 25, 2026

Your repo is not your moat. Your repo is your marketing. I've watched two founders learn this the hard way in the same quarter, and only one of them is still shipping.

The first kept everything closed — every cron job, every retry loop, every weird systemd unit that keeps his workers from fork-bombing at 3am. He called it "proprietary IP." It was a for loop with a time.sleep(2) in it. He spent four months building a sales pitch around a black box, and when a prospect asked "can I see the source?" he had to say no. Deal died. The second founder started with the same code, pushed it to GitHub under Apache 2.0, wrote a README that explained the actual failure modes, and got three job offers and two inbound enterprise deals in six weeks. Same code. Different decision about what to share.

That's the whole game. Not "open source vs. closed." The game is: what exactly do you give away, and what exactly do you keep? Get that line wrong in either direction and you're broke. Get it right and the community does your outbound for you.

The default should be open, and you should be embarrassed when it isn't

Start here: if the thing you're protecting would take a competent engineer a weekend to rebuild from reading your blog post, it isn't a moat. It's a speed bump. Publish it.

Your retry logic. Your queue consumer. Your health-check endpoint. Your docker-compose.yml. Your Terraform module. Your Makefile. All of it. Ship it. Because the alternative — a closed box nobody can inspect — is exactly the thing you personally hate when a vendor does it to you. You know the feeling. You buy a $40k/year "AI platform," it breaks on a Tuesday, and support tells you to "clear the cache and try again." You want to see the code. So does your customer.

The industry is starting to have this argument out loud. Microsoft published a code of conduct for its models this week telling them not to hack systems or trick humans (Microsoft's new AI 'code of conduct'). Fine. Good intentions. But a document is not an implementation, and a policy is not a git log. If you want people to trust what your system does, the cheapest path is to let them read it. That's not ideology, it's just lower friction than a sales call.

And the "AI is fast food for the brain" argument (AI is fast food for the brain) is worth taking seriously for one reason: the antidote to slop is provenance. Open code has provenance. You can git blame it. You can read the commit that fixed the bug. You can't do that with a vendor's API that quietly changed its behavior on a Tuesday.

What to actually keep

Here's the list. It's short, and none of it is code you'd be proud of anyway.

Your data. Obviously. Never open your customers' data. Not in a demo, not in a "sample dataset," not in a screenshot. If you need to show a real example, generate it. faker in Python takes ten minutes. There is no excuse.

Your credentials and deployment config. Your .env, your secrets.yaml, your cloud IAM policies. This is not IP, it's a liability. If you've ever found an AWS key in a public repo at 2am, you know exactly how fast that goes from "oops" to "five figures."

Your customer list and your pricing. Let people self-serve. Don't publish who's paying you what. This is the actual moat for most small operators — not the code, the relationships.

Your taste. This is the one people miss. The code is open. The decisions are yours. Why you chose Postgres over Mongo, why you run on bare metal instead of a managed service, why your retry backoff is 2 seconds and not 30. Publish the code, keep the judgment. The judgment is what people pay for.

Notice what's not on that list: your architecture, your algorithms, your scaling playbook. Those should be open. If you're not willing to write a blog post explaining how your system works, you probably don't understand it well enough to sell it.

The 3am test

Here's how I actually decide. It's one question: if a customer's system goes down at 3am, would I rather be debugging my own code or a vendor's binary?

Every time I've had to debug a closed source system in production — a managed queue, a proprietary SDK, a "smart" autoscaler — I've lost hours. No strace. No gdb. No reading the source. Just a support ticket and a prayer. Every time I've had to debug my own open code, I've had it fixed in twenty minutes because I could read the actual line that broke.

That asymmetry compounds. It's not a philosophical preference. It's a bill you pay every time something fails, and things always fail.

So when you're deciding what to open, run the 3am test on it. If the answer is "I'd rather have the source," publish it. If the answer is "I'd rather have someone else on the hook," then you've found something worth paying for — and you should think hard about whether you want to be the one on the hook.

The licenses, quickly, because this is where people get stuck

You don't need a lawyer for the first version. You need a decision.

MIT or Apache 2.0 if you want maximum adoption and you're not worried about a cloud provider reselling your work. Apache 2.0 has a patent grant, which matters more than people think. This is my default. curl -O https://www.apache.org/licenses/LICENSE-2.0.txt and move on.
AGPL if you're building a service and you want to make sure anyone who runs it as a network service has to contribute back. Good for infrastructure. Scares some enterprises. That's the point.
BSL or "source available" if you're running a hosted product and you genuinely need to keep competitors from reselling it. It's not open source and you should stop calling it that. But it's a legitimate business decision, and being honest about it is worth more than pretending.

The mistake is agonizing. Pick one, put it in the LICENSE file, and get back to work.

The thing that surprised me

I expected open sourcing to bring in contributors. It mostly didn't. What it brought was trust. Prospects who would have ghosted a demo call read the README, ran the docker compose up, and showed up already sold. The sales cycle compressed by weeks. Not because the code was better — because it was visible.

The second thing: I got better bug reports. People running my code on hardware I don't own, in countries I've never visited, hitting edge cases I'd never see. That's free QA. That's the thing you're trading for the "IP" you think you're protecting.

Do this today

Open a terminal. Pick your least-embarrassing internal tool. Run git log --oneline | head -20. If the last twenty commits don't contain a customer name, a credential, or a pricing decision, you're probably safe to publish it.

Write a README that explains what breaks and why. Not a marketing page — a real one. "If you run this on more than 500 concurrent jobs, the queue will back up because the worker pool is fixed. Set WORKERS=32 in your env." That kind of README.

Then push it. Public. Today.

You will feel exposed for about six hours. Then someone will open an issue, and you'll realize the thing you were protecting was never worth protecting, and the thing you were afraid of showing was exactly the thing that makes people trust you.

We build and run these systems over at Side Quest Studios, and this is the posture we take by default — open code, closed data, own the judgment. Come find us when you're tired of black boxes.

References

AI-assisted, curated for Side Quest Studios.