Yes, it is currently focused on openstack clouds, but the goal is to reach parity with Fog (ruby), jclouds (Java), Libcloud (Python), pkgcloud (node.js), and so on.
The focus is a series of clean abstractions for users to be able to build tools and programs which can talk across any cloud provider easily using a common set of names / abstractions.
fwiw. goose is LGPL.
I'm at a bit of a toss up re LCD between clouds vs exposing the underlying functionality of the clouds. The LCD apis (libcloud from experience) break down with real world usage even for simple things like net security groups, or zones spec into provider specific usage. It seems like most cross cloud apps ends up needing to redefine the abstraction layer within itself rather than attempting to reuse the same LCD code across clouds at which point its not clear that the LCD layer isn't a limitation to taking advantage of a native cloud functionality.
The LCD issue is being resolve in libcloud - we have multiple FT devs working on it right now, and does not come up as an issue with Fog, jclouds, or pkgcloud. It's possible to make an abstraction that is simple enough to start but powerful enough to access the advanced features of each individual cloud host.
I hope users and consumers will keep us honest - as we said in the post, our interest is pretty much no lock-in on an API level (hence: openstack) and no lock-in on the code level. We really want to make tools that allow our users and others to fluidly move between hosts.
I want to add some context to this.
Our current abstraction provides a relatively simple API which is guaranteed to work across multiple providers.
If you want to access provider specific functionality we offer so called extension methods and arguments. This is similar to how jclouds and other cross-provider libraries handle that as well.
We support over 30 providers and for the more popular ones this means you can usually access most of the native cloud functionality through the base API + extension methods.
Doing that will obviously make it harder and more work to switch between different providers so we always put up a disclaimer and make sure our users are aware of that.
We are trying to standardize as many APIs as possible and promote extension methods to the to top level API (proposals and patches are always very welcome and appreciated!), but sadly in a lot of cases this is not possible. Usually this is because the provider APIs are too different and the glue code needed to make it work would be to complex.
In the end it's a trade-off, pretty much like everything else in life and a lot of other things in CS (CAP anyone?).
If you want good portability and easily switch between providers you will stick to the base API. If you don't care so much about the portability you will also use the extension API.
Side note: Even though official provider client libraries exists, a lot of people still tend to use Libcloud with extension methods.
Usually the reason is that we support a variety of Python versions and we have a stricter testing policy which tends to result in less buggy code.
"I hope users and consumers will keep us honest - as we said in the post, our interest is pretty much no lock-in on an API level (hence: openstack) and no lock-in on the code level."
any api is a lock-in, openstack just happens to be opensource in implementation, but per google v. oracle, there doesn't seem to be any qualms in other opensource impls using the amazon apis (cloudstack, eucalyptus) to deliver what customers want without lock-in.