Open Stack

My name is Maru Newby, and I am announcing my candidacy for the
Technical Committee (TC) election.

tl;dr;

I'm a relative unknown outside of Neutron, but I've been helping to drive
high-level change in that project. I would welcome the opportunity to bring my
energy and dedication to OpenStack-wide concerns as a member of our TC.

If you're willing to read any part of this email, I hope it would be 'Why vote
for me?'.

If not, and you are as frustrated with the status quo as I am, I hope you will
consider voting for candidates that support the goal of building a more engaged
TC focused on ensuring that participation in OpenStack becomes more enjoyable
and sustainable.

Thank you for reading, and make sure to vote!


* Why vote for me?

If elected, I'm going to be a squeaky wheel advocating for anything and
everything that empowers our development community to deliver useful software
into the hands of users.  If this puts me at odds with those that want to focus
on issues like 'What is OpenStack' or 'How can we systematize project culture to
make it easier to communicate?', good!  I believe that you, as a technical
contributor to OpenStack, need stronger representation of your viewpoints on our
TC, and I'm one of the strongest advocates you're likely to find in this
community.  I am currently employed full time upstream, and I am willing and
able to devote the resources necessary to do justice to the role.

I also intend to advocate for focusing the OpenStack community on ambitious, but
achievable, goals.  I believe this will require making hard choices about which
use cases we can reasonably expect to support.  To me, the idea that OpenStack
can be all things to all people is dangerous.  It's just as likely that in
trying to do it all, we do little of it well, and risk irrelevance.  I think our
primary competition is and will continue to be proprietary cloud, and my biggest
fear is that we become unable to compete on cost due to the operational
complexity required to make everyone happy.  We need to keep our collective eyes
on the ball!

To be clear, I want to be a part of a TC with as diverse a group of viewpoints
as possible to ensure that we have to work hard to achieve consensus.  If
agreement is reached too easily, there is probably something wrong.  My wanting
to push a developer-centric agenda doesn't mean that I don't respect the need to
address other issues.  My voice would be one of many, and I recognize that
consensus requires compromise.


* Why not vote for me?

There are candidates more deserving of your vote if you think our TC shouldn't
have a role in providing leadership to the OpenStack community.  If you believe
that our TC is already sufficiently developer-focused, then I also don't deserve
your vote.

This is in no way to suggest that I want to see our TC become a top-down
decision-making body. This is still an open source project, after all, and I
know first-hand the complexities of the culture involved.  I do think it
appropriate, though, for an elected body with as much visibility as our TC to
participate more actively in addressing the challenges we face.


* Key concerns

There are any number of issues facing OpenStack today, but the items on the
shortlist that follows are the concerns that I would like to see the TC
champion in the near-term:

** Scaling our development effort

The stated goal of our TC of late has been to 'get out of the way'.  I
wholeheartedly support this intention, and would like to see it extended to how
our TC approaches governance beyond project evaluation.  I think our TC should
be responsible for proposing what we want to achieve rather than in how we
should achieve it.  Outcomes, rather than process.  I think project-level
contributors are best equipped to solve the problems of implementation.  Our TC
can take responsibility for setting OpenStack-wide expectations and in
facilitating - rather than managing - cross-project advancement towards these
goals.  More than ever, we need to be pulling in the same direction, and I think
our TC is an obvious candidate to rally ourselves around.

I hope we all recognize that we can't scale OpenStack if decisions are
constantly gated on a small group of 'tastemakers'.  Delegation of trust is
required, whether at the level of our TC or the individual projects.  I think we
need to take our TC's recent momentum to the project level and find ways to
increase delegation of responsibility.  Nova and Neutron, for example, have had
to face ever-increasing demands with the same small pool of core reviewers, and
many of you know all-too-well the pain that has resulted.  Core reviewers - like
the pre-big tent TC - have inadvertently become micromanagers as their
responsibilities have evolved beyond their capacity to meet them.  The model of
direct trust - in which each core needs to trust every other core - doesn't
scale due to fundamental human limits.  This is at odds with OpenStack's need to
grow, and I want our TC to lead an effort to help affected projects find their
way out of this logjam.

