<div dir="ltr"><div>I would like to announce my candidacy for the Technical Committee.</div><div><br></div><div>I have been working on OpenStack since the beginning of the Grizzly cycle. I started working on OpenStack as part of HP's Public Cloud effort. I spent two years working to make Horizon work in that scale of environment and making Horizon the user facing interface of HP's Public Cloud. I have served as a Horizon core reviewer since the Havana cycle and I am starting my third release as Horizon PTL. Currently, I am employed by Intel in their Open Source Technology Center. </div><div><br></div><div>I have been a regular observer of the Technical Committee during my time as PTL. The role of the TC is large and difficult. I appreciate the efforts of all those that have served during that time and I would like to thank them for their dedication. One takeaway from those observations in the very heavy representation on the TC by infrastructure and core services. I think the TC would be benefit from more representation higher up the stack. I think Heat, Horizon, Solum, TripleO have a unique perspective into cross-project issues and the TC would benefit from such representation.</div><div><br></div><div>In my opinion, the fundamental problems the TC needs to address in the Kilo cycle are handling growth and cross-project alignment. I'll be honest, I don't have a master plan to address these, but I think I'm well equipped and motivated to help develop that plan with other members of the TC.</div><div><br></div><div>Thanks for your consideration,</div><div>David Lyle</div><div><br></div><div><br></div><div>Topic: OpenStack Mission: How do you feel the technical community is doing in meeting the OpenStack Mission?</div><div>----------------------------------------------------------------------------------------------------------------------------------------</div><div><br></div><div>"To produce the ubiquitous OpenSource Cloud Computing platform that will meet the needs of public and private clouds regardless of size, by being simple to implement and massively scalable."</div><div><br></div><div>I think this is a very broad mission. Breadth is not a problem, but there are a few implications in here. One OpenStack needs to be inclusive, to accomplish ubiquity we need to strive to allow deployers to meet their widely varied needs. So we need to support a large ecosystem. The ecosystem around OpenStack is certainly large, but there is a fairly sharp dichotomy between OpenStack and not OpenStack, recognizing larger parts of the ecosystem is important for ecosystem health. As to public vs private and massively scalable aspects, I think we have room for growth. Running a public cloud on OpenStack requires not insignificant changes, and OpenStack has room for improvement on the scalability front. We need greater feedback from the very large deployers to make sure we meet those scalability needs.</div><div><br></div><div>Topic: Technical Committee Mission: How do you feel the technical committee is doing in meeting the technical committee mission?</div><div>----------------------------------------------------------------------------------------------------------------------------------------</div><div><br></div><div>"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."</div><div><br></div><div>The technical committee has spent much of the last cycle acting as gate keeper. I would like to see it take a larger role in overall architectural direction in OpenStack. I believe one of the greatest challenges we face is coherency of vision and direction. I think this should be the province of the technical committee to act as an arbitrar and architectural board. I don't hold that overall technical direction is to be dictated by the TC, rather the TC merely helps unify that direction and insures consistency. Obviously this is a herculean task, but I believe OpenStack needs more clearness in direction.</div><div><br></div><div>Topic: Contributor Motivation: How would you characterize the various facets of contributor motivation?</div><div>----------------------------------------------------------------------------------------------------------------------------------------</div><div><br></div><div>Contributors are motivated to contribute for various reasons. People contribute for personal interest, corporate interest, academic interest, and any mix of all three. Corporate interest covers a lot, from users to operators, vendors to consumers. Many ideas from our great community of diverse contributors helps drive us forward and keeps us honest and progressing.</div><div><br></div><div>At the end of the day, OpenStack is cloud software that should be usable. We do need to temper the wouldn't it be neat if, with how will this work in real world application ranging from small test clouds to large public clouds. Services should strive to work across this spectrum. The difficulty is focusing these disparate motivations into a cohesive effort.</div><div><br></div><div>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?</div><div>----------------------------------------------------------------------------------------------------------------------------------------</div><div><br></div><div>The phenomenal growth rate is our greatest asset. It's also our largest pain point. We need to reevaluate our processes to cope with this increased strain. I think we need to remain inclusive, but temper how much the ecosystem taxes the cross-project resources of OpenStack.</div><div><br></div><div>Topic: New Contributor Experience: How would you characterize the experience new contributors have currently?</div><div>----------------------------------------------------------------------------------------------------------------------------------------</div><div><br></div><div>There are several things OpenStack has right for new contributors. The documentation on how to contribute is easy to discover and very thorough. Requisite information for submitting a patch is well presented. The OpenStack developer is also a very open and inclusive community. New contributors are treated with civility, respect, and appreciation. This is something I am very proud of and strive to maintain. From there, the contributor experience becomes a more daunting. Although the documentation for getting started is very good, there is still a great deal of process and configuration required to apply that documentation toward contributing your first patch. Hopefully a new contributor's patch is a bug fix. Once that hurdle is crossed, the experience is much better. Patch review turn-around time is a large concern as well, and again comes back to dealing with the scale of OpenStack.</div><div><br></div><div>I know there has been numerous discussion regarding the CLA requirement. For most contributors this is not much of an impediment. However, I understand some employers are not willing to let employees contribute based on the CLA requirement. I'd like to strive to include those contributors as well.</div><div><br></div><div>Topic: Communication: How would you describe our current state of communication in the OpenStack community?</div><div>----------------------------------------------------------------------------------------------------------------------------------------</div><div><br></div><div>For a global community of developers, I think communication is very good. However, from the feedback I receive, the burden for communication is too high. With 19+ recognized projects and 20+ other satellite projects vying for developer eyeballs, it is very overwhelming for contributors to filter and find the important items to them. I think this is primarily another symptom of community growth.</div><div><br></div><div>Topic: Relationship with the Foundation Board: The technical committee interacts with the foundation board on several different fronts. How would you describe these interactions?</div><div>----------------------------------------------------------------------------------------------------------------------------------------</div><div><br></div><div>As an observer of the technical committee the past couple of years, the open interaction I've witnessed has primarily focused on Def Core. There is a fundamental disconnect between the objectives of the Technical Committee and the Foundation Board on this issue. This is expected as the two bodies have very different end goals. The board's role is to protect the OpenStack trademark in which many companies have heavily invested. Allowing the trademark to carry a very broad definition potentially lessens the return on this investment. The technical committee is made of the builders of OpenStack, believers in an open process of development. To restrict the way operators can use OpenStack to satisfy how the trademark can be applied runs counter to the open process. An impasse is the result. My position is that the components of OpenStack are replaceable, the burden for the trademark should allow for API compatibility, but I fall on the developer side of the fence.</div><div><br></div><div> </div><div><br></div></div>