When Bailey Pumfleet hit publish on an April 14 blog post, the Cal.com co-CEO knew the scheduling platform's announcement wouldn't go over quietly. The company was pulling its commercial codebase behind closed doors. The culprit, according to Cal.com: AI-powered security scanners now methodically crawling through public repositories, transforming theoretical vulnerabilities into exploitable weaknesses faster than anyone anticipated.
Self-hosters wouldn't be left completely in the cold. Cal.com released Cal.diy the same day—a MIT-licensed community edition for anyone wanting to run their own scheduling infrastructure. But the announcement has sparked something larger than a licensing spat. It's reopened uncomfortable questions about whether open-source projects can defend themselves when AI accelerates vulnerability discovery, and whether commercial viability and truly open code can share the same roof.
The Fork in the Road
Cal.diy became the new repository for Cal.com's open-source lineage on April 14, switching from the previous AGPL-3.0 license to the more permissive MIT. By April 22, the GitHub page showed approximately 41.8k stars and 12.9k forks—impressive numbers, though they carry over from the project's earlier life as much as they reflect enthusiasm for the reboot.
The documentation pulls no punches about what Cal.diy is and isn't. It's "the open-source, self-hostable, community-driven version," sure, but liberally sprinkled with disclaimers urging users to proceed at their own risk. The sweet spot, Cal.com suggests, is "personal, non-production" deployments. Anything commercial or enterprise-grade? The company steers those inquiries toward its hosted SaaS offering or private repository access for on-premises installations.
It's a clean division on paper. In practice, it raises eyebrows.
What Didn't Make the Cut
Cal.com's engineering team posted a granular breakdown of features excluded from Cal.diy. Organizations and Teams—essentially the multi-tenant scaffolding that lets teams manage availability and shared booking flows—didn't make the jump. Neither did Routing Forms, the conditional logic engine for directing bookings based on user responses. Workflows, which automate reminders and follow-ups, got axed too.
The casualty list continues: Instant Booking event types, AI Phone (the Cal.ai phone execution layer), Attributes and Segments, SAML and SSO authentication, the Insights analytics dashboard, Booking Audit logs, admin impersonation. Oh, and API v1 disappeared entirely. Cal.diy ships with API v2 only.
What survived? The core scheduling engine, the app store framework, booking infrastructure, and integrations with major calendar providers like Google and Outlook, conferencing tools including Zoom and Teams, CRMs such as HubSpot and Salesforce, plus various analytics platforms. The tech stack—Next.js, tRPC, React, Tailwind CSS, Prisma—follows standard patterns for modern web applications. Docker Compose instructions live in the README, with deployment guides covering AWS, Azure, GCP, Vercel, and a few platform-as-a-service providers.
For hobbyists, it's workable. For businesses? The gaps are strategic.
Security Theater or Legitimate Threat?
Cal.com hangs its rationale on a shifting threat landscape. Public code, the argument runs, provides AI-assisted scanners with a roadmap to systematically identify vulnerabilities. The company isn't pulling this from thin air—in January, Gecko Security disclosed broken access control issues that enabled account takeover and data exposure across organizations. Cal.com patched the vulnerabilities in v6.0.8, credited the researchers, and moved on. But clearly, the incident left a mark.
The New Stack framed the move as a "security reckoning for open source," noting how AI tools now uncover vulnerabilities that previously required painstaking manual work. Whether closing source code meaningfully reduces that risk is... well, that's where things get murky. Attackers have other reconnaissance avenues, and relying on obscurity as a security model rarely ages well. But for Cal.com, managing customer data at scale apparently tipped the calculation toward limiting public exposure.
Perhaps the company knows something others don't yet. Or perhaps it's a convenient justification for a business decision already in motion.
The Maintenance Question
Governance for Cal.diy lands with a handful of former Cal.com interns, now promoted to official maintainers. Cal.com's internal engineering team focuses squarely on the commercial product. It's a tidy separation in the org chart, less clear what it means for release cadence, security backports, or long-term viability. The documentation doesn't sketch out a detailed governance roadmap yet, and as of April 22, the Docker Hub repository existed but contained no tagged releases.
Cal.diy carries the MIT license with no "open core" licensing restrictions beyond the feature removals themselves. For developers spinning up personal scheduling systems, the path forward is straightforward enough. For teams or businesses? The warning labels and missing capabilities practically shepherd them toward the commercial product.
Which, fair or not, strikes some observers as the point.
The Community Pushes Back
The announcement landed poorly in self-hosting and open-source circles. On Reddit's r/selfhosted, users immediately questioned whether the AI-security rationale held water, pointing out that security through obscurity typically doesn't, and that contributors had already invested time and energy under different licensing assumptions. Similar threads on r/opensource and Hacker News mixed surprise with skepticism.
Slashdot summarized the situation under the headline "Cal.com Is Going Closed Source Because of AI." AlternativeTo documented the MIT relaunch but highlighted the "use at your own risk" positioning prominently. Some criticism went further—Vikunja, another open-source productivity tool, published a blog post contrasting its commitment to remaining open with Cal.com's pivot, framing the move as a response to commercial pressures rather than a pure security play.
The developer community is watching what happens next with the kind of attention reserved for precedent-setting cases. Forks already exist—Cal ID, a third-party site built "over the top of Calcom" under the prior AGPL license—but whether Cal.diy sustains momentum as an independent project remains genuinely uncertain.
What It Means in Practice
For individual developers and self-hosters who don't need team features, SSO, or advanced routing logic, Cal.diy delivers a functional scheduling system with integrations covering major calendar and conferencing providers. The MIT license is permissive, and anyone familiar with Cal.com's earlier codebase will recognize the territory.
For teams or businesses evaluating scheduling infrastructure? Different story. The features Cal.com stripped from Cal.diy are precisely the ones distinguishing a personal tool from enterprise-grade software. Organizations that were self-hosting the earlier open-source version now face an awkward choice: migrate to the commercial SaaS, negotiate private repository access for enterprise self-hosting, or stick with a pre-split fork and maintain it independently—a prospect few small teams relish.
The broader question looming over all this is whether Cal.com just drafted a template others will follow. If AI-accelerated vulnerability discovery pushes more projects to close their code, the open-source scheduling landscape—and SaaS ecosystems more broadly—could fracture into permissive-but-limited community editions alongside closed commercial products. Cal.com, with announced funding of $32.4 million and a team of approximately 42 employees according to LinkedIn, made a bet that the trade-off pencils out. Whether the market validates that bet will show up in adoption numbers and whether competitors capitalize by staying open.
For now, the developer community is doing what it does best: forking, debating, and building alternatives. Cal.com closed a door. Whether it opened a window for someone else is the part still unfolding.
