The tech media’s reaction to Coghead’s folding has bubbled up the perception that suddenly we cloud computing and platform-as-a-service vendors need to look at standardization, because businesses need to be able to move their “stuff” over from one vendor to another. While this is certainly an understandable desire, especially for those left in a lurch when their provider goes down, it is ultimately flawed this early in the game.

First, let’s talk “stuff.” If you mean by data, absolutely. As Facebook’s recent stumble has indicated, customers should be able to freely move their content. In fact, any application platform should have published APIs that are enable you to migrate data in and out of the system. And their code-based development should support industry standard syntax and logic like Java so at the very least, you can migrate custom logic and processing. But if you mean the applications themselves, which you could argue is the valued piece, that is going to take awhile.

Applications are a combination of data structures (or data models), processing, presentation, a range of interaction that works in concert with the existing platform. As such, every platform vendor has ways of adapting those structures to help businesses leverage as much of the pre-built platform as possible. For PaaS providers, the application modeling and framework are part of their magical sauce, often uniquely optimized for their operating environment, mixed with a large dose of customer requests, and added to that many late night hours of ingenuity. Why? Because there is no all-encompassing platform yet, but each step takes us closer.

Alan Zeichick of SD Times has a more sensible response to issues of standardizing the cloud.

Standards, hastily enacted, can stifle innovation. Cloud computing is in an early experimental growth stage. Sure, we have some well-entrenched early success stories, such as Amazon, Google and Salesforce.com, but it would be a potential tragedy to allow the early work of three companies to be codified as standards. We need time for their cloud offerings to shake out for a few years. We need time for new players to enter the market with new technologies – and new ideas. We need time to broaden the base upon which the standards are made to go beyond commercial interests.

To add to Alan’s point, as we build our platform, our job is never done. Companies are finding more and more uses for LongJump and with each new use comes a handful of new requirements — sometimes involving a change to our modeling and framework. It’s exciting because it’s making our platform richer, more robust and more sophisticated with every update.

If you asked us today to adhere to a standard, we would say: “for what… and whose?” It’s not like millions of companies are jumping online creating applications and abandoning their traditional architectures. At this point a cloud standard would be like asking companies like us to band together to set rules and speed limits and street etiquette before we’ve reached escape velocity. Yes, it’s safe, but completely impractical.

When WiFi was in its early stages (or the Internet for that matter), standards came about when adoption became wider. Adobe held PDF until it ensured that everyone could read it. HTML is still changing as new browser technology is introduced. You want standards? Help improve adoption of these platforms and lobby for the changes that will make them interoperable. Don’t hang up projects based on interoperability first.

And if you’re worried about lock-in, pick an application platform vendor that is willing to work with you on those issues. Talk to them. Give them a chance to address those issues, one-on-one. It’s still early and you can help define the platform you need. And that is better than any standard.