Open Stack

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.