The Economics of Open Source: Who Pays and Who Builds

22 August 2026

Open source software is everywhere. It runs the servers that host the internet, powers the operating system on billions of Android phones, and forms the backbone of modern cloud infrastructure. Yet for all its ubiquity, the economic engine behind open source remains poorly understood by many who depend on it daily. The question of who pays for the code that the world runs on, and who actually writes it, has no single answer. Instead, it is a patchwork of motivations, business models, and funding mechanisms that have evolved over decades, often in response to crises.

The Myth of the Free Lunch

The most persistent misconception about open source is that it is free in the economic sense. It is free as in beer, yes, but someone always pays. The real cost is hidden in maintenance, security audits, and the time developers spend understanding and integrating code. A business that adopts a popular open source library without considering its upkeep is essentially taking on a liability disguised as a gift.

Consider the case of a widely used utility library. It might have hundreds of millions of downloads per week. The core maintainer might be one person, working evenings and weekends. That person is not being paid by the companies that depend on the code. They are paying with their time, their health, and often their career progression. When that maintainer burns out or moves on, the entire ecosystem that depends on the library faces a sudden, existential risk. This is not a hypothetical scenario. It has happened repeatedly, and it will happen again.

The economic reality is that open source shifts the cost of software from licensing fees to integration and maintenance. For a large corporation, this can be a massive net saving. For a small startup, it can be a hidden tax on engineering time. The key is to understand that "free" in open source means you have the freedom to use, modify, and distribute the code. It does not mean the code costs nothing to own.

The Volunteer Core and the Corporate Shell

The modern open source ecosystem is a strange hybrid. The vast majority of code contributions come from individuals, but the vast majority of funding comes from corporations. This creates a structural tension that shapes everything from project governance to feature development.

At the grassroots level, you have hobbyists, students, and independent developers who contribute because they need a tool that does not exist, or because they want to build a reputation, or simply because they enjoy the craft. These volunteers are the lifeblood of many projects. They write documentation, fix bugs, and answer questions on forums. Their motivation is not financial. It is personal and social.

At the corporate level, you have companies like Google, Microsoft, and Red Hat that employ developers to work on open source full time. These developers are paid to contribute, but they are not paid to be altruistic. They are paid because their employer benefits from the project's success. A company that relies on Kubernetes, for example, has a strong incentive to ensure Kubernetes is well maintained and evolves in a direction that aligns with its business interests.

This dual structure works well when the interests of volunteers and corporations align. It breaks down when they diverge. A volunteer might want to keep a project small and simple. A corporate contributor might want to add features that serve enterprise customers, even if those features add complexity. The resulting conflict can lead to forks, hostile takeovers of project governance, or simply stagnation.

The lesson for anyone involved in open source is to be explicit about incentives. If you are a corporate contributor, acknowledge that your motivations are not purely altruistic. If you are a volunteer, understand that corporate money comes with corporate priorities. Neither side is evil. They just have different goals.

The Business Models That Actually Work

There is no single business model for open source that guarantees success. Instead, there are several approaches, each with its own trade-offs. The most common and durable models are worth examining in detail.

Open Core

The open core model involves releasing a basic version of the software as open source while keeping advanced features proprietary. This is how companies like GitLab and Elastic initially grew. The open source version attracts users and builds community. The proprietary version generates revenue from enterprises that need features like single sign-on, advanced security, or compliance tooling.

The advantage of open core is that it is straightforward to understand and execute. The risk is that the community will perceive the proprietary features as essential, leading to resentment and forks. If the open source version is too limited, no one will use it. If it is too complete, no one will pay for the proprietary version. Finding the right line is an art, not a science.

Managed Services and SaaS

Another model is to offer the software for free but charge for hosting it. This is the approach taken by companies like WordPress.com and, in a more complex form, by cloud providers that offer managed databases for open source engines like PostgreSQL or MongoDB.

The appeal of this model is that it aligns with the way modern companies consume software. They do not want to run infrastructure. They want to consume a service. The challenge is that the open source project itself does not generate direct revenue. The revenue comes from the operational expertise and infrastructure that the company provides around it.

This model also creates a tension with the open source community. If a cloud provider offers a managed service, they are effectively competing with the project's own maintainers. This has led to license changes, most notably by MongoDB and Elastic, which altered their licenses to prevent cloud providers from offering their software as a service without sharing revenue. These license changes were controversial, but they were a rational response to an economic problem.

Support and Consulting

The oldest business model in open source is selling support and consulting. Red Hat built a multi-billion dollar business on this model, providing enterprise-grade support for Linux and other open source tools. The software is free. The expertise is not.

This model works best for complex infrastructure software where the cost of failure is high. A company running a database in production is willing to pay for a guarantee that someone will fix it at 3 AM. The challenge is that support revenue scales linearly with the number of customers, which limits growth potential. It is a solid business, but not a hyper-growth one.

Dual Licensing

Dual licensing is a less common but powerful model. The same code is released under two different licenses: a permissive open source license for community use, and a commercial license for companies that want to embed the code in proprietary software without complying with the open source terms.

This model works well for libraries and components that are embedded in larger products. The company that owns the copyright can offer a commercial license to companies that do not want to share their source code. The advantage is that it creates a clear revenue stream from commercial users. The disadvantage is that it requires the company to own all the copyrights in the code, which means contributors must sign over their rights. This can be a barrier to community participation.

The Role of Foundations and Sponsors

Foundations like the Apache Software Foundation, the Linux Foundation, and the Eclipse Foundation play a critical role in the economics of open source. They provide a neutral home for projects, handling legal issues, trademark protection, and sometimes funding for infrastructure.

