Open-Source in the AI Era

Choices and layers

Choosing between open and closed source is a pivotal decision for developers. While not irreversible, history suggests it is seldom undone. In the AI landscape, a clear divide has emerged: leading US commercial entities like Anthropic, OpenAI, and Google favor closed-source models (Claude, ChatGPT, Gemini), while open-source alternatives are often scaled-down versions or from international competitors.

This choice carries commercial, security, and community implications. However, as technology evolves, traditional arguments for both models require a second look.

Security Implications

Advanced security scanning, like Mythos, will create new motivations for keeping software closed source.

Historically, the “million eyeballs” effect ensured that open-source security defects were quickly found. But in an era of AI-driven scanning, the equivalent of a billion eyeballs can simply be purchased as compute tokens.

Consequently, the primary security benefit of open source declines, while the advantage of closed source—forcing attackers to probe a compiled “black box” rather than reading a blueprint—remains. We should expect the security balance to shift accordingly.

Commercial Implications

Conversely, AI tools capable of reverse-engineering software from specifications weaken the commercial moat of closed source. If a replica can be generated from behavior alone, the protection of hidden code diminishes.

We should be careful not to overstate those capabilities. While advanced AI tools can create working replicas in many cases, a simple approach to this will produce a less capable, less secure and less maintainable replica. And an advanced approach will require a lot of tokens (which you must pay for), and the efforts of someone who knows what software needs to be good software.

Still, even with those qualifiers, a shift occurs, and developers are left with a little less commercial motivation toward closed source. An open source software package that binds a community to it could be a more stable commercial decision.

The Background Shift

While both of these implications are interesting, they are both watered down by the shift toward managed software that’s progressed over the last decade. Software as a Service, and its variants (Platform as a Service, Infrastructure as a Service) involve a third-party taking responsibility for some part of the managing running software. Management provides a way to offer value beyond the observable parts of the software. In the realm of security, the privilege of management can be used to layer protections. In the realm of commercial implications, value may derive from the efficiency and organizational capabilities to operate the software well.

Those security protections allow providers to rely heavily on open-source repositories for foundational logic, but wrap those deployed software in managed, closed-source service layers. This intermediary role is crucial. It creates a secure boundary where security teams can insert active, AI-driven monitoring and take an adversarial role against attackers with the advantage of obscurity. By funneling interactions through this managed layer, threats can be caught and mitigated before they ever touch the raw, open-source code underneath.

In a sense, open-source both won and lost, as the dominant shift was not from closed-source executables to open-source repositories, but from close-source executables, to managed service deployments based on open-source repositories. The managed service layer provides many of the security benefits of closed-source executables, by allowing security teams to take an active adversarial role, with an obscurity advantage. By having some private tools and techniques, they could often have proactive responses to attacks, rather than only reactive ones. This overall mix, millions of eyeballs on the source, with additional managed layers has been a potent one, and will remain so. That said, we should expect some change in the balance here, with a greater part of the managed layers as closed source.

Conclusion

In the realm of managed services, I’d expect the net result to encourage doubling down on the trend. Proprietary layers to create well managed services will proliferate. Competition with open-source software will not be a priority, but proprietary forks and extensions that improve performance, manageability or security will be.

One question is, who will donate the tokens for scanning open-source repositories? You can’t expect open source developers to buy and donate tokens for scanning the same way they donated their time. Industry cooperation, sponsorship and coordination will be needed here.