Open Stack

Folks,

I would like to throw my hat into the ring for the upcoming Technical
Committee election.

I've been involved in the OpenStack community for nearly three years,
starting off by becoming core on glance, before moving my focus mainly
onto the ceilometer project. Along the way I've landed a smattering of
commits across nova, heat, cinder, horizon, neutron, oslo, devstack,
and openstack-manuals, while contributing to the stable-maint effort
over multiple cycles.

More recently, I've served the ceilometer project as PTL over the Juno
cycle, and will be doing so again for Kilo.

I'm employed by Red Hat to work primarily upstream, but I also have
some perspective on the "sausage machine" that operates downstream in
order to put the technology we produce into the hands of users.

My motivation in running is to bring more perspective from a smaller
project to the deliberations of the TC, which I think already has a
tonne of large-project and cross-project perspective to draw on.
Balance is a good and healthy thing :)

As a community we have a big challenge ahead of us to figure out how
we respond to the growing pains that been felt in our governance
structure and cross-project resources. This has crystallized around
the recent layering and big tent discussions. My own feeling has
always been in favor of a big welcoming tent, but I'm less convinced
that a small blessed core is necessarily a corollary of such
inclusiveness. Before we radically alter the release cycle model
that's served us relatively well thus far, I think a critical eye
should be brought to the proposals; in particular we really need to
clearly identify the core problems that these proposed changes are
intended to solve.

And so, onwards to the stock questions ...

Topic: OpenStack Mission
========================

How do you feel the technical community is doing in meeting the
OpenStack Mission?

In all honesty, I would give us an A+ for effort, but more like a B-
for execution. In our excitement and enthusiasm to add shiny new
features, we sometimes take our eye off the ball in terms of what's
needed to make the lives of our users easier. I'm as guilty of this as
anyone else, perhaps even more so. But I think at this stage, it would
be of much benefit to our user community if we swung the pendulum
somewhat in the other direction, and shifted some focus onto easing
the practical challenges of operating our stuff at scale.

Topic: Technical Committee Mission
==================================

How do you feel the technical committee is doing in meeting the
technical committee mission?

Well, to be honest, if I thought this couldn't be improved, I wouldn't
be running for election.

On the one hand, I felt the gap analysis for already-integrated
projects was a good and healthy thing, and certainly assisted in
focusing resources over Juno on the areas where the TC saw
deficiencies.

On the other hand, I was quite disheartened by how some of the TC
discussions around project status played out. IMO there was a failure
of due diligence and mentoring. If we continue to have the TC making
important determinations about the future of projects (whether it be
their integrated status or their "production readiness"), then I think
we need to ensure that the TC keeps itself fully appraised from an
earlier stage about the direction that the project is taking, and
gives fair warning when it feels that a project needs a
course-correction.

Topic: Contributor Motivation
=============================

How would you characterize the various facets of contributor
motivation?

Most of my prior opensource experience was on various Apache projects
and in contrast it's striking that the OpenStack contributor community
is on the whole more skewed away from pure volunteerism, and towards
corporate contributors. By that, I mean contributors who are employed
by major operators and distributors of OpenStack, where their day-job
is to go forth and make it better. On balance, this is actually a
strength in our community. It certainly aids in the continuity and
sustainability of effort. It also helps ensure that less glamorous,
but ultra-important, efforts such as stable-maint and vulnerability
management get the attention they deserve.

However, despite this skew, I'm well aware that we're building a
"broad church" here. I think we all benefit from active efforts to
build diversity in our contributor community and harness the energy of
contributors with all kinds of motivations. Not just because it's the
right-on thing to do, but because it's the *smart* thing to do
... ensuring that we get access to all of the talents, especially from
previously under-represented groups. Towards this end, I continue to
support the efforts of programs such as the GNOME OPW and their recent
moves towards extending their reach to a wider set of contributor
backgrounds.

Topic: Rate of Growth
=====================

