The End of "Open Source" as a Security Blanket

The core thesis here is that the traditional security model of open source--the idea that "many eyes make all bugs shallow"--has been inverted by the rise of AI. Peer Richelsen, co-founder of Cal.com, argues that the democratization of powerful offensive AI tools has turned public repositories into high-value targets. For commercial open-source companies, maintaining a single, public codebase that powers both community versions and enterprise production environments is no longer a sustainable risk. This shift reveals that the openness that once built trust now creates an unmanageable attack surface. Founders and CTOs must recognize that immediate transparency is now a liability. The advantage today lies in internalizing the security of private forks, not to hide functionality, but to protect sensitive customer data from automated, AI-driven exploitation.

The Erosion of the Reporting Culture

Historically, open source relied on a virtuous cycle: security researchers would find vulnerabilities, report them, and maintainers would patch them. AI has shattered this feedback loop by flooding maintainers with slop, such as generated pull requests and hallucinated vulnerability reports.

"The reporting culture that has kept open source safe and secure all these years is collapsing under the ai generated noise."

-- Peer Richelsen

When every repository is drowning in automated noise, the signal-to-noise ratio drops to near zero. This forces maintainers to become gatekeepers rather than collaborators. The downstream consequence is that the best idea no longer wins; the best prompt or the most aggressive automated agent dictates the codebase. Over time, this creates a recursive loop where AI agents learn from low-quality, AI-generated code, permanently degrading the project integrity.

The Death of "Security by Transparency"

The most important insight is that the very thing that made open source safe--public visibility--is now the primary vector for exploitation. In the pre-AI era, black-box hacking, or reverse-engineering an API, required significant time and specialized skill. Today, that barrier to entry has evaporated.

"The amount of money resources and talent to find an abuse for abilities has like a 100x in terms of ease of use... you're giving basically evil people a single prompt in their terminal to find an abuse open source repositories."

-- Peer Richelsen

Because the knowledge graph has been flattened, a malicious actor and a white-hat researcher now possess identical offensive capabilities. When the source code is public, an attacker does not need to guess; they can simply scan the repository for vulnerabilities and trigger them autonomously. For a business processing sensitive customer data, the open-source-as-a-security-feature narrative has become a dangerous relic.

The Shift to Internal Forging

The proposed solution is not the abandonment of open source, but the strategic separation of concerns. Companies like Cal.com are moving toward a DIY model: keeping a community version open for public good while maintaining a private, hardened fork for production.

This creates a necessary buffer. By keeping the commercial and sensitive layers private, companies limit their blast radius. The immediate discomfort of managing two codebases--and the potential backlash from purists--creates a durable advantage: the ability to maintain security in an era where public code is essentially a map for attackers. This is an unpopular move, but it is the only way to reconcile the need for open-source community engagement with the absolute requirement of enterprise-grade security.

Key Action Items

• Audit your exposure: Run automated AI scanning tools against your own repositories to identify what a malicious agent would see. Do this immediately to understand your current blast radius.
• Decouple sensitive layers: If your product handles auth, database interactions, or payment logic, move these components into a private, internal fork. (Immediate investment)
• Implement "Issue-Only" contributions: Stop accepting pull requests from the public. Shift to an issue-based contribution model where you curate and write the code yourself to maintain quality and security. (Over the next quarter)
• Re-evaluate the "Open Source" label: If you are a commercial entity, be honest about what is "public good" (UI components, libraries) versus "commercial asset" (auth, database, middle-layer). Don't conflate the two. (Ongoing)
• Adopt security-by-distribution: For your open-source community version, accept that it will be less secure than your private fork. Market it as "use at your own risk" and focus your security resources on the private production environment. (12-18 month horizon)