Marten Mickos
MySQL CEO on 2 Open Source Business Models

Marten Mickos is a seasoned open source executive who’s passionate about infrastructure software. He is currently the CEO of Eucalyptus Systems, the open source, AWS-compatible cloud. Previously he was CEO of MySQL AB, where he grew the company from garage start-up to the second largest open source company in the world.

00:00:00
00:00:00

My name is Marten Mickos and I'm the CEO of Eucalyptus Systems. As Tom mentioned, I was the CEO of MySQL for eight years. I was de facto the only CEO that the company ever had from 2001 to 2008 when it was sold to Sun, and then one year at Sun Microsystems.

I'm here tonight to talk about open source business models which is a difficult, complex, complicated nuanced topic that doesn't really allow itself to be structured and summarized, but I'll do my best anyhow.

I thought I would ask how many of you use open source software, and that's a silly question because everybody would have their hand up. But, do we have open source vendors in the space, in the audience — people who are building an open source business? There's one, okay, two, three, four. Excellent!

We also have others who are using it or maybe are participating in it. I'll try to cover all of that in the next 20-25 minutes and then we'll do questions and answers. Then, I do have a relatively hard stop, so if you see me rushing out of the space it's not because I don't like the discussions, it's because I have something else I'm going to. But you can absolutely email me afterwards if you have some question or something I can help you with.

I can tell you that when I joined MySQL in 2001, I knew practically nothing about open source. I knew something about databases, and I happened to be friends with the founders of MySQL. They called me in December of 2000 and said, "Marten, we are sitting here in the kitchen and we need a CEO and we think it's you." And I said, "No!" That was my first response.

It turned out that I joined as CEO and I had to decide to learn about open source, and I decided that year to become an expert on open source business models, which back then practically didn't exist.

There was Red Hat out there, a famous open source company, but those of you who remember and who were there at the time know that their initial business model was selling boxes with CD-ROMS and the reference manual and the box. That was the business they had and they went public on it with a huge valuation. It took them several years to develop the real subscription business model that they are now following and that many open source companies are following.

So first quickly about Eucalyptus. It's an open source private cloud software platform. The name is an acronym which makes it easier for you to remember what it does. EUCALYPTUS stands for an Elastic Utility Computing Architecture Linking Your Programs To Useful Systems. Yes, it's very funny, but it's true. That is what the software does. It is the only private cloud platform that behaves like Amazon Web Services. If you run Eucalyptus on your own servers, you have a region that you control. It's like having your own Amazon region.

MemSQL did. They have 35 servers for dev and test running completely in Eucalyptus and it all behaves like Amazon which means they can move workloads back and forth through the public cloud and the private cloud.

And I'm quoting myself here in a tweet. Just a few days ago I tweeted that,

"When you run on Amazon, you run on your credit card and when you run on Eucalyptus you run on your servers." And smart people want a choice of where they run.

There's huge convenience running on Amazon. There's huge control and power of running on your own servers. And you can do both because the APIs are the same, EC2, S3, EBS and so on behaving the same way on both environments. So that's what the company does.

Let's move over to the business models. I want to set the stage here by noting that I think generally when the world evolves, and the universe evolves, we go from one stage to the next and what we solved in the old stage becomes legacy, and it's used, but that's not the new thing. And for every new era we have some new things being invented. I believe that exists even on a physical plane. When the universe started to exist, we had small particles then they said "Why don't we get together and become atoms?" And then the atoms said, "Why don't we get together and become molecules," and so on.

So in small scale in the software business, in the eighties, that's a long time ago but I was there at the time, I joined the software business. It was all about the shift to client/server. From mainframes and mini-machines we shifted to the PC era and the client/server era. And back then we said that the new process architecture, which then would be called x86, was an open architecture for everybody.

So the level of openness back then was the hardware architecture, and everybody built operating systems and software that ran on the same CPUs. It was seen as a fantastic level of openness.

Then, 15 years later we got into the web era and the big shift that disrupted half of client/server. It disrupted the client. In client/server you have an application running on your machine. On the web you have just the browser and everything runs on the back-end somewhere and in the web at the same time. Open source happened and openness was then about openness in the source code.

