A few weeks ago, IBM pushed the Open Cloud Manifesto, a document that was supposed to lay the tracks for openness and interoperability in cloud computing but which was rejected by the industry’s major players. Google, Amazon, Salesforce.com and Microsoft all said “thanks but no thanks” to the document. Microsoft’s objection stemmed from the fact that the supposedly open manifesto was drafted behind closed doors and presented “as is,” with no chance for other parties to have their say.

But even if the manifesto is flawed — and the industry consensus seems to be that it is — the idea is important. Interoperability requires not just standards compliance today, but a unified approach to evolving those standards and for coping with incompatibilities as they occur in the future. Addressing interop on a day-to-day basis just isn’t enough.

We’ve seen this movie before: the W3C has been defining Web standards for almost 15 years, but it’s still a headache to write CSS and JavaScript code that works in both Firefox and Internet Explorer. Today’s cloud vendors should strive to make sure the same isn’t true of different cloud services in the next decade.

For its part, Microsoft looks like it will have a strong product when it rolls out the final version of Azure. When I spoke to Steven Yi, Microsoft’s director of product management for the Azure Services Platform, he noted that Azure is designed specifically for the cloud, meaning that it handles scaling and multiple instances behind the scenes. In contrast, the Amazon Elastic Compute Cloud (EC2) provides VMs closer to the metal; this gives developers more control potentially, but it also means they have to create their own scaling mechanisms and communication between VMs, Yi said.

On the interoperability side, Azure is in a good position for now. It runs non-.NET technologies like PHP natively, and developers can expose their services over several standards, including REST and SOAP. Azure services themselves conform to these standards, Yi said, and developers can configure applications hosted on Azure to communicate with end users via a browser, on-premises servers or even other clouds. At MIX09, for instance, Microsoft showed the Azure Service Bus connecting to the Google App Engine.

But it looks like the long-term interop vision is to keep a short-term vision indefinitely. When I asked Yi how he thought the cloud manifesto should have been drafted, and what Microsoft would like to see in it, his answer raised a red flag.

“I don’t necessarily think there needs to be a manifesto as long as we’re delivering on customer needs” and interoperating with other services, he said. Yi emphasized that Azure is standards-compliant and that the company is constantly talking to its developers.

That approach is working for now, but it doesn’t leave much room for the inevitable differences that will arise between cloud computing platforms. Vendors will always push the envelope in different directions, and some interoperability problems are fine, but vendors should at least agree on a way of settling their differences within a generation of two of their occurrences.

Cloud computing vendors pledge that interoperability is important to them, and so far the system is working relatively well. But it’s also in its infancy. It won’t be long before vendors start coming out with new innovations — a fix to the overly verbose XML-based communication that most services now use, for instance — that will threaten interop in the cloud.

Nobody was ready for breakthroughs when they came to Web browsers, and now we’re all scrambling to glue the eggshells back together. We should demand that cloud computing service vendors stop the next egg from breaking before it’s too late.

First, the good news: IE8 is a major improvement over its predecessor. It’s faster, has plenty of handy features and comes with built-in developer tools. We covered IE8′s developer tools a few months ago, when it was still in beta; some of its new security features include recognizing malware sites and graying out all but the top level domain (TLD) in the URL bars, which will make it easier to notice phishing attacks. Chrome enthusiasts will be interested to learn that IE8 borrowed one of Chrome’s most compelling features: each tab is now a self-contained process, so a crash on one page won’t take down the whole browser.

The browser is also more compliant: Microsoft says it passes all of the 7201 tests it came up with and submitted to W3C, the body that sets Web standards.

But IE8 also has three new features called Slices, Accelerators and Visual Search. These enable sites to repackage themselves in interesting ways. For instances, IE8 sports a toolbar similar to the menu bar for Slices, which act as minature Web sites; clicking on one of these buttons shows its content, which can contain anything from news updates to an in-depth search field. It’s all very cool, and only IE8 supports it.

And that’s the kicker: Slices, Accelerators and Visual Search aren’t standards compliant, because IE8 is the only browser that supports them. Yes, they’re all based on standard XML; but that only takes you so far. That takes us to the real question: are the W3C’s standards the ones that count, or the de facto standards set by browsers?

The point of standards is to simplify development. HTML, CSS, JavaScript and the rest should be “write once, run anywhere,” to borrow Java’s infamous mantra. The best way to do that is to agree on the standards and then write software to match them: Microsoft has done that for CSS, but its unilateral introduction of Slices, Accelerators and Visual Search show that realpolitik is still very much alive in the browser wars.

My guess is that browsers will never be fully compliant, and that’s a good thing. If each browser were really compliant — if it rendered the standards perfectly and nothing else — there’d be very little room for experimentation and progress. Any competition between browsers would be solely on speed, security and stability. Those are all great goals, of course, but it’s also nice that browsers are looking for ways to push the envelope.

What’s important is that we go back every once in a while, see what’s worked, and standardize it before moving forward again. And that’s what Microsoft has done with IE8.