All your base are belong to Python

Got this delightful error today when writing an Open Cloud Computing Interface (OCCI) test harness in Python for Google App Engine:

Error when calling the metaclass bases metaclass conflict: the metaclass of a derived class must be a (non-strict) subclass of the metaclasses of all its bases

All your base are belong to Python. What more can I say?

On the Oracle acquisition of Sun Microsystems...

Ok so IBM dropped Sun on the floor only to have Oracle snap them up (surely a nice bidding war would have been the least they could do for a competitor?). Interesting, and I would say clever move, especially off the back of beating the hell out of cloud computing last year (another potentially more-intelligent-than-it-looked-at-the-time maneuver).

This acquisition touches many parts of the industry and the ramifications could be quite significant. Fortunately we're not all being alarmist about it and Ars Technica for one have good, balanced coverage in their Oracle buys Sun: understanding the impact on open source article (albeit with a pesky rel=shorturl link which is only marginally better than rev=canonical).

Here's a quick summary of what I think's going to happen:

• Sun will be saved what was probably going to be a fairly ugly few months/years potentially followed by a disappointing SGI style exit
• Oracle will quickly promote the interesting products and kill off the rest. In particular:
• End user hardware and software (desktop systems, OpenSolaris on the desktop, JavaFX, etc.) will go.
• Mobile related software will go - iPhone and Android have essentially won that battle and if Java's to have a stake it will be by way of another company.
  
• Sun Ray thin clients might survive because of Oracle's history with network computers (even if in a world of netbooks and nettops this probably isn't entirely sensible).
• Important (for us but not necessarily for them) products like OpenOffice could slip between the cracks, but more likely they'll go on the back burner and little will change.
  
• MySQL will survive, despite what the fear mongerers are saying. There's likely a lot of opportunity for them in the services, espeically if it can be made to play well with its new older step-brother. Nonetheless there will be renewed interest in other projects like PostgreSQL and Drizzle, which can only be a good thing for the rest of us. Let's not forget that it's been rocky for MySQL for a while so this change is probably better than many of the alternatives.
  
• Java will be cleaned and/or opened up as while Sun have been perhaps the only company not to have made a bunch of money out of it, Oracle don't have that concern and can only benefit (in terms of mindshare moreso than money) by further adoption. If not someone else will likely go and do it anyway and what's sure is that status quo is untenable. Will be interesting to see what role, if any, Apache Harmony plays.
  
• In terms of cloud computing the Compute/Network/Storage triple may be consolidated under the Q-Layer software, resulting in a compelling cloud computing infrastructure offering. Even if that's by no means guaranteed I reckon they'd do well to have a crack at it anyway. Virtualisation technology as well as middleware like their identity and systems management software will help here and the result could well become a force to be reckoned with. Oracle are no stranger to grid computing and have tech like OCFS floating around already, so between them and the Sun engineers they may have what it takes to pull this off.
• An Amazon EC2 competitor following on from the network.com offering may or may not still appear, but either way there will be similar offerings for their large enterprise clients.
  

All in all, if they play their cards right Oracle could well end up being a major cloud computing player along with the likes of Amazon, Google and Salesforce. We could all end up beneficiaries too by way of improvements to both Linux and Java, or it could go very badly wrong. I don't plan to think about it much more as there's little we can do but wait and see.

Introducing the Cloud Computing Stack (2009 Edition)

Those of you watching the Open Cloud Computing Interface (OCCI) mailing list over the weekend may have spotted the Resource Types: Compute / Network / Storage thread which the cloud computing stack was discussed. Although a little off topic it was useful for framing the first use case for OCCI (Cloud Infrastructure Serivces aka IaaS) and the result of the discussion was some refinement of my cloud computing stack that Wikipedia's cloud computing article (among other things) is based on.

There was some contention over the use of the term "fabric" for the bottom layer given it has also been used with platforms like Azure, so thanks to Alexis Richardson for suggesting the (obvious) "Servers" replacement. While not perfect I can't think of anything better, and it fits nicely with "Clients" at the top layer, making this a fully functional taxonomy for cloud computing.

Other changes include pushing "storage" down into the infrastructure layer and "services" into the platform layer (ignoring mashups and the like for the sake of clarity) and sticking with the application layer after considering changing it to "software".