It's not an exact comparison because you can claim that there was open source code before that and it had different origins. But when you think about the real mechanisms of the industry, it was in the mid-90's that people started waking up to open source software and we saw the birth and the growth of all these important products. Like Linux, started in '91, MySQL started in '95 and Apache and PHP and Python and all those created at that time.

The business was about building web applications and the openness had moved from the hardware level to source code and suddenly to be really creative and to share things, you opened up your code and the whole open source movement started then. Or, it didn't start then, but it became relevant then. It wasn't even originally called "open source." Just as Cloud wasn't originally called "Cloud." Why is Eucalyptus called a "Utility Computing Architecture?" Well because back in 2007 that's what we called it. We didn't really call it "Cloud" back then. It was called "Utility Computing."

Anyhow, back to the trend. So we got the level of openness in source code and that's why we now have open source businesses. I would now claim, that 15 years later again we are now moving to Cloud and we take the final farewell to client/server. We are breaking the server side now as well and we are deploying our workloads in a way that's completely different from what we learned back in the 80's. It's again, a huge shift. It's disrupting everything.

New vendors are emerging, old vendors are struggling and shrinking, and again there's a new level of openness that's emerging. I believe it is APIs where we see the openness today. I think it's so early that we haven't really seen it play out.

For hardware, the name of openness was x86 — the architecture that then everybody started using. With open source, we had the licenses, GPL licenses and then the Apache license. For the API of today we haven't agreed on a complete openness yet, but we can see how the innovation is happening on an API level. Whereas ten years ago, many of you, or whoever then were building things, were looking at source code. Now to get stuff done, you look at APIs because you have so many different things you need to work with.

MySQL grew on the notion of the LAMP Stack. Every website of any size or fame ran on the LAMP Stack. Google, Yahoo, Facebook later on, MP3.com, Wikipedia, all of those. And LAMP Stack was Linux, Apache, MySQL, PHP, Perl or Python. Today, in your applications you have many different databases, many different languages mixed in one application, set up in one workload. And the question is more about the APIs.

This goes a little bit beyond the topic of tonight, but I'm throwing it out to you so that you can tell me: If sort of my generation built open source businesses, what kind of API businesses will there be over the next ten to fifteen years? I don't know. But you may know because you are the ones building it. You are the Linus Torvalds-es of today.

If we then focus on open source softwares and say, "How do you build a business? What kind of business models are there?"

I believe that there are four types of players that you need to be aware of and they are partly overlapping and you can belong to more than one of them. We have a big group of end users who produce free and open source software.

FOSS stands for Free and Open Source Software. You have end users who use it, who are customers and users of it. Then you have vendors who produce it like MySQL was, like Eucalyptus is. And you have foundations who produce them, like the Eclipse Foundation, the Apache Foundation the Linux Foundation, the Open Stack Foundation, and so on. There is the Mozilla Foundation who are building them.

It has meaning for the business models in that, in the closed source world it doesn't look like this. If you think about source code that's closed, there are practically no foundations for closed source development, collaborative development. And there are practically no end users who produce closed source software and give it out to others. In the world of closed source software you have vendors and you have buyers and that's it. But in the world of open source you have a much more dynamic environment and it's important because the end users produce a ton of open source software.

If you are aiming to become a successful, profitable, fantastic open source company you must know that there can be software coming out of end user organizations that will affect your business. In good or bad.

Take Facebook, they needed a simple, scalable, powerful, reliable storage so they developed Cassandra. What happened to Cassandra? Facebook didn't need it anymore. Already from the beginning they open sourced it, gave it to everybody. Now we have a company called DataStax that commercializes Cassandra and further develops it. For DataStax that was a fantastic starting point for a business — to take an existing product that had been developed by somebody who really needed it. They knew it was a useful product. For them it was an opportunity, but for others it can be a threat.

When you are developing some absolutely amazing software and you have five developers or eight developers, and suddenly it turns out that the big end user organization is developing something similar and they have no limits on their resources, they can have 100 developers working on it; you must think about what kind of code you may get out from those end user organizations.

You could look at big data which you can trace back mostly to Hadoop, and you can trace Hadoop back mostly to MapReduce, and MapReduce you can trace back mostly to Google who developed and perfected the algorithm. You saw several end users there. Google and then Yahoo developed it, and now Hadoop is a project of the Apache Foundation and we have a number of vendors building a business on it.

