For-Profit Companies Should Pay the People Who Build OSS

Note: This article is my personal opinion and does not represent my employer. My company's blog is currently being prepared, and at the moment there was no appropriate place to publish this. Also, because the article is based on my personal concerns, I am publishing it on my personal blog. This is not meant to blame any specific company or individual. It is about whether for-profit companies that use OSS should create more financial flow toward its authors, maintainers, and core contributors.

Introduction

The lack of compensation for OSS authors, maintainers, and core contributors becomes a topic again and again. A maintainer of a library is exhausted; an important package is sustained by a very small number of people; companies around the world depend on it, yet the person behind it does not have a stable life because of that work. Whenever such stories appear, the internet becomes uneasy for a moment.

Of course, OSS is not a simple employment contract. Publishing code does not automatically mean that the author has a right to receive payment from every user, and I am not saying that every user should be forced to pay something.

However, for-profit companies are in a slightly different position. We use OSS, build products with it, improve development speed, quality, and operations through it, and create revenue on top of it. Part of that revenue eventually comes back to us as salary or profit.

If that is the case, it seems natural that companies that generate revenue by using OSS should return money to its authors, maintainers, and core contributors.

This Is Especially True In Web Frontend

I usually work around web frontend, so I inevitably see this issue through that context.

In modern web frontend development, OSS is not merely a collection of convenient tools. It is part of the premise of daily development and operations. When we prepare a development environment, maintain quality, or deliver a product, we touch OSS in many parts of the process, combine those pieces, adapt them to our own circumstances, and use them as part of our development foundation.

Of course, we also write our own code. There is design, operation, and product understanding, and I do not want to dismiss any of that. Still, much of the foundation is supported by people outside our companies. Many of them create, fix, and release things with their own time, without any direct employment or contractual relationship with us.

OSS can look like an abstract public good, but in reality, behind it there are authors, maintainers, and core contributors who review, decide direction, and fix what breaks. When we talk about who should be paid, I want to bring those people further into the foreground.

In this situation, treating corporate payment to the people who build OSS as a special act of charity feels a little unnatural. It is closer to an ordinary cost. We pay for servers, SaaS, design tools, hiring channels, and event sponsorships.

Then we should also pay the people who build the OSS we depend on.

Event Support Is More Common Than Support For Builders

In Japanese tech communities, I often see event sponsorships, and I think this is important. They pay for venues and streaming, improve the experience for speakers and attendees, create contact points between companies and communities, and support the culture in a significant way.

At the same time, compared with the number of companies whose logos appear at events, sponsorships for OSS authors, maintainers, and core contributors still feel relatively rare.

Events are visible. Logos appear, booths appear at venues, they can connect to hiring and branding, and they are easier to explain internally. By contrast, the work of OSS builders is hard to see: reading issues, writing reproduction cases, avoiding breaking changes, updating dependencies, fixing vulnerabilities, writing release notes, and absorbing subtle frustration from users.

This work is not flashy, and it is hard to observe from the outside. But if this steady work stops, our own work may suddenly stop as well.

I am not saying event sponsorships are unnecessary. I want them to continue. What I want to say is that if support tends to concentrate on events, more of it should also go toward the people who create and maintain OSS.

Maintainers Are Not Only People Inside Large Companies

Companies such as Meta, Vercel, and Cloudflare have people who work on OSS as part of their jobs. That is a wonderful thing, and it is meaningful for companies to place OSS at the center of their strategy, employ people, and move development forward.

But OSS is not sustained only by that model.

There are many maintainers who do not belong to large companies. Some work as individuals; some work at small companies and maintain projects at night or on weekends; some end up carrying major responsibility for users around the world, even though the project is not their company's product.

In fact, some OSS that I use in my daily work is created or maintained by developers who do not belong to large companies.

When we think about OSS, we tend to imagine the names of famous companies. But deep inside our dependency graphs, there are individuals whose names and faces we may not know. They are not necessarily employed by large companies, not necessarily fixing things during company time, and not necessarily living with financial room.

Even so, we use what they build to create revenue. We should look more directly at this asymmetry.

Individual Sponsorship Matters, But It Is Not Enough

I receive support from around twenty individual sponsors through GitHub Sponsors, and I am grateful for it.

It is a major source of support. It encourages me emotionally, gives me a real sense that people are watching my work, and also gives me a little more financial room.

So I do not think individual sponsorship is meaningless at all. It has a lot of meaning, and the culture of individuals supporting individuals in small amounts should spread further.

However, as a practical matter, it is difficult to live only on small individual sponsorships.

Hundreds or thousands of yen adding up is valuable. But when we consider living costs, taxes, insurance, rent, equipment, and the time needed to keep working, that alone is not enough to sustain ongoing OSS maintenance or core development participation.

This is where companies need to participate.

