Open Source vs Closed Source in the Age of AI: Why Cal.com's Decision Matters for Developers

For most of the last decade, going open source was seen as a feature, not a risk. It meant community trust, external contributions, and the credibility that comes from having nothing to hide. Cal.com, the open-source Calendly competitor with over 40,000 GitHub stars, built its entire brand on that foundation.

Then its CEO announced they were moving the core product to a private repository.

The open source vs closed source debate has always existed. But Cal.com's decision signals something new: AI has fundamentally changed the risk calculus, and the developer community needs to think carefully about what that means. If you want to understand the broader shift happening in how developers use AI tools, what is vibe coding and why it is reshaping development is a good place to start.

The Threat That Changed the Equation

Before AI, exploiting an open-source codebase required genuine investment. You needed experienced engineers, time in a lab, and substantial effort to identify exploitable vulnerabilities. The attack surface of an open-source project was visible, but the cost of weaponizing that visibility was high enough to act as a practical deterrent.

That cost has collapsed.

Bailey Pumfleet, CEO of Cal.com, explained the shift directly: "The cost to hack has come down significantly. Before, the whole world operated on this security through obscurity thing. You needed a really experienced hacker. Now, you can just kind of point an AI agent at an open-source codebase and say, go attack this, and chances are it's going to find stuff."

The attack surface has not changed. The barrier to exploit it has.

Pumfleet's bank robber analogy captures the problem cleanly: "It's kind of like giving the bank robbers the blueprint to the vault. If you can tell what code is going to generate what output, it becomes a lot easier to reverse engineer everything and exploit it."

What makes this more than theoretical: AI vulnerability scanners have already found real, previously undiscovered vulnerabilities in major open-source projects including React and Firefox. This is not a future risk. It is happening now.

The 5-10x Stat That Should Make Every Open-Source Maintainer Pay Attention

The most striking data point in the Cal.com announcement came from an AI security firm Pumfleet cited: open-source software is 5 to 10 times easier to hack than closed-source software when AI-assisted attack tools are used.

That figure deserves to sit for a moment. Not marginally easier. Not somewhat riskier. Five to ten times more vulnerable to an attacker wielding the same AI tools that developers now use to build software.

According to a 2024 report from Synopsys, 96% of commercial codebases contain open-source components, and 84% of those codebases contain at least one known open-source vulnerability. As AI-powered attack tooling becomes commoditized, that existing vulnerability surface becomes dramatically easier to probe at scale.

The implication for open-source security risk is real: the combination of full codebase visibility and increasingly accessible AI attack agents creates an asymmetric exposure that did not exist two years ago. This is also why choosing the right AI model for your development workflow matters, different tools have very different default behaviors around code exposure and handling.

As Bruce Schneier, Security Technologist and Harvard Kennedy School Fellow, has noted: "Expect open-source software, including open-source libraries incorporated in proprietary software, to be the most targeted, because vulnerabilities are easier to find in source code."

Why Cal.com in Particular

Cal.com is not a generic SaaS product. It processes scheduling data that often carries significant sensitivity: patient bookings for healthcare providers, investor meeting flows, deal-related calendar entries for finance professionals. This is not casual meeting coordination. The data that moves through Cal.com's infrastructure has downstream consequences if exposed.

Pumfleet made this point explicitly. The stakes of a security breach are not just reputational for Cal.com. They extend to the sensitive workflows of their enterprise customers.

He also described a telling operational signal: "Every single week I get some kind of cold email or DM from a different company that's building one of these open-source vulnerability scanners, and they're all finding different things."

That detail is worth unpacking. Different scanners, different findings, every week. No convergence toward a clear security baseline. As Pumfleet put it: "Without one clear source of truth, it's never too obvious whether you're secure or not. There's no single unit test for is your application secure or not."

The open source security risk calculus shifted from manageable to structurally uncertain.

The Emotional Weight of the Decision

This was not a straightforward business call. Pumfleet described the call where going closed source was first seriously discussed as "actually one of the most emotional and difficult calls that I've had in 5 years of running this company."

That matters. Open source is not just a licensing model for a project like Cal.com. It is an identity, a promise to the developer community, and the foundation of the product's early growth. Walking that back is a genuine sacrifice, not a rebrand.

The fact that Pumfleet seemed genuinely troubled by the decision is one of the reasons it is worth taking seriously rather than dismissing as a positioning play.

What Cal.diy Means for the Community

Cal.com is not disappearing from open source entirely. They are open-sourcing the existing codebase under the name cal.diy, giving developers full access to the foundation of what Cal.com built. The components being moved to private repos are the new ones: authentication systems, billing infrastructure, and calendar credential handling.