This has remarkable influence on the ecosystem of open source software in a way that doesn't exist in the closed source world.

I see it as the power of open source. Because we have always said that the majority of all software developed in the world is developed by users, not vendors. In the closed source world you don't get access to the productivity of end users.

Looking at open source softwares particularly, this is a fact that is probably useful to you if you are thinking about business models, many people don't care about it anymore. We talk about FOSS, Free/ Open Source Software, but if we really are strict there's a difference between free software and open source software. On the left, I have Free Software which most typically is GPL software. Software where the license insures freedom. It gives freedoms to you as a user, but it also requires that the freedoms are maintained.

On the right-hand side, you have Open Source software which is open for all, but it also allows you to close it. So here we come back to the famous clause of the GPL license, the reciprocity requirement which says, "If I am open, you need to be open." So software that comes under the GPL license carries with it something that other people call a virus. I call it a blessing because I think it's great if all software becomes open.

It practically says that if you are distributing a derivative work — so two D's, Distributing Derivative works — they have to be licensed under the same license. If you don't distribute them or if they are not derivative works, you're fine, you don't need to share anything. But if you distribute derivative works then they have to be under the GPL license as well.

This is a very powerful construct that Richard Stallman and others came up with called copyleft which insures that the openness persists. There are huge debates about whether that's good or bad.

Some people say the open source software is more business friendly because it puts less requirements on you. Other people say, no, we must insure openness, because otherwise it will not continue and persist.

Take an example: How many of you have Apple laptops? Is the operating system open for you? No, but what was it originally built on? The BSD operating system which was open source. But BSD was licensed under its own license which didn't require derivative works to be open, so Apple could take it, modify it, add their own stuff and keep it completely for themselves.

If you take Linux and modify it and create a new fork of Linux it must continue to be under the GPL license. That explains the power of Linux — you can take it, you can do anything you like with it, you can fork it, you can modify it, but it must always remain GPL when you distribute a derivative work. It ensures and maintains the openness.

Examples of GPL software for each of those groups, there are tens of thousands of examples, but some of the most famous ones are: Linux, Java, MySQL, Asterisk, the PBX software. Eucalyptus is GPL licensed. And the other examples of permissively licensed ones that have the Apache or the MIT or the BSD license or one of the other permissive licenses, are: Apache, everything under the Apache Foundation, the Open Stack Foundation, the Cloud Stack, which is part of the Apache Foundation and so on.

With everything I say here, there are variations and exceptions. A variation of the GPL license is the AGPL license, the Affero GPL license. It takes the requirement on openness one step further. MongoDB is probably the most famous example of an AGPL license product.

Where I previously said that GPL says, "If you distribute derivative works, then it has to be open." In AGPL you don't even have to distribute. If you make public use of AGPL software and you have made modifications, those modifications must be open as well.

Then you have Android which is a mix of GPL and Apache license which is perfectly alright, you can mix the two — you take the Linux kernel and the stuff from Linux and there's Apache license stuff built around it, perfectly okay. The GPL part will always have to be kept open and the Apache parts don't have to. On the other side, variations and exceptions, there is the BSD license, the MIT license. There's a long list of open source licenses. I simplify it for you by talking about the Apache license and the GPL license, in reality there are tens of them. But those are the most prominent examples.

Then you have really extreme ones like SQLite, an amazingly popular, lightweight database that Richard Hipp developed and that he operates and develops in his own little company. He decided to put it in the public domain. All the others when they come under an open source license, they are still owned by somebody. And you as a user or a company, when you use them you must explain under what right you are using them. You say, "I'm using them under the right of the Open Source license."

But Richard Hipp put SQLite under the public domain. He says, "This is owned by everybody and nobody." There's absolutely no restriction because he's already made it common property of all citizens on this planet or the whole universe. There are exceptions like that.

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.

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 these 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.

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 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 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.

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 percent 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 percent 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.

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 decision. 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.

You have to know, is fragmentation good or bad? In Android we have fragmentation. People say, "Is that good or bad?" In the Open Stack project there's fragmentation, is it good or bad that they are mutually incompatible? Some say it's good because it expands the ecosystem some say it's bad because it disables compatibility.

