Key Takeaways
- Open source software runs much of the internet’s underlying infrastructure, from Linux servers and web servers to container orchestration and encryption libraries.
- Its biggest advantage is not that it is “free,” but that organizations can inspect, adapt, audit, and operate the code without being locked into one supplier.
- The same dependency model creates real security and maintenance risks, as incidents such as Heartbleed and Log4Shell demonstrated.
- Governments and enterprises are now treating open source security as supply-chain infrastructure, with SBOMs, provenance checks, and secure development practices becoming more important.
The modern internet is built less like a collection of finished products and more like a shared engineering stack. A website may run on Linux, use an open source web server, rely on OpenSSL for encrypted connections, package services into containers, and deploy them through Kubernetes. Each layer can be maintained by a different community, company, foundation, or volunteer.
That arrangement is why open source software has become foundational to digital infrastructure. Source code is available under licenses that allow people and organizations to inspect, use, modify, and redistribute it under defined conditions. For internet operators, that means critical software can be adapted to unusual hardware, audited for security problems, and supported by more than one vendor.
This is not a claim that open source is automatically better or safer than proprietary software. It is an explanation of why it has become the default building material for the internet—and why the health of relatively small upstream projects now matters to banks, governments, cloud providers, and ordinary web users.
The Internet Runs on Shared Building Blocks
Open source software appears at nearly every layer of a typical online service. Linux is widely used on servers and powers much of cloud infrastructure. Web applications commonly depend on open source databases, programming languages, web frameworks, message queues, and observability tools. At the network edge, operators may use open source components for DNS, TLS, routing, caching, and load balancing.
Containers and cloud-native infrastructure show how thoroughly this model has spread. The CNCF’s 2024 annual survey, published in April 2025, found that production use of Kubernetes reached 80% of respondents in 2024, up from 66% in 2023—a 20.7% annual growth rate. When including organizations piloting or actively evaluating Kubernetes, adoption rises to 93%. The full report is available from the CNCF annual survey page. Kubernetes began as a Google project; Google announced its donation to the newly formed CNCF alongside Kubernetes 1.0 in July 2015, and the project graduated from CNCF incubation in 2018. Its community governance is documented publicly in the project’s governance repository.
That governance model matters. Kubernetes is not dependent on a single cloud company’s roadmap, even though major vendors offer managed versions of it. A company can run Kubernetes itself, buy support from a provider, move workloads between environments, or contribute fixes upstream. This does not eliminate migration costs, but it gives customers more leverage than a closed platform with no practical substitute.
Why Businesses Keep Choosing Open Source
It reduces single-vendor dependency
Organizations do not need permission from one software publisher to inspect a bug, build a feature, or hire a third party for support. For infrastructure expected to remain in service for years, that flexibility can be more valuable than an initially low license cost.
It enables collaboration at internet scale
Internet standards and infrastructure need interoperability. Open source projects give cloud providers, hardware vendors, startups, researchers, and enterprise users a shared place to solve common problems. The result can be faster improvement in areas that do not benefit from every company writing its own incompatible implementation.
It makes code review possible—but not automatic
Public code can be inspected by customers, security researchers, and competing vendors. That transparency is useful for audits and incident response. But “many eyes” is not a security guarantee. A project may be widely deployed while having only a handful of maintainers with time to review complex changes.
The Weak Point: Critical Projects Can Be Under-Resourced
The internet’s reliance on open source also concentrates risk. The 2014 Heartbleed flaw, tracked as CVE-2014-0160, affected certain versions of OpenSSL and could expose sensitive memory from vulnerable servers. In 2021, the Log4Shell vulnerability in Apache Log4j triggered a global response because the logging library was embedded in a vast number of Java applications. Apache maintains the relevant Log4j security advisories.
These incidents exposed a mismatch: a component can be essential to global commerce while its maintenance funding and contributor base remain modest. The problem is not unique to open source, but open dependencies can travel deep through software supply chains, making it difficult for organizations to know where a vulnerable component is used.
That is why the debate has shifted from “open source versus closed source” to better stewardship. Companies that profit from widely used projects increasingly need to contribute funding, engineering time, security review, documentation, and long-term maintenance—not simply download releases and hope volunteers continue indefinitely.
Policy Is Turning Open Source Security Into an Operational Requirement
Governments are responding by focusing on software supply-chain visibility. The United States’ Executive Order 14028 in May 2021 directed federal agencies to improve software security practices and helped accelerate adoption of software bills of materials (SBOMs). NIST’s Secure Software Development Framework (SSDF) provides a common set of secure development practices, while the NTIA publishes SBOM guidance and resources. EO 14028 helped establish the modern U.S. federal software-supply-chain framework, which was subsequently extended by Executive Order 14144, signed on January 17, 2025, titled “Strengthening and Promoting Innovation in the Nation’s Cybersecurity.” That later order built on the SBOM, attestation, and incident-reporting foundations of 14028 and added further measures for secure software acquisition and cyber safety review.
A significant policy development is the EU Cyber Resilience Act, formally published as Regulation (EU) 2024/2847. It distinguishes non-commercial free and open source development from products made available commercially, but it still raises the stakes for companies that package, sell, or integrate open source software into connected products. The practical effect is likely to be greater demand for vulnerability handling, component inventories, and documented security processes.
What Responsible Users of Open Source Should Do
Organizations do not need to avoid open source. They need to manage it as a core dependency.
- Maintain an inventory: Generate SBOMs in recognized formats such as SPDX or CycloneDX. Tools including Syft can create component inventories, while Trivy can help identify known vulnerabilities in images and filesystems.
- Automate dependency updates carefully: Dependabot and Renovate can open update pull requests, but teams still need testing, review, and rollback plans before merging changes into production.
- Verify what was built: Use signed releases and provenance where available. Sigstore’s Cosign can verify container signatures, while SLSA provenance helps establish how an artifact was built.
- Support critical upstream projects: Companies relying heavily on a project should consider paid support, direct sponsorship, developer contributions, or funding independent security audits.
- Plan for abandonment: Know who owns each dependency, how quickly it is patched, and what replacement or fork strategy exists if maintenance stops.
What Comes Next
Open source will remain central to the internet because no single vendor can realistically supply every layer of global computing infrastructure. The more important question is whether the organizations that depend on shared code will help sustain it.
The strongest open source projects combine transparent governance, active maintainers, clear security reporting, reproducible releases, and reliable funding. The weakest are invisible dependencies with unclear ownership. For technology leaders, the lesson is straightforward: open source is not a free resource outside the business. It is part of the business’s infrastructure, and it should be funded, tracked, and secured accordingly.
Frequently Asked Questions
Is open source software free to use?
Many open source projects can be used without paying a license fee, but “open source” describes licensing rights rather than price. Organizations may still pay for support, hosted services, compliance work, security reviews, and engineering time.
Is open source software more secure than proprietary software?
Not automatically. Public source code can make auditing and independent review possible, but security depends on maintainers, review processes, release practices, testing, and how quickly users apply fixes.
What is an SBOM?
A software bill of materials is a machine-readable inventory of components in a software product. It helps organizations identify where a vulnerable library may be used and assess exposure more quickly after a security disclosure.
