Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Making Money From Open Source Software: The Problem

DZone's Guide to

Making Money From Open Source Software: The Problem

The problem is that it's just plain difficult to make a dollar from something that is supposed to be free.

Free Resource

RavenDB vs MongoDB: Which is Better? This White Paper compares the two leading NoSQL Document Databases on 9 features to find out which is the best solution for your next project.  

Open source is a funny business model: first, you give away the crown jewels, then you try to get some money back. I have been working on OSS projects for close to twenty years now. I have been making my living off of OSS projects for most of that time. It is a very interesting experience, because of a simple problem. After you gave away everything, what do you charge for? I wrote this post because of this article and this tweet. The article talks about the Open Core model and how it usually ends up. The tweet talks about the reaction of (some) people in the marketplace when they are faced with the unconscionable request to pay for software.

The root problem is that there are two very different forces at play here.

  1. Building software is expensive. And that is only the coding part*.
  2. There is a very strong expectation that software should be freely available.


* If you also need to do documentation, double that. If you need to do deployment (multi-platform, Docker, K8s, etc.), do that again. If you need to support multiple versions...you guessed it. There is also the website, graphics, GDPR compliance, and a dozen other things that you have to do if you want to go beyond some code on GitHub repository stage. There is so much more to a software project than just slinging code, and most of these things are not fun to do and take a whole lot of time. Which means that you have to pay people to do so.

When I say very strong expectations, I mean just that. To the point where if the code isn’t available, it is a huge barrier to entry. So in practice, you usually have to open source the project, or at least enough of it to satisfy people.

Reading the last statement again, it sounds very negative, but that isn’t meant to be the case. A major advantage of being Open Source project is that you get a lot of credibility from potential users. To start with, people go in and go through your code. They do strange things like talk to you about it, offer advice, patches and pull requests. They make the software better. They also take your software and do some really amazing things with it. For the past decade and a half, my default position has been that software I write is opened by default. I have yet to regret that decision.

An OSS project can typically get a lot more traction than a closed sourced one, these days. Which creates a lot of pressure to open source things. And that, in turn, leads us to a simple problem. How can you make money from OSS projects?

There are a few ways to do so:

  • Labor of love – In some cases, you have people who simply enjoy coding and sharing their work. The problem here is that eventually, you’ll run out of time to donate to the project and have to find some means to pay for it.

  • Donations – This is how people typically imagine OSS projects are paid for. I have tried that a few times in the past, and I don’t believe that I made enough money to go hit the movie theater midday.

  • Sponsorship (small) – Sometimes a project is important enough for a company that they are willing to pay for it. That means either hiring the major contributors or paying them in some manner. This is a great way to get paid while working on what you are passionate for, especially because you can usually complete all the taxes that a project requires (from a website to the documentation).

  • Sponsorship (large) – I’m thinking about something like Apache, Linux Foundation, etc. These typically reserved to stuff that is core infrastructure and trying to build something like that from scratch seems…hard.

  • Services/Consulting – I did that actively for several years. Going to customers, helping them integrate/customize various projects that I was involved in. It was a lot of fun, but also exhausting. It’s basically being a consultant, but you are focusing on a few projects. Here, OSS work is basically awesome for building your reputation and showing off your skills. You can build a business around that, but that requires having a large number of users and is subject to the usual constraints of consulting companies. The most limiting of which is that the company is a charging some percentage of the costs of employees, and the percentage can’t be too high (otherwise the employees will just do that directly).

The common thread among all the options above? None of them are viable options if you have VC money. The problem with all of these options is that (even in the case of something like the Linux Kernel), the ROI just isn’t worth it.

So what can you do, if you believe that your project should be OSS (for marketing, political reasons, or because of strongly held believfs) and you want a business model that can show significant returns?

  • Support – Offer the project itself for free, but charge for support. For certain industries and environments, that works great. But it does suffer from a problem: if you don’t have to buy support, why would you? In such cases, usually, there is a conflict of interest here. Making the software simpler and easier to use will cannibalize the support that the company relies on. Red Hat is a good example of that. Note that a large part of what Red Hat does is the grunge work. Backporting patches, ensuring compatibility, etc. The kind of things that needs to be done, but you won’t get people doing for fun. To my knowledge, however, there are very few, if any, examples of other companies that successfully monetize this approach.

  • Open Core – In this model, you offer the core pieces for all, but keep the features that matter most to the customers with the most money closed in some fashion. In a sense, this is basically what the Support model is doing, for customers who need support. GitLab, MySQL, Redis, and Neo4J are common examples of open core models. The idea is that for development and small fries (people who would typically not pay much/at all) will get you the customers that will pay for the high-end features. The idea here is to get people to purchase licenses, similar to how commercial software works.

  • N-versions back – A more aggressive example of the open core model is simply having two editions. An open source one and a commercial one. The major difference is that the open source one is delayed behind the commercial one. Couchbase, for example, is licensed under such a model.

  • Dual licensing with viral license – In this model, the idea is that the code is offered under a license which isn’t going to be acceptable for the target customers. Leading them to purchase the commercial edition. This model also mandates that the company is able to dual license the code, so any outside contributions require a copyright assignment to the company.

  • Cloud hosting – In this model, the software itself is offered under an OSS license, but the most common use case is to use the cloud offering (and thus pay for the software). WordPress is a good example of that. The idea is that while people can install your software on their own machines, paying the company to do that is the more cost-effective solution.

I’m sure that I have skipped many other options for making money out of OSS projects, but the ones I mentioned seems to be the most popular ones right now. I got a lot more to talk about this topic, so there will be most posts coming.

Get comfortable using NoSQL in a free, self-directed learning course provided by RavenDB. Learn to create fully-functional real-world programs on NoSQL Databases. Register today.

Topics:
open source ,open source business model ,profit ,open source project ,dev life ,open soure community ,licensing

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}