Discourse Is Not Going Closed Source

Cal.com have announced they’re closing their codebase and will no longer be an open-source product. Their reasoning is that AI has made open source too dangerous for SaaS companies. Code gets scanned and exploited by AI at near-zero cost, and transparency is now becoming exposure.

I understand where this is coming from; the industry is changing fast. New AIs with new cybersecurity capabilities are being released every few weeks. It's a scary world, and I agree completely that open-source companies need to adapt.

I do not agree with the decision that closing source is the solution to the security storm that is upon us. I do not agree it is the correct narrow decision for SaaS providers, and I do not agree it is the correct decision for the industry at large.

I want to be clear and firm about the position Discourse is taking. We are open source, we’ve always been open source, and we will continue to be open source. Ever since Jeff, Robin, and I shipped the first commits to the Discourse repository on GitHub, over a decade ago, the repository has been licensed under GPLv2. And that’s not changing.

The Closed-Source Argument

Cal.com’s position boils down to the claim that if attackers can read your code, AI will let them exploit it faster than you can either harden or patch it, and the forced action you need to take is to hide the code so you can buy time. There’s truth to the threat - AI has changed the speed at which vulnerabilities can be discovered. Over the past few months, our team has found and addressed a very large amount of latent security issues in Discourse using GPT-5.3 Codex, GPT-5.4, and Claude Opus 4.6 in our open-source codebase.

OpenAI and Anthropic are both extremely concerned about the vector, and in response GPT-5.4-Cyber and Anthropic Mythos are being rolled out cautiously.

But I think the race to close software off misses something. Those same AI systems don’t actually need your source code to find vulnerabilities; they work against compiled binaries and black-box APIs. Closed source has always been a weaker defense for SaaS than people want to admit. A web application is not something you ship once and keep hidden. Large parts of it are delivered straight into the user’s browser on every request: JavaScript, API contracts, client-side flows, validation logic, and feature behavior. Attackers can inspect all of that already, and AI makes that inspection dramatically cheaper. Closing the repository may hide some server-side implementation detail, but it does not make the system invisible. What it mostly does is reduce how many defenders can inspect the full picture.

The world’s most important internet infrastructure runs on open-source software, especially Linux. That code is exposed to constant scrutiny from attackers, defenders, researchers, cloud vendors, and maintainers across the globe. It is attacked relentlessly, but it is also hardened relentlessly. That is the real lesson of open source in security: transparency does not eliminate risk, but it enables a much larger defensive response.

AI does change the security calculus, but I still believe it favors open source. Yes, AI-powered scanning tools can now surface in hours the kinds of security issues that used to take human researchers weeks to uncover. In its research preview launch, OpenAI said Codex Security scanned more than 1.2 million commits across external repositories in a 30-day beta period and identified 792 critical findings and 10,561 high-severity findings. That is a staggering volume of vulnerability discovery.

But the key question is: who gets to use those tools? If your code is open source, your security team can scan it, your contributors can scan it, and independent researchers can scan it too. That does not guarantee defenders will always get there first, but it dramatically increases the number of people who can help find real problems early. If your code is closed, attackers can still study the product from the outside, through the browser, the API, the mobile client, and the behavior of the running system, while only your internal team gets direct access to the full code. That is not a reduction in exposure. It is a reduction in defensive capacity.

At Discourse, we’ve leaned into this reality. Our last monthly release included fixes for 50 security issues identified through multi-day scans using GPT-5.4 xhigh. Open source creates a useful urgency: when your code is public, you assume it will be examined closely, so you invest earlier and more aggressively in finding and fixing issues before attackers do. In a closed-source environment, you may mistakenly think you are safe because nobody can look. Some fraction of those issues would still be sitting there, undiscovered by defenders and waiting for an attacker to stumble across them. That’s not a better scenario.

Discourse launched in 2013. Jeff Atwood, Robin Ward, and I started it because the state of community software was embarrassing. Forums were running on decade-old PHP codebases with security and upgrade models from the early 2000s. We built Discourse as open source because we thought community software should belong to the communities using it, not to whatever platform happened to be hosting it that year.

That was 13 years ago. Today more than 22,000 communities run Discourse - tiny startups, Fortune 500 companies, everything in between. The whole codebase is on GitHub, GPL-licensed. Hundreds of outside developers have contributed security patches. In 13 years of running Discourse in the open, we have not seen evidence that public source code made us less secure. We have had vulnerabilities, of course; every substantial piece of software does. But the pattern has generally been the one you would hope for: bugs were reported, coordinated disclosures were handled responsibly, CVEs published, and fixes shipped quickly.

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.

Why companies go closed source

I want to be fair to Cal.com here, because I don’t think they’re acting in bad faith. I just think the security argument is a convenient frame for decisions that are actually about something else. Competitive pressure, mostly. If your code is open, your competitors can read your architecture and your product thinking. That’s painful, and it gets more painful as you grow - especially the first time a well-funded competitor forks your repo and ships a hosted version at half your price.

Governance is the other big one. Open-source communities push back. They file issues about decisions they don’t like. They fork. It’s exhausting to manage, and closing the code makes the noise stop immediately. Then you’ve got investors asking why you’re giving away the thing they just funded, and suddenly “closed source” looks a lot more defensible in a board deck.

These are all legitimate business pressures, and I don’t judge anyone for feeling them. But they’re business decisions, not security decisions. Framing a business decision as a security imperative does a disservice to the open-source ecosystem that helped Cal.com get to where they are.

How we handle security in 2026

Every release cycle, our team deploys the latest AI vulnerability scanners (GPT-5.4 xhigh at the moment, and next up is Opus 4.7 max) for multi-day deep analysis of our codebase. The scans catch the same class of vulnerabilities that an attacker’s AI would find.