Competitive move

Cal.com Drops Open Source, Citing AI-Powered Security Threats

Cal.com ends five years of open source after AI-found vulnerabilities exposed millions of bookings. What this means for founders using open-source GTM.

4 min readUpdated 2026-05-31

What happened

On April 14, 2026, Cal.com announced it was closing the source code of its flagship scheduling platform after five years as one of the most visible open-source SaaS projects in the productivity space. Co-founder Peer Richelsen framed the decision as a security necessity, stating that "open source security always relied on people to find and fix any problems. Now AI attackers are exploiting that transparency."

The trigger was concrete. On January 26, 2026, Gecko Security's AI-powered SAST engine discovered three chained access control vulnerabilities in Cal.com Cloud. The exploit chain allowed complete account takeover of any user, including admins, by generating an invite link, producing a 64-character token URL, and using it to reset any victim's password. A separate IDOR vulnerability exposed all booking data across the platform: attendee names, email addresses, meeting metadata, and historical bookings belonging to other organizations. Cal.com patched both issues in v6.0.8, but the experience reportedly catalyzed the license change.

Cal.com simultaneously released Cal.diy, a community fork under the MIT license intended for hobbyists and developers who want to self-host. The production codebase has diverged significantly from what Cal.diy contains, with major rewrites to authentication, data handling, and enterprise features.

Why it matters for practitioners

This is the highest-profile case yet of a VC-funded company using AI security concerns to justify leaving open source. Whether you agree with the rationale or not, the move signals a potential shift in how founders think about open-source-as-distribution.

1. Open source as a PLG channel is under new scrutiny. Cal.com built its brand and initial traction on being the open-source Calendly alternative. That positioning drove developer adoption and community contributions. Abandoning it suggests the team concluded the security costs (or competitive risks) outweighed the distribution benefits. For bootstrapped founders considering an open-source product-led growth strategy, this is a data point worth weighing, though the calculus is different when you lack Cal.com's $32M in venture funding.

2. The "AI makes open source dangerous" argument is contested. Critics on Hacker News and security forums pointed out a contradiction: if the code is too dangerous for Cal.com's enterprise customers, why is it safe enough to release as Cal.diy under MIT? Security researchers noted that "security through obscurity" has a long and inglorious history. The counterargument is that obscurity doesn't eliminate risk, it raises the cost of exploitation, which may be sufficient when combined with other defenses.

3. Competitive dynamics may be the real driver. Several observers suggested the move is as much about preventing competitors from forking the codebase as about security. In the scheduling market, where differentiation is hard, giving away your code makes it trivial for funded competitors to replicate your features. The security narrative provides a more sympathetic framing than "we don't want to be forked."

Key details

  • Date: April 14, 2026 (blog announcement)
  • Vulnerability discovery: January 26, 2026 by Gecko Security's AI SAST engine
  • CVE: CVE-2026-23478 (account takeover via invite token bypass)
  • Impact: Complete account takeover of any user; exposure of millions of bookings with PII
  • Patch: Cal.com v6.0.8
  • Community fork: Cal.diy released under MIT license
  • Cal.com funding: ~$32M raised to date
  • Community reaction: Heavily debated on Hacker News with 500+ comments

Market implications

The decision reshapes competitive positioning in the scheduling space. Cal.com's primary differentiation against Calendly was being open-source and self-hostable. Without that, the comparison becomes feature-vs-feature and price-vs-price, a harder game against a well-funded incumbent. The Cal.diy fork exists but will likely lag behind the production codebase as enterprise features accumulate.

For the broader SaaS ecosystem, this signals that open-source-as-GTM may have a shelf life. Companies like GitLab, Sentry, and HashiCorp have also pulled back from open-source licenses in recent years, but Cal.com's explicit invocation of AI-driven threats is new. If other companies adopt similar framing, bootstrapped open-source projects could face increased skepticism from enterprise buyers about code exposure, regardless of whether the underlying security argument holds.

The practical takeaway for founders: if you're building in public with open-source code, you need a clear-eyed assessment of what AI vulnerability scanners can find in your codebase. The tools are available to anyone now, not just well-funded security teams. Whether you close your source or not, the assumption that "many eyes make all bugs shallow" needs revisiting in an era where AI eyes never sleep.

Read next

More intel

All market intel