This makes a lot of sense. I have heard of other approaches to try and map to cloud API's, but none that are open source, and non from large companies that can back it up, get wide usage, and stick with it, like Red Hat.

This is a very welcome project for those of us looking at how we best utilize cloud without getting locked in to one cloud vendor, or one specific technology at a cloud vendor or inside our own IT.

I suspect many others that are trying to make $ in the cloud wave won't like this, since it diminishes their lock-in. They should remember what happened with AOL, CompuServe, and The Source, who all had captive online communities in the early days, and how the "opening up" of the Internet caused an explosion in usage and value for end users around the world.

This cloud market is interesting for open source since it is the first major market wave where open source is being "assumed" to be part of the solution.

Interesting, but not really. This is just trying to homogenize API differences. It takes us a couple of days to write a client for a new cloud API, that's not where the difficulty lies. The real challenge lies in the semantics of different clouds. Like what can you do with a server? Does the cloud have disk volumes? Can you snapshot them? Can you attach them to multiple servers at a time or only to a single one? Can you have multiple IP addresses on one server or not? *That's* where the real challenge lies, not in argument list differences in API calls.