[openstack-dev] TC candidacy

Adam Lawson alawson at aqorn.com
Wed Oct 8 02:06:27 UTC 2014

Hello everyone!

I'll be perfectly straight and dedicate paragraph #1 to address the
painfully obvious. A number of you are probably reading this after seeing
'TC Candidacy', looked at my name and wondered 'who is this guy?' In short,
I'm pretty low-key but I've been heavily involved in Openstack since the
Folsom release - advising, architecting and deploying Openstack-based
application clouds for numerous companies and end users. I'm probably a lot
like many of you in fact; not the loudest or most witty voice in the room,
I read more than I write, I don't bully ideas and I've never run for
anything in my life because I hate the spotlight. But the importance of
Openstack in the cloud marketplace is increasingly important as is the
integrity of its technical direction. So I'm going to step on a limb here
and enter the circle.

My involvement has been primarily focused on large designs and deployments
of custom automated Openstack clouds. And while I am more than proficient
in Python and numerous other languages including .NET/J2EE and others, my
greatest pleasure has been architecting solutions that are powered by
Openstack. Focusing on that has really given me a unique perspective. Not
just on individual components and how they interact with each other, but
also how they collectively perform within the context of a heterogenous
hybrid cloud solution while adhering to industry best practices. This
perspective is one that I hope to bring to the technical committee if the
Openstack community is so inclined. Not only to shepherd how Openstack is
put together but to help enable an easier and more seamless adoption cycle
within the enterprise.

Lastly in the spirit of full disclosure, I am the principal architect for
an Openstack consulting company I founded which strives for an accelerated
enterprise adoption of the open cloud through, in part, the successes of
Openstack. So one could say I am vested in Openstack in a pretty unique way
compared to most others. So where technical direction is concerned, I
believe I have a deep well of experience from which to draw via designing
and developing production Openstack clouds in the real world - day in and
day out - which I believe would be of immense value to the TC and the
community supporting the project itself.

I know there are some really smart people who want to also serve on the TC
with focuses on various areas of Openstack and thankfully the committee was
designed to accommodate multiple unique perspectives for that very reason.
My hope is that the community chooses to include my program-agnostic
architectural influence to the TC while maintaining the same work ethic and
unyielding commitment to efforts that will deliver excellence to and within
the Openstack platform.

So without any further adieu, below are my thoughts re the requested
questions and thanks for your consideration!

*"My name is Adam Lawson, running for election to the Openstack Technical
Committee, and I approve this message."* ; )

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

*“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.”*

The whole point of mission statements is merely to identify what we are
striving to achieve or accomplish within the organization. With that said,
I feel that technical leadership is the first step to accomplishing a
technical goal. So to that end, the existence of the TC is a positive first
step. But it's just one step or many more to come.
 Within this particular TC cycle, I'd like to see the TC demonstrate
leadership to drive a reduction of lingering technical debt and address API
and module standardization. Openstack in its current form has a number of
challenges that are affecting our ability to scale and while some of this
can be solved organizationally, technical debt and standardization are
challenges that will not be easy to resolve and might not even be 100
percent solvable within a single release cycle. But I look forward to how
the TC *will* shepherd improvements to both process and the product and
help drive the mission.
 On a side note, "easy to implement" is still just a goal and the
engineering requirement to deploy and manage Openstack is still a
prohibitive hurdle for many organizations. But we have more than one tool
in front of us that will help us to help others who want to use Openstack
but .. can't. That's something I'd really like to see change soon.

*Topic: Contributor Motivation*
*How would you characterize the various facets of contributor motivation?*
 I like what I read earlier today: "People want to do work that matters and
enjoy doing it." This sums up Openstack contributors very well but it sums
up a lot of us too though, doesn't it.
 Many of us are lucky enough to be able to work on Openstack full-time as a
job. There are many others who work with Openstack in the context of
Consumers, Users, Operators, Solutions Architects where it is not their
full-time job but they participate with the Openstack community because of
other reasons. Whatever the reason (philanthropy, my good looks), folks
want to work on what matters and if it doesn't matter, there is no
motivation to continue.
 - I see friendly interactions within the community even when we disagree.
That's motivating.
- I see members within the Openstack community soliciting and offering help
to each other - even between companies who could technically be called
competitors. That's motivating.
- I see the same people who earn a living on selling and supporting
proprietary deployments of Openstack offering their assistance and
perspectives to those who are not using their product and possibly never
will. That's motivating.
 The culture developed and nurtured by the Openstack community is nothing
