Yesterday, Cal.com flipped a switch that nobody saw coming.
If you're not familiar: Cal.com is the self-hosted, open-source Calendly alternative that a huge chunk of the developer-adjacent world relies on. Five years of development. Tens of thousands of self-hosted instances. The project that made "I don't want to pay Calendly's per-seat pricing" a viable choice for small teams, NGOs, and indie founders.
On April 15, they announced they're locking down the production codebase. Moving it to a private repository. The public repo — the one you've been self-hosting — becomes Cal.diy, a community fork.
The reason? AI.
"Open source code is basically like handing out the blueprint to a bank vault," said CEO Bailey Pumfleet. "And now there are 100× more hackers studying the blueprint."
What Actually Changed with AI Vulnerability Scanning
This isn't paranoia. It's a real shift in the threat model.
For decades, open-source security operated on the assumption that transparency is a feature: more eyeballs on the code means bugs get found and fixed faster. That assumption made sense when the number of people who could systematically audit a large codebase was limited by human time and expertise. Skilled security researchers are rare and expensive.
AI changed that arithmetic.
New AI security tools — some research prototypes, some already commercialized — can be pointed at a public GitHub repository and asked to find exploitable vulnerabilities. They're systematic. They don't get tired. They can cross-reference a codebase against twenty years of known vulnerability patterns in seconds. Earlier this year, AI scanning tools surfaced over 500 high-severity vulnerabilities in production open-source codebases — bugs that had survived years of expert human review. One of them was a 27-year-old denial-of-service flaw in OpenBSD. Another was a 16-year-old FFmpeg vulnerability that automated testing tools had scanned five million times without flagging.
Those weren't found by lone researchers grinding through code. They were found by AI running on commodity infrastructure.
Co-founder Peer Richelsen put it plainly: "Open source security always relied on people to find and fix any problems. Now AI attackers are flaunting that transparency."
The Controversy: Is This Security Theater?
The community pushed back fast. And some of the pushback is legitimate.
The strongest counter-argument: closing source code doesn't stop AI from finding vulnerabilities — it just removes the community's ability to find and fix them first. Attackers can still find closed-source bugs through black-box fuzzing and reverse engineering. But defenders can't crowdsource the security review anymore. You've traded one real advantage (open auditing) for one that's much harder to verify (obscurity).
There's also the argument that open-source libraries share their auditing budget across the whole ecosystem — every contributor who spots a bug in Cal.com's auth code makes every Cal.com deployment safer. A closed-source equivalent has to fund that entirely in-house.
And there's a practical weirdness to the split: Cal.com's enterprise product is now closed, but Cal.diy — an MIT-licensed fork of essentially the same code — is wide open. If the production code is too dangerous for enterprise deployments, why is it fine for hobbyists? The answer Cal.com gives is risk segmentation: enterprise instances handle more sensitive customer data. Critics see it as having it both ways.
Some commenters on Hacker News are calling it a business move dressed up in security language — a way to extract more value from enterprise customers while shedding the maintenance obligations that come with running a major open-source project. "If the real driver is business strategy, say that" is the more cynical read.
Cal.com's counter: their production codebase has significantly diverged from what's in the public repo anyway — major rewrites to authentication and data handling — so the "same code" argument is weaker than it looks.
Both sides have a point. The honest answer is probably that the threat is real and the timing served their business interests.
What This Means If You're Running Cal.com Right Now
If your organization self-hosts Cal.com, you have two clear paths:
Option 1: Stay on Cal.diy. The community fork. Fully MIT-licensed. Available now at github.com/calcom/cal.diy. This is what was in the public repo. Cal.com says they're actively seeding it with contributions. If you're a smaller org using it for standard meeting booking, this is probably fine. The risk profile for Cal.diy hasn't fundamentally changed overnight.
Option 2: Move to the enterprise tier. If your booking workflow touches anything sensitive — healthcare intake, legal consultations, financial services — Cal.com is offering existing self-hosters access to a private on-premise GitHub repository. That gets you the hardened codebase with their enterprise security posture.
If you're a 5-25 person org using Cal.com mostly for external meeting booking, Cal.diy is almost certainly the right call. If your booking workflow touches sensitive data, it's worth a direct conversation with their team about the transition.
The Bigger Signal: This Is the First of Many
Here's what actually matters beyond the Cal.com situation itself.
Cal.com is the first major commercial open-source project to explicitly say AI-powered threat discovery is why they're going closed. They won't be the last.
Think about the open-source tools your team depends on. Not just scheduling — document processing, authentication libraries, email automation, form handling, database clients. Most of these have their code sitting on GitHub right now. If AI vulnerability scanning continues to improve (it will), the economics of keeping production code public changes for every commercial open-source company.
Some will close. Some will build better automated defenses. Some will double down on community security auditing. The trajectory varies by project, but the pressure is now uniform.
What you can do right now:
Run the same scans on your dependencies before someone else does. Tools like Grype, Trivy, and OSV-Scanner will crawl your package dependencies and flag known CVEs. They're free to run and take about ten minutes to set up in CI. If you've never done a software composition analysis (SCA) scan on your tooling, now is a good time — because the bar for attackers just got lower.
Know your actual open-source footprint. Most small orgs have no idea what's actually running in their stack, especially if a contractor set it up. A quick audit: what are we running, what's the last known-good version, who's responsible for monitoring it? If nobody owns that question inside your org, now's the time to answer it.
Watch the Cal.diy community over the next 60 days. The GitHub activity will tell you whether the community picks it up or lets it drift. Actively maintained forks of commercial open-source projects can be excellent. Neglected forks are a security liability. It's too early to call Cal.diy either way — but the commit graph won't lie.
The Uncomfortable Truth
The argument that "open source is more transparent, so it's more secure" was never universally true — it was true when the bottleneck was skilled human reviewers and attackers faced the same constraint. AI just removed that bottleneck on the attack side faster than it did on the defense side.
Open source isn't dead. Most open-source software will continue to be maintained and secured by active communities. But the specific argument that "more eyes = fewer exploitable bugs" works a lot less cleanly when the attacker's eyes are an AI running at scale against a public codebase.
This is what an inflection point looks like. Usually you only recognize them in hindsight.
We help small orgs audit and harden their open-source tooling stacks — figure out what's actually running, who owns it, and whether it needs attention before someone else finds out for you. It's usually a one-day engagement. If you're not sure what's in your stack, that's the conversation to start.