Open Stack

I'd like to announce throwing my hat into the ring for the OpenStack
Technical Committee.

= My Background on the Project =

I've been a contributor to OpenStack since late in the Essex release. I
was the QA PTL for the Havana and Icehouse cycles. I'm a core reviewer
on QA (Devstack, Grenade, Tempest), on Nova, and on the new Project
Config repo in infra, and a host of other projects in OpenStack. I was
elected to the TC last fall as part of the first fully directed TC.

You might also know me from the fact that I spend a lot of time on the
OpenStack gate, which really means I spend a lot of time trying to
understand why when all the OpenStack components run together, they
often break horribly, and actually try to debug and address those. I was
part of the team that built Elastic Recheck
(http://status.openstack.org/elastic-recheck/) for that effort.

In any particular release of OpenStack I'm typically one of the largest
reviewers of code. A lot of these are help shepherding in easy fixes
that get lost in our review queues. I built things like Gerrit Dashboard
Creator (https://github.com/stackforge/gerrit-dash-creator) to make it
easier for reviewers to sift patches to make sure that good patches
don't get lost, and make reviewer's lives easier.

And I am a strong believer that the way we grow our community is through
growing our contributors. This is one of the reasons I kicked off the
OpenStack Bootstrapping Hour
(https://wiki.openstack.org/wiki/BootstrappingHour) with Jay Pipes and
Dan Smith, to provide one avenue for this growth to happen. I think many
other are required as well, but this is one way to get us started.

= My Views on the Future of OpenStack and the TC =

I feel like OpenStack is at a crossroads. The original definition of the
integrated release, and horizontal teams was built around the concept of
2 projects. It worked at 5. It was strained at 8. And I think we're now
on the very of it being completely broken.

I think that in order for OpenStack to move forward we need to
pragmatically redefine the integrated release as the set of horizontal
components that have to be linked together to be useful. Exactly the
right unit I think is up for debate. It could be as small as Nova,
Glance, Keystone, Neutron. It might include Cinder, Designate, and / or
Oslo (I can see the case for and against any of these). Those should be
the projects that QA, Docs, and Stable Maint, Release Management,
Security Team, and the TC needs to take responsibility for.

I think that we need to have an expansive ecosystem where projects like
Swift, Heat, Horizon, Ceilometer, Trove, Congress, Sahara, Zaqar, Rally,
Ironic, and all the other really interesting projects can flourish. I
think their inclusion in the OpenStack umbrella should be a lightweight
process that is largely a self assessment and an acceptance of certain
principles that are core to OpenStack. I think these projects should be
self responsible for their own QA, Docs, Stable Maint, Security, and
Release Management. And I think mentoring should be made available to
help them with any of these. I believe a structure similar to the User
Committee is probably most appropriate here. However we get this body,
it should have an electorate (directly or indirectly) that represents
ATCs from the broadest expanse of our ecosystem.

I think the TC needs to evolve from a policy body, to a body that's
primarily directly responsible for the integrated release (as I defined
above). Direct responsibility means more than approving and managing gap
analysis plans. It means diving directly into project code across all
the integrated release projects at substantial regularity. It could mean
the TC inheriting +2 on the integrated projects and horizontal efforts
supporting it (like QA, Docs, and Stable Maintenance) (Note: clearly we
could only do this with a strong set of expectations and checks and
balances to prevent abuse, but it's an idea that's interesting to think
about).

I would like to think about this as a tight integrated release plus a
large and solid ecosystem.

These are things I'm going to push for going forward, whether or not I'm
on the TC, however I think the idea of having the TC take more ownership
of the integrated release, directly. We need an OpenStack base box set
with more full and cohesive user experience (one that doesn't require
understanding and maintaining multiple db systems), that is deployable
at everything from small colleges and institutions, to giant places like
wall street, telcos, and research institutions. And then we need to have
space to promote great expansions to OpenStack the institutions can
deploy as needed for their needs that a much freer to use exciting new
technology to solve interesting problems.

= Standard TC Questions =

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

Our mission statement is: "To produce the ubiquitous OpenSource Cloud
Computing platform that will meet the needs of public and private clouds
regardless of size, by being simple to implement and massively
scalable." (http://www.openstack.org/blog/2010/07/introducing-openstack/)

I honestly feel like we're only doing an sort of OK job right now. I
think that the current growth of services and they way we implement them
(by bringing in a lot of new external dependencies) is not holding true
to "being simple to implement". I think that's excluding the use of
OpenStack at smaller institutions. If OpenStack is only in the toolchest
for large sophisticated institutions, it will not become ubiquitous.

Linux was deployed in production first by small ISPs, entities with only
a few employees. If OpenStack can only be deployed by having a very
skill integrator come on board, it by definition can't be Ubiquitous.

My feelings around a smaller nucleus/layer/ring/zone/integrated release
are largely shaped by my feeling that we're losing the smaller users of
OpenStack. And that's something we can fix.

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

The mission: 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.
(https://wiki.openstack.org/wiki/Governance/Foundation/TechnicalCommittee)

In the current TC, I'm one of the newest OpenStack community members. I
was honestly surprised with how much TC time was spent evaluating new
project requests (and this is growing over time). I think the TC mission
for providing technical leadership and even understanding issues
affecting multiple programs becomes very strained when the scope of that
governance includes the whole OpenStack ecosystem. And I think it will
limit the TC's effectiveness at having oversight when it is so far removed.

== How would you characterize the various facets of contributor
motivation? ==

I'm not really sure the intent of this question, but I'll take a swing
at what the author might have intended. A very large amount of OpenStack
work today is sponsored. Some of it is very vendor oriented for very
specific features those vendors want in the OpenStack changelogs, some
of it is people that love this community, and have found entities that
will support that. The fact that a huge number of our community leaders
are not working at the same company as when they started with OpenStack
(including myself) speaks to that passion.

I'd honestly like to see more small contributors, and more people
feeling like they could make an impact to OpenStack even if the don't
have the privilege to work on it full time.

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

The rate of growth has very much meant that most contributors to
projects only contribute to their one effort. The cultures in each
project have grown quite different over time as to what's acceptable
patch culture for each project, acceptable review culture, how bugs get
handled, what's validated, and many more things.

When I joined the projects one of the mantras for no non python
OpenStack projects was that common language and common tooling would
mean that developers and operators would have an easy time moving from
one project to another to address an issue.

I think the explosive growth we've seen, and the challenges with
coherent integration of all these moving parts, has shown that there is
a lot more to unified experience than common language and tooling.

I think it has also very concretely strained the Horizontal efforts past
their capacity points. Docs, QA, Stable Maint, Security, all very much
have to now pick their battles and leave a lot on the cutting room floor.

Take this example: I recently started working on the final Nova fixes
for a cross project security issue that was made public 14 months ago -
https://bugs.launchpad.net/keystone/+bug/1188189. It's honestly unclear
if this has been completely addressed in other projects.

== How would you characterize the experience new contributors have
currently? ==

Terribad.

24 steps of CLA madness, multiple ids, signing stuff,  to get to the
point of submitting your first bug fix is insane.

You have exactly one chance to make a first impression, and today I
think the process of contributing to OpenStack prior to even uploading
to Gerrit is onerous enough that we're preventing most of our best
future OpenStack contributors from ever existing.

This needs to change.

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

I'm going to take "our" to mean all of us in the OpenStack community.
And the best way I can say is fragmented. We have the mailing list, but
with so many efforts being on list (Nova and Fuel being in the same
list, for instance) it means that many things get lost. We have a vast
array of per project IRC channels... though very little traffic on
#openstack-dev. As far as I can tell only a very few core developers
currently monitor #openstack-dev for interesting content, which adds
huge burden to any cross project effort that's not got a dedicated cross
project channel.

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

Confused? No, I mean I'm confused, because honestly there seems to be
not that many fronts in which they interact. I was very mixed on DefCore
because it seemed like so much of the important work there happened in
face to face meetings in San Fran. And there kept being real confusion
over intent.

Beyond that I feel like there hasn't been a ton of Board / TC
interaction. The joint Atlanta meetup was good, and I think some
concerns that got raised in the room did get talked about. But I feel
like there are actually quite different scopes of the Board trying to
define the commercial ecosystem and market dynamics, and the TC trying
to define a set of bits that do a thing. And hopefully keep doing that
thing even when some more bits are added.
Honestly, perhaps the disconnects that currently exist between the TC
and the Board are largely around the fact that the only place our roles
seem to overlap is near the trademark definition, and so vastly
different perspectives exist based on the day to day challenges each face.

= Final thoughts - caveats =

I'll pre-apologize for any oddities in this write up, or if I missed
context on questions that might have been surfaced on the mailing list.
Or if people have noticed me absent in any community threads in the past
week in which they expected to hear my voice (I have not read any email
related to the project since Oct 3rd). I'm currently functioning under a
bit of sleep deprevation after the arrival of our latest family member -
https://twitter.com/sdague/status/519173169643388929, and will be
disconnected from the community for the next couple weeks as I focus on
family. I only broke the sabbatical because TC candidacy had an
expiration date.

Will be back roaring and raring to go by Paris. And will look forward to
seeing you all there whether or not you want me back on the TC for
another year. :)

	-Sean

-- 
Sean Dague
http://dague.net