Here’s why IT decision makers shouldn’t ignore Red Hat’s submission of the cloud neutral Deltacloud cloud API to the Distributed Management Task Force (DMTF) and Apache Software Foundation.

Deltacloud sputtered under a single vendor’s control
Deltacloud was announced nearly a year ago at the 2009 Red Hat summit. Brian Stevens, CTO and VP, Engineering at Red Hat described Deltacloud’s goal:

The goal is simple. To enable an ecosystem of developers, tools, scripts, and applications which can interoperate across the public and private clouds.

Today each infrastructure-as-a-service cloud presents a unique API that developers and ISVs need to write to in order to consume the cloud service. The Deltacloud effort is creating a common, REST-based API, such that developers can write once and manage anywhere.

A cloud broker if you will, with drivers that map the API to both public clouds like EC2, and private virtualized clouds based on VMware and Red Hat Enterprise Linux with integrated KVM.

Red Hat’s approach was simple and seemingly appealing enough. Write to the Deltacloud APIs and your workloads can be ported across any cloud provider’s infrastructure that Deltacloud is able to interoperate with. However, the prospects of trading cloud provider API lock-in for Red Hat API lock-in wasn’t an appealing prospect for potential Deltacloud adopters. Whether “The World’s Open Source Leader”, as Red Hat bills itself, or not, lock-in is lock-in.

Choosing open standards & open source for Deltacloud
Red Hat wisely decided to contribute their Deltacloud API implementation to an independent third party, the Apache Software Foundation. By moving the implementation to an Apache Incubator project earlier this summer, the Deltacloud project is no longer saddled with the chains of a single vendor controlled open source project. This in turn has made it easier for multiple vendors to consider adopting and contributing to the Deltacloud project.

Red Hat appears to be following the standardization through implementation approach, and has submitted the Deltacloud API specifications to DMTF cloud standards body.

Regardless of how successful Red Hat’s cloud and PaaS business results are, they will likely pale in comparison to the customer value enabled should Deltacloud become a widely adopted industry standard.  By leveling the cloud workload portability playing field, Red Hat is enabling other vendors to compete based on the quality and completeness of their PaaS offering rather than portability itself.

It’s encouraging to see that Deltacloud already allows a high level of portability across six different cloud providers, with support for two more providers on the way.

Bryan Che, Red Hat cloud product manager, explained the Deltacloud announcement:

We do not want Deltacloud to be under the control of any one particular vendor, including Red Hat. If you want true interoperability and true portability, you need a third-party governance structure.

On the other end of the spectrum are vendors such as Eucalyptus that have decided to adopt Amazon EC2′s APIs. Marten Mickos, Eucalyptus CEO explains:

We believe the Amazon API is becoming the industry standard, and that many companies will follow it.

Choosing defacto standards vs. open standards
Deltacloud’s success as the standard for controlling cloud operations is far from guaranteed. In the same token, Amazon’s EC2 API remaining the defacto standard is not guaranteed as cloud usage shifts from early adopters to the mainstream enterprise market. Enterprises have been increasingly educated to demand open standards for which multiple implementations exist. IT decision makers must weigh the short term benefit of adopting a cloud specific API, such as Amazon’s EC2 API, versus the long term benefit of a cloud agnostic API such as Deltacloud.

Comments

To be completely honest, none of Oracle’s plans come as a surprise.  And at the end of the day, the FAQ is not legally binding and is not a commitment to deliver products, code or functionality. Oracle clearly states this at the end of the FAQ.  This too is completely understandable.  Oracle, like any other company with shareholders, will have to evaluate and adjust their plans and intentions on a product by product basis over time.  Oracle has a fiduciary duty to do so.

In the FAQ, potentially released to appease the EU and critics of the deal, Oracle tackles its plans for MySQL as follows:

“Oracle plans to spend more money developing MySQL than Sun does now. Oracle expects to continue to develop and provide the open source MySQL database after the transaction closes. Oracle plans to add MySQL to Oracle’s existing suite of database products, which already includes Berkeley DB, an open source database. Oracle also currently offers InnoDB, an open source transactional storage engine and the most important and popular transaction engine under MySQL. Oracle already distributes MySQL as part of our Enterprise Linux offering.”

This position makes complete sense as MySQL and the Oracle DB are more complimentary than competitive.  I doubt that this assurance from Oracle will help Monty, Florian, RMS and others opposed to Oracle’s ownership of MySQL get past their fears.

Not unexpectedly, Oracle plans to keep GlassFish around, since it is the reference implementation for Java EE:

“Oracle plans to continue evolving GlassFish Enterprise Server, delivering it as the open source reference implementation (RI) of the Java Enterprise Edition (Java EE) specifications, and actively supporting the large GlassFish community. Additionally, Oracle plans to invest in aligning common infrastructure components and innovations from Oracle WebLogic Server and GlassFish Enterprise Server to benefit both Oracle WebLogic Server and GlassFish Enterprise Server customers.”

The plans for NetBeans are somewhat certain.  You’ll notice that Oracle makes no claims about “investing more than Sun does today” or “continue evolving”.

