Sam Ramji said: "My team's focus has been on making sure that this platform treats open source development technologies as first-class citizens" and here are some of the quoted examples :-
- A developer using the Eclipse IDE can write a C# application that runs on Windows Azure
- Gallery, the leading PHP photo application, can access Windows Azure cloud storage
- A blog engine hosted on Windows Azure can authenticate users with OpenID.
This is excellent news but as I've said many times before, what we require is portability (or what I used to call patration)
In a service world, lock-in is not solved by interoperability alone. You require portability of your code and data from one framework provided by a large computing vendor, to another or to your own machines. This is my basic minimum in order for me to be happy with a cloud service.
This can be achieved with a closed stack (adopted by many providers) or an entirely open framework, however in the cloud computing world the frameworks (Azure, Google App Engine, Zembley, Jaxer, ReasonablySmart, 10Gen etc) are the potential standards that allow for portability & interoperability between these providers. This is what you need in order to overcome the current lack of second sourcing options.
In the service world, specifications and open standards are not enough. In a service world, standards need to be actual pieces of operational code. Whilst a "standard" can be a closed technology, it obviously creates dependencies of all the participants in a marketplace on the technology vendor who owns that "standard".
If you're going to compete on service, compete on service but don't try and convince us that either a proprietary technology is open because it uses some open standards or a proprietary technology doesn't create lock-in in the service world.
There will always be some CIOs who will rush head long into a gilded cage, I suspect most will be considering how to deal with second sourcing issues.