short of admirable and from someone who is socially-driven (despite my
little shell), I have to say that so long as the TC adheres to and advances
this culture, motivation will be easy to find for those who desire to get
 For those who need a little help, I think the Upstream University is
another place to encourage new contributors and get them motivated through
empowerment via learning/knowledge and the satisfaction of watching their
hard work being used and consumed by countless companies and individuals.
*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?*
 I believe Openstack is on the cusp of experiencing growth pains like it
never has before. I don't think we've even touched on what those pains will
look like when we hit some of our long-term adoption goals/milestones. But
pain drives change and change that drives improvement is good. So we can
all tell change is on the horizon.
 One of the consequences of rapid growth can be disproportionality between
different areas of the Openstack and its community. Code might get ahead of
docs, the need for process might get ahead of the definition of those
processes and scale requirements might reveal all of those unsightly warts
we've been content to ignore for the last year.
 I don't see growth as having consequences per se. Without wanting to sound
cliché, I see Openstack as approaching growth-related challenges that we
need to treat as real opportunities. So long as we focus on the task at
hand and not lose sight of the 'why' not allow overwhelm-ment (is that a
word?) from affecting the measure of correction that may be needed to
resolve a challenge, I think we'll continue  to land on our feet from cycle
to cycle.

*Topic: New Contributor Experience*
*How would you characterize the experience new contributors have currently?*
 I mentioned Upstream University earlier and I think it's worth repeating
that working on something that matters is motivating.
 I do *not* believe however that maintaining the status quo is ever an
acceptable approach with technical leadership as provided by the TC.
Quirks, 'that is the way we've always done it' and 'get used to it' are
completely unacceptable. We can't discourage change if it helps but we
can't allow unnecessary or poorly-prioritized changes to negatively affect
our progress on the project as whole either.
 With that said, I'm pretty sure new contributors that are contributing to
Openstack (more than casually) understand the dynamics around contributing
to a high-volume open source project like Openstack. For those who do not,
the learning curve can be pretty steep but beneficial. And we need to be
careful not to allow the process to suffer for high performers in the name
of inclusiveness.
 One of my goals, if elected, will be to facilitate a superior product via
process(es) that enables a scalable contribution pipeline for experienced
developers - coupled with an effective onboarding process for those who are
just getting started with Openstack's development cadence. I think the
priority definitely needs to be where we get our biggest bang since our
resources are obviously not unlimited but I hope that an effective
contributor experience does a good job at accommodating both new and
existing contributors and I hope we aren't afraid to challange the status
quo if we're failing that goal somehow.
*Topic: Communication*
*How would you describe our current state of communication in the OpenStack
 While I think our communication overall is encouraging and moving in a
positive direction as a whole, I think cross-project and communication
between developers and the consumers remains to be a challenge.
Understandable though when you have multiple mailing lists with countless
updates and program owners and contributors who can't possibly read every
message to se if there's something that requires their attention.
 IRC and email tends to be our forte but I envision expanding the Operator
Summits to include cross-project summits where brainstorming between 2-3
programs that compliment each other (i.e, Swift/Sahara,
TripleO/Ironic/Nova) can be *highly* beneficial. I know we already have
mid-cycle meet-ups but this level of collaboration might even benefit from
a dedicated design summit. No sponsors - just a place where ideas dedicated
to the technical direction of Openstack share the spotlight. Just a thought.

*Topic: Relationship with the Foundation Board*
*The technical committee interacts with the foundation board on several
different fronts. How would you describe these interactions?*
 There's a world of difference between project governance and technical
leadership. I admittedly have not sat down with the Foundation members
within a TC context so I couldn't speak to how it works well or not today.
But what I can say is that I've read what the other candidates who have
served on the TC in the poast have shared and my interpretation is that
things seem to be a bit frosty.
 But I've run into this before. Regardless, I think a clear definition of
roles and responsibilities would be of value to both the Foundation and the
TC and the relational elements that affect their ability to work together
effectively. I'm looking forward to seeing this interaction firsthand and
making up my own mind. But until then, onward and upward!

*Foundation:* http://www.openstack.org/community/members/profile/11026
*IRC:* greenhorn
*Website:* http://www.aqorn.com/about


*Adam Lawson*

427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141007/2a74992e/attachment.html>

More information about the OpenStack-dev mailing list