“As such, NetBeans is expected to provide an additional open source option and complement to the two free tools Oracle already offers for enterprise Java development: Oracle JDeveloper and Oracle Enterprise Pack for Eclipse. While Oracle JDeveloper remains Oracle’s strategic development tool for the broad portfolio of Oracle Fusion Middleware products and for Oracle’s next generation of enterprise applications, developers will be able to use whichever free tool they are most comfortable with for pure Java and Java EE development: JDeveloper, Enterprise Pack for Eclipse, or NetBeans.”

Finally, Oracle suggests that OpenOffice.org and a commercial offering will receive investment.

“After the transaction closes, Oracle plans to continue developing and supporting OpenOffice as open source. As before, some of the larger customers will ask for extra assurances, support, and enterprise tools. For these customers we expect to offer a typical commercial license option.”

So there you have it.  Oracle’s plans for Sun, well, based on current thinking and subject to change at Oracle’s sole discretion.  Which again, is perfectly sensible.

Comments

“Here at the amazing HAR2009 hacker conference + camp, I have the pleasure of operating a camp-wide GSM network.

Under license of the Dutch regulatory authority, we operate two BTS with two TRX each, forming the network 204-42. The BTS are positioned on the top of a hill, with the antennas mounted back to back on a tree, each covering about half of the HAR2009 camp site. Every transceiver runs at 100mW transmit power, which is the maximum output as per our license.

From that tree, we run AC power and a single E1 line down to the GSM tent, where it runs into the Linux PC that runs our OpenBSC software. “

For those of us who aren’t mobile phone networking experts, BTS stands for Base Transceiver Stations, TRX stands for transceivers and BSC stands for Base Station Controller.

OpenBSC is a GPL implementation of major components of a GSM network. Welte is one of the key developers behind OpenBSC, which aims to:

• provide a basis for experimentation and security research with GSM from the network side
• document, publicized and point out any security related issues that we find as part of that
• learn more about GSM networks on a lower level, particularly the practical aspects with real-world equipment

Unfortunately, the project is not interested in:

• building a stable/reliable BSC/MSC for deployment in actual networks
• building something that follows the GSM spec to the last detail
• disrupting actual commercial GSM network

Since a government issued network bandwidth license is required to run a GSM network in most countries, few of us will never run our own open source GSM networks.  Although it seems that countries like Russia allow the use of licensed frequencies for low-power indoor use.  So the title of this blog is squarely targeted at readers in Russia.  Kidding aside, I wonder while Welte and team aren’t interested in building a distribution that does fully implement the GSM specification.  The use of OpenBSC on Linux could be targeted at telecom operators in emerging markets.  Considering the growth in mobile phone usage in emerging markets, and network operator’s constant search for cost reduction, there could very well be a business here.

Any takers?

*Well, if you can get a government issued bandwidth license

Comments

“The GPL may be a community-building signaling device, but it is also a confession of fear and weakness. To believe that it matters, you have to believe that you live in a Type A universe where closed-source development is such an attractive proposition that you have to punish people for trying to move to it.”

The first reason has to be the big-bad Elder Companies.  It’s no surprise that Elder Companies prefer more permissive licenses such as the Apache license.  OSS startups fearing that their work will be hijacked by a larger vendor tend to select the GPL as a result. The validity of this fear has been called into question by the success of Oracle’s Unbreakable Linux.  Or imagine if MySQL had used the Apache license.  Would Oracle, Microsoft or IBM (or others) have been able to use MySQL’s IP to compete against MySQL?  Well, in theory yes.  In practice, just imagine the community uproar against an Elder Company that tried to fork MySQL.  Using the GPL for fear of Elder Companies is unfounded.

The second reason to use the GPL is to encourage customers and partners to pay for the open source software in question. Let’s only consider the situations where the customer or partner is seeking not to pay for the OSS.

Does the GPL encourage payment from a customer any more than the Apache license? I’d argue no. Very few customers create applications that are distributed outside of their walls.  Hence, there is no trigger for the viral nature of the GPL. A customer could equally choose to use GPL or Apache licensed software without paying the OSS vendor.

Does the GPL encourage payment from a partner any more than the Apache license?  In this case, yes.  The partner must choose to pay for a commercial, non-GPL, license or choose to license their own product under an open source license.  Since the latter is not the preferred route for ISVs/SIs, especially regional ISVs & SIs, the GPL does encourage payment more so than the Apache license would.  But there’s a catch.  The GPL would force this partner (that doesn’t want to pay or open source its product) to look at non-GPL alternatives.  When this occurs, the OSS vendor has lost a partner and end-customers delivered through this partner “forever” (as long as that is in the IT market).

The third reason is that the OSS vendor intends to leverage code from third party GPL projects.  Considering the amount of GPL projects out there today, this is a pretty strong reason for startup OSS vendors to select the GPL.

For me, reason #3 is, at this stage in the maturity of open source, the reason that the GPL will retain it’s dominance in the industry.  For better or for worse.

Comments