Meta Description: Cal.com just abandoned open source after 5 years, blaming AI-driven security threats. Here's why this matters for every startup betting on OSS — and what founders should learn from it.
The Open Source Darling Just Closed Its Doors
Cal.com — the scheduling platform that built its entire brand on being "the open source Calendly alternative" — just announced it's going closed source. After five years. The post went up on April 14, 2026, and the Hacker News thread exploded immediately.
The reason? AI-powered security scanning.
In their own words: "Being open source is increasingly like giving attackers the blueprints to the vault."
They're not entirely wrong. But they're also not telling the whole story.
What Actually Happened
Here's the core argument from Cal.com CEO Bailey Pumfleet:
- AI can now systematically scan open source codebases for vulnerabilities — what used to require a skilled hacker with weeks of patience can now be done by pointing an AI at a public repo
- AI security startups are productizing this — multiple platforms now offer automated vulnerability discovery, each surfacing different issues, creating chaos around what's "actually secure"
- AI found a 27-year-old vulnerability in BSD kernel — and generated working exploits in hours, demonstrating how even battle-tested code is now exposed
- Their production codebase had significantly diverged — including major rewrites of auth and data handling, meaning the public repo wasn't even their real code anymore
Their solution: close the source, release a separate MIT-licensed version called Cal.diy for hobbyists, and hope the community accepts the split.
The Community Reacts — And It's Not Pretty
The Hacker News reaction was swift and divided:
The defenders argue this is pragmatic. If AI makes every vulnerability findable, open source becomes a liability for companies handling sensitive data (scheduling = calendar data = meeting participants = business intelligence).
The critics see it differently:
- This was always the plan — build community and trust with OSS, then pull the rug
- "Security" is a convenient justification for what's really a business model pivot
- The code had already diverged from the public repo, meaning the "open" part was already hollow
- Cal.diy is essentially a maintenance dump, not a genuine community project
The truth is probably somewhere in the middle. But the pattern is undeniable.
The Open Source Bait-and-Switch Pattern
Cal.com isn't the first to do this. It's become a recognizable playbook:
- Launch as open source — Get free marketing, community contributions, developer trust, and HN/Reddit love
- Build enterprise features — Use the community as a funnel for paid tiers
- Diverge the codebase — The public repo becomes a shadow of the real product
- Go closed source — Cite "security" or "sustainability" as the reason
- Release a "community edition" — A stripped-down version to soften the blow
We've seen variations of this with HashiCorp (Terraform → BSL), Elasticsearch (SSPL), and now Cal.com. Each time, the community that helped build the product gets left with a forked, maintenance-mode version.
This isn't a coincidence. It's a business model.
Why AI Security Is a Real (But Incomplete) Argument
To be fair to Cal.com, the AI security concern is legitimate:
- Automated vulnerability scanning is now trivial. Tools can probe an entire codebase in minutes, not months. The "many eyes make bugs shallow" argument assumes those eyes are friendly. AI doesn't discriminate.
- Zero-day discovery is accelerating. The BSD kernel example Cal.com cites — a 27-year-old vulnerability found and exploited in hours — is real. That's terrifying for any security-conscious team.
- The attack surface is asymmetric. Defenders need to fix every vulnerability. Attackers only need to find one. Open source makes that asymmetry worse.
But here's what's incomplete about the argument:
- Security through obscurity doesn't work. Closed source code still has vulnerabilities — they're just harder for good-faith researchers to find and report. You lose the "many eyes" benefit while attackers still reverse-engineer.
- Cal.com's production code had already diverged. The public repo wasn't the attack surface anymore. The "security" argument applies more to the principle than their actual risk.
- The timing is suspicious. This happened right after major enterprise feature launches. The security justification came after the business decision.
What This Means for Founders Building on Open Source
If you're a founder or developer, Cal.com's move should make you rethink a few things:
1. Don't Build Your Business on Someone Else's Open Source Promise
If your product depends on an open source tool that could go closed, you need an exit plan. Cal.com users who self-hosted are now stuck on a diverged codebase with no clear upgrade path.
2. Open Source Is a Strategy, Not a Religion
Cal.com used OSS brilliantly for growth. They got years of free distribution, community goodwill, and contributor labor. Going closed is a rational business move — but let's call it what it is, not dress it up as purely a security decision.
3. License Matters More Than You Think
Cal.com used AGPL v3, which has strong copyleft requirements. Their move to closed source means they can now monetize without contributing back. If you're choosing an OSS dependency, check the license and the company's trajectory, not just the GitHub stars.
4. Community Trust Is a One-Way Door
Once you break trust with your open source community, you don't get it back. Cal.diy might keep hobbyists happy, but the developers who contributed PRs, filed issues, and evangelized the product? They're gone. That's a real cost that doesn't show up on a balance sheet.
5. The "AI Security" Argument Will Be Used Again
Expect more companies to follow Cal.com's playbook. AI-driven security is a legitimate concern, and it's a convenient, hard-to-argue-against justification for going closed. If you're evaluating OSS tools for your stack, factor in the risk of this happening.
Is Open Source Dead for SaaS?
No. But the landscape is shifting:
- True community-driven projects (Linux, PostgreSQL, Kubernetes) are fine — they're not owned by a single company chasing VC returns
- VC-backed open source SaaS is the vulnerable category — the incentives eventually conflict
- New models are emerging — BSL (Business Source License), SSPL, and custom licenses try to balance openness with sustainability, but they all face community pushback
The Cal.com case is a warning: open source is not a permanent feature of a product. It's a phase. Plan accordingly.
Conclusion
Cal.com went closed source. They blamed AI security. The community is split. And the pattern will repeat.
For founders: use open source, contribute to open source, but never bet your business on someone else's open source staying open. The license can change. The code can diverge. The promises can break.
Build on foundations you control. Contribute to the commons. But keep your escape route ready.
FAQ
Q: Why did Cal.com go closed source? A: Cal.com cited AI-driven security threats as the primary reason, arguing that open source codebases are now easier to exploit with AI vulnerability scanners. Critics note the company's production code had already diverged from the public repo and the timing coincides with enterprise feature launches.
Q: What is Cal.diy? A: Cal.diy is the MIT-licensed, community-driven version of Cal.com released alongside the closed-source transition. It's based on an older, diverged version of the codebase and is intended for hobbyists and self-hosters.
Q: Can a company legally change from open source to closed source? A: Yes, for future releases. Existing open source code remains under its original license — users can still fork and use the last open version. But new features, updates, and bug fixes can be released under a closed license. Cal.com retained the right to relicense their own code.
Q: Is "security through obscurity" effective? A: Not as a primary strategy. Most security professionals agree that obscurity can be a layer but should never be the only defense. Closed source doesn't prevent vulnerabilities — it just changes who can find them. You lose the benefit of community security review.
Q: What should I do if my stack depends on a tool that might go closed source? A: Evaluate the license, the company's funding trajectory, and whether a viable fork exists. Consider contributing to community forks. Maintain your own patches if needed. And always have a migration plan ready.
About the Author: Arkin is a startup founder and developer building Orbits Studio, a UGC marketplace platform. He writes about open source, AI, and the business of building software.