By contrast, I think that the concept of Interoperability is significantly in need of expansion. As if often said, the great thing about standards is that there are so many to chose from. Simplicity is not an sufficient differentiator. Security is a great example: sending passwords in the clear is the “simplest” solution, but generally viewed as a non-solution. Google’s solution is simple: as long as everybody has a Google Account, everything “just works”. It may work, but it is an anti-pattern in terms of openness. Worst: security is never a one size fits all: what is appropriate for Bank of America may not be appropriate for a wiki.
Additionally, simple standards also often compose in weird and unexpected ways. For this reason, interoperability requires more than a set of principles, it requires a set of profiles and testing tools. Start small, pick something like OAuth, and expand over time into areas such as integration, portability, interoperability, governance/management, and metering/monitoring.
P.S. SamJ: one other anti-pattern: use of iPaper and Flash to publish open letters.
Thanks for sharing your thoughts - your comments are insightful though we have already considered some of the points you have raised. Mentioning Open Source (and now Open Data too) is important to make it clear what we do (and don’t) do, especially for businesses who might otherwise be quick to pigeon hole us as “free software advocates” (which I am by the way, just an objective one).
I tend to agree with you in that it’s all about the APIs and the data, and if we were to define “Open Cloud” to include Open Source and Open Data then we would immediately exclude the overwhelming majority of the current cloud computing ecosystem. It’s still important to draw attention to these “residual issues” so as people know where they stand when it comes to freedom (e.g. that “open cloud” is not a panacea)
We are also in the process of setting up “whitelists” of pre-approved APIs, formats, data and software which will could develop into something like profiles, though it’s hard to imagine that testing would become part of our mandate (except perhaps in the context of certification for trademark use).
If you have some spare cycles we would love to have you on board, even if just for the initial discussion around beating the OCP into shape.
Sam
PS The use of iPaper and Flash was a pragmatic one. If you looked closer you would have seen that they fall back to PDF and OGG respectively, but we’re not going to exclude most users to prove a point just yet!
Oh and one more thing... I happen to have a finger in the other projects you listed too. You can find “open” versions of the Bill of Rights and Manifesto here: [link] and I’m upto my neck in trying to get CCIF into a sensible state (but pretty close to giving up to be honest).
Windows Azure and Cloud Computing Posts for 4/6/2009+
Windows Azure, Azure Data Services, SQL Data Services and related cloud computing topics now appear in this weekly series. Note: This post is updated daily or more frequently, depending on the availability of new articles. § Item repeated from...
Nice. Thanks for the many hours of my life you saved.
So in addition to your commentary above (seconded by Oakleaf) which we’ll take into account, you could keep an eye on the discussion (which should [hopefully] be fairly lightweight) but more importantly have a pass over the resulting document.
GAE doesn’t require the use of Google Accounts. You have fully access to the HTTP headers, so you can do any kind of authentication you want. It is totally open. They just give you an easy head start.
The real problem with authentication is not a lock-in around Google Accounts, but the difficulty in massive provisioning of SSL/TLS for the applications. Since (classicly) virtual hosts under SSL are IP-based, then Google would need a unique IP address per hosted applicaton. That just isn’t doable. As a result, strong forms of authentication are not possible on your domain. If you run your app on appspot.com, then SSL is available.
There are design changes to allow SSL to avoid IP-based virtual hosting, but I’m not sure what the browser penetration is for that capability.
You are, of course, correct. I was mixing concepts. Google hosts a lot of applications “in the clouds”, and requires Google Accounts to access same. Applications like Google Docs, Google Groups, GMail...
strong forms of authentication are not possible on your domain.
The on your domain is an excellent point that I haven’t seen mentioned in any of the cloud proclamations. Any web-facing cloud will produce pages that are linked. In many cases the links are as valuable as the content itself. Requiring one to change links when one changes providers is therefore a barrier to exit.
A the IETF meeting last month, a new form of authentication was discussed. If implemented by a few browsers, I could see it spreading quickly.