<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">    </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 class="" style="white-space:pre">        </span></div><div><span class="" style="white-space:pre">   </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 class="" style="white-space:pre">     </span></div><div><span class="" style="white-space:pre">   </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 class="" style="white-space:pre">       </span></div><div><span class="" style="white-space:pre">   </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 class="" style="white-space:pre"> </span></div><div><span class="" style="white-space:pre">   </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 class="" style="white-space:pre">  </span></div><div><span class="" style="white-space:pre">   </span>- I see friendly interactions within the community even when we disagree. That's motivating.</div><div><span class="" style="white-space:pre">   </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 class="" style="white-space:pre">     </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 class="" style="white-space:pre">       </span></div><div><span class="" style="white-space:pre">   </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 class="" style="white-space:pre">     </span></div><div><span class="" style="white-space:pre">   </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 class="" style="white-space:pre">        </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 class="" style="white-space:pre">       </span></div><div><span class="" style="white-space:pre">   </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 class="" style="white-space:pre"> </span></div><div><span class="" style="white-space:pre">   </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 class="" style="white-space:pre"> </span></div><div><span class="" style="white-space:pre">   </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 class="" style="white-space:pre">      </span></div><div><span class="" style="white-space:pre">   </span>I mentioned Upstream University earlier and I think it's worth repeating that working on something that matters is motivating.</div><div><span class="" style="white-space:pre"> </span></div><div><span class="" style="white-space:pre">   </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 class="" style="white-space:pre">      </span></div><div><span class="" style="white-space:pre">   </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 class="" style="white-space:pre">  </span></div><div><span class="" style="white-space:pre">   </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 class="" style="white-space:pre">       </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 class="" style="white-space:pre">   </span></div><div><span class="" style="white-space:pre">   </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 class="" style="white-space:pre">        </span></div><div><span class="" style="white-space:pre">   </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 class="" style="white-space:pre">     </span></div><div><span class="" style="white-space:pre">   </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 class="" style="white-space:pre">       </span></div><div><span class="" style="white-space:pre">   </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">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">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: +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>
</div>