Open Stack

It seems I left out a response. Sorry for the follow-on but here's what was
missing.

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

I believe the TC has thus far done a pretty fair job given the team and its
charter are both rather new. While the TC has been providing leadership for
individual components, I would not characterize the TC today as providing
highly visible leadership (necessary for openness and transparency) which I
would like to see improved. Much of the TC's work today coalesces around
providing a safe harbor for meaningful program integration and ensure
challenges are resolved optimally but the TC needs to get better at
identifying the good/poorly-defined boundaries of this kind of technical
governance model. In other words, the TC needs to get better at being a
good TC. The instantiation of a TC is a perfect first step but the pink
elephant in the room seems to be around cross-project and architectural
guidance; ensuring Openstack as a whole is moving in a direction that
doesn't require accommodating things we shouldn't be doing in the first
place. The lack of API standardization is a great example of moving in a
direction without a big picture context.
 Communications that have gone back and forth and debated about the big
tent model, layers/cascading, scaling documentation, etc have been visible
and the candor of opposing viewpoints have been awesome to follow. But we
could really benefit from some structural adjustments so more decisions
placed before the team are equally visible, a visible and transparent
decision-making process enabling those who use Openstack understand the
architectural perspectives shepherding it. Not just the decision that have
100+ replies on the mailing list
 "Oversight over all the projects" is an area that I'm anticipating where
we have some easy low-hanging fruit. Where we are today with regard to
focus is understandable given the number of fires affecting individual
programs that cannot be ignored. But we have a big opportunity (there's
that word again) to get some traction on the larger architectural decisions
that may require more work up front but produce some big wins over the long
term. Customers who want to use Openstack have often played the "constant
change = unstable" card for good reason; Openstack has a long way to go
before it gets to Production-quality for the masses (i.e. without heavy
re-development requirements). I believe the TC can and should influence
that with better solution-level leadership.
 - The deployment challenge is beyond ready for attention.
- A working default 'out-of-the-box' config that can boot an instance
accessible over the network is STILL a challenge. Long past due in my mind.
- Programs like Oslo that address library requirements moves a cloud closer
to Production-capable but really shouldn't be optional. Doing something
well shouldn't be optional. In fact, a Production context shouldn't be one
option of many despite the prevalence of Openstack PoC and pilots; it
should be a consistent design assumption. Gating a feature to the point
that it's 'good enough' is part of the problem. It must be
Production-worthy otherwise it is NOT good enough. That's ready for
attention.
 We might not be able to address all of these and some ideas could use a
lot more cross-talk, but if elected I would like to champion improving how
the TC approaches problems and vets their potential solutions.


*Adam Lawson*

AQORN, Inc.
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


On Tue, Oct 7, 2014 at 7:06 PM, Adam Lawson <alawson at aqorn.com> wrote:

> 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
> Mission?*
>
> *“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
> engaged.
>  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 community?*
>  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
>
> Mahalo,
> Adam
>
> *Adam Lawson*
>
> AQORN, Inc.
> 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/20141008/c54aa4ec/attachment.html>