Open source and AI code: the maintenance bill comes later

The cost starts after the download

An open-source package can save a team months of development. Once it reaches production, someone still has to patch vulnerabilities, manage breaking upgrades and answer the call when it fails at 2 a.m. A zero-dollar license tells you little about the cost of keeping the software running.

Justin Dolly, Ory's Chief Customer and Security Officer, describes that difference through an analogy he encountered in a presentation by Insight Partners' Lonne Jaffe: free beer versus a free puppy. One is consumed and finished. The other brings years of responsibility.

The distinction sits alongside the open-source movement's older definition of freedom. Richard Stallman's “free as in speech” concerns the liberty to use and modify software. Production teams have another question to answer: who will maintain what they adopt?

The initial installation is usually the easy part. A package brings dependencies, which bring dependencies of their own. A major release may break an integration. A disclosed vulnerability can turn a Friday evening into an emergency patching session. Those obligations rarely appear in the original adoption decision, even when the team has accurately counted its infrastructure costs.

When maintainers become a dependency

Companies often depend on a small group of people to maintain widely used software. Those maintainers may be volunteers, underfunded or stretched across more work than they can sustain. The downstream organization still carries the consequences when something goes wrong.

Dolly points to three incidents. Heartbleed, disclosed in 2014, affected OpenSSL, a critical part of internet encryption maintained by a small, underfunded team. Log4Shell, in December 2021, exposed how difficult it was for organizations to identify a vulnerable logging library buried inside their Java applications. Teams first had to establish whether they were using it before they could assess and repair their exposure.

The 2024 xz utils backdoor exposed a different weakness. An attacker spent roughly two years building trust around an overworked maintainer. Microsoft's Andres Freund discovered the problem after investigating an unusual delay in SSH logins. The incident made maintainer capacity and trust part of the security discussion, alongside the code itself.

Dolly's argument is that these incidents reveal gaps in ownership. A project can be open to inspection while the work of reviewing, maintaining and funding it still falls to too few people. An organization adopting that project needs to understand how much of that work it is relying on others to perform.

Generated code still needs an owner

Generative AI makes the adoption decision easier to underestimate. If a model can produce an internal service in seconds, buying or integrating existing software may look unnecessarily expensive. The cost comparison changes once the team includes the work that follows generation.

A custom service may have no external maintainer community reviewing it and no project-specific advisory feed telling its owner when something is wrong. Its dependencies can still have public advisories, but defects in the generated application itself may be visible only to the organization running it. The team that accepts the code also accepts responsibility for finding and fixing those defects.

AI may reduce maintenance costs as tools improve at finding and repairing bugs. Dolly acknowledges that possibility while noting that attackers have access to the same tools. Faster fixes can reduce the burden; teams still need someone accountable for reviewing changes and keeping the service secure.

Make maintenance part of adoption

That starts with knowing what is already running. A software bill of materials should cover transitive dependencies as well as the packages a team directly installs. During an incident, an inventory can help teams answer whether a vulnerable component is present without first reconstructing their software stack.

Project health deserves its own review. Maintainer count, commit activity and funding offer evidence of how the work is sustained. A published security policy tells users how to report a vulnerability. A project with one maintainer also concentrates continuity and trust in one person, a risk the xz incident made difficult to ignore.

Patching, upgrades and monitoring need a recurring budget and an owner. Teams can take that responsibility fully in house or share it through commercial support, a managed service or an enterprise license. The important decision is to assign it before the next vulnerability forces the question.

Organizations can also fund the projects they rely on and contribute fixes upstream. Generated code belongs in the same ownership process: review it, test it, scan it and assign someone to maintain it. The speed of producing software does not determine how much attention it will need in production.

For teams running Ory open source that want Ory to handle CVE patching, the company outlines its CVE support offering.

Based on “Free beer, free puppy: the real cost of open source in production,” supplied by Justin Dolly, Chief Customer and Security Officer at Ory.