Greetings OpenStackers,
I would like to announce my candidacy for the OpenStack Technical Committee.
I have worked closely with the TC since around the time that Heat was
incubated, two years ago. I have been a regular participant in TC
meetings throughout the Juno cycle as the Heat PTL, so I am familiar
with the current structures and procedures, their back-story, and the
issues that are before the committee.
I think I can best contribute by digging deep into issues, rooting out
the points of contention or misunderstanding and building consensus from
there. If you follow openstack-dev closely you'll probably have seen me
doing that quite a bit already. I don't claim to have all the answers,
but I'm pretty good at asking questions.
The OpenStack project has been incredibly successful in building a
strong community where people want to collaborate on solving problems
for our common users.[1] We are at a point where we need to readjust the
structure of the project to better respond to the next phase of that
success. This is not the first time we have reached such a point; nor
will it be the last. There is no final form of the OpenStack project; we
must approach it as we would any engineering problem (_not_, I hasten to
add, a technical problem): by considering our goals and opportunities,
making incremental changes, evaluating their effects (both intended and
unintended), and repeating.
I believe we need to work to reduce entropy in the OpenStack system -
encouraging shared components and implementations over repeatedly
reinventing the wheel - without crushing innovation. Those two goals are
in tension (note that the wheel has been repeatedly reinvented
throughout history, often to great effect), but they are the ones I will
be trying to balance. And we must, of course, do this while giving
operators and end-users confidence in their investments in the OpenStack
ecosystem.
I think making it easier for projects to join the OpenStack community
would be a good thing, provided that still entails a commitment to doing
things the OpenStack way backed up by meaningful oversight by the TC.
I'm comfortable for now with leaving a high bar for graduation in place,
though it needs to move around less. While I am in favour of more
projects in principle, I'll be scrutinising specific projects carefully
to make sure that they've either been able to apply the feedback part of
the engineering process I described above with real users, or
alternatively have solved the simplest possible version of their design
problem with a view to maximising their flexibility to respond when they
do get that feedback.[2]
What we're really missing are stepping stones from the lower incubation
bar to the high graduation bar. We need to do more to help projects
understand how they can fit in to the bigger picture and what they need
to do to get there.
That will require greater involvement from the TC, but it appears we
have already reached the point where the TC itself does not scale. That
was evident from the Zaqar's second graduation review. One year after
its incubation, the TC was still debating whether an SQS-like cloud
messaging service was most comparable to AMQP, XMPP or SMTP[3] (hint:
none of them[4]), and in the end deferred for another six months to
figure it out. It's clear that TC members don't have the time to dig
deeply into all the issues that cross their desks. I already proposed a
structure whereby subcommittees in each general subject area, comprising
a representative from each of the relevant projects plus one TC member,
would do the investigation and mentoring of new projects and report the
results to the TC.[5] In this model the TC would be responsible for
setting an overall vision for the project and ensuring that it is
applied consistently. I would welcome other proposals that could help to
expand and deepen support for new projects in a way that can scale
through our next stage of growth. (I am also a strong supporter of
having formal liaison programs to boost the impact of horizontal,
cross-project functions without stretching them to breaking point.[1])
As we're figuring out structural changes I think we need to be careful
to decouple short-term technical issues, like how to scale the gate to a
larger number of projects that don't all have mutual dependencies, from
longer-term structural issues. We also need to be very aware of how
changes we make might be perceived by external parties not sharing the
same context, including the Foundation Board and especially the DefCore
subcommittee. Finally, we need to remember that our users see the cloud
from many different perspectives and that no single perspective can
capture what is important to our community.[5]
Answers to the TC Election questions are below. I'm happy to answer any
other questions folks have too, in an open forum of course.
cheers,
Zane.
[1]
http://lists.openstack.org/pipermail/openstack-dev/2014-August/043583.html
[2]
http://lists.openstack.org/pipermail/openstack-dev/2014-September/046563.html
[3]
http://lists.openstack.org/pipermail/openstack-dev/2014-September/045788.html
[4]
http://lists.openstack.org/pipermail/openstack-dev/2014-September/046934.html
[5]
http://lists.openstack.org/pipermail/openstack-dev/2014-September/047025.html
TC Election Questions
=====================
(from
https://wiki.openstack.org/wiki/TC_Elections_October_2014#TC_Election_Questions)
* How do you feel the technical community is doing in meeting the
OpenStack Mission?
(The mission is here, by the way:
https://wiki.openstack.org/wiki/Main_Page just in case you don't have it
committed to memory.)
I think we all have a lot of work to do on several fronts: - "simple to
implement" and "massively scalable" in particular. But I'm very
optimistic that work will get done because we have built a healthy,
thriving community to do it.
* How do you feel the technical committee is doing in meeting the
technical committee mission?
(That one is here:
https://wiki.openstack.org/wiki/Governance/Foundation/TechnicalCommittee)
I think the TC is doing a good job at encouraging the OpenStack ideals,
but I think the size of the project as a whole has overwhelmed its
capacity to provide _active_ technical leadership. We need to build up
that capability.
* How would you characterize the various facets of contributor motivation?
I wouldn't, but since you ask... OpenStack is not a hobbyist project. No
major open source project is. The vast majority of contributors are able
to contribute because it is benefiting their employer somehow - either
because they have a problem to solve directly with OpenStack, or because
they are selling something complementary to OpenStack. We need to make
contributing as easy and pleasant as possible, so the first group will
contribute at all and so the second group will contribute as much as
possible in their long-term interests and not only in their short-term
interests.
* There is no argument the OpenStack technical community has a
substantial rate of growth. What are some of the consequences of this rate?
The biggest and most important consequence is that we have lots of
talented contributors working hard on solving real problems that our
users have, and doing it in the open, the OpenStack way. Another is that
we've outgrown some of the centralised shared resource structures that
made sense in a smaller project. We'll need to work on decentralising
and building communication paths.
* How would you characterize the experience new contributors have currently?
I would have to guess frustrating. The process starts badly with a bunch
of hoops to jump through culminating in the CLA. At least the first
patch is greeted with a friendly, helpful "Welcome new contributor"
message. From there we should keep in mind that the experience differs
from project to project. The smaller ones are probably doing OK for the
most part, but the larger ones are struggling to provide the timely
feedback that new contributors need. In some cases that's exacerbated by
overly-bureaucratic processes and review nitpicking (which could be
summarised as a generally procedure-focused rather than results-focused
outlook).
* How would you describe our current state of communication in the
OpenStack community?
We communicate a lot, and in the open, which is great. The hard part is
filtering the fire hose. As we decentralise even more, we'll need to
mitigate that problem by establishing fixed (rather than ad hoc)
channels of communication, so that people hear about the things they
need to without getting swamped. The Oslo liaison program is one great
example of how to achieve this.
* The technical committee interacts with the foundation board on several
different fronts. How would you describe these interactions?
Getting the TC and the Board on the same page on any issue is a big
challenge, because the combined group is *huge* (~30 people). Discussion
inevitably moves slowly at that scale, and the Board doesn't tend to
hold wide-ranging open discussions between meetings the way the TC does
on openstack-dev. Cultivating relationships is important, but most of
the work will continue to get done by joint subcommittees.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