There are amounts that individuals cannot easily pay, but that are relatively small budgets for companies. An amount of tens of thousands of yen, which is large for an individual, can be close to one business dinner, one SaaS tool, or one hiring initiative for a company. That gap matters, and I think we should use it.

Large Recurring Sponsorship Has Risks

This point matters.

Unless a company is truly prepared for it, a single company should not provide large recurring monthly support to one author, maintainer, or core contributor.

At first glance, large recurring support looks desirable. Of course, stable funding itself is good, and it helps the person receiving it.

But if that support becomes too central to their life, the damage is large when it stops.

The company's policy may change, the person in charge may move to another role, the economy may get worse, the budget may be cut, or the company may stop using that OSS. These things can happen on the company side, but for the person receiving support, they can disrupt life and activity plans.

That is why I think corporate OSS support should be made of many thinner pillars, rather than one concentrated pillar.

One-time sponsorships should happen in a distributed way from many companies. One company supports once, then another company supports next. Once a year is fine, once a quarter is fine, and it can happen when a project releases something or when the company was helped significantly by the project.

Do not turn it into one company's beautiful story, and do not make one builder depend on one company. Support them broadly and lightly across many companies, but in amounts larger than typical individual sponsorships.

I think this shape is healthier for the economics of OSS.

Companies Can Support In One-Off Ways

When people hear that companies should pay the people who build OSS, they may imagine large programs or ongoing contracts.

But it does not have to start as an impressive program. A company can pay a library it often uses this month, a tool that helped with a major migration, a maintainer who responded carefully to an issue, a core contributor who supports important design decisions, an individual deep inside its dependency chain, or a project when a release happens.

That kind of one-time support is enough.

Even if the amount is small for a company, it can be significant for the individual receiving it. For example, support around 50,000, 100,000, or 150,000 JPY may not be excessive as a corporate budget, but for an individual author, maintainer, or core contributor, it can mean a lot.

And if that money does not come continuously from one company, but instead arrives irregularly from multiple companies, the dependency becomes softer.

Of course, accounting may be complicated, and there may be approval processes. There are many questions: whether the recipient uses GitHub Sponsors or Open Collective, whether an invoice is needed, whether it fits internal rules.

Even so, companies should work on it.

We depend on OSS too much to let procedural complexity be the reason we do nothing.

What I Brought Up At My Company

Here I want to talk a little about my employer. I usually work as Chief Engineer at Mates, Inc., a for-profit company.

Naturally, we use a lot of OSS at work. In web frontend, backend, and development infrastructure, OSS exists everywhere. Products are built on top of that, revenue is created, and some of it is paid to me as salary.

When I think about that structure, I personally feel strongly that companies should pay the people who build OSS.

However, this article does not represent the company, and it is not the company's official position. I want to separate that clearly.

With that in mind, I brought this topic up internally, because I thought that the person making the proposal should move first.

"Since we are supported by OSS, could the company also sponsor its authors, maintainers, and core contributors in one-off ways from time to time?"

That is the rough summary of what I asked, and thankfully, people inside the company agreed with it.

I do not want to frame this as an overly beautiful story. The company has not created a huge fund, and a world-changing program is not starting today. The amount will probably be small from a company perspective.

Still, I think there is meaning in starting.

Start from the place where I am, and then, if possible, involve other companies as well. Do not make it one company's admirable initiative. Make it something many companies naturally do.

That is the direction I hope we move toward.

This Is Payment More Than Charity

OSS support easily creates the impression that a company is "doing something good." It can become a story where the sponsoring company is admirable and the supporter is kind.

Of course, there is some truth to that. Supporting people is good.

But for companies, I think we can understand it more calmly.

Pay the people who build what we use, the people who maintain what contributes to our profit, and the people who support our development speed.

This is less charity than ordinary payment.

We might even say that the unnatural state was the one where we had not been paying enough.

Being able to use something for free does not mean that maintaining it costs nothing. Being able to use something for free under its license does not mean it is economically right to keep free-riding forever.

OSS is often free to use, and that is exactly why those who can pay should voluntarily pay.

Especially companies that generate revenue by using OSS.

Conclusion

For-profit companies should pay the people who build OSS.

This is not a phrase meant to attack companies. It is a phrase for looking more accurately at the foundation of our own work.

We use OSS, and OSS gives us development speed, quality, and revenue.

Then part of that should go back to OSS authors, maintainers, and core contributors.

Event sponsorships should continue, individual sponsorships should spread, and the movement of large companies employing OSS developers should continue.

On top of that, I want more for-profit companies to pay the authors, maintainers, and core contributors of the OSS they depend on, in one-off and distributed ways, with amounts a little larger than typical individual sponsorships.

Instead of one company standing too far in front, many companies should naturally pay. Instead of tying one builder to one company, many companies should support them together. Instead of treating it as decoration for hiring or branding, treat it as part of development cost.

I hope the economics of OSS move even a little in this direction.

And I want to help create that flow from the place where I am.