Keys to turn your open source project into a business

Broadly speaking, there are two types of open source software. The free software, which has a reciprocity requirement in it. Open source software which doesn't.

We can have debates about the merits of those two groups for the whole evening. I think both of them are needed and it depends on the usage and the purpose of your project.

This article is part of my talk, Open-Source Business Models. You can see the full transcript and the video of my talk on Heavybit.com.

When we come to making money on open source software, at MySQL we had about 15 million users of our product and 15 thousand paying customers. That was like the needle in a haystack. In a haystack of a thousand users we would find one paying customer, and we made it work. We had a business that produced cash and paid for our expenses, but that's at the extreme end of open source software.

We always debated on how to balance the act between who should pay and who shouldn't? We boiled it down to a principle which is here on the slide saying: "There are always people who will spend any amount of time to save money, and there are other people who will spend money in order to save time." Typically in your life, or in the life of a company, you go from one to the other.

"Why does Facebook run on MySQL?" I asked Mark Zuckerberg a long time ago. And he looked at me and said, "Marten, I grew up on MySQL."

So when he was 15 or 14 or something, he started using it, so of course he would build Facebook on the LAMP Stack. They were a big non-paying user for the longest time, and one day they came to us and said, "Our business is growing so fast, we have so much to do. Why do we have all these people here maintaining our MySQL databases? Could we buy a support contract and the services from you to keep the site going?"

Then they became one of our biggest customers. They shifted from the mindset of saying, "I'll do anything with my bare hands to save money," to "I have other more important things to do, so I'll pay money to get it done." This is a philosophical principle, it's not a business model, it's not a licensing term. But it guided us and it has guided many open source companies in figuring out how do you figure out how to make money and who you think should be paying for your stuff.

Because if you can't live with the fact that 999 out of 1000 of your users are not paying you anything, you will never succeed. You must love those who are not paying you anything as much as you love your customers.

We said that! We said, "We love you, we really love you, but until you pay us money, love is all you get." Meaning if you need support or anything else, then you pay us. And you must also know that no matter how much customers love you because they said, "I love your product it's fantastic!" They don't love you as a vendor. They have no mercy with you. If they can get away by not paying, they will. They can be the nicest people, the most fantastic company. There's nobody who will pay voluntarily.

We had one customer at MySQL who paid us voluntarily. Craigslist. So Craig Newmark sent us $10,000 saying, "I don't find anything to buy in your offerings, but I love you guys and I would like to support you, so here's $10,000." And that was the reminder to us that we had no good business model. We had to figure it out and we had to build that which we called hard differentiation that said, "If you don't pay you get this, if you pay you get this. You can take it to your boss, because it's your boss who is the problem."

When you sell, it's never a problem of selling to the person you're selling to; it's that person who has to go up to the budget boss and say, "Boss, I just paid $50,000 for something I could have gotten free of charge." You can't do that. You must say, "I just paid $50,000 for something we uniquely get as a paying customer." You must build that differentiation.

You must be comfortable being on both sides of the fence. If you don't like your free users, you won't have a business. Then you shouldn't be open source. You should be a closed source vendor. So, do it only if you are really committed to being open.

I was checking through some old documents, and I found an article written by somebody a few years ago that had a list of 17 open source business models. That again is a description of the trauma of open source. We struggled for so long to figure out how to make money and in some cases we couldn't. And there are companies who didn't and who went out of business. I've again tried to simplify it for you, and I believe that there are two broad models for building an open source business.

Two broad open source business models

The one is the foundation-originated model where you have some non-profit organization or place that spits out code all the time. And then you have a set of vendors around them who take the code, turn it into a product, and sell it to their customers. Linux is the best example: we have Kernel.org, we have The Linux Foundation producing the main Linux Kernel, and then we have distros turning it into products and selling them. But they all say we sell Linux. There's Red Hat Linux, there's SUSE Linux, there's Ubuntu Linux, and so on. That's one business model.

The other business model is the singular one where the open source project and the open source company is practically the same thing. I would say that MySQL was the prime example of this. We had the Swedish company MySQL AB that had the whole project in its hands, and it maintained both MySQL.org and MySQL.com. And there are many others, MongoDB is such a thing. Eucalyptus is following that. I have a lot of names there on the list, but it's a one-to-one relationship. Of course, others can fork it and they do.

