Cal.com went proprietary on April 14, 2026. Five years as open source advocates, then the pivot: their production codebase moved from AGPL to proprietary, with AI security listed as the explicit reason.
Cal.com’s argument
Co-founder Bailey Pumfleet summarized the decision plainly: “just having a previous-generation model like Claude Opus analyze an open-source codebase makes it trivial to find vulnerabilities.” Code visibility, in his framing, becomes an attack vector in the age of AI-assisted exploitation.
Cal.com didn’t abandon open source entirely. Cal.diy is a community version released under the MIT license. The production codebase has already diverged significantly, though, with authentication and data handling rewritten. Developers who built on open source Cal.com now face a choice: follow the proprietary version, fork Cal.diy, or migrate.
The real problem is velocity, not visibility
The Black Duck 2026 OSSRA report documented a 107% increase in mean vulnerabilities per codebase, reaching 581 per application across 947 codebases in 17 industries. 87% of audited codebases contained at least one vulnerability; 44% had critical-risk issues.
Pumfleet cites these numbers as validation, but he’s reading them backward. The surge doesn’t show that open source is inherently less secure — it shows that AI-generated code reaches production without adequate review time. The actual vector isn’t the license: it’s production speed without review. A proprietary codebase growing at the same pace accumulates the same security debt that AI-generated code creates, just out of sight.
Pumfleet, with this framing, is inverting the causal chain.
How open source security actually works
Open source’s defensive model isn’t based on obscurity. It’s based on distributing the cost of auditing.
Simon Willison, quoted in the original Register piece, framed it precisely: open source projects can share their vulnerability auditing budget across the entire community, while closed-source software has to find all the exploits internally, with one team and one budget.
As AI tools lower the cost of vulnerability scanning toward zero, this advantage doesn’t shrink — it scales. Every researcher, every security team, every developer with access to a model can analyze a public codebase. Cal.com, by closing its code, converts its asset from distributed eyes to a few internal eyes, paid.
There’s a factor Pumfleet skips entirely: the same AI models that find vulnerabilities in open source code can reverse-engineer compiled binaries. Code secrecy is not a sustainable defense against an attacker with adequate AI tooling. It’s a barrier for honest contributors, not for adversaries.
This gap widens as AI tooling becomes cheaper. A researcher today can run automated security scans against any public repository, identify a vulnerability, write a patch, and have it reviewed by maintainers in days. That pipeline doesn’t exist for closed-source software. The fix has to come from inside, from the same team that may have introduced the flaw.
TechMonk’s take
Cal.com’s decision stacks three separate errors, and they’re worth naming individually because they tend to travel together.
First: confusing visibility with vulnerability. Security through obscurity has been discredited so thoroughly that relitigating it requires ignoring the past thirty years of security history. OpenBSD’s threat model, academic cryptography in the 1990s, two decades of CVE data from commercial software all point in the same direction. It doesn’t stop competent attackers; it stops auditors, researchers, and patch contributors. Pumfleet is resurrecting a settled case.
Second: misreading Black Duck’s data. The 107% surge in vulnerabilities per codebase is not an indictment of open source. It’s an indictment of unsupervised AI-generated code shipping without review. The correct correlation: AI lowers the barrier to writing code, code written without review reaches production with more flaws, regardless of license. The problems that come with AI code aren’t fixed by changing the license; they’re fixed by changing the process. The legal exposure that vibe coding creates under GPL follows the same logic: the license is irrelevant if no one controls what goes in.
Third, and most consequential: underestimating what happens when AI enters the equation from the defensive side. When the cost of vulnerability scanning approaches zero, so does the cost of defensive auditing. An open source project with hundreds of contributors, an active review process, and AI tooling accessible to anyone has coverage capacity that an internal security team can’t match in absolute terms. Cal.com was exactly that kind of project: a community watching the code, testing it, patching it. It chose to give up that advantage, citing as a threat the same tools that would have made that coverage more thorough.
The practical result is that Cal.com has joined the security model used by Oracle, SAP, and every enterprise closed-source vendor. All of them have dedicated security teams. All of them still produce hundreds of CVEs per year. If secrecy protected software, the numbers would show it. They don’t, because code secrecy protected against one specific vector: the researcher manually browsing a repository for vulnerabilities. That attack became marginal once automated scanners made it possible to analyze any binary without accessing the source.
The only scenario where this decision has defensible logic: Cal.com is sitting on architectural vulnerabilities it can’t fix publicly without acknowledging they’ve already been exploited. In that case, closing the code is reputation damage control, not security engineering. But that’s a judgment about the decision-makers, not the architecture.
Conclusion
Open source will survive AI. The structural advantage of community auditing compounds with the same tools Pumfleet uses to justify the closure. The more interesting question is how many other companies will run the same bad calculation, and how many developers will discover too late they built on infrastructure they could no longer inspect.