[openstack-dev] TC candidacy

Monty Taylor mordred at inaugust.com
Tue Oct 7 15:25:12 UTC 2014

Hi everybody!

I'd like to announce my candidacy for re-election to the TC.

tl;dr - Vote for me or vote for someone else you prefer

I've been around the project for quite a while, having been on the phone
calls where we were discussing the name OpenStack - although I'll admit
I had absolutely zero decision making power there. The first decision in
the project I took any active part in shaping was the decision to keep
the code names nova and swift and not to rename each project
openstack-compute and openstack-object-storage.

My main technical focus within OpenStack is in Infra, where I am a
former PTL and current core. I tend to focus energy on cross-project
concerns over individual project concerns. I believe that a strong
OpenStack comes from a high degree of coordination and standardization -
but I think it's important to keep standardization in perspective as a
tool to help us make a better product and not an goal in and of itself.

As an Infra team member, I am a fairly large end-user of OpenStack.
Infra runs across two public clouds and a private cloud run by the
TripleO team. Although I sometimes express it in a non-productive and
rage-filled way, I regularly experience first hand what our end users
experience ... which is both awesome and not-awesome ... and I've been
spending more and more of my effort on improving that experience.

As may be clear from my big-tent blog post, I believe it's highly
important to be inclusive in "who" we are, while at the same time
collectively taking a higher amount of accountability for the quality of
"what" we produce.

Finally, there is a natural tug between exciting new features to make
people's lives better and the quality of the existing features we have.
We've been growing at a rather unprecedented pace over the last four
years, so at the moment I think we need a double-down on quality and
stability with less of a focus on adding features. As with everything
else though, this is a balancing act and the relative importance changes

Balancing the competing needs such as the ones above is what I believe
the main job of the TC is. We have process, we have policy, we have
governance structure - but ultimately humans need to talk and make
decisions, even if the decision is to do nothing. I think as the TC we
need to own that responsibility and not shrink from it when it's hard or
potentially unpopular.

== The questions ==

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

In case you haven't read it recently:

"to produce the ubiquitous Open Source Cloud Computing platform that
will meet the needs of public and private clouds regardless of size, by
being simple to implement and massively scalable."

If there is anyone out there who feels we've nailed "simple to
implement" I'd love to meet them. I think we've been focusing on all of
the other parts - I'd like to see more attention placed on "simple to

Topic: Technical Committee Mission
How do you feel the technical committee is doing in meeting the
technical committee mission?

In case you haven't read it recently:

"The Technical Committee ("TC") is tasked with providing the technical
leadership for OpenStack as a whole (all official programs, as defined
below). It enforces OpenStack ideals (Openness, Transparency,
Commonality, Integration, Quality...), decides on issues affecting
multiple programs, forms an ultimate appeals board for technical
decisions, and generally has oversight over all the OpenStack project."

I think over the last year since we became all-elected, the TC has been
doing a better and better job. Historically the TC has been a bit
reluctant to own the words "technical leadership" Over the past cycle or
two, the TC has consistently been stepping more up to the plate on this
topic, and I think that trend needs to continue.

Topic: Contributor Motivation
How would you characterize the various facets of contributor motivation?

I'm pretty sure the majority of our contributors are doing so as part of
their jobs. I think this makes our dynamic a bit different than a
"traditional" Open Source project.

That said - I think we see a very strong set of people who are
passionate about what we're doing evidenced by the number of people who
have worked for multiple companies while working on OpenStack.

I can't speak to everyone's motivation - but I can tell you what mine is.

Cloud is taking over as the way we think about how IT works. It's not an
if, it's a when. But even with that, Cloud is an idea more than a
destination. When we started, there was one legitimate definition for
"Cloud" and it was Amazon. Amazon is a closed-source company run by a
ruthless dictator. I do not want to live in a world where I need his
permission to use a computer.

Over the last four years, we've made significant inroads in redefining
what Cloud can be. Containers and bare-metal are now legitimate building
blocks and I think it's becomming understood that you can use cloud to
effectively run things other than scale-out ephemeral compute based

That direction and that transformation are the things that must happen
for the Internet to keep both open and operational. I think it's
essential that people make them happen. I'm lucky enough to be in a
position where I can contribute to that - so I hack on OpenStack.

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?

There are people who are core reviewers who I do not know. That's awesome.

Some of the consequences are that we have to continually reassess how
we're doing things. I'm sure this drives people nuts - but we've
reworked how we organize and govern ourselves several times as each
previous system reaches a scaling point. The introduction of programs is
an example of that - they were not needed in 2010, but in 2013 they
solved a problem. It's possible that they, as an organizational
structure have outlived their time, or it's possible that they still
serve a purpose in helping us get our job done but need to be tweaked in
scope. The big-tent-targetted-gate discussions point to fragility in our
monolithic integration story - again caused by scale, and incidentally
caused by us actually meeting and not shrinking away from the challenges
of doing captive integration at scale.

Topic: New Contributor Experience
How would you characterize the experience new contributors have currently?

OpenStack is optimized for high-throughput at the expense of individual
patch latency. This means some of our processes may seem new or opaque
to people depending on their background. However, given that the project
has regularly doubled every six months for quite some time, I do not
think solving this is a priority if it's at the expense of the
productivity of the folks that breathe OpenStack 80 hours a week.

For those who have not begun contributing to another Open Source project
in a while, I recommend you do so. EVERY project of size has its own
quirks. Ours are, while long, well documented and consistent.

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

Did you read this email all the way to here? If so, communication is
going well. :)

Inside of the tech community I think we're doing ok with communication.
Piercing our bubble, on the other hand, needs work. Keeping up with what
we're doing as an inside is hard enough, I cannot imagine trying to
follow it as an outsider. Similarly, since we're optimized for
intra-developer communication, getting a voice to operators and users is

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

Abysmal, but getting better. We had a good TC/Board meeting in Atlanta
and have another scheduled for Paris.

I think the biggest issue we face there is figuring out how to disagree
with each other productively. It's essential that both the TC and the
Board get better at being direct and open with each other when we feel
that the other body is maybe not stepping up to the plate. There is
information we learned from the board as part of DefCore that probably
would have been better if it had just been some direct statements - and
which I think once Rob and TC reps started meeting directly started
getting worked out much more effectively. Similarly, the TC just passed
a resolution requesting that the Board consider the DCO to be our CLA.
It's clearly the board's prerogative to do whatever - but it's our
responsibility to let them know that we have an opinion.

In short, we're learning how to work together being respectful of
boundaries but still being honest about needs. It's a journey, and one I
think is important that we take seriously.


More information about the OpenStack-dev mailing list