What does community mean to you? Community is an overloaded word, it can mean anything. Community can mean just people who use your product. Or maybe it's those who build your product, or maybe it's the business partners who are using it. Or maybe it's those who are blogging about it.

Decide what kind of community you like, because there are different ones. Again MySQL had a total of maybe 100 contributors over its lifespan of code and we hired many of them into the company. That part of the community was relatively small. The community of users was enormous and still is. And the community of those who build an add-on to MySQL was enormous. You have different ways of doing them.

Then finally, and this is perhaps the most remarkable insight I've made about open source licensing models and governance, it's very much about branding.

This has to do with the fact that an open source license stipulates nothing about the name. If they do that, it means the name isn't free, it is protected by copyright.

So, if you use Android and you take it and fork it and you refuse to sign the Open Handset Alliance, you're not allowed to call it Android, you must call it something else. You could use the code because the code is open source, but you are not allowed to call it Android.

That's why Amazon took the Android code used it in their Kindle Fire, I think, but they can't call it Android because they didn't sign the Alliance that would have forced them to use Google Services. If you take Red Hat's code and distribute it, you can do that, but you're not allowed to distribute anything that shows the brand or the logo. The name Red Hat Enterprise, Linux and all the marks that go with it, the visual, the JPEGs and PNGs, and the pictures, they are all proprietary.

I'm not sure the open source gurus who invented the licensing models and governance 20 years ago thought about this, that actually branding becomes the control point of how it works.

Similarly, the Apache Foundation had set a smart rule. They say whatever is in the Foundation has a name and those names must not be used commercially. If you use Hadoop, you can say this is built on Hadoop, but your commercial product cannot be called Hadoop. It has to be called Cloudera or Hortonworks or MapR or something. Branding actually becomes the way you control the behavior of the ecosystem.

We had that in the MySQL where we are holder of the brand, both the commercial and the non-commercial, and we were thinking, "Should we split them up?" Because we're looking at Red Hat saying, okay Red Hat, they took the Red Hat name from the community and turned it commercial only. And the non-commercial name is Linux or Fedora. We asked ourselves at MySQL should we also split up the branding and have one name for the open source thing and one name for our commercial offering. And we never believed it was the right thing to do, but we spent a lot of time thinking about it.

We had our challenges either way. The fact that we had them together gave us certain challenges, and also certain benefits. So branding is more important than I realized when I was in the middle of it.

Here is some further reading if you are interested. The one up there written by Matt Asay is an interview with me that he did just a couple of weeks ago so there's more about my thinking about open source. Feel free to use them. I think the slides will be distributed to you, that's why I didn't shorten the URLs. I thought you would get them or somebody would take a picture or something.

So with that let me stop here, I'm ready for questions and discussion with you. You'll find my Twitter handle there and my email address, if you would like to get in touch with me after this. Thanks for listening actively and intently, and now I'm ready for your questions.

Q: When you have a commercial product, what do you do if someone contributes a similar product that is open source?

A: A good question, when you have commercial add-ons, what do you do if someone contributes an open source product that does the same? We have decided to just welcome it; we did it at MySQL, and we are doing it at Eucalyptus. I'll give a Eucalytpus example.

When you run Eucalyptus on Linux and KBM, you need nothing else and you can run massive clouds on that product. If you need to run it on VMware hypervisor, you need our commercial plug-in. Now we think if you're paying VMware all those millions you might as well pay us a few thousand bucks as well so we think it's fair. And we also say, "Or then you write that plug-in yourself. If you think you can do it, then go ahead." Because the platform is open and the API is open so anybody can do it.

That means that if somebody would contribute a competing component we would welcome it. Because we believe that, for those who do go through the work it will have benefit for them. For most customers they'll say, "Yeah I know there are open source alternatives. I would like to have the one which comes from Eucalyptus Inc., which is tested and proven." So we welcome those happenings.

That's what I tell customers, I say, "We have these commercial add-ons but you can develop your own." We saw it at MySQL where we developed a management tool that you paid for to manage large MySQL installations and many others developed their own commercial ones and non-commercial ones. And they existed in the ecosystem.