It's available under the new Creative Commons Zero license (essentially public domain).

rel=shortlink: url shortening that really doesn't hurt the internet

 Inspired primarily by the fact that the guys behind the RevCanonical fiasco are still stubbornly refusing to admit they got it wrong (the whole while arrogantly brushing off increasingly direct protests from the standards community) I've whipped up a Google App Engine application which reasonably elegantly implements rel=shortlink: url shortening that really doesn't hurt the internet:

http://rel-shortlink.appspot.com

It works just like TinyURL and its ilk, accepting a URL and [having a crack at] shortening it. It checks both the response headers and (shortly) the HTML itself for rel=shortlink and if they're not present then you have the option of falling back to a traditional service (the top half a dozen are preconfigured or you can specify your own via the API's "fallback" parameter).

An interesting facet of this implementation is the warnings it gives if it encounters the similar-but-ambiguous short_url proposal and the fatal errors it throws up when it sniffs out the nothing-short-of-dangerous rev=canonical debacle. Apparently people (here's looking at you Ars Technica and Dopplr) felt there was no harm in implementing these "protocols". Now there most certainly is.

Here's the high level details (from the page itself):

Who
A community service by Sam Johnston (@samj / s...@samj.net) of Australian Online Solutions, loosely based on a relatively good (albeit poorly executed) idea by some some web developers purporting to "save the Internet" while actually hurting it.
What
A mechanism for webmasters to indicate the preferred short URL(s) for a given resource, thereby avoiding the need to consult a potentially insecure/unreliable third-party for same. Resulting URLs reveal useful information about the source (domain) and subject (path):
http://tinyurl.com/cgy9pu » http://purl.org/net/shortlink
Where
The shortlink Google Code project, the rel-shortlink Google App Engine application, the #shortlink Twitter hashtag and coming soon to a client or site near you.
When
Starting April 2009, pending ongoing discussion in the Internet standards community (in the mean time you can also use http://purl.org/net/shortlink in place of shortlink).
Why
Short URLs are useful both for space constrained channels (such as SMS and Twitter) and also for anywhere URLs need to be manually entered (e.g. when they are printed or spoken). Third-party shorteners can cause many problems, including link rot, performance problems, outages and privacy & security issues.
How
By way of <link rel="shortlink"> HTML elements and/or Link: ; rel=shortlink HTTP headers.

So have at it and let me know what you think. The source code is available under the AGPL license for those who are curious as to how it works.

CBS/CNET/ZDNet interview on cloud standards & platforms

Morning all,

I'm a bit too busy right now for putting together my usual meticulously crafted blog posts and random thoughts have found a good home at Twitter (@samj), so I thought I'd copy an interview this week with CBS/CNET/ZDNet on the emotive topic of cloud standards. As you know I'm busy putting the finishing touches on the Open Cloud Initiative and am one of the main people driving the Open Cloud Computing Interface (OCCI), where I'm representing the needs of my large enterprise clients... we're on track to deliver a nice clean cloud infrastructure services (IaaS) API next month as promised.

Anyway not sure when/if this will appear as I took a few days to respond, but here goes:

Questions:

1. Regarding infrastructure-as-a-service: Does the infrastructure matter? Whether it's on Amazon's EC2 for example -- does it matter where your app is hosted?

Cloud infrastructure services (IaaS) should be easily commoditised (that is, where product selection becomes more dependent on price than differentiating features, benefits and value added services), but this is not yet the case. At projects like Open Grid Forum's recently launched Open Cloud Computing Interface (OCCI) we are fast working to make this a reality (potentially as soon as next month).

According to the Open Cloud Initiative the two primary requirements for "Open Cloud" are open APIs and open formats. In the context of cloud infrastructure services that means OCCI (a draft of which will be available next month) and OVF (which was released last month) respectively. These open standards will allow users to easily migrate workloads from one provider to another in order to ensure that they are receiving the best possible service at the best possible price.

In the mean time providers typically differentiate on reputation, reliability and value added features (such as complementary components like Amazon S3 and SQS and network features like load balancing and security). 

 

2. Regarding platform-as-a-service providers: What sort of tools would you require, and what tools/services would help sway your vote toward one platform over another? 

 

Open standards (particularly for APIs and formats) are far more important for cloud platform services (PaaS) than any tools that a provider offers. The trend today (with providers like Amazon, Google, Salesforce and Aptana) is to extend the Eclipse software development platform. That said, I expect web based development environments like Mozilla Bespin to become increasingly popular - providers like Heroku are leading the charge here.

On the other hand cloud hosting offerings like Rackspace/Mosso's Cloud Sites could also be considered a cloud platform in that I can upload open source applications like Drupal and MediaWiki and they will take care of the scaling for me, billing me for what resources I use. I like this approach because I get the benefits of cloud computing but I could easily move to a competitor like Dreamhost PS becuase there is virtually no vendor lock-in.

Conversely, while an application written and optimised for Google App Engine will operate and scale extremely well there, it could be very difficult to move elsewhere thanks to the modifications they have made to the Python and Java runtimes. Note that many of these modifications are necessary to enforce security and scalability.

 

For example, Sun is coming out with a platform stack for the cloud, which will give developers common services to hook their Java apps into. Is this something significant? What else would you like or need from providers? 

 

That all depends on the environment they create and what interfaces they expose - a good test is how many existing Java applications will run on it without modification. Very few applications will run "out of the box" on Google App Engine but the modifications that need to be made should make the platform more scalable and cheaper overall than one running stock standard Java.

Sun's Simon Phipps sharply criticised Google earlier in the week, noting that "sub-sets of the core classes in the Java platform was forbidden for a really good reason, and it's wanton and irresponsible to casually flaunt the rules". That would lead me to believe that their offerings will be somewhat more compliant (and therefore enterprise friendly), but also somewhat more expensive.

One of the major sources of incompatibility here is the migration from relational databases (RDBMSs) to their cloud counterparts such as BigTable and SimpleDB. In order to enable massive scalability significant changes had to be made to core concepts and until we have an open standard interface for cloud databases (possibly following the examples of ODBC and DBI) interoperability at the platform layer will be challenging.

 

I'm also writing to providers like Amazon and Microsoft, to see if they have anything to add. :) 

 

Amazon are at the forefront of what I would call the "cloud operating environment". They offer a number of criticial "cloud architecture" components (most notably SQS queues and more recently elastic MapReduce services) which can be assembled together to create arbitrarily large, loosely coupled cloud computing systems.

Microsoft's Azure offering will also be interesting in that it is based on the Common Language Runtime. This will allow developers using their language of choice to target the platform, which has been something that has restricted Google App Engine to subsets of the developer community (first Python developers and now Java). It should in theory also be relatively straightforward to migrate from traditional architectures to their cloud platform.

Introducing rel="shortlink" - a better alternative to URL shorteners

Yesterday I wrote rather critically about a surprisingly successful drive to implement a deprecated "rev" relationship. This developed virtually overnight in response to the growing "threat" (in terms of linkrot, security, etc.) of URL shorteners including tinyurl.com, bit.ly and their ilk.

The idea is simple: allow the sites to specify short URLs in the document/feed itself, either automatically ([compressed] unique identifier, timestamp, "initials" of the title, etc.) or manually (using a human-friendly slug). That way, when people need to reference the URL in a space constrained environment (e.g. microblogging like Twitter) or anywhere they need to be manually entered (e.g. printed or spoken) they can do so in a fashion that will continue to work so long as the target does and which reveals information about the content (such as its owner and a concise handle).

Examples of such short URLs include:

• http://example.com/123
• http://example.com/3R (123 base32 encoded)
• http://example.com/csrf (title "initials")
  
• http://example.com/promo (manual slug)
  

The idea is sound but the proposed implementation is less so. There is (or at least was) provision for "rev"erse link references but these have been deprecated in HTML 5. There is also a way of hinting the canonical URI by specifying a rel="canonical" link. This makes a lot of sense because often the same document can be referred to by an infinite number of URIs (e.g. in search results, with sort orders, aliases, categories, etc.). Combine the two and you've got a way of saying "I am the canonical URI and this other URI happens to point at me too", only it can only ever (safely) work for the canonical URL itself and it doesn't make sense to list one arbitrary URL when there could be an infinite number.

Another suggestion was to use rel="alternate shorter" but the problem here is that the content should be identical (except for superficial formatting changes such as highlighting and sort order), while "alternate" means "an alternate version of the resource" itself - e.g. a PDF version. Clients that understand "alternate" versions shoult not list the short URL as the content itself is (usually) the same.

Ben Ramsay got closest to the mark with A rev="canonical" rebuttal but missed the "alternate" problem above, nonetheless suggesting a new rel="shorter" relation. Problem there is the "short" URI is not guaranteed to be "shortest" or indeed even "shorter" - it still makes sense, for example, to specify a "short" URI of http://example.com/promo to a user viewing http://example.com/123 because the longer "short" URI conveys information about the content in addition to its host.

Accordingly I have updated WHATWG RelExtensions and will shortly submit the following to the IANA IESG for addition to the Atom Link Relations registry:

Value:
shortlink (http://purl.org/net/shortlink)

Description:
A short URI that refers to the same document.

Expected Display Characteristics:
This relation may be used as a concise reference to the document. It will
typically be shorter than other URIs (including the canonical URI) and may
rely on a [compressed] unique identifier or a human readable slug. It is
useful for space constrained environments such as email and microblogs as
well as for URIs that need to be manually entered (e.g. printed, spoken).
The referenced document may differ superficially from the original (e.g.
sort order, highlighting).

Security Considerations:
Automated agents should take care when this relation crosses administrative domains (e.g., the URI has a different authority than the current document). Such agents should also avoid circular references by resolving only once.

Note that in the interim "http://purl.org/net/shortlink" can be used. Bearing in mind that you should be liberal in what you accept, and conservative in what you send, servers should use the interim identifier for now and clients should accept both. Nobody should be accepting or sending rev="canonical" or rel="alternate shorter" given the problems detailed above.

Update: It seems there are still a few sensible people out there, like Robert Spychala with his Short URL Auto-Discovery document. Unfortunately he proposes a term with an underscore (short_url) when it should be a space and causes the usual URI/URL confusion. Despite people like Bernhard Häussner claiming that "short_url is best, it's the only one that does not sound like shortened content", I don't get this reading from a "short" link... seems pretty obvious to me and you can always still use relations like "abstract" for that purpose. In any case it's a valid argument and one that's easily resolved by using the term "shortcutlink" instead (updated accordingly above). Clients could fairly safely use any link relation containing the string "short".

Update: You can follow the discussion on Twitter at #relshortcut, #relshort and #revcanonical.

Update: I forgot to mention again that the HTTP Link: header can be used to allow clients to find the shortlink without having to GET and parse the page (e.g. by doing a HEAD request):

Link: <http://example.com/promo> rel="shortlink"

Update: Both Andy Mabbett and Stan Vassilev also independently suggested rel=shortcut, which leads me to believe that we're on a winner. Stan adds that we've other things to consider in addition to the semantics and Google's Matt Cutts points out why taking rather than giving canonical-ness (as in RevCanonical) is a notoriously bad idea.

Update: Thanks to the combination of Microsoft et al recommending the use of "shortcut icon" for favicon.ico (after stuffing our logs by quietly introducing this [mis]feature) and HTML link types being a space separated list (thanks @amoebe for pointing this out - I'd been looking at the Atom RFCs and assuming they used the single link type semantics), the term "shortcut" is effectively scorched earth. Not only is there a bunch of sites that already have "shortcut" links (even if the intention was that "shortcut icon" be atomic), but there's a bunch of code that looks for "shortcut", "icon" or "shortcut icon". FWIW HTML 5 specifies the "icon" link type. Moral of the story: get consensus before implementing code.

As I still have problems with the URI/URL confusion (thus ruling out "shorturl") but have come around to the idea that this should be a noun rather than an adjective, I now propose "shortlink" as a suitable, self-explanatory, impossible-to-confuse term.

Update: I've created a shortlink Google Group and kicked off a discussion with a view to reaching a consensus. I've also created a corresponding Google Code project and modified the shorter links Wordpress plugin to implement shortlinks.

rev=canonical considered harmful (complete with sensible solution)

Sites like http://tinyurl.com/ provide a very simple service: turning unwieldly but information rich URLs like http://samj.net/2009/04/open-letter-to-community-regarding-open.html into something more manageable like http://tinyurl.com/ceze29. This was traditionally useful for emails with some clients mangling long URLs but it also makes sense for URLs in documents, on TV, radio, etc. (basically anywhere a human has to manually enter it). Shorteners are a dime a dozen now - there's over 90 of them listed here alone... and I must confess to having created one at http://tvurl.com/ a few years back (the idea being that you could buy a TV friendly URL). Not a bad idea but there were other more important things to do at the time and I was never going to be able to buy my first island from the proceeds. Unfortunately though there are many problems with adding yet another layer of indirection and the repurcussions could be quite serious (bearing in mind even the more trustworthy sites tend to come and go).

So a while back I whipped up a thing called "springboard" for Google Apps/AppEngine (having got bored with maintaining text files for use with Apache's mod_rewrite) which allowed users to create redirect URLs like http://go.example.com/promo (and which was apparently a good idea because now Google have their own version called short links). This is the way forward - you can tell at a glance who's behind the link from the domain and you even get an idea of what you're clicking through to from the path (provided you're not being told fibs). When you click on this link you get flicked over to the real (long) URL with a HTTP redirect, probably a 301 which means "Moved Permanently", so the browsers know what's going on too. If your domain goes down then chances are the target will be out of action too (much the same story as with third-party DNS) so there's a lot less risk. It's all good news and if you're using a CMS like Drupal then it could be completely automated and transparent - you won't even know it's there and clients looking for a short URL won't have to go ask a third party for one.

So the problem is that nowdays you've got every man and his dog wanting to feed your nice clean (but long) URLs through the mincer in order to post them on Twitter. Aside from being a security nightmare (the resulting URLs are completely opaque, though now clients like Nambu are taking to resolving them back again!?!), it breaks all sort of things from analytics to news sites like Digg. Furthermore there are much better ways to achieve this. If you have to do a round trip to shorten the URL anyway, why not ask the site for a shorter version of its canonical URL (that being the primary or 'ideal' URL for the content - usually quite long and optimised for SEO)? In the case of Drupal at least every node has an ID so you can immediately boil URLs down to http://example.com/node/123, http://example.com/123 or even use something like base32 to get even shorter URLs like http://example.com/3R.

So how do we express this for the clients? The simplest way is to embed LINK tags into the HEAD section of the HTML and specify a sensible relation ("rel"). Normally these are used to specify alternative versions of the content, icons, etc. but there's nothing to say that for any given URL(s) the "short" url is e.g. http://example.com/3R. That's right, rel="short", not rel="alternate shorter" or other such rubbish ("alternate" refers to alternate *content*, usually in a different mime-type, not just an alternate URL - here the content is likely to be exactly the same). It can be performance optimised somewhat too by setting an e.g. X-Rel-Short header so that users (e.g. Twitter clients) can resolve a long URL to the preferred short URL via a HTTP HEAD request, without having to retrieve and parse the HTML.

Another even less sensible alternative being peddled by various individuals (and being discussed here, here, here, here, here, here, here, here, here, here, here, here, here, here, here, here, here, here, here, here, here, here, here, here, here, here, here and of course here) is [ab]using the rightly deprecated and confusing rev attribute ala rev="canonical". Basically this is saying "I am the authorative/canonical URL and this other URL happens to point here too", without saying anything whatsoever about the URL itself actually being short. There could be an infinite number of such inbound URLs and this only ever works for the one canonical URL itself. Essentially this idea is stillborn and I sincerely hope that when people come back to work next week it will be promptly put out of its misery.

So in summary someone's got carried away and started writing code (RevCanonical) without first considering all the implications. Hopefully they will soon realise this isn't such a great idea after all and instead get behind the proposal for rel="short" at the WHATWG. Then we can all just add links like this to our pages:

<link href="http://example.com/promo" rel="short">

Incidentally I say "short" and not "shorter" because the short URL may not in fact be the shortest URL for a given resource - "http://example.com/3R" could well also map back to the same page but the URL is meaningless. And I leave out "alternate" because it's not alternate content, rather just an alternate URL - a subtle but significant difference.

Let's hope sanity prevails...

Update: The HTTP Link: header is a much more sensible solution to the HTTP header optimisation:

Link: <http://example.com/promo>; rel="short"

An open letter to the community regarding "Open Cloud"

I write this letter in order to be 100% transparent with you about a new initiative that could prove critical to the development of computing and the Internet: the protection of the term “Open Cloud” with a certification trademark (like British Standards’ Kitemark® and the FAIRTRADE symbol) as well as its definition via an open community consensus process.

Cloud computing users will soon be able to rest assured that offerings bearing the “Open Cloud” brand are indeed “open” in that critical freedoms (such as the right to access one’s own data in an open format via an open interface) are strongly protected. It will also ensure a level playing field for all vendors while keeping the barriers to enter the marketplace low. Offerings also bearing the “Open Source” mark will have additional freedoms relating to the use, modification and distribution of the underlying software itself.

Cloud computing is Internet (“cloud”) based development and use of computer technology (“computing”). It is the first significant paradigm shift since the introduction of the PC three decades ago and it is already changing our lives. Not only is it helping to deliver computing to “the other 3 billion” people, but also facilitating communication and collaboration, slashing costs and improving reliability by delivering computing as a utility (like electricity).

The Open Source industry is built around the Open Source Definition (OSD), which is itself maintained by the non-profit Open Source Initiative (OSI). The fledgling “Open Cloud” industry should be built on a similar set of well-defined Open Cloud Principles (OCP) and the associated Open Cloud Initiative (OCI) will closely follow their example. The proposed mission is simply “To define and protect ‘Open Cloud’” and the body will be developed from inception via an open process. Even if USPTO eventually reject our pending registration, by drawing attention to this critical issue now we may have already won.

I need your help, which is why I have called on individuals like Joi Ito and Bruce Perens, as well as established vendors including Google and Amazon (and their respective developer communities) for assistance. By way of this open letter, I commit to donate assets held in trust (domains, trademarks, etc.) to a non-profit similar in spirit to the Open Source Initiative which acts to protect the rights of the number one stakeholder: You.

Sam Johnston
Founder

Gearing up for the CCIF goat rodeo... and CC-Deathstar?

Morning all, and especially to those of you in New York who will shortly be meeting to discuss the fate of the Cloud Computing Interoperability Forum (CCIF). You have an important job to do and while an adverse outcome today wouldn't be the end of the world we have a lot of momentum and I don't know of anyone (myself included) that doesn't want this to work out. The formative phase is incredibly important to get right as it defines the trajectory of the organisation for its entire lifespan - if it's done badly we'll end up with another paper tiger ala the Open Cloud Manifestation... nobody will trust the result and another (bigger, more critical) opportunity will have been missed. There are plenty of smart people heading over there (many of whom I have talked to personally over the last days) and provided they can get a word in sideways I'm confident we'll have a good result.

First let's set expectations:

• I've given up hope of seeing any deliverables today. The closest thing perhaps is this UCI EC2<->ECP PoC and I don't see that as particularly interesting (I still haven't worked out what it is). That's disappointing after 6+ months but ok, we have what we have - no point crying over spilt milk when you don't walk away with whatever you had anticipated. Some draft documents (charter etc.) or even notes would be a deliverable of sorts and good inputs for the stage of actual formalisation.
  
• I don't expect to see any firm decisions made today. The group in New York is an (unbalanced?) subset of the CCIF that doesn't constitute a quorum (170 of 815 or ~20%, not all of whom aren't going to be members). It normally takes weeks to even start a working group and this is an arbitrary, self-assigned deadline... we can afford a brief window of discussion following this meeting and this doesn't have to be set in stone in order to produce useful work (despite FUD about IP problems which would be easily resolved by a click-through agreement). My intention here is that concise proposal(s) for charters et al be presented for refinement and ratification as would normally be the case rather than "shooting from the hip" with shows of hands and other subjective malarky. We've waited a year so another week to get it right won't hurt.
  
• I don't expect to see any announcements as we have nothing to announce (we don't, and if we do then seriously, what the FOCC were you guys doing running around behind our backs?). I definitely don't want to read about this event in the press, except perhaps in the context of a bunch of people coming together to make apple pie and discuss the form[alis]ation of a cloud computing interoperability and/or advocacy group.

Yesterday I heard the term goat rodeo used to describe the event and I think it's apt in the sense that today's meeting "requires about 100 things to go right at once if you intend to walk away from it" moreso than a "total mess, a chaotic or frustrating situation, often involving a large number of people attempting the same task". The unagenda (with an empty keynote slot!?) won't help (or will it?), nor will the fact that [at least half of] the "committee" (who I shall henceforth refer to as the "Power Rangers" given recent behaviour and contention over the "committee" moniker) has been found to have [had] a pre-conceived agenda. Putting smart people together in a room though tends to be productive and if nothing else it gets people in sync - it's just a pity we can't all be there (were it not for agenda clashes I'd have been there with bells on).

In many ways we're lucky to even have the opportunity to mould the process as there is no doubt whatsoever in my mind that were it not for ManifestoGate (already reported as an alliance) followed closely by the revealing of AllianceGate in A thinly veiled warning to the CCIF "committee"... then we'd have been going to see a[nother] pronouncement from Power Ranger Reuven about his long-running pet project, the Cloud Computing Alliance. I have a strong feeling that, while the "alliance" moniker may have been dropped the key elements (and in particular the stakeholders) remain. There's been a lot (too much IMO) of talk about the financial side of things, especially considering the amount of success often tends to be inversely proportional to the size of the budget, if web site sexiness is any indication (no offense):

• Internet Engineering Task Force (IETF)
• Web Services Initiative (WS-I)

I'm not disputing that we need some resources, but I'd much rather see us work out what it is we're doing and how it will be structured before starting to talk about who is going to fund it - the other way around is putting the cart before the horse and results in the early entrants having a significant advantage over the late ones (in the extreme case resulting in "founding" members being burnt into the DNA while others have to fight to stay involved, as was the case with WS-I). The Cloud Computing Community project has run on the smell of an oily rag and that approach is certainly one option for us which would eliminate any question of biases etc. Then you've got the shoestring-budget Cloud Camps which are wildly successful thanks in no small part to Dave (who tracks them around the globe and who I've developed a lot of respect for over the course of a series of conversations). In any case it would be better if the resulting group funded by sponsorships and events rather than membership fees if it's going to be truly open, as it well should be. The work that's been done in this regard is commendable and any potential sponsors who have offered support in the absence of something concrete are appreciated - thankyou.

Assuming we've decided we do need money, have some idea of how much and what we're planning to use it for (drawing up a rough budget would be an insightful exercise for today, including niggling details like roles and salaries) we then need to start thinking about where it will come from. Power Ranger Jesse has been transparent about wanting this to be a big budget affair, which suggests to me that a big budget has already been tabled. He was also quite adament about not needing assistance in the form of new Power Rangers which is something I think should be addressed today. There are plenty of people floating around with more relevant experience than both of us combined (and I've been working with various committees for the last decade or so) who have offered to be involved and I'd consider throwing my hat in the ring to help with building out the community (having done so already at Citrix). Putting together a list of potential participants would be a useful exercise too. Following the meritocracy model which has been so successful for open source organisations like the Apache Software Foundation with a light governance layer would be arguably more sensible than many of the alternatives but in any case looking at how different (successful) organisations are structured is an essential step.

The very last thing we need here though is a WS-I style CC-Deathstar, and I'm not the first to draw the comparison - see Out of Order 2.0 (about us) which follows on from Out of Order (about WS-I). Power Ranger Reuven's connections with IBM were clarified by manifestogate (plus they're drinking buddies), his link(s) to Cisco are bleeding obvious and Intel have recently stepped into the fray after being referenced on his blog. He's almost certainly stretched Microsoft's patience by calling them liars (then again he's also been burning bridges with Christopher Hoff from the Cloud Security Alliance, and essentially told me to FOCC off and do my own thing too, despite being one of the few active participants without blatantly obvious biases). OTOH you've got Amazon too who were recently interfaced to UCI (I'm not sure whether to make anything of that) but I expect the incumbents (Amazon, Google, Microsoft, Salesforce) to arms-length all this for now. This could (and hopefully will) change quickly if we get our act together. Finally there's also representatives from other $bigco's but it's not clear who is and who is not in Power Ranger Reuven's "Inner Circle" (I know I'm not, at least not yet, though things are improving). On the off chance that there was already an announcement to make around this following back-room negotiations I'd suggest sitting on it until we've locked down exactly what it is we're doing.

Finally you've got IEEE-ISTO, "a federation of programs that works to standardize technical implementations that span the spectrum of today’s electro-technologies" who are one of a number of groups who may be able to help us with organisational infrastructure. Their standards focus adds a tinge of WS-I and makes them the black sheep of the bunch given (in @ruv's eyes at least) CCIF is "a thought forum and advocacy group for cloud interoperability and related standards, it is NOT to be a standards body". This curious connection is probably another topic for discussion today as in my opinion there are better options out there who offer more in terms of existing members from both customer and vendor sides of the fence. In the very least there should be an open process to assess all the options, as there is value in relying on existing infrastructure so as to "hit the ground running" rather than trying to reinvent the wheel (albeit at a cost).

Anyway I hope you all have a good and productive day, aren't too hungover from CloudCamp (which sounded great from what I've heard) and that we get a good result at the end of it. Even if we don't there's many alternatives for us and no hard deadline.

On the CCIF unkeynote and open cloud community

On a more serious note Reuven Cohen's taking the stage for an unkeynote at the Cloud Computing Expo in New York City, in which he will drop the original topic (Unified Cloud Computing, which got dangerously close to revealing reveal some "acutal work" linking Amazon EC2 with Enomaly ECP) in order to talk about, wait for it... the future instigation activation creation of a group that has already existed for the best part of a year... a process which I am told by someone who should know will take 6-12 months.

That's right folks, even though it's April Fool's day, this one's for real - he's actually going to get up on stage and "publicly ask for the support of the greater community in the creation of a completely new kind of cloud computing trade association", which will be "focused on the marketing and advancement of cloud computing industry", save that the majority of the 800 or so Cloud Computing Interoperability Forum (CCIF) members won't be there.

Smells like yet another old school trade association to me, especially since one of the committee told me yesterday that it would have to be a 501(c)(6) organisation (Business Leagues, Chambers of Commerce, Real Estate Boards, etc.) in response to my raising the issue yesterday. Forgive me for being cynical after all that's happened this week, but that's just the Cloud Computing Alliance they were planning to dump on us up until yesterday with a slightly different wrapping.

On Thursday at the CCIF Wall Street event they plan to go over the details again including Governance (e.g. @ruv's official post-Instigator title and what to do with the money), Goals, Platform and Marketing Efforts, in an otherwise vacuous agenda. Once again the actual CCIF community over here will learn about the outcome in a blog post diligently pasted into the group a day or two later and will almost certainly not be given the opportunity to contribute. In fact if I understand yesterday's update well, the most contentious issues (such as a to-be-announced relationship with IEEE-ISTO) have already been decided by the self-appointed leadership team who lack the mandate to do so.

My point is not to criticise them for the sake of it, rather to encourage fellow community members to critically assess what is forced down their throatsproposed for creating a truly open cloud computing community. This is something I've been working towards all along (ironically, against the very people who now propose it) and something I for one have a lot of experience with. While I'm glad Reuven's finally on board with the "open cloud community" idea (a "melting pot" where both users and vendors come together to share ideas") I'll be disappointed if he claims it as his own (like the manifesto which did more damage than good.

Let's take our time and make sure we get this right - the Thursday "deadline" is arbitrary and self-imposed and getting some actual deliverables would be far more beneficial. If this is mishandled the repurcussions have the capability to be far worse and longer-lasting (WS-Deathstar anyone?).

CCIF Forked: CCIF for Commerce spins off

This is entertaining enough to be an April Fool's day joke, but alas it's not. Sure enough, the Cloud Computing Interoperability Forum (CCIF) has forked, though that's not the best of it: there's absolutely nothing that the "real" CCIF can do about the insolent Cloud Computing Interoperability Forum for Commerce spin-off. If you want to be part of the fiasco you can apply for membership.

Even if CCIF had a trademark for it's name (it doesn't), and a legal entity to strap it to (it doesn't) this is a European based "initiative" that would be outside of reach of the long arm of the USPTO. CCIF for Commerce claims to have offices all over the place so getting it to drop the use of the term could well be quite complicated - notwithstanding the many months it will take to set up the infrastructure and register trademarks (as you know I've been following trademark issues around cloud computing since Dell tried to co-opt the term last year).

Started by Jason Meiers of "XMPP is too stuffy" fame, it's being actively pimped on the basis of "added trust and setting expectations correctly". They've already been told to cut it out by Reuven Cohen (self-appointed "Instigator" of CCIF) but he's essentially been told to sit and spin.

The gags keep rolling in...

Update: Or should that be CCIF FOCCed? ;)