There is no argument the OpenStack technical community has a
substantial rate of growth. What are some of the consequences of this
rate?

It's clear that we're nearing an inflection point in our growth path,
where the ability of our cross-project concerns to continue scaling up
to meet the growing demand can no longer be taken for granted.

My instinct on this is to first examine how we organize those
cross-project concerns to see if the scalability ceilings can be
raised, before going down the route of rationing these cross-project
resources across a smaller set of projects.

Topic: New Contributor Experience
=================================

How would you characterize the experience new contributors have
currently?

To answer this question, I tried to project myself back to my own
journey up the on-ramp. It was of course a simpler time in terms of
the proliferation of projects and services, but the key elements have
mostly remained the same. 

Firstly, the good ...

One thing I found awesomely useful at the time was the ability to
easily spin up an entire mini-cloud in a VM and just get my hands
dirty, attempt to decipher the logs, snoop the messages passing
between services, peek inside the databases and so on. Given that we
rely on it so heavily in our day-to-day, it's easy to forget how
helpful devstack really is. I found it a massive leg-up, coming from a
scenario where setting up any kind of simulacrum of production was
quite a gnarly task.

I also found refreshing the willingness of various "old-timers" to
answer my dumb noob questions in a friendly and non-judgemental way.
We should never under-value this quality in our community, anyone who
in a past life has struggled with knowledge-hoarding will attest to
how open we are in this respect.

Next, the bad ...

We have a particular culture on gerrit were newbies sometimes feel
they're being ignored, or at least that their patches are not getting
the timely traction they expect. I know I fell into this trap myself
back in the day, where I followed up a git push with an almost
immediate full-court-press on potential reviewers via IRC. With
predictably counter-productive results. I think we could better
serve new contributors by setting more realistic expectations of
review turnaround from the very outset.

And finally, the ugly ... ;)

Ah yes, the old Contributor License Agreement that many of us love to
hate. TBH being required to sign this was more of an irritation to me
when I first encountered it, but thanks to efforts over the last
couple of cycles by some individuals on the TC, I now have a much
clearer perspective on the real and practical difficulties this
seemingly unnecessary legalism introduces for some contributors.
Needless to relate, I'd be fully supportive of the TC's continuing
efforts to replace the CLA with the Developer Certificate of Origin.

Topic: Communication
====================

How would you describe our current state of communication in the
OpenStack community?

We have many "official" vectors of communication: the design summit,
mailing lists, mid-cycle meetups, gerrit, logged IRC meetings and so
on. All of these have their strenghts and weaknesses, but as a
community we're learning to use and filter them quite well, despite
their firehose-like nature.

There is also an emerging trend for important discussions to be
initiated and developed outside of these official channels, e.g. via
ad-hoc discussions and blog posts. This is something I'm not so
enthused about, as it's harder for such channels to host a two-way
inclusive conversation.

Also, as in any technical community that I've ever experienced,
there's a lot of shared "tribal knowledge" sitting in peoples'
heads. I'm as guilty of it as anyone else, perhaps even more
so. That's just what happens day-to-day as the rate of knowledge
accretion surpasses the time available to codify it. However we all
need to try forcing ourselves to take the time to write such nuggets
down in a discoverable place, in order to provide a bread-crumb trail
for those who come behind us.

Topic: Relationship with the Foundation Board
=============================================

The technical committee interacts with the foundation board on several
different fronts. How would you describe these interactions?

Interestingly, the membership of these two governance structures is
somewhat intertwined. Obviously this presents challenges for the
individuals involved in both, in ensuring that they can "swap hats"
and context-switch appropriately. But it does at least ensure that the
board is not resting in an ivory tower, insulated from the day-to-day
technical leadership. In terms of the practical interactions that I've
seen, I was heartened by the robust approach of the TC in making their
preference to switch to the DCO crystal-clear and putting it up to the
board to deal with the CLA issue once and for all.

Cheers,
Eoghan