If you have released a library to the world you may know: it is a ton of work. Some of us are motivated simply by the pure desire to build software and see our fellow humans using it. But we also all have bills, and a finite amount of time and energy. Often these desires come into conflict, but I think we can all agree that the ideal scenario is that software authors get paid for the value that they create.
We currently have a few options at our disposal to fund our open source work.
One option is to get hired by a company to work on it. This is a form of sponsorship, and often this is viewed as part of the marketing budget for the company. The company benefits from added exposure, perhaps you go talk at conferences or write blog posts, and you benefit from a steady salary. This generally works out pretty well, but it's only accessible to the real stars of open source development.
Next we have the donation model (buy me a coffee!). There are a dozen websites (including GitHub itself) where you can ask for donations to fund continuing work. In general I believe this model has failed and is not a serious contender.
We also have the consulting model. You have built a nice package, and now you have some name-recognition in the community. Perhaps you can use this to sell other services! A common one is to sell consulting services, either general consulting _(I will help build whatever you are working on)_ and specific consulting _(I will help you integrate the package I wrote into your platform)_. This works, but it doesn't leave you with a lot of time to work on your project, and your compensation is tied directly to the amount of work (not the value) that you deliver to your customers.
Finally, we have volunteering, also known as working for free. I think a large amount of open source work falls under this category. There is nothing wrong with this! But it doesn't work for every project. Your interest in the project may wane, and when that happens, your project will likely suffer.
What happens when this is not working? Sometimes the result is that someone else takes over the project. Sometimes, the project (even high profile ones, like autoconf) ends up abandoned. Occasionally someone takes over a package and adds code to steal your user's crypto wallets.
These are undesirable scenarios. Now, in the best case, you are deriving no benefit from your hard work, and it may be that your users are also now unable to derive any benefit from it either. In the worst case scenario, your users might be actively harmed. If we can broaden the options available to software authors to fund their work, we can potentially avoid some of these undesirable scenarios.
Many packages will continue to be best served by an open-source approach, relying on one of the funding methods mentioned above. But I think there are also many who will benefit from a closed or a hybrid approach.
Most of all, I want to help software developers change their compensation from being a function of the number of hours worked, to a function of the value that they create.
Some existing models include:
Dual License - where we pick a restrictive, usually copyleft license for the free version (AGPL for example), and also release our package under a commercial license, in exchange for payment.
Open Core - where we release two packages. One contains the core functionality of the product, and is free. The other contains additional functionality, which we sell exclusively under a commercial license.
There are other models that have been popular in other sectors of the internet. Patreon and SubStack are good examples here. Both platforms allow their customers to build their audiences with a free tier, while offering them exclusive benefits for subscribing.
This can also work in the software world - offer some versions of your package for free, and require payment for the latest versions.
It's not all bad news for businesses that are relying on open source software. Most of the infrastructure (languages, web servers, DB adapters, and much more) is being successfully funded by one of the above established methods, and will continue to be funded that way. But there is a lot of software out there that could be of a higher quality, if someone (or multiple people) was being compensated for the value it delivers.
For example, in the Elixir ecosystem the Oban project has adopted the Open Core pattern. It solves a problem that we all have, at a much lower cost (on the order of $100 a month) than it would otherwise cost businesses to build themselves. For context, $100 is approximately equal to the cost of a single man hour of work, which means that paying for Oban Pro is not only a win for most companies - it is a slam dunk.
Take a look at your own project, and ask yourself:
How many open issues / pull requests do you have?
How many hours do you spend in a month on maintenance and responding to questions?
Would companies, who are using your project, benefit from your increased attention to it?
Would you benefit from a changing relationship with your users (aka customers)?
If you answered yes to one of these questions, then consider giving Code Code Ship a try.
Start releasing new versions into the paid tier. Add a free version policy (eg: "paid versions become free after 9 months; always 2 paid versions") Advertise this to some of your existing users and see how they respond. Give it some time, not everyone is auditing their dependencies every day.
Code Code Ship integrates deeply with your package manager of choice (at time of writing: Elixir, Ruby, JavaScript, and the DotNet family), and offers tools to help you sell your package, whether you want to do a dual license, open core, something with a free tier, or just a straight up paid package.
Here is a link to a project of mine, which I have uploaded to Code Code Ship for illustration purposes.
I have also uploaded a video to YouTube, embedded below, which you can watch to get an better idea of how Code Code Ship works.
Thanks to Will Rogers for proofreading and suggesting improvements to this post.
