Cal.com Goes Closed Source: What It Means for the Future of Open Core

The open source community felt a tremor this week. Cal.com, the scheduling infrastructure darling that built its reputation on being the "open source Calendly alternative," announced it is going closed source. For a company that raised millions on the promise of open scheduling infrastructure, this move raises uncomfortable questions about the viability of open core as a business model—and what it means for the thousands of businesses running self-hosted instances.

The Announcement: Reading Between the Lines

In their blog post, Cal.com's leadership framed the decision as necessary for "sustainable growth" and "protecting our intellectual property." The timing is telling: after years of burning VC cash to acquire users, the company appears to be pivoting toward monetization—and closing the source code is the lever they've chosen.

The move follows a familiar pattern. Once the open source project gains enough traction and enterprise customers are locked in, the rug gets pulled. It's not illegal—most open core companies retain the right to relicense—but it fractures trust in the ecosystem.

Why Open Core Keeps Failing

Cal.com isn't the first, and won't be the last. The open core model has a fundamental tension: you need to give away enough to gain adoption, but keep enough proprietary to make money. Most companies get the balance wrong.

The VC Trap: Open core startups raise money on inflated valuations based on GitHub stars and developer mindshare. When growth slows and investors demand returns, the only assets left to monetize are the ones they gave away for free. Closing the source becomes the Hail Mary.

The Feature Gap: Enterprise features—SSO, audit logs, admin controls—are exactly what self-hosters need. By keeping these proprietary, open core vendors alienate their most committed users. When those users fork the project or migrate away, the vendor responds by closing more of the stack.

The Community Betrayal: Open source isn't just a license; it's a social contract. Contributors who donated code under the assumption it would remain free now find their work enclosed. The Cal.com repository had hundreds of external contributors. Their labor just became someone else's proprietary asset.

The Technical Migration Path

If you're running a self-hosted Cal.com instance, you have three options:

1. Stay on the Last Open Source Version

Fork from the final open source commit and maintain it yourself. This is viable short-term but creates technical debt. Security patches, new calendar provider integrations, and bug fixes won't flow downstream anymore.

bashCopy
1# Fork from the last known open source commit
2git clone https://github.com/calcom/cal.com.git
3git checkout <last-open-source-commit>
4git remote rename origin upstream
5git remote add origin your-fork-url

2. Migrate to Alternatives

Several open source alternatives exist, though none match Cal.com's feature completeness:

• Easy!Appointments: PHP-based, simpler but stable
• Qalendar: Vue-based, newer, less mature
• BookStack: Not a direct replacement, but handles scheduling workflows
• Build your own: For teams with specific needs, a custom Next.js + Prisma implementation might be cleaner than fighting a bloated codebase

3. Pay the Toll

Accept the new reality and migrate to Cal.com's hosted offering. For small teams, this is often the pragmatic choice. But it validates the enclosure strategy and leaves you vulnerable to future price hikes.

The Bigger Picture: Open Source Sustainability

Cal.com's move is a symptom of a deeper disease. We haven't solved the funding problem for open source infrastructure. Companies raise venture capital, grow on free labor and free software, then close the code when the unit economics don't work.

Alternative Models Worth Watching:

• Open Source Foundations: Projects like OpenTelemetry and Kubernetes that are truly community-governed, not vendor-controlled
• Dual Licensing with Copyleft: AGPL-style licenses that force contributions back to the community
• Public Benefit Corporations: Legal structures that prevent enclosure by prioritizing mission over profit
• Developer-First Funding: Models like GitHub Sponsors and Open Collective that let projects survive without VC pressure

What This Means for 2026

The Cal.com decision is a warning shot. Any open core project backed by venture capital should be treated as potentially temporary. When evaluating infrastructure for your stack:

1. Check the license history: Has the company relicensed before?
2. Examine the governance: Is there a foundation, or does one company control everything?
3. Assess the forkability: Could your team maintain a fork if needed?
4. Diversify dependencies: Don't build critical infrastructure on a single vendor's goodwill

Conclusion

Cal.com going closed source isn't surprising—it's inevitable under the current funding model. The tragedy is that we keep repeating this cycle. Open core promises the best of both worlds but often delivers the worst: the instability of startups combined with the lock-in of proprietary software.

For developers and businesses, the lesson is clear: treat open core as a loan, not a gift. It can be called in at any time. Build your architecture accordingly.

The scheduling wars aren't over. They're just entering a new phase—one where the open source community will need to rebuild what was taken. Again.