Companies depend on open source software.
They use it to build products, operate infrastructure, serve customers, and make money. In many cases, the company couldn’t function without it.
Then someone asks whether the company should help support the projects it depends on, and the conversation turns strangely charitable.
Is supporting open source a nice thing to do? Is it part of being a good member of the community? Can we find a little budget for sponsorship this year?
Those aren’t bad questions. They’re simply not enough to sustain something a business relies on.
Charity is optional. Dependencies aren’t.
That distinction matters more now than it did when I first started drafting this argument years ago. Open source is no longer something companies use at the edges because a developer found a helpful library. It’s the foundation under products, infrastructure, AI systems, security tools, cloud platforms, developer workflows, and the web itself.
We’re also seeing more public recognition that open source is infrastructure. The Sovereign Tech Agency now lists more than 100 supported technologies and tens of millions of euros invested in open digital infrastructure. That kind of funding is useful. It’s also a sign of how large the maintenance problem has become.
If a project is critical enough for governments, foundations, and companies to describe it as infrastructure, then supporting it can’t depend on whether someone feels generous this quarter.
Comic: “Dependency” by Randall Munroe / xkcd, used under CC BY-NC 2.5.
Money Matters
Companies need to make money.
That isn’t a criticism. Revenue lets a company pay employees, support customers, invest in new products, and continue operating. A company that doesn’t care about financial sustainability won’t be a reliable partner for very long.
Open source projects need sustainability too. Code has to be maintained. Reports have to be reviewed. Releases have to be tested. Documentation has to be written. Security issues have to be handled carefully. Contributors need help becoming maintainers, and maintainers need the ability to step away without putting the project at risk.
Much of that work is difficult to see precisely because someone has been doing it well.
When a company treats support as a donation, that support has to compete with every other worthy cause. The budget may survive one year and disappear the next, even though the company’s technical dependence hasn’t changed.
A more durable model starts by recognizing support as an investment in infrastructure.
That’s a different conversation inside a company. Donations are nice. Risk reduction, dependency health, predictable maintenance, security response, and operational continuity are business concerns.
Free to Use Doesn’t Mean Free to Sustain
Open source licenses give people important freedoms. Depending on the license, those freedoms may include the ability to use, study, modify, and redistribute the software.
They don’t promise that another person will maintain the software forever.
This is where expectations can become badly misaligned. A company adopts a project because it’s capable, flexible, and free to use. Over time, it becomes critical. The company expects timely security responses, compatibility, documentation, roadmaps, and help when something goes wrong.
Those expectations are understandable. They’re also work.
The license may not require the company to fund that work. Sustainability asks a different question: what behavior gives the company the reliable dependency it wants to keep having?
Companies Need More Than Code
Most businesses don’t actually want a pile of source code.
They want confidence.
They want to know whether a project is maintained. They want a clear way to report a security problem. They want to understand the direction of the project before a change surprises them. They may need support, migration guidance, compatibility information, or someone accountable for helping when the software fails.
This creates several kinds of value an open source project or its surrounding ecosystem can provide:
Support
Companies will pay for access to people who understand the software deeply and can help resolve important problems.
This can come from a commercial company, a foundation, a maintainer collective, or independent experts. The exact structure matters less than whether the support is reliable and the people providing it are connected to the project.
Risk Reduction
Funding maintenance, security work, testing, release engineering, and documentation reduces the risk attached to a critical dependency.
This is often easier to justify internally than a general donation. Companies already spend money reducing operational and supply-chain risk. Open source shouldn’t become invisible merely because there wasn’t a traditional vendor invoice.
Participation
Companies need a practical way to understand what’s changing and provide useful input.
Telling them “anyone can participate” is technically true and often practically useless. Meaningful participation may require learning unfamiliar tools, attending meetings in another time zone, following several discussion channels, and understanding years of project history.
A funded liaison, regular briefing, advisory group, or clearly documented feedback process can lower that barrier without selling control of the project.
Accountability
Businesses often need to know who will respond when something goes wrong.
Open source communities are right to resist the idea that volunteers owe every user an enterprise service-level agreement. If a company needs guaranteed response times or contractual accountability, it should pay an organization prepared to provide them.
The answer isn’t to pressure maintainers into behaving like an unpaid vendor. It’s to build a commercial layer where commercial guarantees are actually possible.
WordPress Is a Useful Example
WordPress is the ecosystem I know best, and it’s a useful example precisely because the support doesn’t come from one company in one way.
Automattic has put enormous time and money into the project for years. So have companies like 10up, XWP, Bluehost, Yoast, and rtCamp, to different degrees and at different times. Some of that support shows up as sponsored contributors. Some shows up as core committers. Some shows up in release work, testing, documentation, accessibility, performance, hosting knowledge, community work, and the unglamorous maintenance that keeps a project usable.
The 2023 Year in Core post makes the point in numbers. It counted 1,079 people contributing to WordPress Core through Trac, including 472 first-time contributors. It also matched contributors to at least 286 companies. Automattic, Yoast, 10up, Bluehost, and XWP all appeared among companies with more than 100 contributions that year, and rtCamp appeared among the small group of companies with at least 10 people credited on Trac.
Those numbers shouldn’t be treated as a perfect scoreboard. The post itself is careful to say the data covers code contributions to the WordPress codebase on Trac, not every kind of contribution across the project. It doesn’t capture all of the community work, events, documentation, support, training, project management, plugin ecosystem work, or the many ways people help that don’t land as a commit.
Still, the pattern matters.
In the 2022 Year in Core data, Yoast, Automattic, 10up, Bluehost, and other companies were again visible in the contribution numbers. In the 2021 Year in Core data, Automattic, Yoast, and Bluehost were prominent, and 10up appeared among the few companies with more than ten people credited on Trac.
The specific numbers move around. That’s normal. Company strategy changes. Product priorities change. People move. Release cycles emphasize different areas of the codebase. A healthy ecosystem shouldn’t require every company to contribute the same way every year.
What matters is that commercial participation can be made visible enough to recognize, discuss, and improve.
WordPress has plenty of tensions around contribution. Every large open source project does. But it also shows that companies can put real money, time, and people into a project because that project helps support their business.
That’s different from charity. It’s not only goodwill, and it shouldn’t need to be defended as a favor to the community. It’s a company helping sustain the infrastructure, ecosystem, and user trust that its own products and customers depend on.
That’s the kind of exchange open source needs more of.
Payment Can’t Buy Governance
Once money enters the conversation, another risk appears.
A company may reasonably expect value for its investment. That doesn’t mean it should be able to buy the project’s decisions.
If funding becomes pay-to-play governance, the project stops serving its wider community and begins serving its largest sponsors. Users lose trust, unpaid contributors lose influence, and the project becomes open source in license more than in practice.
Healthy support separates access from control.
A sponsor may receive support, briefings, risk reporting, implementation help, or a structured way to offer input. It shouldn’t receive an automatic veto over maintainers or users.
This is one reason clear governance matters. Companies need to know what their money does and doesn’t buy. Maintainers need boundaries they can point to. Contributors and users need confidence that participation still matters.
Projects Have Work to Do Too
It’s easy for an open source project to say that companies should contribute more. It’s harder to make contribution practical.
Projects asking for sustained support should be able to explain:
- What work needs funding
- Who will do it
- How priorities are chosen
- How progress will be communicated
- What supporters receive
- What supporters don’t control
- How the investment benefits the wider project
This doesn’t require turning every project into a company. It does require treating sustainability as a product and governance problem rather than waiting for someone to feel generous.
The project has to make the value legible.
That may feel uncomfortable. Many maintainers started by solving a problem, not by building a funding model. But if the project wants sustained support from organizations, someone has to explain the exchange clearly enough that a product leader, security leader, procurement team, or executive can justify it.
The alternative is hoping the right person inside the company cares enough and has enough influence to push support through manually. Sometimes that works. It doesn’t scale.
Companies Have Work to Do Too
Companies should know which open source projects their products and operations depend on.
That sounds basic, but many organizations can’t answer it confidently. They know the direct dependencies in a particular application but not the transitive dependencies, build tools, libraries, infrastructure components, and community services underneath them.
Once those dependencies are visible, the company can assess:
- How critical is this project to us?
- How concentrated is its maintenance?
- What would happen if releases or security work stopped?
- Are we creating support burden without contributing useful reports or fixes?
- Can we fund the project directly?
- Should we buy support from a company employing maintainers?
- Can employees contribute during paid time?
- Can we help with documentation, testing, infrastructure, or governance instead of only code?
Money is important. It’s not the only useful contribution.
The goal is a relationship where the project’s health is part of the company’s dependency strategy.
That relationship also needs humility from the company. Money doesn’t make a company the main character of a community. If the only contribution a company is willing to make is one that gives it special control, the project has every reason to be cautious.
Good support should make the project healthier for everyone who depends on it, not just more responsive to the loudest or richest user.
Build an Exchange That Can Last
Open source support motivated by generosity is worth appreciating. It just isn’t a durable foundation for critical infrastructure.
Companies need reliable software, reduced risk, useful participation, and accountability. Projects need money, time, maintenance, contributors, and governance that protects the community.
The opportunity is to build an honest exchange between those needs.
Companies should be able to explain why supporting a project is good for the business. Projects should be able to explain what support makes possible. Neither side should have to pretend that money is shameful or that a license creates an unlimited obligation to serve.
Open source is built on shared value.
Its support models should be too.