What's in a name in open source?

Image by:

Opensource.com

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.

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.

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.

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 said, "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 are the benefits and disadvantages 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% 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,000 is for companies up to 400 employees and then it is 400,000." 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.

open_source_business_models_201310_mgm.pdf