To echo what Ignasi said, I think we need to note that jclouds calls
itself "the Java multi-cloud toolkit." To find out what that means in
the face of some pretty big changes in cloud usage, I think we really
need to ask our users, but more on that in a different thread. To me,
the "multi-cloud" in that definition means a couple of things:
1. Providing useful, portable cloud abstractions that are relevant to
our users now and going forward
2. In APIs and providers, focusing on code that allows us to implement
those abstractions
3. Ensuring that APIs and providers, especially the most popular ones,
remain up-to-date and functional
4. Allowing jclouds to be used in as many JVM-based environments, with as few
implications for your code, as feasible
By extension, this also means:
5. Pulling in as few dependencies as possible, and in general imposing minimum
constraints on user code
6. Spending less time trying to support non-portable features in APIs
and providers (whilst being open to updating the portable
abstractions, or adding new ones, where justified!)
7. Spending less time supporting APIs and providers that are unrelated
to portable abstractions
8. Prioritizing issues or missing features in providers that are most
heavily used, rather than those you happen to be familiar with
9. Removing APIs and providers that no longer work
Taking into account the reality of limited resources, my suggestion
(concretely, for 1.9.0) would be to try to make jclouds as lean, mean
and easy to contribute to as possible:
* promote all providers and APIs that implement abstractions and are
in common use to jclouds/jclouds
* complete half-finished abstractions and discuss where existing
abstractions need to be modernized
* remove all deadwood providers and APIs
* create an "example PR" of how to add a new minimal provider or API,
using the "latest and greatest" jclouds dev practices (@nacx: would
the Abiquo re-impl be a good candidate?)
Regards
ap
