オープンソースプロジェクトの資金調達の創造的な方法

Every engineer and tech company likes open source projects, but few are willing to pay for them. This is fine for a while – enthusiasm to support a project does go a long way – but after some time, maintainers of popular projects could burn out or just stop supporting the project. Recently, I came across two creative approaches of maintainers generating revenue for open source projects that also see significant commercial usage.

Open source maintenance fee: an interesting experiment

Wix Toolset is a set of open source tools for creating Windows installers. As with most open source projects, the long-term financial sustainability of the project was uncertain: who would pay for core maintainers to spend time on this project, rather than on their work or other side projects? A project like Wix needs to be continuously updated to support new versions of Windows, and security and other issues must be responded to by maintainers, who also review pull requests.

The team decided to adopt a relatively new concept called the Open Source Maintenance Fee. How it works:

The code is freely available under an open source license

Support: paid. Opening issues or commenting on them, or participating in releases or pull requests requires paying the fee

Binary releases: paid. To download any binary release of the project, one needs to pay the fee. But the binary can be compiled from the code - one just has to build it themselves.

Basically, if an individual or business uses Wix Toolset as part of its revenue-generating activity, and someone from that company wants to ask questions or submit changes, or download a pre-built binary, then it’s necessary to become a sponsor and pay:

$10/month when working at a company up to 20 people

$40/month for companies of 20-100 employees

$60/month for companies with 100+ employees

So far, the fee seems to be working: The project currently has 64 sponsors, including Microsoft (which needs to pay the $60/month fee). This could be generating anything from $640/month up to a few thousand dollars per month, which can be used to cover costs, such as compensating core contributors. As maintainer Rob Menshing elaborated:

“The maintenance fee is intended to go to those doing maintenance. In my project, there are two of us working to keep the project running. We have contributors who do stuff they find interesting, but none of them do ‘boring but important stuff’.

So far, it is working.”

What I like about this structure is that it removes the burden on maintainers who invest their time, and turns it into an incentive for commercial users to pay for their time.

The idea of the fee came after observing the XZ Utils supply chain attack incident. As Rob shared on the backstory of the Open Source Maintenance Fee:

“I touched on it in the video but I felt compelled to do something about the sustainability problems facing Open Source Maintainers. My personal frustration dealing with entitled consumers for the last few years—and watching other maintainers go through the same thing—hit a breaking point with the XZ Utils incident.

Two things happened in that incident. First, we saw a maintainer—who was vulnerable due to the lack of project sustainability—manipulated by attackers to sneak a backdoor into Linux… and then nothing changed. Second, in my viral tweet-thread everyone agreed that something should be done. I’ve never seen that many people on the internet agree about anything.

The cognitive dissonance that something should be done but nothing was done, fundamentally bothered me. I couldn’t stop thinking about the problem. It wasn’t until early July that the Maintenance Fee idea really started to come together.”

And you know what - I agree! As an OSS maintainer, it can feel that users are entitled: demanding a lot, but offering nothing in return. More than a decade ago, I also burnt out maintaining a Windows Phone library called AdRotator that helped users generate revenue for their apps. I released my library thinking it will help others make more money, and everyone will sort out their own issues. I was not expected to see demands coming from users that I implement new features, or fix issued they are seeing. Back then, I was relieved to hand over maintenance to a fellow contributor who had far more energy to support users with questions and feature requests.

I naively assumed open source was about offering the source as open, and everyone taking it, and sorting out their issues by themselves. I was not prepared that by releasing something as open source, I’d get a bunch of maintenance burden to have to deal with — something I never signed up for or asked for.

I wonder if GitHub’s popularity means more projects will implement a similar fee. GitHub has become the de facto place for open source projects to live: its simple, intuitive UI makes it very easy to open an issue and raise a pull request.

However, open source maintainers of more popular projects face a steady stream of often low-quality issues raised, and pull requests which aren’t ready to be merged. Meanwhile, users expect responses and can get frustrated when issues are not quickly resolved.

