Here’s one solution to the problem of funding open source software I’m kicking around. It’s a good fit for smaller projects which aren’t ready for something like Fast Path/open-core.
The solution in brief: a developer withholds new performance improvements and non-critical bugfixes from the public, making these available to supporters only. Blue Oak License or similar is used. Supporters download the supporters-only version via a password-protected repository (easy for NPM, golang, PyPI, etc.). (Fixes are eventually “unlocked” for everyone after some time.)
When a supporter signs up and pays the monthly/yearly subscription fee to be a supporter, they agree not to redistribute the source code to non-subscribers.(Not unlike how Fast Path users agree not to redistribute the documents when they access them.)
Might this work? Is anyone already doing this?
There are two sources of inspiration here. First is Patreon/Substack as used by many podcasters/youtubers/writers addressing a large audience. These creatives produce a steady stream of new content and withhold ~5% of content for supporters, people paying at least 5 USD a month. What’s being sold is easy access to this new material.
The second inspiration is the practice of withholding “performance fixes” by hardware companies. Hardware manufactures frequently selectively disable functionality in otherwise perfectly good CPUs and GPUs. For example, certain CPUs which can be safely overclocked are configured such that they cannot be overclocked by consumers. Such CPUs are called “non-overclockable SKUs”. The company is doing this in order to do price discrimination and increase revenue. For example, hardware enthusiasts will have to pay for the overclockable version of the chip—many other users will not care. The strategy being described here is similar in spirit.
How does this improve on open core?
It’s a featherweight version of open core. There are two key benefits:
- The developer doesn’t need to prepare or sign any contracts. Open core typically does require preparing a license for each end user.
- The developer is relieved of the cognitive burden of deciding which features should go in the core project and which features should be licensed to paying users.
What if some jerk mirrors the supporters-only version?
I’m encouraged by the observation that this does not seem to be a big problem for podcasters/youtubers/writers using Patreon and Substack. I’m also encouraged that many Data APIs – services which sell access to a data stream of some kind – seem to do well even though they also potentially have this problem.
What are the limitations?
It clearly works better for a piece of software which is being actively developed. The value proposition is clearer when performance fixes arrive regularly.
What if the supporter wants to redistribute a modified version of the supporters-only version?
An additional tier would allow for this.
Having a special tier for this really does solve the problem, I think. After all, only the supporter has the API key to access updates at the private repository. Downstream users (of the supporter’s software) may have a copy of the supporters-only version but they will not get updates.
If this got out of hand, the supporter in question would be asked to sign a more formal (Fast Path-like) agreement, the cost of which would include the expected value of lost subscriptions.