Cal.com Just Went Closed Source Because of AI — And Your Open Source Stack Is Next

On April 15, Cal.com — the open-source Calendly alternative a lot of us have quietly been running in production — killed its own open source license. After five years as a genuinely open project with a public repo, they're going proprietary.

The official reason: AI-powered vulnerability scanning has made it too dangerous for a small team to keep the code public. The CEO, Bailey Pumfleet, posted the decision on LinkedIn. The blog post is live on cal.com. And as a consolation prize, they forked the old codebase into a project called Cal.diy, which they'll keep MIT-licensed — except the production code has already diverged significantly, with major rewrites of authentication and data handling on the closed side.

This is the first major indie-friendly open-source SaaS to flip the switch in the AI era. It will not be the last. And the decision every solo operator has to make this weekend is whether you believe the stated reason, whether you care either way, and what to do about the pattern that's coming.

The Stated Reason, Taken at Face Value

Cal.com's argument goes like this. AI code-scanning tools — the kind of thing Anthropic's Mythos demo showed in early April, the model they decided was too dangerous to ship because it could break into OpenBSD — have fundamentally changed the economics of vulnerability research. If your code is public, attackers can feed it into a scanner and find exploitable bugs faster than a small team can patch them. The traditional "many eyes make bugs shallow" argument assumed human eyes. AI eyes don't scale the same way, and they don't scale for defense the way they scale for offense.

Pumfleet's framing: "remain open source and accept increasing risk to customer data, or move to closed source to reduce that risk."

Taken at face value, this is a real concern. AI has changed the speed at which vulnerabilities can be discovered. Any security person will tell you that's true.

But there's also a less flattering read, and it's worth sitting with.

The Uncomfortable Alternative Read

Cal.com is a venture-funded SaaS company. They've been open source for five years, which is a long time in startup years. They've also been under the kind of growth pressure that eventually forces commercial-open-source companies to ask uncomfortable questions — like "how do we stop enterprise self-hosters from cloning our product and eating our revenue?"

"AI security" is the best cover a commercial open-source company has ever been handed for a business-model pivot. It's technically true, it sounds responsible, and it conveniently solves the other problem at the same time. Expect to see a lot more of this argument over the next twelve months. Some of it will be sincere. Most of it will be mixed motives dressed up in security language.

The tell is always the same: companies with real security concerns tend to invest heavily in automated patching, bug bounties, and responsible-disclosure programs before they go closed source. Companies using security as cover tend to go straight to "trust us, it's closed now."

I don't know for certain which side of that line Cal.com falls on. Neither do you. And neither does anyone else who hasn't seen their internal incident logs.

The Counterpoint Discourse Published the Next Day

Discourse — the forum software that powers a huge chunk of the internet's community infrastructure — published a direct response titled "Discourse is Not Going Closed Source." It showed up on Hacker News within hours and hit 313 points.

Their argument is the cleanest pushback I've read. Discourse has been open source for thirteen years. In that entire time, they have zero evidence that making their code public has measurably increased their security incident rate. They've had bugs. Every project has. But the open-source review has, in their telling, consistently caught more than it introduced. The "AI changes everything" argument doesn't hold up for them.

What's interesting is that Discourse and Cal.com are in very different businesses. Discourse is a community tool with tens of thousands of public instances, many self-hosted by hobbyists. Their security surface is messy and exposed in ways Cal.com's scheduling backend isn't. If anyone had an obvious reason to go closed source over AI security fears, it would be Discourse. They looked at the same trend and came to the opposite conclusion.

That gap — same industry, same AI landscape, opposite decisions — is a signal. It means the decision is at least as much about business model as about security.

What This Means for Your Solo Stack

Here's the uncomfortable audit I'm running on my own stack this weekend, and I recommend you run the equivalent on yours.

Every tool you depend on that's labeled "open source, self-hostable, you own it" is a potential Cal.com. The set of projects that could plausibly pull this move in the next year is larger than most solo operators realize. It includes a lot of the tools on every "indie hacker $0 stack" list — Supabase-style databases, Plausible-style analytics, n8n-style automation, half the self-hosted Calendly alternatives, a pile of chat tools.

The test I'm using: for each tool in my stack, could the company behind it decide tomorrow that the open-source license no longer serves their business? If yes, what's my migration cost, and am I okay with that cost?

For most tools, the answer is "yes, they could, and migration would be a pain but not catastrophic." For a few tools, the answer is "yes, they could, and I'd be genuinely stuck." Those are the ones that matter.

For the stuck-list tools, I'm doing three things:

One, pinning to a known-good commit. If I'm running a self-hosted version, I'm tagging the specific commit I trust and documenting it. If the project goes closed tomorrow, I'm still shipping on whatever I had yesterday.

Two, identifying genuine forks or alternatives. Some projects have legitimate forks with diverse contributor bases. Those are more robust than the single-vendor open source. Matrix instead of Slack. PostgreSQL instead of a vendor-backed database. The boring answer is often the resilient one.

Three, picking my battles. For one specific vendor whose trajectory I don't trust, I'm already migrating this month. For the rest, I'm watching and pinning, not panicking. The cost of pre-emptively moving off every commercial open-source tool is higher than the cost of reacting when one of them flips.

The Bigger Pattern

Cal.com going closed isn't really a story about Cal.com. It's a story about what happens when the "commercial open source" business model meets AI-accelerated vulnerability research meets growth-stage SaaS economics. All three pressures push the same direction.

The era where a solo operator could confidently say "my entire stack is open source, self-hostable, and vendor-proof" was always a little bit of a fiction — but it was a useful fiction, and it's ending faster than a lot of us expected.

The workable answer isn't "panic and rebuild everything on truly open standards." It's "understand which of your dependencies are actually vendor-controlled, price that risk into your planning, and stop treating 'open source' as a free pass on the lock-in question."

Cal.com told the truth about something that's also true about most of your stack. You just got to hear them say it out loud.

Sources

• Cal.com Goes Closed Source: Why AI Security Is Forcing Our Decision — cal.com
• Discourse is Not Going Closed Source — Discourse Blog
• AI Pushes Cal.com to Shutter Open and Go Nonfree — FOSS Force
• Cal.com Goes Private. Best Open Source Alternatives — Implicator
• Cal.com Is Going Closed Source Because of AI — Slashdot