The operating system running most of the internet's servers is Linux. The programming languages underlying most modern applications are open source. The databases, frameworks, container orchestration tools, and machine learning libraries that power contemporary software development are largely open source projects. This didn't happen by accident, and it didn't happen because of any single philosophical movement or corporate strategy. It happened through a gradual accumulation of pragmatic decisions — by developers, companies, and increasingly by the organizations that fund and deploy software at scale.
How We Got Here
The early history of free and open source software is well-documented: Richard Stallman's GNU project in the 1980s, Linus Torvalds' Linux kernel in 1991, the gradual coalescing of the open source label as a more commercially palatable framing of software freedom. What's less often told is the business story — how major commercial software companies went from treating open source as a threat to becoming its largest funders and contributors.
The pivot began in earnest when cloud computing companies recognized that open source infrastructure was both a cost reduction and a market development strategy. If a database project becomes the industry standard through open source adoption, the company best positioned to offer hosted, managed versions of that database at scale has a durable business. Contribute to the project, build organizational expertise, offer the convenience of managed hosting — this model, pioneered in various forms by companies like Red Hat and Cloudera and later refined by AWS, Google Cloud, and Azure, turned open source from a commercial liability into a core business asset.
The effect was a significant acceleration of open source development. Corporate contributions to major open source projects grew substantially through the 2010s. The Linux kernel, Apache projects, Kubernetes, TensorFlow, PyTorch, and dozens of other foundational technologies benefited from engineering investment that wouldn't have been available to volunteer-maintained projects alone.
Most professional developers today work primarily with open source tools and libraries on a daily basis. — Photo: Unsplash
The Sustainability Problem That Didn't Get Solved
The commercial investment in open source has been real and significant. It has also been extremely uneven. The projects that received corporate backing tended to be ones where large companies had clear commercial interests — infrastructure components that formed the basis of cloud services, languages and runtimes that supported major application ecosystems, tools that reduced operational costs at scale.
The vast middle of the open source ecosystem — thousands of smaller libraries and utilities that underlie production software without being prominent enough to attract corporate sponsorship — has remained largely dependent on volunteer maintainer time. The Log4Shell vulnerability in 2021 illustrated this vividly: a critical security flaw in a widely used Java logging library maintained essentially by a small number of volunteers without dedicated funding created a major security incident for organizations across industries. The library was everywhere; the resources to maintain it properly had been nowhere.
Several initiatives — the Open Source Security Foundation, GitHub Sponsors, various foundation funding programs — have attempted to improve this. Progress has been real but modest relative to the scale of the problem. A large fraction of production software continues to depend on components maintained by individuals working without compensation, on their own time, with no formal obligation to continue.
The License Wars Have Resumed
One of the more contentious recent developments in open source has been a wave of projects switching from permissive licenses to more restrictive ones — typically in response to cloud providers offering hosted versions of those projects as revenue-generating services without meaningfully contributing back to the original codebase.
MongoDB, Elasticsearch, HashiCorp, and several others have moved to licenses that restrict commercial use without a paid agreement. The debates these moves have triggered touch on fundamental questions about the social contract of open source: Is software released under a permissive license genuinely offered for any use? What obligations, if any, do commercial beneficiaries of open source projects have to their maintainers? The open source definition as maintained by the Open Source Initiative doesn't accommodate restrictions on commercial use — which means these new licenses are, by that definition, not open source. That hasn't stopped their practical adoption.
Open Source AI: A Different Kind of Openness
The AI era has introduced new complexity into what "open source" actually means. Major AI labs have released model weights — the parameters that define a trained model's behavior — under various licenses, and described these releases as "open source" to varying degrees of accuracy. Releasing weights is different from releasing training code, training data, and the full methodological details needed to reproduce a model from scratch. Some releases include all of these; many include only some.
The community shorthand "open weights" has emerged to describe releases where only the model parameters are public, without full training reproducibility. This distinction matters for several reasons. A model whose weights are public but whose training data is proprietary can still be used, fine-tuned, and deployed — but it can't be independently audited for the data it was trained on, can't be fully reproduced if the originating organization disappears, and raises different intellectual property questions than a project where every component is documented and reproducible.
The policy debate around open weights AI has been vigorous. Advocates argue that open model releases democratize access to capable AI, enable independent research, and counterbalance the concentration of AI capability in large private companies. Critics argue that releasing capable model weights without adequate safety evaluation is a form of irreversible proliferation — once weights are released, they cannot be recalled, and downstream fine-tuning can remove safety constraints imposed during original training.
The Developer Experience Dividend
Whatever the complications around sustainability, licensing, and AI-specific definitions, open source has delivered a concrete and substantial improvement in the developer experience over the past two decades. A developer building a web application in 2026 has access to a mature ecosystem of open source frameworks, libraries, testing tools, and deployment infrastructure that would have required significant proprietary software expenditure (or from-scratch development) in any previous era.
The learning resources associated with open source ecosystems — documentation, community forums, tutorials, code examples — have similarly been a substantial collective good. The density of available knowledge around popular open source tools has raised the floor of what individual developers can accomplish significantly.
This is perhaps the most underappreciated part of open source's economic contribution. The reduction in software development costs enabled by freely available, high-quality components has compounded through the entire technology economy, enabling businesses and individuals to build on infrastructure that would otherwise have required substantial capital investment or simply been inaccessible.
Where It Goes From Here
Open source's dominance in infrastructure is unlikely to reverse. The switching costs, network effects, and developer ecosystem effects that favor incumbent open source projects in their respective domains are substantial. What will continue to evolve is the economics — how maintainers are compensated, how the tension between open access and commercial sustainability is resolved, and how "openness" gets defined in the context of AI systems that are considerably more complex than traditional software packages.
The organizations navigating this most thoughtfully are treating open source contribution not as charity but as a genuine infrastructure investment — understanding that the health of the projects they depend on is a business continuity concern as much as an ideological preference. That framing — pragmatic, specific, and resource-backed — is probably more durable than any of the various philosophies that have surrounded open source since its origins.