Open-source software is often described through what it removes. There may be no per-seat license, no single vendor controlling the source code and fewer barriers to modification. Those freedoms are real. They do not make the software ownerless once it enters a production system.
New guidance from the US Cybersecurity and Infrastructure Security Agency makes that distinction unusually clear. Published on July 30 for federal agencies, it recommends treating open source like any other software asset. Organizations should assess it before adoption, track it throughout its lifecycle, patch it and replace it when support ends.
The document is guidance for government agencies, not a universal mandate for companies. Its central lesson travels well because almost every modern application depends on code maintained somewhere else.
Open source changes the relationship between a user and a supplier. It offers the ability to inspect, modify and share. In return, the adopting organization must know what it is running and who will take responsibility when the project changes.
CISA recommends choosing actively maintained projects, understanding their licenses and keeping an inventory of open-source components and dependencies. A software bill of materials, or SBOM, can help a team identify which applications contain a vulnerable package after a new flaw is disclosed.
An SBOM is useful visibility, not a security certificate. It tells a team where a component may be present. Someone still has to decide whether the affected version is reachable, test the update and deploy it without breaking the product.
That work becomes harder when a small dependency sits several layers below the software a company believes it chose. It also continues for as long as the system remains in service. CISA advises monitoring projects for new vulnerabilities and signs that they no longer meet the organization’s trust requirements. If a supported fix never arrives, the user may need to contribute one or migrate to an alternative.
This is where “free” becomes an incomplete budget category. The source code may have no purchase price, while maintenance requires engineers, testing environments, dependency tooling and time reserved for upgrades.
The 2026 State of Open Source Report illustrates the tension. The survey, produced by OpenLogic with the Open Source Initiative and Eclipse Foundation, collected more than 700 responses. Fifty-five percent cited avoiding vendor lock-in as a reason to adopt open source. Among respondents at organizations with more than 5,000 employees, 60 percent said at least half their time went to maintenance, production issues and bug fixes rather than new features.
Those figures describe the respondents, not every company. They still show why control and effort must be discussed together. The same report found that 20 percent of organizations had no specific process for responding to disclosed vulnerabilities, while 39 percent of large enterprises struggled to meet their own remediation deadlines.
CISA also encourages agencies to return security fixes, bug reports, documentation and technical discussion to the projects they rely on. That is not charity added after the “real” work. A shared fix can remove duplicated maintenance and reduce the chance that a private patch becomes an unsupported fork.
Contribution requires care. Code, configuration and documentation must be reviewed so they do not expose credentials, internal system details or other sensitive information. Organizations also need clear rules about who may participate publicly and which changes belong upstream.
The deeper point is that an open-source dependency is a relationship with a project, even when no contract exists. Maintainer activity, release practices, vulnerability disclosure and community governance all affect operational risk. Download counts alone say little about whether a package can support a system for the next five years.
Open-source AI makes the definition even less tidy. CISA warns that a model can carry an open license while withholding training data or details of the training process. Without enough visibility into those components, an organization may be unable to assess provenance or investigate manipulation. The guidance recommends treating such a system more like proprietary software with incomplete provenance and applying stricter controls.
That does not settle the wider debate over what qualifies as open-source AI. It gives adopters a practical test. The value of openness comes from meaningful access and the ability to study and repair, not from a label attached to a download page.
For a team choosing software, the useful questions are therefore operational. Who owns the dependency inventory? How quickly must critical patches ship? What happens if the maintainer disappears? Can the organization build the code itself? Is there a tested replacement path? Will engineers be allowed time to contribute fixes upstream?
A proprietary product can fail these tests, and an open project can pass them brilliantly. The license alone does not decide reliability.
Open source remains one of the most productive arrangements in technology because it distributes knowledge and permits cooperation across organizational boundaries. Its mature use begins when a company stops treating adoption as a one-time download. The door is open. Keeping the software healthy still requires someone to walk through it, inspect what is inside and stay responsible after installation.