Cal.com Goes Closed Source — The Open-Source Business Model Hits Another Wall

Cal.com, the open-source scheduling platform that pitched itself as the free alternative to Calendly, has gone closed source. Not a license tweak. Not a partial relicensing. A full retreat behind closed doors. And if you’ve been paying attention to the last two years of open-source business drama, this feels less like a surprise and more like an inevitability.

Why Cal.com Went Open Source in the First Place

Cal.com launched in 2021 riding a wave of developer frustration with Calendly — overpriced, barely customizable, and holding your data hostage. The pitch was simple: everything Calendly does, but open, self-hostable, and yours to control. GitHub stars piled up. The self-hosting crowd showed up in force.

Here’s the problem that followed: self-hosting users are enthusiastic. They’re also, by definition, not paying for your cloud service. Cal.com ran headfirst into the oldest problem in open-source business — the free-rider gap. Lots of users, not enough revenue.

The Open-Source Exodus Is a Pattern Now

Line up the last two years and the trend is hard to miss.

In 2023, HashiCorp switched Terraform and its entire product line from MPL to the Business Source License. The community revolted. OpenTofu was forked within weeks. In 2024, Redis dropped its BSD license for a dual-license model. Sentry introduced the Functional Source License, effectively blocking competitors from running their code as a service.

Now in 2026, Cal.com joins the list — but goes further than any of them. This isn’t a license swap or a competitor-blocking clause. It’s a complete move to closed source. The door isn’t just harder to open. It’s bricked shut.

The Structural Contradiction of Open-Source Startups

Open-source companies traditionally monetize through three channels: open-core (free base, paid enterprise features), managed cloud (SaaS hosting), or support and consulting.

All three models have the same vulnerability: hyperscalers. AWS, GCP, and Azure can take your open-source code, wrap it in a managed service, and run it on better infrastructure at a lower price point than you can. Elastic spent years fighting AWS’s OpenSearch. MongoDB rewrote its license specifically to block this. It’s a well-documented playbook at this point.

For a startup the size of Cal.com, the math is even more brutal. You’re maintaining an open codebase, competing with your own self-hosters, and trying to explain to investors why giving away your product is a growth strategy. That pitch gets harder with every board meeting.

So Is Open Source Dead?

No. But the specific model of “raise VC money, open-source the code, figure out monetization later” is in serious trouble.

Foundation-backed projects — Linux, PostgreSQL, Kubernetes — are doing fine. They were never dependent on a single company’s revenue model. They’re funded by coalitions, governed by committees, and sustained by the sheer gravitational pull of industry adoption.

The projects struggling are the ones where a single company open-sourced its product as a growth hack, then hit the inevitable wall where growth needs to convert into revenue. The playbook worked brilliantly for user acquisition. It was never a monetization strategy.

What survives will likely split into two camps. Companies that win on the quality and convenience of their hosted offering — making self-hosting possible but genuinely inferior. And projects with real community governance sustained by broad sponsorship, not a single corporate backer. The middle ground Cal.com occupied — VC-funded, company-led, open-source-as-marketing — is eroding fast.

What This Means If You’re a Cal.com User

If you’re running a self-hosted Cal.com instance today, nothing breaks tomorrow. The code you deployed doesn’t vanish. But security patches and new features are now behind a closed door. Start evaluating alternatives on a reasonable timeline rather than a panicked one.

The broader lesson is worth sitting with. When you pick an open-source tool, how seriously are you evaluating sustainability? GitHub stars and feature checklists are easy to compare. Governance structure, revenue model, and community health are harder — but they’re what determine whether the project you depend on will still be open in three years. The Cal.com story suggests that due diligence needs to go deeper than the README.