For open source projects with significant commercial usage, an open source maintenance fee could be a viable way to reduce this kind of noise, and generate some revenue for the time maintainers spend on them. For example, the Wix Toolset project currently has 775 open issues (!) and another 6,500 closed ones. Just keeping on top of the issues raised looks like a lot of work!

For projects that do not use GitHub, the barrier to entry for creating issues and pull requests is a lot higher. For example, Linux still runs on email mailing lists, and patches need to be sent via email. To contribute to Linux, a lot of upfront work is necessary first. We cover more about contributing to Linux in the episode of the Pragmatic Engineer Podcast, How Linux is built with Greg Kroah-Hartman.

A fee like this could help keep open source projects as free and open source software (FOSS). Someone might argue that the existence of a fee goes against the concept of “free”. However, the “free” in FOSS stands for the freedom to:

Run the program as you wish for any purpose (you can do this!)

Study how the program works and modify it as you wish (you can do this; just get the code and change it, or fork it!)

Redistribute copies to help others (you can do this)

Distribute copies of modified versions (again, you can do this)

FOSS shouldn’t mean that someone works for free in replying to issues and responding to change requests. In the case of Wix Toolset, maintainer Rob Menshing worked hard with lawyers to ensure that this Open Source Maintainer Fee is fully compliant with FOSS principles and expectations. As Rob put it:

“OSS does not mean that everything is available for no cost.”

The more open source projects on GitHub are sustainable, the better it will be for the tech ecosystem. An open source project that is sustainable long-term – with maintainers having a reasonable workload, keeping up with comments, and releasing new versions when needed – is a lot better than one that puts up no such barriers and leads maintainers to throw in the towel and quit.

Don’t forget, any company or individual who does not want to pay this fee but does want to make modifications to the code can go ahead and do it! They just need to create their fork and then can go ahead with the modification. The cost of keeping this fork up-to-date with the project then becomes theirs to pay and it could be more expensive than the $10-60/month fee asked for by the project.

When introducing the fee, the Wix Toolset project had a long discussion; read the thread for more details of the thinking behind this move.

Enterprise-only features: how uv’s creator plans to make money

In the Python world, the uv package manager is surging in popularity: it is ultra-fast and 10-100x speedier than the formerly popular package manager, pip. Part of this speed is thanks to uv being written from scratch, in Rust, for performance. It does lots of clever things like parallel downloading and installing of packages, and maintaining an optimized module cache. uv is so useful that an AI startup told me that moving over to this package manager improved productivity more than any AI tool they trialed. From Software engineering with LLMs in 2025, reality check:

“An interesting detail emerged when I asked how they would compare the impact of AI tools to other innovations in the field. This engineer said that for their domain, the impact of the uv project manager and ruff linter has been greater than AI tools, since uv made their development experience visibly faster!

imageuv is a lot faster than other package managers. Source: uvuv is built by a startup called Astral that has raised $4M in seed funding in 2023. With VC funding, Astral has to generate revenue, but how to do this with a free open source package manager?

We now have an answer:

Astral created a private package registry called pyx, a paid-enterprise focused package registry. It’s like uv, but with additional features for security and GPU support. Astral has signed up companies like Ramp and Intercom as customers already.

This approach of charging for enterprise features is clever and great news for the open source community: if Astral can get traction for pyx, they could have a business offering standout tools for free to individual developers, and also more advanced paid versions with enterprise features for companies. We have covered the pressure on commercial open source companies to make money, so fingers crossed that Astral succeeds!

This was an excerpt from The Pulse #143. The full issue additionally covers:

Industry pulse. Microsoft’s US compensation bands revealed, a reader gets in touch about Forward Deployed Engineers, why OpenAI has released an open model, Canva trials AI coding tools for interviews, and more.

Tailwind CSS team burnt by LLM’s inconsistent code generation. A project estimated to take 6 weeks without AI, took 12 weeks with Claude Code.

Meta and OpenAI in talent & compensation war. 15 years after aggressively poaching engineers from Google, Meta is doing the same to OpenAI, which is responding with six and seven-figure retainer bonuses.

What people think improves AI applications vs what actually does. Instead of keeping up with the latest AI headlines, why not talk to users? Author Chip Huyen has practical tips for AI engineers.

Read the full issue here