If there was an annual prize in the PR industry for the best press release about a “Turkey really looking forward to Thanksgiving”, then it should be won by the PR from Cloud.com as it announced its participation in OpenStack. Cloud.com’s only asset is an GPL-licensed Open Source IaaS Cloud platform which it sells under “Open Core” licensing (more on this below). If OpenStack succeeds, this asset is worthless.
However, if you look a little closer, it is clear that the canny investors at Cloud.com have a plan – just before the company becomes completely worthless, sell it for ridiculous amounts of money to Citrix. Surely that won’t work?
Cloud.com had lined itself up with Citrix by using only XenServer in the commercially-licensed version of its IaaS product, and now is being used by Citrix to ensure OpenStack supports XenServer (which it doesn’t at the moment), presumably to keep Red Hat’s KVM under control and VMware out.
It is still necessary to find a way of paying the salaries of the developers of the software. That said, we do hold out a lot of hope for the success of the OpenStack platform, because in a certain sense the salaries are already covered (NASA has US Government funding, and Rackspace – which in development terms will be a junior partner – pays its development team as 3rd-line support).
The other thing to bear in mind is that Open Source community models can end up being fantastically productive through the way developers self-select (only the good ones have the brass neck to get involved), self-organize (without any expensive management)and peer-motivate (impossible deadlines get met by the application of appropriate amounts of caffeine). Open Source projects can, however, be a nightmare to manage if you care about such things.
We’ve also been trawling through the available OpenStack documentation to understand why NASA thinks its cloud is more scalable than Eucalyptus. One does really wonder exactly how scalable this layer has to be, given it is a management layer, not an end-user transaction layer, it’s not a shared filesystem or similar shared resource, and you can expect to partition the cloud into physical geographies at some level. However NASA clearly needed something on the PR to justify its 30 Million VMs headline.
It seems to be all to do with how the state information is passed amongst the various servers that make up the system. Where possible they use a message queue, and although they claim the system is “shared nothing”, this applies at the hardware and base O/S level, there is a minimal layer of shared state (as you would expect) that needs to be kept cache coherent. User authentication is via LDAP (or an LDAP stub), and LDAP replicates and scales up to a point.
There’s been a lot of noise in the Open Source community about OpenStack, particularly about the break with Eucalyptus. A lot of this has been focused on the Eucalyptus business model, and perhaps misses the key point which is actually buried in the legalities of Open Source, the distinction between permissive and non-permissive licenses.
Paradoxically, the license the Open Source community loves most known as Gnu Public License, GPL, is non-permissive in the sense that you cannot combine GPL code with other code without inheriting GPL for the entire resulting codebase. However, if you actually own the IPR, you don’t need to license it exclusively under GPL, you can issue it under another license as well, and (in a model typically known as Open Core) you are free to add features to the commercially-licensed version without the resulting codebase coming under GPL. This means the IPR owner is in a preferential state to the licenses in commercializing the IPR, because licensees must issue such products under GPL.
GPL-based Open Core models break down when you move to multi-vendor foundations because the cross-licencing of IPR under GPL immediately infects the recipient codebase, and precludes commercial licensing of the resulting combined work. The result is that the GPL Open Core business model doesn’t work in the same way, and both Eucalyptus and Cloud.com cannot apply their current business model in these multi-vendor foundations.
All the other main Open Source license families, including the Apache 2 license used by OpenStack, are permissive, which means that both the licensor and the licensee are able to operate a dual licence Open Core model, and cross-company foundations can exist without requiring all consuming products to be open source. In this sense they are much fairer because they don’t preference the IPR originator, you are effectively giving away the IPR irrevocably for any recipient to use any way they see fit.
One of the peculiarities of all this is that Cloud.com is consuming the Object Storage platform in OpenStack (they had no comparative layer themselves), and because it is being licensed under Apache 2, OpenStack can issue it under a commercial license.
From the NASA side, the problem was that the NASA team couldn’t contribute to Eucalyptus under GPL because Eucalyptus couldn’t take it on that basis without breaking their dual license, so either NASA assigned IPR to Eucalyptus (which they weren’t really allowed to do, given it was US Government funded for the benefit of mankind), or they forked the Eucalyptus codebase and continued to maintain the fork, effectively cross-porting changes from the Eucalyptus codebase into its own version of that code in its repository.
So, NASA said to itself “none of this Eucalyptus stuff is Rocket Science, we can do something better if we write it ourselves and maintain it ourselves, and actually that is lower risk for us because our funding timelines are fairly long-lived and these guys at Eucalyptus could go bust any minute if the Venture Capitalists pull the plug.” And that was the end of that.
It is a big blow for Eucalyptus. They have turned their biggest potential customer into a massive and credible competitor, built in their own image (only – at least from a PR perspective – much more scalable). The reason why this is rumbling around the Open Source community so much is that the purists all hate the dual-license Open Core models, and the OpenStack split with Eucalyptus is seen as a clear rejection of those models. As early adopters these people matter, and it is likely Eucalyptus will never recover its street credibility.
And so to the question of API standards. The Nova API in OpenStack is, like the Eucalyptus APIs, based on the Amazon EC2 APIs. There are (as we mentioned in a previous post) two APIs both web-based, one SOAP and one Query-based. The latter is (incorrectly, and not by Amazon) sometimes referred to as a REST API, but they are both just simple wrappers around a traditional programming language APIs.
Meanwhile the Rackspace REST API which we talked about in a previous post is now on the way out, but DMTF has been receiving other submissions for an API standard. Oracle has made its submission public. It is based on an earlier Sun proposal, and it is the best API we have yet seen. Furthermore, Oracle has identified a core subset to allow initial early adoption, as well as areas where vendors (including themselves and crucially VMware) may continue to extend to allow differentiation.
In OpenStack the API is implemented in a separate service which translates external HTTP requests into commands across the internal message bus, and so it looks (on the face of it) possible for someone (preferably Oracle) to implement the Oracle DMTF submission as a separable new API server module without disrupting the OpenStack architecture.We don’t expect Amazon to be happy about it, but it would come into line (likely keeping its own implementation rather than adopting OpenStack as a codebase, and maintaining its own extensions).
When Cloud.com decided to join Openstack, we understood that some people might confuse the effort as a competing effort to our own. After engaging with the team and understanding the dynamics of commercial vs. community, we were convinced that this was the right thing to do and that vendors that chose not to participate would be damaged in both the short and long run. I’ve created a response to your blog here: http://cloud.com/main/company/blog/on-competition
Hi Peder,
Thanks for responding. I am absolutely clear that it was the right thing for you to engage with OpenStack – after all I engaged with the Eclipse Foundation in my previous company, and indeed was on the Eclipse Board of Directors for many years. I maybe gave you a bit of a “kicking” in pursuit of a good headline.
I’d like to have the opportunity to hear the story from your perspective and to put together another piece for our readers.
Regards,
Mike