I mean, I get that it can be as valuable to define something by what it isn't as by what it is. But I am struggling to understand the recent he-said/she-said debates over what does and does not constitute "cloud computing."

As with "Web 2.0" (and here is my take on that debate) such an ephemeral tag was bound to engender some disagreement at some point over exactly what it was. Unlike Web 2.0, however, which was only ever really useful as a marketing or a look and feel tool, cloud computing is about the guts of the systems, and so it's as much an engineering debate as a marketing one. The question I keep running up against, though, is: is it a useful engineering debate?

I don't think it is. The post that seems to have set all this off is on James Governor's Monkchips blog entitled 15 Ways to tell it's not Cloud Computing. Other than certain vendors who have a vested interest in the marketing implications of the term, I'm not sure who should care if a solution is or isn't a "cloud" as long as it works. And don't get me wrong, I like Cohesive's (the vendor linked to above) vision of cloud computing and I think it's a valuable approach which will ultimately prevail in the market, but I think it sells itself on those merits. I don't see the need to defend the terminology. It might even backfire, as it seems to for IBM's Mark Cathcart, who reacts here to the same post. Cathcart's point is that a good solution is a good solution; 15 arbitrary restrictions on what you call it just seem petty and petulant.

All of the responses that I have seen so far have been reacting essentially point by point to the 15 items that Governor mentioned, but I think despite that limitation I have seen the seeds of a better and less provocative definition of cloud computing.

Cloud computing:

• Relies on elasticity (as Chris Petrilli excellently puts it), the ability to rapidly scale up and down
• On ease of use, or a "retail experience" for consumers as Cohesive explains it
• On non-specificity... you shouldn't have to know what sort of application you are going to build in it, or even necessarily what platforms you will use to build it with.

If you want to define it down past that, it seems to me that you are simply trying to co-opt the term for your own purposes rather than to use it handily to refer to what the community can seem to agree on for the concept. I think it's probably inevitable that people will do so, both for marketing purposes and out of that general need that geeks seem to have to pound details in the ground, but there is really no need to take a perfectly useful, broadly scoped term and try to turn it into an IEEE specification. Like Web 2.0... you know cloud computing when you see it.