Take MySQL, there are forks of MySQL sold by others. I'm not saying that it's strictly a singular, I'm saying it's basically a singular model. I've now learnt only later that when you do make that choice you're sort of forced to a certain business model. In the foundation-originated one, and here Hadoop would be an example. There are many Hadoop vendors but they draw the Hadoop code originally from the Apache project. In the foundation-based model, many differentiate from each other through the binaries.

Take Red Hat. Can you get access to the binaries of Red Hat Enterprise Linux? No, you can't. But it's open source, why can't you? Well because they have perfected their model in a way that their best binaries are given out only to paying customers and if you want something from Red Hat that doesn't cost you anything, it's called Fedora and it's different binaries.

When you have that common platform called Linux, the way they differentiate is through different binaries and the fact that they are tested, certified, trustworthy, they're maintained, they have security fixes, and so on. When you're a singular vendor, you can't do that. At MySQL if we had said, and we tried but it failed, that the best binaries are for our paying customers and our community gets slightly worse binaries, we wouldn't have had a community. Because nobody else was providing it. So, at MySQL we had to give our best binaries, the best executable to everybody.

If you give that to everybody how do you make money? That's where I think the only viable model is to have commercial add-ons that you give only to paying customers. Some of you are saying, "But Marten, we can sell support can't we?" Absolutely you can, but that's not a scalable business model. I'm assuming you're building scalable businesses. It's great if you build nice businesses that don't scale, there's nothing wrong it. But I'm talking about scalable business models and therefore, I believe you must build a commercial differentiation. You see that Cloudera has that, Eucalyptus has that, MySQL has it. If you go to Acquia, because you're a Drupal user, Acquia in their commercial offering has stuff that you don't get if you are not a paying customer, features and characteristics of the product. You must have some sort of hard differentiation that comes on top of it.

The open source product is fully-fledged, ready-to-go, mission critical, capable, stable mature, tested, all of that. It's an amazing platform. But it lacks something that appeals to enterprises, something that appeals to those who are ready to pay money in order to save time. I think this is how it's happening now in terms of business models.

As always, there are always exceptions.

Take the Mozilla Foundation, how did they make money? Selling ads. Well they gets tens of millions per year, maybe a hundred million per year from Google for having the Google toolbar in the browser. Then Mozilla isn't technically a for-profit organization, so you could say, "Is it a business model or is it just a funding model?" We could go deep into those questions.

I'm saying, broadly speaking, generally speaking, if you are building an open source business you choose between the foundation based where many companies draw from the same upstream place or the singular where it's one company with one product.

Like NGINX is a new one, for the last 15 years, we've all used Apache as the web server and now slowly but surely, and maybe not even so slowly, we're seeing the market share of NGINX growing in the world of web servers. Because NGINX is more performant than plain Vanilla Apache. The company NGINX is now building a business around it.

So you have those two models, and you have to have hard differentiation that you can sell. I have gone through all these tests and experiments with MySQL and I've taken all the flack that you can get for doing it. Wherever I go, there's always somebody who thinks that it's bad what we are doing. Because we are building a business, we have to add a closed source component. We're doing something like that.

I believe that's the only way to build an open source business. And you must have the courage to stand in front of the crowd who's demanding that you give away everything for free.

Because customers have no mercy with you, they don't mind if you don't make money. They have demands and you must have the courage to say, "I do all of this for you, but this I need to make money on." I think you have to have that sort of a mindset.

You can also say that commonly, if you are building a product and nobody is against you, if you have no detractors, well then you are not really being popular. A measurement of popularity is that you have different groups and some of them criticize you wildly. That's a sign of success in a way. But as an open source vendor you have to have very thick skin for all that input you have.

Once you say you are an open source company they will assume that you are ready to share everything, your thinking, your plans, your finances, your product, your code, everything; and they will have a sense of entitlement to what you are doing. It's sort of true, and you have to live with it.

At MySQL, we had so many people who came to us and said, "We made you successful." Like, "Okay, but we've been working hard here for ten years and we did all the code, coded everything, and tested everything, and fixed all the bugs, and you just helped us here and there." No. They believe and sort of know that they made us successful and it was true. MySQL couldn't have been successful without those passionate users all over the place.

