Cal.com’s Closed Core and the Future of Open-Source Security

I have become an even stronger advocate for open source because shared code lets communities build on and improve the software they rely on. That is why Cal.com’s announcement worries me. The scheduling company said it was closing its core codebase in response to AI-related security concerns.

Cal.com has been a substantial example of a full-stack TypeScript application and has been useful for learning and testing tools. I know the team and had discussed the decision with them. I had hoped to persuade them to keep the main project open, so I have a personal connection to this debate.

Cal.com co-founder Bailey Pumfleet said AI could make source-code analysis and exploitation easier at scale. He announced a closed core codebase alongside a separate MIT-licensed project called cal.diy. That is a change in the company’s approach to its main codebase, not evidence that all open-source software has ceased to exist.

A change in future development also needs to be distinguished from previously released versions and their licenses. The practical rights around any particular version depend on its applicable license and the facts. My concern here is the loss of ongoing access to the main product’s development, not a claim that old permissions automatically disappeared.

Finding a vulnerability has traditionally required both security knowledge and an understanding of the system being examined. I use a simple diagram combining those ideas. It is a way to think about the problem, not a measured mathematical formula for predicting whether an exploit will be found.

Source access can help a reviewer understand the relationships between components. AI tools may also help analyze unfamiliar code and let people explore more potential issues. But having source or a model does not automatically produce a valid exploit: context, testing, configuration and human judgment still matter.

I asked viewers to rate their confidence in security research, and many reported low confidence. That is an informal chat poll, not evidence that expertise in TypeScript and security are inversely related or a measurement of the broader developer population. It illustrates my concern that these specialties can be hard to combine.

My hypothesis is that stronger coding models can lower some barriers to understanding a codebase and investigating security issues. I draw illustrative numbers to make the point, but they are not experimentally measured thresholds. The amount of expertise and time needed varies with the target and the reliability of the tool.

Anthropic reported that Claude Mythos Preview found a now-patched 27-year-old OpenBSD vulnerability during security research. OpenBSD is a BSD operating system, not a Linux distribution. The report is a concrete example of a tool assisting vulnerability discovery, not proof that every system is equally exposed: https://www.anthropic.com/research/mythos-preview.

The research used agents to examine a codebase from many starting points. I find that approach concerning because it can expand the amount of code reviewed without a human manually reading every file. The model still needs validation: a candidate finding is not the same thing as a confirmed, exploitable vulnerability.

I think closing source may raise the effort needed for some kinds of analysis, at least for a time. It is not a security guarantee. Public clients and exposed interfaces can reveal parts of a system, while private server-side code is not automatically available to an outside reviewer.

My prediction is that improvements in analysis and reverse engineering could reduce the benefit of hiding code. That is a forecast, not a demonstrated timeline. Open and closed systems each have different exposure and review properties; neither label alone tells us how secure a deployment is.

Time and cost also matter. Automated tools can work over longer periods and explore many possibilities, which may change the economics of both attacks and defensive review. The outcome depends on access, verification, operational controls and people, not just how many agents someone can run.

Tanner Linsley argues that closing a project may also reduce opportunities for good-faith developers to inspect and harden it. I think that is important, while understanding why a company responsible for customer data might worry about rapid vulnerability discovery. Both the exposure and the loss of shared review deserve consideration.

Defensive tools are advancing too. I mention a security-oriented model intended to help organizations harden code and compare the situation to an arms race between attackers and defenders. Access and capabilities at the time of the video are a snapshot, not a current product guide.

Drew Breunig’s article frames the issue as “proof of work” in the economic sense: security teams and attackers both spend resources searching for weaknesses. His argument is at https://www.dbreunig.com/2026/04/14/cybersecurity-is-proof-of-work-now.html. I find the framing useful, but it is an analogy rather than a universal law of security.

A computational challenge can raise the cost of automated abuse, although it does not prove that a requester is human and can burden legitimate users. Similarly, more analysis budget can help defenders, but spending more than an attacker does not by itself guarantee that every vulnerability is found or fixed.

The UK AI Security Institute evaluated Mythos Preview on “The Last Ones,” a simulated 32-step corporate network challenge. It reported three complete successes in ten attempts. This is a controlled evaluation of a particular setup, not a measurement of the model’s success rate against arbitrary real organizations.

The chart compares steps reached with cumulative token budgets, and the article discusses a 100-million-token limit per attempt. It reports that models continued making progress within the tested range. That observation does not establish unlimited improvement at higher budgets or a simple formula for real-world defense spending.

One argument for open source is that organizations relying on the same library can share findings and fixes. A fix contributed upstream may benefit many users, whereas isolated copies require separate maintenance. This benefit depends on maintainers having time and resources to evaluate and integrate the work.

There is also a countervailing risk: a widely used dependency can be a more valuable target because a single weakness may affect many downstream users. Neither shared review nor popularity guarantees safety. Responsible disclosure, rapid updates and careful dependency management remain important.

The article proposes a workflow with development, code review and security hardening as distinct phases. That can make ownership and spending visible, but security should also inform design and implementation throughout the lifecycle. A final scan cannot compensate for every architectural or operational problem.

More automated reports create another burden for open-source maintainers. I discuss a disagreement around an FFmpeg vulnerability report and argue that valid findings deserve attention. The severity and history of a specific case should be judged from its technical record; maintainers must also spend time filtering false positives and coordinating fixes.

A security report is only useful when someone can reproduce, assess and remediate it. Researchers should provide clear evidence through the project’s appropriate disclosure channel, and organizations benefiting from shared software should help fund the people who maintain and secure it.

I understand Cal.com’s concern about protecting customers, but I still regret seeing the main project close. My position is that open source remains worth supporting, especially as the cost of security work grows. The answer requires sustained maintenance and collaboration, not assuming that either openness or secrecy automatically solves security.

Support the projects you rely on and help maintainers respond to real security findings. We should take AI-enabled security risks seriously without declaring open source obsolete.