Does the cloud really need a manifesto?

IBM's Open Cloud Manifesto is all the rage, but it needs a ride on the cluetrain if it's ever to amount to anything

The open cloud manifesto sparked debate and speculation in just about every corner of the Internet. "Did IBM purposely structure the document with an anti-Microsoft bias?" "Why did Amazon and Microsoft both roundly reject the document?" "Why are there so many companies that have seemingly nothing to do with the cloud boasting their support?" They're all ultimately superficial and irrelevant.

"Manifestos" have a somewhat sordid history in the tech world. They word used to indicate that a monarch, government, or political party was issuing a declaration of intent. Now it seems to mean some geek has something to say online.  Since 1985 there have been manifestos on every topic from cyborgs to the GNU project, cyberfeminism to the origins of the Windows Powershell -- some good, some bad, all entertaining. What I want to know is why the author of the open cloud "manifesto" is getting so much attention from the press? Is it just because it uses the words "cloud" and "manifesto" in the same title? Why is it stirring up speculation and rumor among the techno-political crowd?

[ A question left unanswered by the manifesto: Is cloud computing inherently evil? ]

For the unaware, we're talking about a bloated eight-page PDF (that could be easily trimmed to two) with a very basic structure:


What is Cloud Computing and Why Is It Important?

Challenges and Barriers to Adoption

The Goals of an Open Cloud

Principles of an Open Cloud


Obviously, the important section is "Principles of an Open Cloud." While cracker-jack bloggers waste time on the hidden agendas of the various corporations for and against this proposal, I'd like to examine the proposal itself. I think the author needs a good whack with the clue stick.  Maybe I can help.  I'd like to rebut the six "principles of an open cloud":

  1. Cloud providers must work together to ensure that the challenges to cloud adoption (security, integration, portability, interoperability, governance/management, and metering/monitoring) are addressed through open collaboration and the appropriate use of standards.
  2. Cloud providers must not use their market position to lock customers into their particular platforms and limit their choice of providers.
  3. Cloud providers must use and adopt existing standards wherever appropriate. The IT industry has invested heavily in existing standards and standards organizations; there is no need to duplicate or reinvent them.
  4. When new standards (or adjustments to existing standards) are needed, we must be judicious and pragmatic to avoid creating too many standards. We must ensure that standards promote innovation and do not inhibit it.
  5. Any community effort around the open cloud should be driven by customer needs, not merely the technical needs of cloud providers, and should be tested or verified against real customer requirements.
  6. Cloud computing standards organizations, advocacy groups, and communities should work together and stay coordinated, making sure that efforts do not conflict or overlap.

I find these mildly interesting and mostly depressing. Yet again we're treating cloud computing like a shiny new technology or some new magic that needs to be regulated in the open. All enterprise technology should benefit customers by addressing issues through "open collaboration in the appropriate use of standards." Many attempts to adhere to this principle have been made in the past -- some have succeeded; most have failed. I'm going to go out on a limb here and predict that any attempt to apply this principle in the spirit of this document will result in flaming failure fueled by the political infighting of the various companies that have signed on to be open.

I don't think number two is particularly realistic either because cloud providers see the ability to lock customers in as one of the most attractive features of the cloud market in the first place. Without vendor lock-in, they'd have to compete on ridiculous metrics like SLAs and customer satisfaction to keep customers. With vendor lock-in, they only need to get customers to put their valuable information into the cloud once and then make it nearly impossible to get it back out again.  That's a no-brainer to most vendors.  You think your manifesto is gonna make that all better?

Speaking of duplication (number three), there have been several efforts in the recent past to accomplish exactly this goal. Remember the open call from 3tera to move "toward a cloud computing standard"? It's absolutely true that the "IT industry has invested heavily in existing standards and standards organizations." But most of these "standards" weren't followed in the first place.  There are a few examples of successfully implemented standards like TCP/IP, but the graveyards are littered with the bodies of hundreds of standards created by companies hell-bent on making their standard the standard.

On to number four.  Being "judicious and pragmatic" is an honorable goal, to be sure.  Again, totally unrealistic. Some say the W3C has been very "judicious and pragmatic" with regards to technologies like HTML; many would argue it's stifled real innovation in the process. There are some very compelling arguments about the role of standards in facilitating innovation. When done right, everything can work out beautifully. Sadly, we love to create new standards, but we rarely get it remotely close to right.

What makes the cloud so special as to be the only recipient of the special treatment outlined in number five? Why aren't all software products tested and verified against real customer requirements? Like the rest of this silly rag, this is just good practice.  What does it really have to do with cloud computing?  Is this a cloud computing wish list? A best practices manifesto?  Who cares, we've finally gotten to number six.

The utopian vision espoused by number six won't last a hot minute in the real world, if ever even implemented in the first place.  I wish it weren't so, but simply involving competing corporations dooms number six from the get-go. Harsh, I know, but oh so true.  And still I'm asking, as I read this little gem-child of our Internet age, "Why cloud computing?"  Besides the denotation of the name, what puts the cloud above other technologies whose lack of openness and collaboration cause daily user pain and suffering? 

I'm bewildered why the author even published this in the first place. This is no Declaration of Independence for cloud computing; it contains no earth-shattering call for revolution. It's another paper tiger.  It's that sad, sinking feeling (i.e., reality) that another self-promoter is "pushing the future of cloud computing!" as a tool to level the playing field they know will soon be dominated by the larger, more aggressive companies in this space. Author, if you really want to make an impact, you'll get back to us with some substance specific to cloud computing.  Which, by the way, you avoided defining like a matador -- my final gripe before my two cents are up.  The following passage opens the second section, "What is Cloud Computing and Why Is It Important?"

In order to understand the core principles of an open cloud, we need to first agree on some basic definitions and concepts of cloud computing itself. First, what is "the cloud?" The architecture and terminology of cloud computing is as clearly and precisely defined as, well, a cloud. Since cloud computing is really a culmination of many technologies, such as grid computing, utility computing, SOA, Web 2.0, and other technologies, a precise definition is often debated.

While definitions, taxonomies, and architectures are interesting, it is more important to understand the value propositions for cloud computing. 

Allow me to paraphrase: "First, we need to agree on some definitions. Alas, those are hard!?! No one agrees. Next paragraph: While definitions are interesting, let's skip to the value-prop...."  Genius.  You can't even tell us what you're declaring your intentions about.  Manifesto consumed; still hungry.


Copyright © 2009 IDG Communications, Inc.

How to choose a low-code development platform