Open Stack

I would like to announce my candidacy for the Technical Committee.

I have been working on OpenStack since the beginning of the Grizzly cycle.
I started working on OpenStack as part of HP's Public Cloud effort. I spent
two years working to make Horizon work in that scale of environment and
making Horizon the user facing interface of HP's Public Cloud. I have
served as a Horizon core reviewer since the Havana cycle and I am starting
my third release as Horizon PTL. Currently, I am employed by Intel in their
Open Source Technology Center.

I have been a regular observer of the Technical Committee during my time as
PTL. The role of the TC is large and difficult. I appreciate the efforts of
all those that have served during that time and I would like to thank them
for their dedication. One takeaway from those observations in the very
heavy representation on the TC by infrastructure and core services. I think
the TC would be benefit from more representation higher up the stack. I
think Heat, Horizon, Solum, TripleO have a unique perspective into
cross-project issues and the TC would benefit from such representation.

In my opinion, the fundamental problems the TC needs to address in the Kilo
cycle are handling growth and cross-project alignment. I'll be honest, I
don't have a master plan to address these, but I think I'm well equipped
and motivated to help develop that plan with other members of the TC.

Thanks for your consideration,
David Lyle


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

"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."

I think this is a very broad mission. Breadth is not a problem, but there
are a few implications in here. One OpenStack needs to be inclusive, to
accomplish ubiquity we need to strive to allow deployers to meet their
widely varied needs. So we need to support a large ecosystem. The ecosystem
around OpenStack is certainly large, but there is a fairly sharp dichotomy
between OpenStack and not OpenStack, recognizing larger parts of the
ecosystem is important for ecosystem health. As to public vs private and
massively scalable aspects, I think we have room for growth. Running a
public cloud on OpenStack requires not insignificant changes, and OpenStack
has room for improvement on the scalability front. We need greater feedback
from the very large deployers to make sure we meet those scalability needs.

Topic: Technical Committee Mission: How do you feel the technical committee
is doing in meeting the technical committee 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."

The technical committee has spent much of the last cycle acting as gate
keeper. I would like to see it take a larger role in overall architectural
direction in OpenStack. I believe one of the greatest challenges we face is
coherency of vision and direction. I think this should be the province of
the technical committee to act as an arbitrar and architectural board. I
don't hold that overall technical direction is to be dictated by the TC,
rather the TC merely helps unify that direction and insures consistency.
Obviously this is a herculean task, but I believe OpenStack needs more
clearness in direction.

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

Contributors are motivated to contribute for various reasons. People
contribute for personal interest, corporate interest, academic interest,
and any mix of all three. Corporate interest covers a lot, from users to
operators, vendors to consumers. Many ideas from our great community of
diverse contributors helps drive us forward and keeps us honest and
progressing.

At the end of the day, OpenStack is cloud software that should be usable.
We do need to temper the wouldn't it be neat if, with how will this work in
real world application ranging from small test clouds to large public
clouds. Services should strive to work across this spectrum. The difficulty
is focusing these disparate motivations into a cohesive effort.

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?
----------------------------------------------------------------------------------------------------------------------------------------

The phenomenal growth rate is our greatest asset. It's also our largest
pain point. We need to reevaluate our processes to cope with this increased
strain. I think we need to remain inclusive, but temper how much the
ecosystem taxes the cross-project resources of OpenStack.

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

There are several things OpenStack has right for new contributors. The
documentation on how to contribute is easy to discover and very thorough.
Requisite information for submitting a patch is well presented. The
OpenStack developer is also a very open and inclusive community. New
contributors are treated with civility, respect, and appreciation. This is
something I am very proud of and strive to maintain. From there, the
contributor experience becomes a more daunting. Although the documentation
for getting started is very good, there is still a great deal of process
and configuration required to apply that documentation toward contributing
your first patch. Hopefully a new contributor's patch is a bug fix. Once
that hurdle is crossed, the experience is much better. Patch review
turn-around time is a large concern as well, and again comes back to
dealing with the scale of OpenStack.

I know there has been numerous discussion regarding the CLA requirement.
For most contributors this is not much of an impediment. However, I
understand some employers are not willing to let employees contribute based
on the CLA requirement. I'd like to strive to include those contributors as
well.

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

For a global community of developers, I think communication is very good.
However, from the feedback I receive, the burden for communication is too
high. With 19+ recognized projects and 20+ other satellite projects vying
for developer eyeballs, it is very overwhelming for contributors to filter
and find the important items to them. I think this is primarily another
symptom of community growth.

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

As an observer of the technical committee the past couple of years, the
open interaction I've witnessed has primarily focused on Def Core. There is
a fundamental disconnect between the objectives of the Technical Committee
and the Foundation Board on this issue. This is expected as the two bodies
have very different end goals. The board's role is to protect the OpenStack
trademark in which many companies have heavily invested. Allowing the
trademark to carry a very broad definition potentially lessens the return
on this investment. The technical committee is made of the builders of
OpenStack, believers in an open process of development. To restrict the way
operators can use OpenStack to satisfy how the trademark can be applied
runs counter to the open process. An impasse is the result. My position is
that the components of OpenStack are replaceable, the burden for the
trademark should allow for API compatibility, but I fall on the developer
side of the fence.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141009/f2c1bd62/attachment.html>