Like once when we were in Rio de Janeiro with the MySQL founder. He had a MySQL T-shirt on him and we were down in Ipanema Beach. And you would think that young men on Ipanema Beach would be focused on something other than middle-aged men. But, once they saw this MySQL T-shirt and realized who it was, they were just all flocking around him. They forgot all the fun stuff and all the girlfriends they had there because it was so amazing to meet the founder of MySQL. It sort of shows this weird relationship that they completely buy into it and are passionate about it, and then they say, "It's partly mine, I have an entitlement to it." You must live with it.

Winner takes all

I wrote something about the foundation-originated business model. I wrote, "Winner takes all." Then I thought I had to write it on the other side as well. And this is a little bit disturbing, but I sort of grew up in the open source business when there was a number of Linux distros. Turbolinux, we had Mandrake, we had the one in France, we had SUSE, we had Red Hat, and so on. Today, 90% of all money that's made in Linux is made by Red Hat, so you can say it's a winner take all.

Then you say, "Okay, but now we have Android. Everybody is building something on Android." Well guess what, 95% of all profits in the Android world are going to Samsung. Samsung is the one that makes real money on Android, and Google on their ads, but actually using Android.

I'm not sure it's completely true, but there's a trend of winner takes all in that space that can be a little bit challenging for those who know that by definition there are many vendors there. Long term it seems that only one can really win.

Then I was thinking about the other side, the singular ones. There it's also winner take all, because either you win or you don't. If you are MongoDB then, if the open source product is successful the company will also be successful at the same time. So you could say it's a winner takes all. But what then when there are different vendors in sort of the same category? There I don't think we have an answer yet. We have a traditional example of JasperSoft and Pentaho—both in practically the same space, both are open source, both are doing well, neither is killing the other. So there you see a healthy ecosystem.

Or you could take the new NoSQL Databases, sure MongoDB might be the biggest one, but you have CouchBase, you have Cassandra, you have Neo4j. They are smaller and larger and they have different styles, but in the new world of databases there is a healthy ecosystem of different players that seem to be doing well. I'm hoping that would happen because that gives more hope to all the entrepreneurs in that space.

Keys to turn your open source project into a business

If you are starting an open source project and if you decide to turn it into a business, here's some key things to think about:

First, why are you producing open source code? Some share it to make it technically even more viable. Facebook when they shared Cassandra, they thought, "Hey, if others start using it, it will evolve and we will benefit from it." Netflix open sourced Chaos Monkey and Asgard, Edda and all their cloud management tools for the same reason. So there's a lot of good stuff coming out from users there. I don't need to make money, I just want to insure the longevity of this product. B) is build a business on it, like MySQL. MySQL always wanted to build a business. Always. The purpose was always to build a business. And there are many others, MongoDB and so on. They are building a business. And then there is C) grow and install base for some benefit or monetization opportunity.

When Google came out with Android they were not planning to make money on Android. They were planning to make money on those who make money on Android. Meaning when you sign the Open Handset Alliance and you start using Android in your phones, you bind yourself to using Google services, Search and so on, and that's business for Google.

You can build an open source product that indirectly serves you. This is important to know if you are in that space because you can have asymmetric competition from somebody. You can have competition from somebody who doesn't have to make money on what they are doing because they are open-sourcing it. So you need to know why you are doing it.

Then you need to decide on what the governance is. How do you govern the roadmap? Meaning you have a great open source product, who decides what happens with it, what features get put in and what features won't? Who decides on what contributions you'll take and what you won't take?

There are many models here and the great thing with open source is that it has figured out ways to handle it, but it's a choice you have to make.

In a company like MySQL or in Eucalyptus, it's easy. We have a hierarchal organization, at the end of the chain is a CEO and he can make decisions. You can get very fast road map development and you can be customer-focused, you can do a lot of that. Others take a different approach. Take Cloud Stack, which was a company like Eucalyptus, now they donated the code to the Apache Foundation. Which means governance of the roadmap is now in the Foundation's hands.

When Citrix, from where it came, want to implement a new feature, they go to the foundation and they have a steering committee that votes about it. They've given up control of their roadmap, counting that the support they get is more valuable than the control they lose.

It's for you to decide what you want. And some of you are passionate founders, and you will never give up control of anything. Linus Torvalds is like that, he's not building a business but boy 20, how many years is it?—22 years after he started the project, he's still the guy who makes the ultimate decisions on what goes in and what doesn't. He really is passionate about his project.