<div dir="ltr">It seems I left out a response. Sorry for the follow-on but here's what was missing.<div><br></div><div><div><b><u>Topic: Technical Committee Mission</u></b></div><div><b>How do you feel the technical committee is doing in meeting the technical committee mission?</b></div><div><br></div><div><i>"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></div><div><br></div><div><span class="" style="white-space:pre"> </span>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.</div><div><span class="" style="white-space:pre"> </span></div><div><span class="" style="white-space:pre"> </span>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</div><div><span class="" style="white-space:pre"> </span></div><div><span class="" style="white-space:pre"> </span>"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.</div><div><span class="" style="white-space:pre"> </span></div><div><span class="" style="white-space:pre"> </span>- The deployment challenge is beyond ready for attention.</div><div><span class="" style="white-space:pre"> </span>- 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.</div><div><span class="" style="white-space:pre"> </span>- 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.</div><div><span class="" style="white-space:pre"> </span></div><div><span class="" style="white-space:pre"> </span>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.</div></div></div><div class="gmail_extra"><br clear="all"><div><div dir="ltr"><div><font><div style="font-family:arial;font-size:small"><b><i><br>Adam Lawson</i></b></div><div><font><font color="#666666" size="1"><div style="font-family:arial"><br></div><div style="font-family:arial;font-size:small">AQORN, Inc.</div><div style="font-family:arial;font-size:small">427 North Tatnall Street</div><div style="font-family:arial;font-size:small">Ste. 58461</div><div style="font-family:arial;font-size:small">Wilmington, Delaware 19801-2230</div><div style="font-family:arial;font-size:small">Toll-free: (844) 4-AQORN-NOW ext. 101</div><div style="font-family:arial;font-size:small">International: +1 302-387-4660</div></font><font color="#666666" size="1"><div style="font-family:arial;font-size:small">Direct: +1 916-246-2072</div></font></font></div></font></div><div style="font-family:arial;font-size:small"><img src="http://www.aqorn.com/images/logo.png" width="96" height="39"><br></div></div></div>
<br><div class="gmail_quote">On Tue, Oct 7, 2014 at 7:06 PM, Adam Lawson <span dir="ltr"><<a href="mailto:alawson@aqorn.com" target="_blank">alawson@aqorn.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hello everyone!</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>So without any further adieu, below are my thoughts re the requested questions and thanks for your consideration!</div><div><br></div><div><i>"My name is Adam Lawson, running for election to the Openstack Technical Committee, and I approve this message."</i> ; )</div><div><br></div><div><b><u>Topic: OpenStack Mission</u></b></div><div><b>How do you feel the technical community is doing in meeting the OpenStack Mission?</b></div><div><br></div><div><i>“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.”</i></div><div><br></div><div><span style="white-space:pre-wrap"> </span>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.</div><div><span style="white-space:pre-wrap"> </span></div><div><span style="white-space:pre-wrap"> </span>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.</div><div><span style="white-space:pre-wrap"> </span></div><div><span style="white-space:pre-wrap"> </span>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.</div><div><br></div><div><b><u>Topic: Contributor Motivation</u></b></div><div><b>How would you characterize the various facets of contributor motivation?</b></div><div><span style="white-space:pre-wrap"> </span></div><div><span style="white-space:pre-wrap"> </span>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.</div><div><span style="white-space:pre-wrap"> </span></div><div><span style="white-space:pre-wrap"> </span>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.</div><div><span style="white-space:pre-wrap"> </span></div><div><span style="white-space:pre-wrap"> </span>- I see friendly interactions within the community even when we disagree. That's motivating.</div><div><span style="white-space:pre-wrap"> </span>- 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.</div><div><span style="white-space:pre-wrap"> </span>- 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.</div><div><span style="white-space:pre-wrap"> </span></div><div><span style="white-space:pre-wrap"> </span>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.</div><div><span style="white-space:pre-wrap"> </span></div><div><span style="white-space:pre-wrap"> </span>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.</div><div><span style="white-space:pre-wrap"> </span></div><div><b><u>Topic: Rate of Growth</u></b></div><div><b>There is no argument the OpenStack technical community has a substantial rate of growth. What are some of the consequences of this rate?</b></div><div><span style="white-space:pre-wrap"> </span></div><div><span style="white-space:pre-wrap"> </span>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.</div><div><span style="white-space:pre-wrap"> </span></div><div><span style="white-space:pre-wrap"> </span>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.</div><div><span style="white-space:pre-wrap"> </span></div><div><span style="white-space:pre-wrap"> </span>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.</div><div><br></div><div><b><u>Topic: New Contributor Experience</u></b></div><div><b>How would you characterize the experience new contributors have currently?</b></div><div><span style="white-space:pre-wrap"> </span></div><div><span style="white-space:pre-wrap"> </span>I mentioned Upstream University earlier and I think it's worth repeating that working on something that matters is motivating.</div><div><span style="white-space:pre-wrap"> </span></div><div><span style="white-space:pre-wrap"> </span>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.</div><div><span style="white-space:pre-wrap"> </span></div><div><span style="white-space:pre-wrap"> </span>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.</div><div><span style="white-space:pre-wrap"> </span></div><div><span style="white-space:pre-wrap"> </span>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.</div><div><span style="white-space:pre-wrap"> </span></div><div><b><u>Topic: Communication</u></b></div><div><b>How would you describe our current state of communication in the OpenStack community?</b></div><div><span style="white-space:pre-wrap"> </span></div><div><span style="white-space:pre-wrap"> </span>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.</div><div><span style="white-space:pre-wrap"> </span></div><div><span style="white-space:pre-wrap"> </span>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.</div><div><br></div><div><b><u>Topic: Relationship with the Foundation Board</u></b></div><div><b>The technical committee interacts with the foundation board on several different fronts. How would you describe these interactions?</b></div><div><span style="white-space:pre-wrap"> </span></div><div><span style="white-space:pre-wrap"> </span>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.</div><div><span style="white-space:pre-wrap"> </span></div><div><span style="white-space:pre-wrap"> </span>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!</div><div><br></div><div><b>Foundation:</b> <a href="http://www.openstack.org/community/members/profile/11026" target="_blank">http://www.openstack.org/community/members/profile/11026</a></div><div><b>IRC:</b> greenhorn</div><div><b>Website:</b> <a href="http://www.aqorn.com/about" target="_blank">http://www.aqorn.com/about</a></div><div><br></div><div>Mahalo,</div><div>Adam</div><div><div dir="ltr"><div><font><div style="font-family:arial;font-size:small"><b><i><br>Adam Lawson</i></b></div><div><font><font color="#666666" size="1"><div style="font-family:arial"><br></div><div style="font-family:arial;font-size:small">AQORN, Inc.</div><div style="font-family:arial;font-size:small">427 North Tatnall Street</div><div style="font-family:arial;font-size:small">Ste. 58461</div><div style="font-family:arial;font-size:small">Wilmington, Delaware 19801-2230</div><div style="font-family:arial;font-size:small">Toll-free: (844) 4-AQORN-NOW ext. 101</div><div style="font-family:arial;font-size:small">International: <a href="tel:%2B1%20302-387-4660" value="+13023874660" target="_blank">+1 302-387-4660</a></div></font><font color="#666666" size="1"><div style="font-family:arial;font-size:small">Direct: <a href="tel:%2B1%20916-246-2072" value="+19162462072" target="_blank">+1 916-246-2072</a></div></font></font></div></font></div><div style="font-family:arial;font-size:small"><img src="http://www.aqorn.com/images/logo.png" width="96" height="39"><br></div></div></div>
</div>
</blockquote></div><br></div>