** Growing our contributors

Not only does the current core reviewer regime in some projects limit our
capacity to get work done, not only does it contribute to burnout and a
perception of indifference - it also has the effect of restricting growth
opportunities for new contributors.  How can a contributor hope to stretch
themselves if they don't have the opportunity to take on additional
responsibility because the positions of authority are already occupied and
turnover is negligible?  This problem has gone on long enough that I think it is
time for our TC to support affected projects in finding solutions.  We need to
provide contributors more and better avenues for growth if we hope to sustain
our development efforts over the long-term.

Similarly, at the level of our TC, I want to see a governance change that
imposes term limits on elected positions.  We need continuity of leadership, but
not at the cost of limiting the growth opportunity for our future leaders.
Influence is extraordinarily sticky, as we've seen with incumbents almost always
winning over challengers in any given OpenStack election, and we need to balance
that stickiness with deliberate policy.

** Unwinding the integrated gate

Over the past year I've seen awareness grow as to the costs of our integrated
gate.  Those costs were worth bearing in the past, but times have changed.
Co-gating has allowed our biggest projects to come to rely on the implicit
behavior of their co-gating siblings rather than forcing all involved to rely
only on explicit API contracts.  The resulting combinatorial increase of
interaction complexity has imposed a severe penalty on the velocity of OpenStack
as a whole.  I think the way forward is having our TC work with co-gated
projects to define a timeline for decoupling.  Without an explicit mandate to
focus up-front resources on the increased testing rigor required to remove the
co-gating requirement, affected projects will continue to suffer from
unnecessary coupling and the resultant impact on quality, reduced merge
velocity, and contributor frustration.


* Who am I?

I've saved this for last, since I think the issues are more important than who I
am. If you've read this far, though, you probably want to get a better sense of
who I am before you consider casting a vote in my favor.

I've been developing software professionally for almost 20 years, and and I've
been using Python professionally for more than 14.  I've been responsible for
enough legacy systems that I am extremely focused on maintainability.  For me,
maintainable software is well-designed, well-written, and well-tested, and only
constant iteration can hope to achieve these goals.  But given that maintainable
software is only valuable if it meets user needs, I've always focused on the
user first.  This focus has taught me the value of listening and of being humble
in the face of disagreement (too often the result of misunderstanding).
OpenStack has proven an ideal match for this background, and I enjoy applying
myself to the challenges we face.

I've been an active upstream contributor to OpenStack since Essex (2012), a core
reviewer in Neutron for most of that time, and for the past 2 years have been
privileged to work upstream on a full-time basis.  I have been a capable (if
inconsistent) reviewer, but mainly I have made it my responsibility to improve
Neutron's testing story.  Early efforts included advocating for unit testing,
kicking off the effort to write Tempest scenario tests for Neutron, and more
recently I've led the effort to enable in-tree functional and API testing.  The
latter effort required considerable coordination with both the QA and Infra
teams.  In my experience, there is no amount of post-dev QA that can keep up
with a developer community that doesn't have primary responsibility for the
quality of what they merge.  I've learnt the hard way that enabling pre-merge
testing is key to mandating a developer focus on the quality of what they are
implementing.  Elected or no, I will continue to promote this vision of
test-focused development within OpenStack.

I've also been involved in improving Neutron's culture and development process.
I've worked closely with Kyle Mestery, the current Neutron PTL, and Mark
McClain, the previous PTL, in improving how the project is run.  I've learned
the hard way that change requires detailed knowledge of the culture, a local
base of support, and a knack for diplomatic tact.  I think our TC can do a more
effective job in providing the vision and leadership that OpenStack as a whole
needs to take us to the next level.  I believe the experience I have gained in
facilitating change in Neutron will prove valuable in getting us there.