Open Stack

On Fri, 20 Apr 2018, Doug Hellmann wrote:

> [This is meant to be one of (I hope) several conversation-provoking
> questions directed at prospective TC members to help the community
> understand their positions before considering how to vote in the
> ongoing election.]

Thanks for getting the ball rolling on some discussion, Doug.

> Without letting the conversation devolve too much into a discussion
> of Adjutant's case, please talk a little about how you would evaluate
> a project's application in general.  What sorts of things do you
> consider when deciding whether a project "aligns with the OpenStack
> Mission," for example?

This is an important question because project applications are one
of the few ways in which the TC exercises any direct influence over
the shape and direction of OpenStack. Much of the rest of the time
the TC's influence is either indirect or limited. That's something I
think we should change, in part because I feel the role of the TC
should be at least as, if not more, focused on the day-to-day
experiences and capabilities of existing contributors as it is on
new ones.

I prefer that we keep a large human factor involved in the
application process. I do not want us to be purely objective because
such a process can never take into account the wider and ever
changing world. The members of the TC can be human info sponges that
do that accounting. The current process was created in part to
overcome the far too heavy and nitpicking (and human) previous
process but it has resulted in what amounts to a dilution in
direction.

For me, each application tends to result in a lot of questions such
as the list I produced on patchset 34 of the Adjutant review[1]. I
worry that we are predisposed to accept applicants out of a general
sense of being "nice" and a belief that growth is a sign of health.
I'm unsure how these behaviors help to drive OpenStack in its
mission, but while the rules [2] say something as broad as

      It should help further the OpenStack mission, by providing a
      cloud infrastructure service, or directly building on an
      existing OpenStack infrastructure service.

I feel we're painted into something of a corner where acceptance
must be the default unless there are egregious interoperability or
"four opens" violations.

I'd like to see us work harder to refine the long term goals we are
trying to satisfy with the projects that make up OpenStack. This
will require us to continue the never-ending discussion about
whether OpenStack is a "Software Defined Infrastructure Framework"
or a "Cloud Solution" (plenty of people talk the latter, but plenty
of other people are spending energy on the former). And then
actually follow through: using the outcome of those discussions to
impact not just projects that we accept but also where existing
project focus their attention. We need to be as capable of saying
an informed "no" as we are of saying "yes".

In the modern OpenSource world there are so many different
ecosystems that are cloud friendly: We don't need to provide a home
for everyone. There are plenty of places for people to go, including
the many different (and growing) facets of the OpenStack community.
I would prefer that we be assertive in how we evaluate for alignment
with the OpenStack mission. Doing that requires fairly constant
re-evaluation of the mission and a willingness to accept that it
does (and must) change.

[1] https://review.openstack.org/#/c/553643/
[2] https://governance.openstack.org/tc/reference/new-projects-requirements.html

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent