By Chen D. Ravid
Chen Ravid is a free software enthusiast and serial entrepreneur. He is one of the founding members and chief product officer at xs:code, a subscription based open source billing platform.
Making open source sustainable
The open source community has done something never before done in history. A massive knowledge base of useful tools that is freely available for anyone to use, duplicate, learn from and distribute. It’s hard to find anything similar in the course of human history. A group of individuals willingly performed work on such scale without any form of compensation.
Developers invest time, passion and talent to create incredible software that is used freely by everyone. But when companies use it for-profit, without any form of compensation for the developers, it’s not really sustainable or fair. With no compensation, how much longer will developers keep developing?
True, we all know companies built around open source projects, generating billions in revenue every year. However, that is the case for large scale projects such as Linux, WordPress, Redis and the likes, and these projects are not the focus of this article. The heart of the open source community are the millions of small-to-medium sized projects used on countless software products. Huge companies use these projects for-profit, but the hard working community of developers who created them is not compensated at all. This is market failure at it finest – and a huge one at that.
Most open source developers are not in it for the money. If you were to ask a developer why she is working so hard on her open source project, the response you are likely to get ranges from “I like working on it”, to “It makes me feel good others are enjoying my code” and ending with “It’s good for my resume”. Money is out of the equation. Taboo. He who must not be named.
It seems that what developers really want, is the ability to work on their projects on their own terms. They want the time, the resources and the freedom to make their software better. No one is looking to get rich, and you are not likely to find an open source developer at a Ferrari dealership.
Monetization is not a goal. It’s a means to an end. The goal is the freedom to build better software.
Compensation = motivation
If you are using open source code in your commercial projects, wouldn’t you be happy to know the code you use is well maintained, kept up to date and constantly being improved? It’s a matter of allocating resources. Developers’ time is precious. Most companies prefer to spend that time on mission specific tasks, not on tasks that are ubiquitous and widely used on many other software products. Open source projects fill that gap, for exactly $0.
It is likely that a clear path of monetization will make a developer more motivated to keep her users happy and paying, as a part of her continuous effort to make her code better – for everyone. Wouldn’t you pay $5 for well maintained piece of code that would save dozens of man hours? How about $10? $100?
“Umm… I’ll donate tomorrow, thanks”
Excluding huge companies with complex monetization processes in place, the average open source developer has only a handful of monetization options to choose from. The most popular choice is asking for donations from whomever is using the code. While this is a noble notion, it has its pitfalls. First of all, donations are, of course, not mandatory. This means developers put their revenue at the mercy of their users, who will mostly opt to not donate. Moreover, even if someone has decided to donate, they have no obligation (or incentive) to keep donating in the future. How many of us have elegantly ignored Jimmy Wales’ plea for donating to Wikipedia, a tool we all use extensively? You get the point.
Subscription based open source
Subscription based open source provides a simple and easy to implement solution to the compensation problem. It allows developers to offer subscription based, paid access to a separate version of their code, otherwise unavailable anywhere else, while keeping another, free version, available for everyone.
The developer is free to choose how the paid and free versions differ. There are several ways go about this:
Dual licensing means the developer keeps the exact same code for free on Github and behind a paywall on xs:code. The only difference is in licensing. For example, a GPLv3 (A highly restrictive, copyleft license) version is publicly available on Github, and an MIT (a highly permissive license) version is available via a subscription on xs:code. This means the code is still freely accessible by the community to use and contribute to, but companies that need an MIT license, need to buy a subscription.
With this model, a “lite” version is kept on for free on Github, and a subscription based “premium” version is offered for a on xs:code. If a user wants to access the unique features available on the “premium” version, they will have to pay for a subscription. The flexibility of this model gives developers a lot of freedom in determining what exactly is available on the free and paid versions.
Dual licensing freemium
This approach mixes the two mentioned above. A free “lite” version is kept on Github , along with a GPL licensed “premium” version – both are free. Another premium version with an MIT license is offered via a subscription on xs:code, which guarantee that users who need an MIT license for the premium version, need to buy a subscription. This way guarantees all the code remains open source, even for developers who prefer to have a “lite” and “premium” versions.
If you want to learn more about how these models work, check out our use cases page.
While there will always be pirates, I believe that some, if not most, companies will opt to pay in order to access the version with the license they need. Honestly, it’s just too much work to steal. Especially if you have dozens of open source projects to manage and the code you need is only $5 a month. It gives you access to constant updates, bug fixes and improvements. Developer time is worth more, and it would be plain insanity to assign a $50/hour developer to steal $5/month code.
1:1 or 1:n
Subscription based open source, makes a fundamental change in the value of open source developers’ time.
Developers, in their day-job capacity, are usually compensated on an hourly basis. This means they work at a 1:1 ratio – 1 hour’s work equals 1 hour’s pay. With subscription based compensation, developers become compensated at a 1:n ratio. 1 hour of work can be worth n subscriptions that accumulate and pay every month.
A 1:n ratio means a developer can quickly achieve compensation that is larger than what she can possibly make hourly or monthly. Some developers have repositories with 10K downloads per month. Others have 1 million. Some have more. Multiply that with those $5 and all of a sudden developers can afford better hosting servers. They can hire more developers to help them. They can quit their day jobs. Heck, with 1 million monthly downloads, that idea of a developer at a Ferrari dealership becomes a reality. If you’re into that kind of thing.
Fear of commitment
Once a relationship is established between developers and paying users, the questions pop up. “If I get paid, do I have to stay committed”? Well, the answer is quite simple. “No”. Other than the will to have users keep paying, the developer is not under any legal or contractual obligation to accommodate requests.
Borrowing from the laws of a free market, we can assume that once a developer has motivation to keep selling, she will be more inclined to accommodate a user’s request. And if not? It’s a free market, and other developers might offer a similar repository with better support. Let the market forces do their work, and you’ll see that competition will keep things in check.
Change is hard. Companies might not like the fact they need to start paying for something that was free. Free software enthusiasts might not like that permissive licenses are given to proprietary software companies.
But the fact is that with subscription based open source, everybody wins. Developers are compensated fairly for their work and can focus on writing great code. Companies get access to better code, created by motivated developers, working harder to improve their projects. The community gets access to more, ever improving code for learning, non-commercial use, or just for fun.
A change in the way open source is developed and distributed is long over due. The time for change is now.
I know it seems I left contributors out of the equation. I haven’t. Another post about the economics of contributions is coming soon.