The funding for these foundations typically comes from corporate members. A company might pay a six-figure annual fee to be a "gold" or "platinum" member. In return, they get a seat on the board and influence over the project's direction. This is a form of insurance. By paying into the foundation, a company ensures that the project has the resources to survive and that no single vendor can control it.

Foundations also help with the "tragedy of the commons" problem. Without a foundation, a popular project can become a victim of its own success. No single company wants to pay for maintenance because they all benefit from it equally. A foundation can pool resources and allocate them to the most critical needs, like security audits or full-time maintainers.

However, foundations are not a panacea. They can become bureaucratic and slow. They can also be dominated by the largest donors, which means the interests of small companies and individual contributors are often ignored. The key is to choose the right governance model for the project's stage and size.

Who Actually Builds the Code

The stereotype of the open source developer is a lone hacker in a basement, living on ramen and caffeine. The reality is more prosaic. Most open source code is written by people who are paid to write it, either by a company that uses the software or by a company that sells it.

A study of the Linux kernel, for example, would show that the majority of contributions come from developers employed by large tech companies. These developers are not writing code in their spare time. They are writing it as part of their job. Their employer benefits because the kernel is critical to their products, whether those products are servers, phones, or cloud services.

This does not mean that volunteers are irrelevant. They are essential for the long tail of open source: the small utilities, the niche libraries, the plugins, and the documentation. These are the projects that do not attract corporate funding but are still used by thousands of developers. They survive on the goodwill of individuals who find them useful.

The implication is that the open source ecosystem is not a meritocracy. It is a market. The projects that get the most attention and funding are the ones that are most strategically important to large companies. This is not a criticism. It is just a fact. If you are starting an open source project, you should be aware that the chances of it becoming a critical infrastructure component are low. The chances of it being a useful tool for a small community are much higher, and that can be a perfectly good outcome.

The Hidden Costs of Open Source

Open source shifts costs, but it does not eliminate them. The most significant hidden cost is security. When a vulnerability is discovered in a widely used open source library, the entire ecosystem must scramble to patch it. This is not a one-time event. It is a continuous process.

The Log4j vulnerability in late 2021 is a prime example. A single logging library, used in millions of applications, had a critical remote code execution flaw. The response required emergency patches, coordination across thousands of organizations, and a great deal of anxiety. The library itself was maintained by a small group of volunteers who were suddenly thrust into the global spotlight.

Another hidden cost is compliance. Open source licenses are not all the same. Some are permissive, like the MIT and BSD licenses. Others are copyleft, like the GPL, which requires derivative works to be released under the same license. Companies that do not have a robust open source compliance program can find themselves in legal trouble for inadvertently violating a license.

The best practice is to have a clear policy for open source usage. This includes maintaining a list of approved licenses, tracking which open source components are used in which products, and having a process for reviewing new dependencies. This is not glamorous work, but it is essential.

The Sustainability Crisis and What to Do About It

The open source community has been talking about a sustainability crisis for years. The problem is simple: demand for open source is growing faster than the supply of maintainers. More and more companies are building on open source, but they are not contributing back proportionally to their usage.

There are several reasons for this. First, contributing to open source is not free. It takes time to understand the codebase, write quality patches, and navigate the review process. Many companies simply do not see the return on investment. Second, there is a free-rider problem. If a company can use a library without paying for it, why would they pay? Third, the incentives for individual developers to contribute are often misaligned. A developer might want to contribute, but their manager sees it as a distraction from their day job.

There is no single solution to this crisis, but there are several practices that can help.

For Companies

If your company uses open source, you have a responsibility to support it. This does not mean you have to write code. You can provide financial support through a foundation, sponsor a maintainer, or simply donate to a project's funding platform. You can also encourage your developers to contribute fixes and improvements as part of their regular work. This is not charity. It is maintenance. The code you use is an asset, and assets need to be maintained.

For Individual Developers

If you benefit from an open source project, consider contributing back. This can be as simple as reporting a bug clearly, writing documentation, or helping other users on a forum. You do not have to be a core maintainer to add value. The small contributions are what keep a community alive.

For Maintainers

If you maintain a project, you need to be realistic about your capacity. It is better to have a small, well-maintained project than a large, neglected one. Set clear expectations for response times and contribution guidelines. Do not be afraid to say no to feature requests that are outside the project's scope. And if you are burning out, step back. The project will survive without you, or it will not. Your health is more important.

The Future of Open Source Economics

The economics of open source are not static. They are evolving in response to changes in technology and business. The rise of cloud computing has shifted the value from software itself to the services around it. The rise of artificial intelligence has introduced new questions about licensing and training data. The rise of supply chain attacks has made security a top priority.

One trend is the increasing professionalization of open source. More projects are adopting formal governance structures, hiring full-time maintainers, and treating sustainability as a budget item rather than an afterthought. This is a positive development, but it also risks creating a divide between professionally maintained projects and community-driven ones.

Another trend is the emergence of new funding mechanisms. GitHub Sponsors, Open Collective, and other platforms allow individuals and companies to directly fund the projects they depend on. These platforms are not a complete solution, but they are a step in the right direction. They make it easier for money to flow to the people who do the work.

The most important thing to understand is that open source is not a charity. It is an economic system with its own incentives, costs, and benefits. The sooner we treat it as such, the better we can manage it. Companies that view open source as a free lunch will eventually be surprised by the bill. Companies that view it as a shared resource to be cultivated will be rewarded with a more stable and secure foundation for their products.

The question of who pays and who builds does not have a simple answer. It is a negotiation between the people who need the software and the people who create it. The best outcomes happen when both sides recognize their mutual dependence and act accordingly. That is the real economics of open source.