The dangers of early "formalization"

If you've been watching cloud computing at all, you've undoubtedly seen the whole brouhaha over the Open Cloud manifesto. I won't recount it here, mostly because - frankly - I can't tell what's actually going on there anymore. So and so said one thing, while thanking so and so, who declined to comment on three organizational....BLECH!What I will say is this: Gluecon, as you all know by now, is not YACCE (yet another cloud computing event). We've got plenty of YACCE's and 90% of them will be dead within 18 months (bet on it). But, cloud computing the topic is a big part of what we want to talk about at Glue (even if it's only one part). And, now that I've seen several people and articles mention the idea that this whole open cloud brouhaha points to the need for a "formalization of the standards process" around cloud computing, I want to throw in my 2 cents.First, a quick caveat: I'm not an engineer. If pushed, I can stretch my limits of programming into writing one line of code for active server pages. As such, I've never sat on a body that writes standards. I have, however, been involved with them (I was an active member of the Liberty Alliance for some time), and have been an observer of "standards" for some time. The "standards" that inform my thoughts on this include things like RSS, XML (or more properly, XML-RPC), all of the liberty alliance specs, jabber (xmpp), OpenID, XRI and XRD (now XRDS, or something), and the mess that was/is WS-*.That said, here's my part-gut feel, part observer experience of it all:"Formalizing the standards process" only ever does one thing well -- SLOW DOWN ADOPTION.That is not to say that formalized standards processes (and bodies) don't have their place. They do. But they shouldn't be formalized at too early a stage, as they do only one thing really well (say it with me) -- SLOW DOWN ADOPTION. The reason they slow down adoption is really quite simple -- if I'm an "enterprise guy" that's looking at adopting cloud stuff, I don't want to have to adopt things 3 or 4 times because my budgets are scarce, my time is even more scarce, and screwing up something like this will get me fired. As soon as some group of vendors says, "we're forming a body to formalize the standards process," my reaction as the enterprise guy is to say -- "whoa, brakes time!" As it's much easier for me to delay my adoption by 6, 12 or 18 months. And I can do so under the rational thought process of -- "by waiting, I'll ensure I adopt a standard."Of course, there's not a single cloud vendor on the planet that wants to see adoption of their products slow down.So what's a cloud vendor to do? Realize that it's not about "formalizing standards," it's about driving adoption.RSS didn't succeed because it was standardized. It succeeded because it was adopted. The same thing goes for XMPP. And the inverse hold true as well - organizations like the liberty alliance have ended up largely giving in to other standards because theirs weren't being adopted in the ways they'd hoped for. Similarly, there's an awful lot of heat around OpenID, and folks there will claim adoption -- but we have yet to really see it ignite.My point is: real "standards" come about through adoption first, and a formalized process second. Not the other way around.Notably, Amazon, Google, Salesforce.com and Microsoft are among those absent from the open cloud manifesto. Does that pose an "adoption problem?"-- oh yea.Look, the big guys are gonna jockey for position, and I don't care WHAT they say, they're always going to want to preserve some sort of angle for themselves. Always. That's the nature of the beast.Without a "formalized standards process" will the cloud go through a proliferation of differing "standards" and a period of confusion and lock-in? Of course. But I'd still argue that going that route leads to faster adoption than formalizing the standards process too early.Am I wrong? Well, we're gonna find out (and you can show up at Glue and tell me so).