Of course I had sales people who came to me and say, "Marten, we must crush this competitor to our commercial product!"

I said "No, we don't have to crush them, this is part of open source. There's always an ecosystem of small players out there. They serve to demonstrate the openness and the lack of lock-in."

And the majority of customers will always come to the main vendor and say, "Okay, I understand I can get it cheaper or for free somewhere, but I want to deal with you guys."

You have to have that conviction, but you can easily get tangled into sort of distrustful relationships if you don't go all in with this.

Q: What are the advantages or disadvantages of having a singular product with multiple brands?

A: The question was what was the benefits and disadvantage of having one brand for both sides. If you go to a branding expert who knows nothing about open source and you say, "Should I have two brands or one?" They would say, "One, of course!"

People have a limited attention span, they can't remember two brands. Don't make it complicated for them.

We had huge benefit of this with MySQL because anybody who said "MySeQuaL" or "MySQL", it came to us always, it was always ours. So we saw that benefit. But we had the problems when let's say somebody built something on MySQL or forked it, and wanted to call it MySQL or wanted to call it the MySQL Administrator. We had to go to them and say, "We know you love us, and we know you did it with good intentions, but the naming convention 'MySQL something' is ours. You can call it 'Administrator for MySQL' that's fine, but it's only us who can call it 'MySQL Administrator'."

Sometimes when we did that we got very negative reactions because they say, "What is this, I'm helping you and you are ungrateful." You have to deal with them softly and firmly at the same time.

I forgot to say that if you go into open source business models you are asking for a lot of trouble anyhow, so you might as well get used to it but you're also asking for the most powerful disruptive force in the world. It's well worth it in my mind.

Q: How much code was contributed to MySQL?

A: The question was how much was contributed to MySQL or MySeQuaL. It's amazing how little it was. When I joined in 2001, 90 or 95 percent of the code was written by one single man. And over the next eight years when I was in charge of that place, like I said I think we had a hundred contributors. In terms of percentages or meaningfulness, it wasn't meaningful.

I've told the world, I myself am of the firm belief that when people say open source they easily think about contributions. "Oh that's what open source is about. Everybody is contributing and everybody is happy." That's not true! Open source is not necessarily about contributing code. There are many other things that you do in the community: you use the code, you test the code, you write add-ons. The act of contributing has both benefits and drawbacks.

We all know, I think we all know, that some of the best designs of the world are made by small teams. Steve Jobs said, "Small teams of A-players will run circles around large teams of B and C players." And it's so true.

If you're building a monolithic product like MySQL with huge demands on concurrency and synchronicity and stuff, you should keep the team small to make a fantastic engine. Then everybody else is building around it. I happen to believe in that model. But we have other projects like the Apache Web Server where when you go and say, "Who was the chief designer of the Apache Web Server?" They all point at each other. You know you can talk to the founders and they don't have a view of who the main designer was. They say, "Well we did it together."

You have examples of projects that are very successful where there isn't strict design governance, but I happen to believe that the most artful things must have a core philosophy and maintaining a core philosophy is very difficult if you don't have a chief designer like Linux has Linus Torvalds, like MySQL had and has, and like others have that.

That's why to me, if I could choose for an open source project, I don't need code contributors. I need people who do something with the code. That's more valuable. In my mind.

Q: How do you determine what to keep closed source?

A: Right, so drawing the line between what's paid for and what's not paid for is really difficult, and whatever you do you will regret it. And if you do nothing you will regret it even more. So welcome to the club.

I think we developed a good principle at MySQL which we are now using at Eucalyptus. We said, "We believe in open source. We will do open source as much as we can." We also believe like with food, food without salt, may not taste that good. Maybe it's healthy to not have salt, but add just a little bit of salt and it's amazing. Similarly we think that with an open source product you can add commercial plug-ins that add something to them without being the major part.

We always said that the main open source product must be fully ready for mission-critical heavy use. You mustn't take away something that's vitally important because then you are questioning and second guessing yourself and your ambitions. You have said that open source is fantastic, so you should show it.

But then you go beyond that and say those who use it, some of them want convenience, some of them want assurance, some of them want ease-of-use, some of them are in a commercial setting and you find those borderline cases where they are actually looking for a reason to pay. We had many customers who came to us and said, "We would love to pay, give me something I can tell my boss that I'm buying and I will buy." It wasn't a difficult value proposition at the end of the day, you just had to have a clear distinction.

