Open Stack

On Fri, Apr 14, 2017 at 12:55 PM, Jeremy Stanley <fungi at yuggoth.org> wrote:
> It's intentionally ambitious, yes, because we want to inspire and be
> inspired to great achievements.

I generally don't think that that approach works for a large
community, except in the rare cases of where you have both an utterly
awe-inspiring goal and a one-sentence definition of what "done" means
— like "before this decade is out, land a man on the moon and return
him safely to the earth" —, but I fully appreciate that people will
strongly disagree with me on that one. So let's not get into that
discussion. :)

> At the same time, the comment period
> and public review process are totally about getting some grounding
> in reality from the community, keeping us honest with ourselves as
> to what is or is not a reasonable goal (seeking exactly the sorts of
> analysis you've provided here). We want to be sure both that our
> choices of focus reflect the people we've been elected to represent,
> and that those same people can see some possibility for reaching
> these goals.
>
> So to turn this around, if we were to keep it at a 2-year vision
> do you believe we should lower our target metrics or reduce the
> number of things we're seeking to accomplish through the technical
> community (or a bit of both)?

I don't like to think in "target metrics", but looking through the
draft there are several items which look like ambitious 2-year goals
by themselves:

- Constellations. This is an extremely impactful goal where, I
believe, some organizations with entrenched business practices would
take 2 years to come aboard *even if upstream had already completely
decided right now.* OpenStack distributions as offered by vendors are,
currently, normally general-purpose, and to tailor this to specific
reference architectures is a massive undertaking for an organization
(including its support engineers, QA/QE people, presales, and sales
people). Consider that the vision draft talks about a world where
constellations already "have become the new standard way to start
exploring
OpenStack." If in 2 years constellations are already meant to the new
and accepted standard, that requires all hands on deck right now.

- Multi-language outreach. Yes we do have OpenStack and
OpenStack-related code in other languages like Go and Erlang, but
adjacent communities perceive OpenStack as primarily a Python project.
Many non-Python OpenStack SDKs were lagging behind the Python ones for
so long that they were barely usable, and we need to win back a lot of
trust from non-Python communities even after "Go, Nodejs, or Java"
support is on par with, or comparable to, Python. Again, if you want
to convince those communities that they are now first-class citizens
in OpenStack land, that would take 2 years by itself, I'd imagine.

- Adjacent communities, and using OpenStack code in non-OpenStack
environments. The vision calls for "thinking differently about
adjacent communities". Again, this is a massive community-wide
undertaking, and much more easily said than done. Yes, some projects
(Swift comes to mind, as does Ironic) have made a conscious effort to
be valuable independent of an OpenStack environment. In others, we've
seen an effort that has since died down somewhat — the last time I
heard serious discussions about standalone Heat, for example, was in
2014.

Now, you could argue that it's a big community, we can do all those
things in parallel. Parallelization is problematic to take for granted
in collaboration (cf. Fred Brooks, The Mythical Man-Month, 1975), but
even if we assert that it can be done (with a lot of effort), then it
only makes sense for goals that do not run counter to each other.
Constellations are all about standardization, which cuts down on
flexibility, multi-language outreach is the opposite. Incorporation of
OpenStack code into non-OpenStack projects is also counter to
standardization, or rather requires going by the rules of said
projects, not OpenStack, and thus again runs counter to the goals of
constellations.

My humble opinion here is pick one goal. As for the others, you'll
have to see how they play out. Then, in two years, reassess and pick
the next goal. Thus, to answer your question, I'd say reduce not the
number of things you're seeking to accomplish through the technical
community, but through the explicit guidance of the technical
*committee.*

Cheers,
Florian