Is Open Source Worth It in the AI Era?
2026-07-01 · 5 min readI’ve spent most of my career assuming open source is a default good — you build something, you put the code out, the community makes it better, everyone wins. I still believe that most of the time. But two things have been nagging at me lately, and I don’t think I can resolve them cleanly, so I’m writing them down instead.
Argument one: you’re publishing a map
The classic security argument for open source is “many eyes make bugs shallow” — enough people read the code, someone spots the flaw before an attacker does. That argument was always a little optimistic (plenty of famous vulnerabilities sat in plain sight in popular open-source libraries for years before anyone noticed), but it’s gotten shakier now that “reading the code” is something an AI agent can do at scale, continuously, for free, on every public repo it can find.
An attacker no longer has to be a person who understands your codebase. They can point an agent at your repo and ask it to reason about your auth flow, your input validation, your dependency graph, and your deploy config, and get back a prioritized list of soft spots — the same kind of architectural reasoning a senior engineer would do on a code review, except it scales to every repo on GitHub simultaneously and never gets bored. Open-sourcing your code doesn’t just risk a vulnerability being found; it hands over the reconnaissance step for free. As I’ve put it to myself while deciding what to open up: it just hands an AI a map of where you’re weak.
That’s part of why the auth and user-data module of one of my own projects has stayed closed-source, even from early on, well before “AI agent reads your repo” was a mainstream worry. The rest of the codebase — the interesting, differentiated parts — I’ve been comfortable sharing. But the module that decides who gets in and what happens to people’s data felt like a bad place to hand out a floor plan, and I still think that instinct was right, even if the reasoning behind it (attackers get smarter tools) has changed since I first had it.
Argument two: code without a business model dies anyway
The second argument is less about attackers and more about attrition. Plenty of genuinely good, well-maintained open-source projects still fold — not because the code was bad or the maintainers stopped caring, but because nothing was paying for the maintainers’ time. Goodwill is real, but it’s not a renewable resource at the rate a serious project needs it. Sooner or later the project dies anyway without a business model behind it, openness or no openness.
If that’s true, the security argument above is almost moot for a lot of projects — the vulnerability never gets exploited because the maintainers already walked away and the repo is quietly rotting in an unmaintained state, which is arguably worse than either alternative.
The tension I can’t fully resolve
Here’s what makes this uncomfortable for me specifically: I’ve argued at length that CC0 — zero restrictions, no strings attached — is the right license for openly licensed Bible texts, precisely because openness removes friction, invites local ownership, and lets communities build sustainably on top of a shared resource. I still believe that. I’ve also written about wanting Bible translation to move toward permissionless, decentralized tooling built and extended by the communities using it, not gatekept by a central authority.
So why would I turn around and be cagier about code than I am about content? Part of the answer might just be that content and code fail differently. A Bible text doesn’t have an attack surface. Nobody can use a translated verse to compromise a server or exfiltrate user data. The “many eyes” argument for content is basically just quality and reach — more translators, more dialects, more reviewers — with none of the security downside, because there’s no exploit sitting in a psalm. Code is different: openness and attack surface aren’t separable the way openness and translation quality are. Maybe that’s the whole answer and I’m overthinking it. Or maybe it’s a rationalization I’ve backed into because I already had a closed-source module and needed a reason.
I don’t have a tidy rule here, and I’m suspicious of anyone who does. If you’ve found a decision framework that actually holds up — something more principled than “vibes about which module feels sensitive” — I’d like to hear it, because right now I’m mostly running on instinct and a lingering unease about what an agent could do with a full read of my repo.