Thanks to author George Reese--who wrote a thoughtful blog about open clouds and whose book Cloud Computing Architectures will be released in print next month (it's available now as an online RoughCut)--I learned about the bruhaha over an Open Cloud Manifesto. Let's put the debate in the context of some basic and perennial issues about openness and standards.
Update: George's book has been released.
You can take your data out of a cloud any time you want, and connect a server in one cloud to a server in another cloud just like any two servers on the Internet. So what's all this talk about openness? How would an "open cloud" look any different?
Obviously, people have different answers, but I think of an open cloud as a supercloud. Right now, virtualization and cloud computing mean you don't know (or care) where your server is geographically. In a supercloud, you wouldn't know or care which company was hosting the server. You could start servers on EC2 and tell them to move automatically to Azure if traffic slows on EC2.
But this simple description doesn't answer the question of whether such interoperability is desirable. I think it's possible. Sites could already choose to adhere to the Open Virtualization Format (OVF) proposed by VMware (who cloud support I reported on last October) and storage facilities could become interoperable using a distributed system like Cleversafe, whose advanced solution I reported on as far back as 2006.
Interestingly, I had a talk with George and some other people over the past couple days about a related issue, open text messaging. My boss asked me why open source advocates don't consider Twitter open, considering it has an API that lets you interact any way you want. I basically answered that an open system doesn't got down periodically. An open system in this case would be a distributed system, which is much harder to design.
The problem with sailing the seas of openness is that standards throw up a Scylla and Charybdis before you. Standards are absolutely necessary but quite risky.
You can impose a strong standard that everybody follows faithfully, and put a stop to all innovation until the standards committee meets again ten years later and updates the standard.
Or you can forget standards and compete in a free-for-all that offers new features every month but locks users in to whatever company they've chosen.
Or you can have the worst of both worlds: a never-maturing standard that companies half-implement, a standards committee constantly trying to catch up to implementations while trying to be all things to all companies, and ultimately a system that collapses under its own weight. This has happened in Fortran, CORBA, and too many other products.
There are other variations as well. Open source software solves some of the problems by allowing innovative extensions to be shared immediately, but one still has to deal incompatible features and backward compatibility.
So when can a standard co-exist with innovation?
How Can a Standard Promote Interoperability as Well as Innovation?
I think a standard works well when the designers, really, really understand what they're standardizing. It takes time. The designers must possess a kind of wisdom that lets them know exactly how what is accomplished by the system and how it achieves its goals. That lets them know the absolute minimum that must be standardized, permitting interoperability without cutting off innovation.
SMTP is an excellent example of such a standard. Its success has been imitated over the years by many other standards, including HTTP and SIP. The limitations and security weaknesses of email are infuriating, and I aired my wish for it be replaced nine years ago, but there are good reasons it's still the way most people use the Internet most of the time.
So let's take things slowly. Everybody acknowledges the value of interoperability, even Steven Martin speaking for Microsoft. His praise for "interoperability principles" isn't exactly a full commitment to interoperability, but I find it more significant than the manifesto's sweet-sounding phrases such as "an open cloud makes it easy for them to work with other groups." When we see a good standard, we'll probably know it because we'll wonder how it could be so simple.