The repo you were auditing wasn't the one they were running

The repo you were auditing wasn't the one they were running

Buried in the coverage of Cal.com's licence change is a line that should reframe the whole thing for anyone who chose it for auditability. By the time of the announcement, the production codebase had drifted significantly from what was public — core systems including authentication and data handling had been through substantial rewrites that the open repository didn't carry.

So the reassurance people were buying — the code is open, anyone can inspect it, that's why I trust it with client data — was already partly fictional. What was open was a sibling of the thing running at cal.com, not the thing itself. That was true before April. The licence change just made it official.

If you self-hosted, this matters less: the code you ran was the code you read. If you used their cloud because it was open source and therefore inspectable, the guarantee you thought you had had already quietly expired.

The stated reason, and why I don't buy it

Co-founder Bailey Pumfleet's argument is that AI has changed the economics of attack. Finding an exploitable bug used to take expertise and patience; now a model can be pointed at a public repository and work through it systematically. He backed this with a case where AI tooling found a decades-old kernel vulnerability and produced working exploits within hours.

The concrete trigger was real. In January 2026 the security firm Gecko Security reported a chain of three linked vulnerabilities in the public codebase that allowed complete account takeover, including admin accounts, exposing booking data. That is not a hypothetical, and if it were my product I would have had a bad week too.

I still think the conclusion is wrong, for the old boring reason: fewer eyes find fewer bugs, and attackers don't need your repository to find them. Heartbleed and Log4Shell were both found by outside researchers precisely because the code was readable. Closing the source doesn't remove the vulnerabilities that a security firm found in January; it removes the security firm.

There's also a smaller thing that bothers me more than it should. The kernel example was misattributed — the decades-old bug was in OpenBSD, found by an AI red-teaming effort, and patched. Getting the headline example wrong in the announcement that justifies the decision doesn't make the decision wrong. It does suggest the argument was assembled after the conclusion.

Reasonable people land elsewhere on this. If you run a scheduling product holding healthcare appointments and executive calendars, and a public repo just cost you an account-takeover chain, "fewer eyes" may look like a feature rather than a bug. I don't agree, but I understand the week in which that decision gets made.

What Cal.diy is, and what it can't do

The pre-closure codebase lives on as Cal.diy, MIT licensed, installable via Docker, Vercel, Railway and Render. It covers the personal scheduling essentials: event types, calendar integrations, video conferencing, webhooks and API access.

Read the disclaimers before you plan around it. The project is community-maintained with no official backing from Cal.com. Its documentation calls it strictly recommended for personal, non-production use, with "use at your own risk" repeated throughout. And for anything commercial, the docs point you back at the paid product.

What's gone:

That last row is the one I'd think hardest about. A fork's first three months tell you almost nothing about whether anyone will still be triaging CVEs in month eighteen.

AGPL was never the guarantee people thought it was

This is the part worth carrying to your next decision, and it isn't really about Cal.com.

A permissive or copyleft licence on a single-vendor product protects the code that already exists. It does not oblige anyone to keep writing more of it. When one company holds the copyright, it can relicense whatever it publishes next, and everything you have is a snapshot with your name on the maintenance contract. Cal.com had already done one licence change — MIT to AGPLv3 in 2021, alongside an Enterprise Edition. The second one was the same lever pulled further.

The fork inherits the code. It does not inherit the paid engineers, the security budget, the release cadence or the obligation to care in two years. That gap is the whole risk, and it's invisible on the day you choose the tool, because on that day the repo looks healthy.

Worth applying the same lens elsewhere before you commit: Easy!Appointments, the most durable remaining option for customer appointments, now has a paid premium tier. That's a good sign — somebody is funded to maintain it. It's also exactly the structure from which licence changes get made.

If you're self-hosting Cal.com right now

Three options, and they are not equally good.

Stay on the last AGPL release. Tempting, and fine for a few weeks. It stops being fine the moment a vulnerability is disclosed in code that overlaps with what you're running, because nobody is backporting a fix to your snapshot and the January report suggests the class of bug exists. Treat this as a bridge with a deadline written on it, not a decision.

Move to Cal.diy. Reasonable if you're one person scheduling your own calls and the blast radius is your own diary. Not reasonable, by the project's own instruction, for client data. If you go here, go here knowingly.

Pay Cal.com. The unglamorous answer, and for a team that needs Teams, SSO and Workflows it's the one I'd actually pick. You were getting a funded engineering team's output for free and now you aren't. That's a price change, not a betrayal.

What would change my recommendation: if Cal.diy picks up a named maintainer group with a security policy and a patch history over the next two quarters, the second option stops being a personal-use-only footnote. Check that before assuming it hasn't happened.

Half this audience needed a different product

Half the people reading a Cal.com migration guide don't need a Cal.com replacement.

Cal.com, Cal.diy and Calendly solve meeting scheduling: one person or a small team, a slot, a video link, no money changing hands. If a customer is buying ninety minutes with a specific practitioner at a specific location, paying a deposit, and rescheduling through a portal, that was never the same product — people just reach for the scheduling tool they've heard of and then spend a year bending it.

That second shape is what Opencals is, and the honest framing is that it's a different category rather than a better version of the same one. If you're coordinating interviews, a scheduler is right and we're the wrong tool. There's more on where that line falls in open-source vs hosted booking APIs, and the wider survey of self-hostable options is in the best open-source booking systems — which, incidentally, I need to correct, because it still describes Cal.com's core as MIT licensed.

For the German-language version of this question, including what self-hosting does and doesn't do for GDPR, there's Buchungssystem Open Source.

What I'd want to know before betting on anyone, including us

Here's the uncomfortable part, and I'd rather write it than have you notice it yourself.

Opencals is not open source. The Next.js booking templates are MIT and the storefront SDK is public, but the availability engine, the payment handling and the data live on our infrastructure. If the risk you're trying to eliminate is a supplier changes the terms underneath me, a hosted API does not remove that risk. It makes it explicit and puts it in a contract, which I think is more honest than a licence that feels like a guarantee and isn't — but it is not the same thing as control, and anyone telling you otherwise is selling.

What I can't tell you: whether Cal.diy will be maintained in a year, whether Cal.com's decision makes their product measurably safer, or whether the next project on your shortlist has already had this conversation internally. The only defence I know is the boring one — pick tools whose data you can export on a Tuesday afternoon, and check that claim before you need it rather than after.

If you self-host anything from this category, the question to answer this month is not which fork to follow. It's who on your team reads the security advisories, and what happens in the week they're on holiday.