Problems with Open Source: Part 2

In my prior post on the problems with open source, I wrote that one issue that impacts open source revenues is the macro economy, and how a declining or difficult macro economy can result in reduction of revenues to open source companies. The following article talks about how financially troubled Spain is saving a "fortune" by moving to open source. The Spanish government's savings are coming at the expense of proprietary server software companies--most likely Microsoft--but I would be willing to bet that none of this "savings" is flowing to the open source vendors. That is what happens in a difficult macro economy.

Problems with Open Source

Monty Widenius wrote about the problems with the open sourcemodel, or more specifically the problems he is experiencing with his open source project MariaDB. In a nutshell, it lacks two things: (1) developers committing code; (2) users paying. He then focuses primarily on #2, lack of paying customers.

I believe that Monty’s concerns are the result of a number of factors: 

1.  Maturity (coolness factor): When a product is new and cool, developers want to work on it and customers get in the spirit and want to pay for it to continue to evolve. But once it becomes mature…eh not so much.
   
2. Maturity (downstream revenues): When a product is new and cutting-edge, “experts” make a ton of money. Look at Hadoop experts now. But as it becomes mainstream, the experts are making far less and feel less charitable toward their respective open source project.
3. Maturity (market adoption): When you are one of the few early adopters of an open source project you may be more charitable toward the company in an effort to see it survive. Once it gains universal appeal, you figure that the rest of the people will pay so you don’t need to…in other words, “they are a success now, no need to continue funding them.”
4. Macro Economy: If the macro economy is tight, as it is now, and companies are looking for where to cut, it is easier to cut funding to an “optional donation” than to cut one more individual. This is similar to the “downstream revenues” issue above but at the company level.

Open source projects follow a cycle, just like most everything in life. Commercial products achieve peak revenues with maturity and broad adoption. I believe that open source projects are the inverse, with maturity comes a decline in revenues. Ironically, it could well be that success is dangerous to a company's health.

Monty has some interesting ideas on separating "free" from open source...at least to some degree.

Thoughts on Xeround and Free!

Everybody loves free. It is the best marketing term one could use. Once you say “FREE” the people come running. Free makes you very popular. Whether you are a politician offering something for free, or a company providing free stuff, you gain instant popularity.

Xeround is shutting down their MySQL Database as a Service (DBaaS) because their free instances, while popular, simply did not convert into sufficient paid instances to support the company. While I am sad to see them fail, because I appreciate the hard work required to deliver database technology, this announcement was not unexpected.

My company was at Percona Live, the MySQL conference, and I had some additional conversations along these same lines. One previously closed source company announced that they were open sourcing their code, it was a very popular announcement. A keynote speaker mentioned it and the crowd clapped excitedly. Was it because they couldn’t wait to edit the code? Probably not. Was it because now the code would evolve faster? Probably not, since it is very low-level and niche oriented, and there will be few committers. No, I think it was the excitement of “free”. The company was excited about a 49X increase in web traffic, but had no idea what the impact would be on actual revenues.

I spoke with another company, also a low-level and niche product, and they have been open source from the start. I asked about their revenues, they are essentially non-existent. Bottom line is that the plan was for them to make money on services…well Percona, Pythian, SkySQL and others have the customer relationships and they scoop up all of the consulting and support revenue while this company makes bupkis. I feel for them.

I had a friend tell me that ScaleDB should open source our code to get more customers. Yes open source gets you a lot of free users…not customers. It is a hard path to sell your first 10...25…50…etc. customers, but the revenue from those customers fuels additional development and makes you a fountain of technology. Open source and free are great for getting big quickly and getting acquired, but it seems that if the acquisition doesn’t happen, then you can quickly run out of money using this model (see Xeround).

I realize that this is an unpopular position. I realize that everybody loves free. I realize that open source has additional advantages (no lock-in, rapid development, etc.), but in my opinion, open source works in only two scenarios: (1) where the absolute volume is huge, creating a funnel for conversion (e.g. Linux); (2) where you need to unseat an entrenched competitor and you have other sources of revenue (e.g. OpenStack).

I look forward to your comments. We also look forward to working with Xeround customers who are looking for another solution.

The Future of NoSQL (Companies)…

A friend recently bought a GM car. I proceeded to inform him that I am shorting GM stock (technically a put option). He was shocked. “But they make great cars,” he exclaimed. I responded, “I’m not shorting the cars, I’m shorting the company.” Why am I recounting this exchange? Because I believe that the new wave of NoSQL companies—as opposed to the rebranded ODBMS—presents the same situation. I am long the products, but short the companies.

Let me explain. NoSQL companies have built some very cool products that solve real business problems. The challenge is that they are all open source products serving niche markets. They have customer funnels that are simply too small to sustain the companies given their low conversion/monetization rates.

These companies could certainly be tasty acquisition targets for companies that actually make money. But as standalone companies, sadly, I would short them. On that note, I am off to the NoSQL Now! Conference. Hopefully, this post won't get me beat-up while cruising the conference.

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.