This is a meaningful distinction. Cal.diy gives the community a legitimate, fully functional scheduling foundation to build on. The choice to close the new security-critical components while open-sourcing the legacy foundation is an attempt to honor both obligations simultaneously.

Whether the community accepts that framing or reads it as a net loss will depend on what cal.diy turns out to be in practice.

What This Means for Developers Building in the Open

The Cal.com announcement raises harder questions beyond just one company's repository strategy.

If you are maintaining an open-source project that handles sensitive data, the open source vs closed source calculus looks different than it did in 2023. The question is no longer just "do we have a responsible disclosure policy and regular dependency scans?" It is "are we prepared for AI-assisted adversarial probing of our entire codebase at a pace we cannot match?"

For well-known projects with significant user data, that question may not have a reassuring answer. Pumfleet's argument was not that Cal.com had weak security practices. It was that even excellent security practices could not keep pace with AI-accelerated attack tooling. That is a structural argument, not an operational one.

If you are building vibe-coded applications and shipping them publicly, this is a prompt to think carefully about what you are exposing. An AI coding agent can produce a functional application quickly. It can also introduce subtle vulnerabilities in authentication logic, credential storage, or API key handling that are easy to miss in a fast-moving build. If that code lives in a public repository, the same tools that helped build it can be used to attack it.

The practical move: keep security-critical components out of public repos, use environment variables religiously, and treat any public-facing code as if a well-resourced attacker has already read every line of it. The vibe coding best practices that separate developers who ship from those who break things in production are worth internalizing before you push anything public.

If you want to build something production-ready from the ground up with security built in from day one, the Master Course: Build and Ship a Production-Ready App with Lovable and Cursor covers the full journey from prototype to deployed app, including auth and environment handling.

If you maintain infrastructure that open-source projects depend on, this situation raises an interesting accountability question. Pumfleet floated it himself: "It's in GitHub's interest to keep open source alive. Should they be the ones to come up with a bulletproof way of scanning vulnerabilities every time someone pushes a contribution?"

That is a legitimate ask. GitHub's business model depends on the health of the open-source ecosystem. If AI-powered attack tooling is making open source structurally less safe, there is a reasonable case that GitHub and the major cloud providers have a role to play in building the defensive equivalent.

The Bigger Question: Is Open Source Incompatible with AI-Speed Development?

Cal.com's decision will not be the last of its kind. Other high-profile open-source projects that handle sensitive user data are facing the same structural pressure. The question is whether this becomes a trickle or a wave.

There are reasonable counterarguments to the closed-source response. Security through obscurity has well-documented limitations. Closing a codebase does not eliminate vulnerabilities; it just makes them harder to find for both attackers and defenders. Closed-source software has its own breach history.

The open-source community also has capabilities that closed teams do not: independent security researchers, bug bounty participants, and contributors who spot problems precisely because they have full context. The question is whether those advantages survive a world where AI can probe the same codebase with equivalent depth on an attacker's timeline.

Pumfleet left the door open explicitly: "If things change in the future and there become better ways to defend against this stuff, then we will absolutely revisit this and try to become open source once again."

That framing suggests this is not a permanent philosophical shift, but a pragmatic response to a specific threat environment. If GitHub, security tooling companies, or the broader developer ecosystem produces a credible AI-native defense layer, the calculus could reverse.

The Honest Assessment

The open source vs closed source debate in the age of AI does not have a clean answer yet.

Cal.com's decision is defensible given what they handle and the pace at which AI attack tooling is evolving. The 5-10x vulnerability multiplier, the weekly cold emails from different scanners finding different things, the sensitivity of the data they process: each of those is a legitimate data point, not a pretense.

At the same time, the answer for every open-source project is not to immediately close their repos. Scale and visibility matter. A smaller project without significant external contributors and without sensitive data exposure faces a different risk profile than Cal.com. The structural argument Pumfleet makes is most compelling for high-profile projects that are simultaneously highly visible, actively maintained, and processing sensitive user data.

The harder truth is that the developer community does not yet have good infrastructure for AI-native open-source security. The existing model of periodic scans, responsible disclosure, and community auditing was built for a pre-AI threat environment. That model needs to evolve faster than it currently is.

For developers building today, the most actionable takeaway is this: treat your public codebase as if it has already been fully analyzed by an adversarial AI agent, because with enough visibility and the right tool, it has. Build accordingly. Understanding how AI tools like Claude Code are changing the development workflow is part of developing that security-conscious mindset as an AI-era developer.

If you want to develop the practical skills to build secure, production-ready applications from the ground up, the courses at vibecodingacademy.ai cover the full stack from architecture decisions to deployment, with a clear-eyed view of the security considerations that matter in 2026.