Does AI change the risk of OSS?

Two different positions:

Cal.com is going closed source

Open source is dead. That’s not a statement we ever thought we’d make.

@calcom

was built on open source. It shaped our product, our community, and our growth. But the world has changed faster than our principles could keep up. AI has fundamentally altered the security landscape. What once required time, expertise, and intent can now be automated at scale. Code is no longer just read. It is scanned, mapped, and exploited. Near zero cost. In that world, transparency becomes exposure. Especially at scale. After a lot of deliberation, we’ve made the decision to close the core

@calcom

codebase. This is not a rejection of what open source gave us. It’s a response to what risks AI is making possible. We’re still supporting builders, releasing the core code under a new MIT-licensed open source project called cal. diy for hobbyists and tinkerers, but our priority now is simple: Protecting our customers and community at all costs. This may not be the most popular call. But we believe many companies will come to the same conclusion. My full explanation below ↓

Discourse will remain OSS

Cal.com is making a bet about the future of software security. They are betting that in an AI-accelerated threat environment, reducing visibility into the codebase will improve their security posture. I think that is the wrong bet. We are making the opposite one: that in a world where AI makes vulnerability discovery dramatically cheaper, the stronger position is to let defenders use the same tools against code they can actually inspect.

Biological immune systems work because they’re exposed to threats. They encounter pathogens and build memory. An immune system that’s never been challenged will collapse at the first real infection. Open-source codebases work the same way - vulnerabilities that get found and patched make the software harder to attack. Security researchers who read the code add layers of defense, and public audits build institutional knowledge about where the weak points are and how to shore them up.

Closed source can buy some obscurity, but obscurity is brittle. Code gets leaked, binaries get reverse engineered, APIs get mapped, and attackers learn a lot just by interrogating the running system. The real defense is not keeping the code hidden forever. It is building software and operational practices that hold up when scrutiny arrives.

Open source isn’t dead. But it takes courage to do security properly instead of retreating behind a locked door and hoping nobody has a key. We’ve done it for 13 years and we’re going to keep on doing it.

1 Like

This may be related:

It seems reliability and security are related.

Open source will have short term pain now, as it’s easier to find security issues, but after this short term pain open source will be MUCH more robust long term.

Closed source will avoid the short term pain, somewhat, but long term the attackers are still going to attack you. With the variety of reversing tools today and AI tooling which knows how to use them extremely effectively, it soon won’t matter if you’re closed or open source, effectively your source will be open enough that attackers will not really care about the availability of your source code.

Saying closed source will save you from attacks is misguided and is likely to only result in significantly more pain down the road, when the tools are even better than they are today and because altruistic smart people won’t want to help you in the same way they may want to help open source software.

3 Likes

I agree with @bradfa. Open source will actually benefit more than closed source over the long haul.

Also, maybe it’s just me, but it seems like most of this talk about AI cybersecurity is a big part of the AI hype train. Yes, most applications will need to be hardened, but for most applications, this can be done over time.

My biggest concern for open source is the inadvertent use of unmaintained libraries in the supply chain. We all need to be more vigilant (especially when it comes to NPM dependency hell) that libraries are being actively maintained so that an identified security issue can be quickly resolved.

1 Like