On 10/08/2014 05:29 PM, Adam Lawson wrote: > 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 > Thanks Adam, I will add this to the wikipage.
Thanks, Anita. > > On Tue, Oct 7, 2014 at 7:06 PM, Adam Lawson <alaw...@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 >> >> > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev