But this cuts both ways: many of their clients don't immediately adopt new changes, and if we can provide a spec for what parts of the amazon api you have to stay within to obtain switch-ability with openstack, then we slow down the adoption of those new features.
The clients that are happy with lock-in and already on amazon aren't going to change to openstack anyway. But let's be clear, Amazon is not Microsoft, and I don't think this category is the dominant one. The market is growing and the biggest opportunity is for new adopters. It's valuable to openstack for some new adopters to have the option to switch back to EC2, because we are the newcomer. We also want to win some directly to the open APIs, and convert some once they get here by offering a better overall feature set in the open API. On 7/9/11 9:48 AM, "George Reese" <george.re...@enstratus.com> wrote: >The other piece of the puzzle is that it is very easy to keep a client >consistent with the API; it's very hard to keep an implementation >up-to-date. > >I've built an EC2 compatible API and the problem is that understanding >what has changed in the API (and it changes fairly frequently) is hard. >On the other hand, AWS is great at not breaking clients. So, when they >roll out a change, it doesn't impact clients; but anyone implementing an >EC2-compatible API will immediately be broken for clients taking >advantage of new features. Furthermore, it may not be entirely clear from >your end what it is that broke things. This email may include confidential information. If you received it in error, please delete it. _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