If you listen to Mike Olsen, he was interviewed somewhere recently, he said exactly the same thing, maybe even stronger. Mike Olsen has an even longer experience from open source than I do.

It's a constant debate and you can move things from proprietary to open, you can't really move from open to proprietary. That's like shooting yourself in the foot.

But you can move the other way, and you can build new things over time that are useful but that are not essentially needed for the production workload.

Q: What advice do you have for a cloud-based service built to run on open source software?

A: Okay, yeah we have an example. Amazon, AWS RDS is MySQL as a service. Do they pay anything to the owner of MySQL, to Oracle? No. Is it bad? Maybe somebody thinks it's bad, but the ones who created the product, meaning us when it comes to MySQL, we decided to make it open source and we have to stand our choice and our selection.

I don't think you have to worry. You're just making use of the license the way it was supposed to be made and if the originator doesn't want you to do it, he or she should have picked a different license. I don't see any moral question there. You use it under the contract that has been given to you.

Of course if you do build, if I were now to build, if I start a company to sell MySQL as a service, I would absolutely go to Oracle and say, "I'm going to do this, I would like to have a commercial arrangement with you so I get quick bug fixes, I get your help." I would actually establish a business relationship because I think it makes sense.

I don't think there's an obligation moral or otherwise to do so because those of us who have produced open source code we exercised freedom zero, the freedom to set the license. The license then dictates what can be done and what can't.

Q: What defensibility and strategic concerns are there for a cloud-based service run on open source software?

A: Yeah defensibility is difficult if you are not at the core of the development because we all now know that there's a lot of software in the world, and owning the software is just one part of your business. You have to show that you can develop it and that you can keep it competitive.

I sort of think, yes you can drill into all the questions and you get these weird, sort of difficult questions. But at the end of the day it's very simple. If you do a great job and you innovate you will have a business and if you don't, you won't.

It's easier if you own everything, if you have control of everything and you own the brand name, you have much more control. That's why MySQL became such a valuable property. MySQL was acquired for a billion dollars. Postgres has never been acquired by anybody. Technically Postgres is as good as a product as MySQL. Some people think it's better and that's fine.

MySQL became a business worth a billion dollars because there was a concentration of brand and skill, and innovation, and marketing and sales, and leadership and technology, and everything in one place. It does add up, but there are components. You can go either way. There are companies who are building businesses on MySQL without owning the code.

Q: How do you price support contracts for free software?

A: Right, how do you price support contracts for free software.

I'll start by saying I don't believe support is a scalable business, so I don't know how to price just support.

At MySQL and at Eucalyptus we price subscriptions. An annual fee that gives you everything you need: the features, the support, the legal indemnification, the priority with consultants, and so on. And we price it, we don't know, somewhere, and then we look at the market and see how it reacts and we go up and down.

I'll give you a wonderful example though. Our general counsel at MySQL, who would think that a lawyer would come up with it, but he's amazing. He came up with the best marketing idea. He said, "We should sell something called MySQL Unlimited." And everybody said, "What is that, we can't do that!" Because the idea was to sell an unlimited license for a fixed price, as many servers as you had. We priced it at $40,000. We went out to the world and said, "If you pay us $40,000 per year you get an unlimited subscription to MySQL. You can have one server or a million servers and we will take care of you." And $40,000 is the price of Oracle Enterprise Edition on one CPU.

That whole marketing trick was so powerful in the industry, that was the best thing we ever did with pricing. Then in reality we started building tiers into it, and said, "Okay, the 40 thousand is for companies up to 400 employees and then it is 400 thousand." And we built a great business around it, nobody was disappointed, it was still a huge saving. Our fear that it would cannibalize our support ability didn't happen because in reality companies don't grow their installations that fast. If somebody really has a huge number of MySQL servers, you want them as your customer anyhow because they're a great reference.

We had a lot of pricing power because we had a business model and we could play around and test the pricing in the market. We did and it worked well. But you must have that courage to do some testing and experiments and apologize when you price it incorrectly, and come back and price it in a new way.