Making money from Open Source SoftwareHow we do it?
After my previous two posts on the topic, it is now time to discuss how we make money from Open Source Software. Before I start, I want to clarify what I’m talking about:
- RavenDB is a document database.
- It is about a decade old.
- The server is released under the AGPL / commercial license.
- We offer free community / developer licenses without any AGPL hindrance.
- The RavenDB client APIs are licensed under the MIT license.
- RavenDB (the product) is created by Hibernating Rhinos (the company).
I created RavenDB because I couldn’t not to. It was an idea that had to go out of my head. I looked up the details, and toward the end of 2008 I started to work on it as a side project. At the time I was involved in five or six active open source projects, just got my NHibernate Profiler product to a stable ground and was turning the idea of getting deeper into databases in my head for a while. So I sat down and wrote some code.
I was just doing some code doodling and it turned into deep design discussion and at some point I was actually starting to actively look for hep building the user interface for a “done” project. That was in late Feb 2010. Somehow, throwing some code at the compiler become over a journey that lasted over a year in which I worked 16+ hours days on this project.
Around Mar 2010 I knew that I had a problem. Continuing as I did before, just writing a lot of code and trying to create an OSS project out of it would eat up all my time (and money). The alternatives were actually making money from RavenDB or stop working on it completely. And I didn’t want to stop working on it.
I decided that I had to make an effort to actually make a product out of this project. And that meant that I had to sit down and plan how I would actually make money from it. I firmly believe that “build it, and they will come” is a nice slogan, but it doesn’t replace planning, strategy and (at least some) luck.
- I already knew that I couldn’t sustain the project as a labor of love, and donations are not a sustainable way (or indeed, a way) to make money.
- Sponsorship seemed like it would be unlikely unless I got one of my clients to start using RavenDB and then have them pay me to maintain it. That seemed… unethical, so wasn’t an option.
- Services / consulting was something that I was already doing quite heavily, and was quite successful at it. But this is a labor intensive way of making money and it would compete directly with the time that it would take to build RavenDB itself.
- Support is a model I really don’t like, because it put me in a conflict of interest. I take pride in what I do, and I wanted to make something that would be easy to use and not require support.
- Open Core / N versions back – are models that I don’t like. The open core model often leaves out critical functionality (such as security) and the N versions back mean that you give the users you most want to have the best experience (since that would encourage them to give you money) the worst experience (here are all our bugs that we fixed but won’t give to you yet).
That left us with dual licensing as a way to make money. I chose the AGPL because it was an OSI approved license that isn’t friendly for commercial use, leading most users who want to use it to purchase a commercial license.
So far, this is fairly standard, I believe.
I decided that RavenDB is going to be OSS, but from most other aspects, I’m going to treat it as a commercial product. It had a paid team working on it from the moment it stopped being a proof of concept. It meant that we are intentionally set out to make our money on the license. This, in turn had a lot of implications. Support is defined as a Cost Center in Hibernating Rhinos. In other words, one of the things that we routinely do in Hibernating Rhinos is look at how we can reduce support.
One way of doing that, of course, is not have support, or staff the support team with students or the cheapest off shore option available. Instead, our support staff consists of decided support engineers and the core team that builds RavenDB. This serves several goals. First, it means that when you raise a support issue with us, you get someone who knows what they are doing. Second, it means that the core team is directly exposed (and affected by) the support issues that are raised. I have structured things in this manner explicitly because having an insight into actual deployment and customer behavior means that the team is directly aware of the impact of their work. For example, writing an error message that will explain some issue to the user matters, because it would reduce the time an engineer spends on the phone troubleshooting (not fun) and increases the amount of time they can sling code around (fun).
We had a major update between versions 3.5 and 4.0, taking almost 3 years to finish. The end result was a vastly improved performance, the ability to run on multiple platforms and a whole host of other cool stuff. But the driving force behind it all? We had to make a significant change to our architecture in order for us to reduce the support burden. It worked, and the need for support went down by over 80%.
Treating RavenDB as a commercial product from the get go, even though it had an OSS license, meant that we focused on a lot of the stuff that is mostly boring. Anything from docs, setup and smoothing out all the bumps in the road, etc. The AGPL was there as a way to have your cake and eat it too. Be an OSS project with all the benefits that this entails. Confidence from our users about what we do, entry to the marketplace, getting patches from users and many more. Just having the ability to directly talk to our community with the code in front of all of us has been invaluable.
At the same time, we sell licenses to RavenDB, which is how we make money. The idea is that we provide value above and beyond whatever it is our license cost, and we can do that because we are very upfront and obvious in how we get paid.
We have a few users who have chosen to go with the AGPL version and skip paying us. I would obviously rather get paid, but I have laid out the rules of the game when I started playing and that is certainly within the rules. I believe that we’ll meet these users as customers in the future, it isn’t really that different from the community edition which we offer freely. In both cases, we aren’t getting paid, but it expands our reach, which will usually get us more customers in the long run.
We have been doing this for a decade and Hibernating Rhinos currently has about 30 people working full time on it, so it is certainly working so far !
More posts in "Making money from Open Source Software" series:
- (08 Feb 2019) How we do it?
- (07 Feb 2019) The dichotomy
- (06 Feb 2019) The problem
OSS seems to have 2 different sought after value propositions:
1) Ability to customize it yourself. Few need this but it's critical for companies working at the technological edge, innovating or companies going off mainstream. These days mostly device companies and large providers. 2) BlackBox anxiety elimination. Companies are not interested in the actually using the source code, they just don'w want to deal with the anxiety of the "black box" of the closed source software. Do you trust close source software enough to gamble your entire business on it? This decision becomes harder and harder the bigger the capital under risk.
All other pretended benefits of OSS like:
Are a bunch of nonsense.
P.S. Yes you do get contributions from time to time, but nowhere enough to be considered a benefit.
Pap Catalin, You are correct, and very accurate. In particular, I don't know if you noted it, but there is a big distinction here between who benefits. Both your points about customization and visibility are about the benefits to the user of the code. The rest are about the benefits to the _project_.
Hi, thanks for very good content. I read your post about caching on irepository, but you closed comments! and i have questions, you dont said any thing about invalidating caches, windsor interceptor works on only virtual methods! is it true? and if the cache works on repository then all methods will be cached? is it true practice? repository has methods to crud functionality this methods must invalidate caches(i think).
Saeid, I'm not sure what post you are referring to, at any rate. Email me the question with the full details, since this isn't a relevant for this post. my contact details are located at the left side of this page
Very good articles! Very inspiring for me. I am working on a Startup project around a new type of DBMS technology. If I understand correctly, most of your customers respect the licensing rules. - How do you do with those who do not respect the license? What is the rate of non-compliance? - Do you not lose a large part of your income due to non-compliance with the license? - On the RavenDB website, licenses have memory limits, number of nodes, etc. Does this respect the spirit of an AGPL license? Do not developers try to remove these limitations in the code? Thanks to you.
Gabriel, Most of the customers respect the license and pay for it, yes. There has been a small number of customers that chose to use the software under the OSS license. However, I find that most users don't want to take the hassle of maintaining a forked version of the code with the licensing code removed. The AGPL is perfectly fine with both my actions and theirs.
Thank you for sharing this article, it's been something that hasn't been that clear to me about OSS projects. To add to (and probably just clarify) Gabriel's questions: 1. Since RavenDB is open source, someone could just download the source code and run an etnerprise version of the raven db server without paying for a license? 2. Would this be illegal (violating the license of RavenDB), or is this part of the OSS license RavenDB is made available with? 3. Is this sort of Open Source license (i.e. there are both free and non-free versions of the same thing) common?
Thank you for sharing your experiences and knowledge.
To answer your questions:
1) Yes. 2) It is part of the OSS licenses, yes. 3) Something like that wouldn't be an OSS license, because it would limit what you can do with the code. That is explicitly called out as non free license.
Redis, MongoDB, Elastic all have such clauses in their licenses and as such, are not considered to be OSS licenses.