The Cloud vs. Open Source

Let’s get ready to rumble! Providing cloud services (a la Amazon AWS) is a business of slim margins. Because of this, cloud vendors are more than happy to exploit open source to keep their costs low. However, what happens when they siphon off support business from the open source vendors themselves? The cloud vendor becomes the single point of contact/support for the entire collection of tools, so who needs a support contract with the individual open source vendors? What revenue crumbs does this leave for the FOSS companies to live on? Not much.

The latest example of this trend is Amazon’s Relational Database Services (RDS). It is essentially a packaging and automation of vanilla MySQL. They automate set-up and administration. They also restrict things like slaves and replication, because they are a pain to manage. But they provide a failover solution (basically attaching your data to a fresh machine), which will address some use cases. The out-of-the-box integration with EBS makes it a breeze to work with. RDS makes it quick and painless to get MySQL running, so why roll your own on premise solution?

As competition in the cloud accelerates, I suspect that this trend will accelerate. Cloud vendors will integrate various tools, provide automation and become the single point of contact for support. This approach lowers the ultimate cost to consumers, simplifies their support process, and creates barriers to exit by customers, while maintaining the cloud vendors’ margins. In short, if you think the cloud is cannibalizing FOSS revenues now, you ain’t seen nuthin yet.

Soon we will see round two in this battle of the titans. Cloud vendors, in an effort to differentiate from one another will offer proprietary extensions/modifications to open source. It’s just a matter of time. These extensions may be developed in-house, or they may be acquired from third parties. What is the motivation to provide these extensions back to the open source community? Legally, the cloud vendors are fine, since they don’t redistribute the code. So why provide them back just to have your competitors integrate them into their own cloud services?

How could the FOSS community fight back? The only approach I see is the legal approach. If the FOSS license agreements redefine cloud/SaaS as being a form of distribution that requires open sourcing any extensions or modifications, they might have a chance. Maybe this comes in the form of a “hosting for third-parties use” clause or something. Otherwise, just like the classic Buggles song “Video Killed the Radio Star”, Cloud just might kill FOSS.

Open Source Licensing Considerations

The two predominant forms of open source licenses are BSD and GPL. PostgreSQL is licensed under the BSD license , while MySQL is licensed under GPL . While the details are arcane, the business impact is significant, and that is what this post addresses.

The BSD (or BSD-style) License: This license basically says: ‘This code is provided as is, do what you want with it, and include this copyright in your resulting product.’

The GPL License: This license, also known as the copyleft license, essentially says: ‘This is free and distributed as source code, and any addition or extension must also be distributed under these exact terms.’

BSD essentially says I prefer open source code, so I’m making my source code open and freely available, but what you do with it is your own business. GPL is based upon the belief that all software should be open source as espoused by Richard Stallman and the Free Software Foundation (FSF). The GPL license acts like a virus, attaching itself to anything that combines with that GPL code. I don’t mean to imply negative intentions, their intentions are to ensure that open source does not become perverted through the insertion of proprietary code, which is a very admirable goal.

Companies that want to operate in the ecosystem of a GPL product must agree to forgo the most common and most profitable business model used in software, namely licensing of closed source applications. (Note: This excludes those companies that utilize hybrid licensing, of course.) While the intentions behind GPL are good, there are unintended consequences. Consider the following situations:

1. Inbound License Conflicts: My application might include licensed images, code, linked libraries, etc. that is not GPL and refuses to accept the GPL license. I cannot use this in a GPL environment.

2. Reuse of Code in Other Products: If a GPL product (e.g. MySQL) has a really cool piece of code I want to deploy in another product, whether closed source or open source, that is licensed under a different model, I cannot do so.

3. If I donate my code to a GPL effort, giving them the copyright, I cannot reuse that code in a non-GPL product, unless the GPL product uses a dual license for the copyright (AKA shared copyright).

4. Niche Markets: All companies must make money in order to survive. If your software is free, then you can make money in ancillary ways, such as charging for support or consulting. This is fine if you have a large number of users. Consider that only 1 in 14,000 MySQL users pay for support. Let’s assume that you invest considerable effort into building a niche product that appeals to a total addressable market of 10,000 customers, and over time you get 50% market share or 5,000 customers. Now, if you charged $1,000 license subscription, you would make $5,000,000 per year. Even if your user base was 10% of this size, as a result of charging, you would still make $500,000 off of 500 customers. But if you charged $1,000 per year for support and 1 in 5,000 paid, you would make $1,000 per year. In conclusion, it is very difficult to recoup your investment of time and money if you invest in a niche market and you are prohibited from charging a license fee.

These are just a few of the challenges one faces when working within the restrictions of a GPL license, as opposed to other less restrictive open source licenses. GPL makes it more difficult to assemble a thriving ecosystem because it limits the types of applications and business models the ecosystem can use.

GPL extends the terms of its license to cover additions and extensions to GPL products in an effort to ensure that the code remains open source. But is this really necessary? If we look at Postgres, it uses the more permissive BSD-style license. Yet Postgres remains open and supports a thriving ecosystem. One might argue that MySQL is larger, thus validating its licensing model. I believe that this is not tied to the license. The real impact of the license is tested when the companies build sustainable ecosystems around their products, and in that realm, the jury is still out.

Being a Platform is Everything

“… when you get the money, you get the power. Then when you get the power, then you get the women.” --Tony “Scarface” Montana

In the world of computing, first you get the users, then you get the applications, then you get the power. What do I mean by power? In a word “platform”. If the only way for users to get applications is through you, and the only way for application developers to get to users is through you, then you are a platform. If you continue to nurture and grow your platform, your company is immortal and it is a goose that will continue to lay golden eggs.

To get the users, you need to deliver immediate value. Once you achieve critical mass of users, the developers will start showing up, whether you want them or not. A good example of this was Myspace. They attracted so many users, that developers started providing extensions directly to these users without Myspace’s blessing. But instead of embracing these developers and their applications—and thereby achieving immortality—Myspace took the perspective that these applications were leaches cutting in on their franchise. Distant second place contender Facebook embraced developers and the rest is history. Facebook growing, Myspace shrinking.

Another classic example of the power of the developer is the iPhone. Before the iPhone, the carriers would pick and choose which applications would be “on deck” and thereby available to that carrier’s users. It was a long and expensive process and you had to run separate processes for each carrier.

The iPhone came along and made it easy for users to find and use any number of applications and load them on their phone. This has turned the phone industry on its head. Building a developer-friendly platform is in the DNA of Apple, clearly it wasn’t in the DNA of mobile carriers, but they are learning.

The challenge in dealing with developers is that if you invite them in the front door, they will then want access to the back door and the side doors. By this I mean that if you provide a base platform with a certain set of functions, the initial wave of applications will build on top of this platform. Then others will find deficiencies in the platform and they will want to extend the core platform. This is analogous to going in the back door. Then others developers will want to connect your platform to other applications or services (the side door).

If you only open the front door and barricade the side doors and the back door, you expose yourself to the risk of a more open platform stealing your users and application developers. Apple has historically opened only the front door to developers. They are following this model once again with the iPhone, resulting in jailbreaking efforts. If another device comparable to the iPhone comes along and provides a more open and flexible platform it too could displace the iPhone. The Palm Pre is just being released and they are talking about opening it to all applications. Google’s Android operating system is also a threat.

How does this topic apply to ScaleDB? MySQL has become a platform, but will they continue to nurture and grow the platform, or will they barricade the side and back doors, thus driving developers into the open arms of competitors like PostgreSQL? See my next post…