A few clarifications are in order:

* Microsoft, IBM, Nirvanix, Rackspace, and GoGrid didn’t just endorse the API; they committed to contributing to it. All of them have made commits (well, Rackspace in their own repo for now :) ) except GoGrid, who will contribute their adapters as they roll out application services.

* We intend to recruit more corporate contributors, along with the community that has already begun to form around the API. Stay tuned.

* Most of the co-founding contributors were involved with the naming of the project. We came up with ‘Simple’ after considering a few other candidates. I think that we came up with something that is descriptive of the API, which captures the common features among vendors and is therefore inherently simple. It also seems to appeal to PHP developers who have warm fuzzies about projects such as SimpleXML. I’m not sure how many PHP developers could even tell you what SOAP stands for. :) Even fewer care. :D

* I’ve never seen it referred to as ‘SCA’, and I personally wouldn’t use that acronym myself. We have referred to it internally as ‘SCAPI’, but I haven’t seen that acronym yet in the wild.

* IMO, the technologies SCAPI (I’ll put it out there and see if it sticks. ;) ) is built on are sound: PHP, Adapters to Zend Framework, Zend Framework, the internet, remote APIs of the services, and the services themselves. But you’re correct. It could be shaky at the adapter level because of all the differences in the APIs. And I’m not just talking about method signatures. Every one of them has limitations on names, data, functionality, etc.- as well as subtle behavioral differences- that SCAPI will have to address if we can claim that it makes portability among vendors a matter of simple configuration changes. This is the hard part. And we need input on this: http://www.simplecloud.org/forum.

Ultimately, our goals are humble: create a PHP API that allows developers to use application services from different vendors, along with exposing the differences in cloud offerings before the developer gets burnt. But our motivations are as simple as the API itself: we have to start somewhere.

Thanks for the write up, and we’re looking forward to more of your insight on the API and the cloud in general.

,Wil