Everyone in the tech world appreciates open-source projects, yet few are willing to pay for them. While initial enthusiasm helps sustain a project, over time, creators of popular projects risk burnout or discontinuing support. Recently, two creative approaches have emerged for maintainers to generate revenue for open-source projects that are widely used in the commercial sector.
The first is the so-called open-source maintenance fee. An example is the Wix Toolset, a suite of tools designed for creating Windows installers. As with most open-source projects, long-term financial sustainability was uncertain: who would pay key maintainers for time spent on the project instead of their paid work or other activities? A project like Wix requires constant updates to support new Windows versions, address security and other issues, and review pull requests.
The Wix Toolset team decided to introduce a relatively new concept of a maintenance fee. It works as follows: the code is freely available under an open-source license, but support and binary versions are paid. This means that opening issues, commenting, participating in releases, or submitting pull requests requires paying a fee. Similarly, downloading any pre-compiled binary version of the project is subject to a fee, although the code can, of course, be compiled manually.
Simply put, if an individual or company uses Wix Toolset as part of their income-generating activities and wants to ask questions, submit changes, or download pre-compiled binaries, it is necessary to become a sponsor and pay a monthly fee. Fees are tiered: $10/month for companies with up to 20 employees, $40/month for companies with 20–100 employees, and $60/month for companies with over 100 employees.
The fee seems to be working: the project currently has dozens of sponsors, including large technology companies. This can generate significant monthly revenue, which can be used to cover costs, such as compensating key contributors. As one of the creators, Rob Menshing, explained, the fee is intended for those who perform maintenance, especially the “boring but important tasks” that no one else wants to do. This model removes the burden from creators and incentivizes commercial users to pay for their time.
The idea of the fee arose after the XZ Utils vulnerability incident, which highlighted the fragility of open-source project sustainability and the vulnerability of creators. Many agreed that something needed to change, but no change occurred. This cognitive dissonance led to the creation of the new model. For many open-source project creators, it is frustrating when users demand a lot but offer nothing in return. In the past, similar situations led to burnout in other projects when creators were unprepared for the unexpected maintenance burden that comes with releasing open-source code.
While the easy option of opening issues and submitting pull requests on popular code management platforms facilitates collaboration, it also increases the workload for creators, who must deal with a large number of often low-quality requests. The maintenance fee can reduce this “noise” and generate income for the time creators invest. For those unwilling to pay, the option to fork the project and maintain it at their own expense is still available, which may prove to be a more expensive option than paying a monthly fee.

Planen Sie eine neue Website oder App?
Schreiben Sie mir, was Sie vorhaben — ich schaue es mir gerne an und berate Sie zum besten Vorgehen.
The existence of a fee may raise questions about the principles of “free” software (FOSS). However, “freedom” in FOSS does not refer to price, but rather to the freedom to use the program, study it, modify it, redistribute it, and distribute modified versions. FOSS does not mean that someone works for free when addressing issues and change requests. The creators of Wix Toolset carefully collaborated with lawyers to ensure full compliance of this fee with FOSS principles, because “open-source software does not mean everything is available at no cost.”
The second innovative approach is the enterprise-oriented features model. An example is the Python package manager uv, written in Rust, which is significantly faster than its predecessors. The uv tool, developed by the startup Astral, is offered for free. Astral, which secured significant initial funding, needed to find a way to generate revenue, and it succeeded by creating a private package registry called pyx. This offers advanced features for enterprises, such as improved security and GPU support, and is already registering its first customers.
This approach, where the basic tool is available for free to individual developers and advanced features are paid for by corporate clients, is very clever. If Astral succeeds with the pyx platform, it can continue to offer excellent free tools while generating revenue from paid enterprise versions. Sustainable open-source projects, where creators have a reasonable workload, keep up with comments, and release new versions as needed, are much more beneficial to the entire technology ecosystem than projects that do not implement such barriers and lead creators to burnout and cessation of activity.
