I'd like to announce throwing my hat into the ring for the OpenStack Technical Committee.
= My Background on the Project = I've been a contributor to OpenStack since late in the Essex release. I was the QA PTL for the Havana and Icehouse cycles. I'm a core reviewer on QA (Devstack, Grenade, Tempest), on Nova, and on the new Project Config repo in infra, and a host of other projects in OpenStack. I was elected to the TC last fall as part of the first fully directed TC. You might also know me from the fact that I spend a lot of time on the OpenStack gate, which really means I spend a lot of time trying to understand why when all the OpenStack components run together, they often break horribly, and actually try to debug and address those. I was part of the team that built Elastic Recheck (http://status.openstack.org/elastic-recheck/) for that effort. In any particular release of OpenStack I'm typically one of the largest reviewers of code. A lot of these are help shepherding in easy fixes that get lost in our review queues. I built things like Gerrit Dashboard Creator (https://github.com/stackforge/gerrit-dash-creator) to make it easier for reviewers to sift patches to make sure that good patches don't get lost, and make reviewer's lives easier. And I am a strong believer that the way we grow our community is through growing our contributors. This is one of the reasons I kicked off the OpenStack Bootstrapping Hour (https://wiki.openstack.org/wiki/BootstrappingHour) with Jay Pipes and Dan Smith, to provide one avenue for this growth to happen. I think many other are required as well, but this is one way to get us started. = My Views on the Future of OpenStack and the TC = I feel like OpenStack is at a crossroads. The original definition of the integrated release, and horizontal teams was built around the concept of 2 projects. It worked at 5. It was strained at 8. And I think we're now on the very of it being completely broken. I think that in order for OpenStack to move forward we need to pragmatically redefine the integrated release as the set of horizontal components that have to be linked together to be useful. Exactly the right unit I think is up for debate. It could be as small as Nova, Glance, Keystone, Neutron. It might include Cinder, Designate, and / or Oslo (I can see the case for and against any of these). Those should be the projects that QA, Docs, and Stable Maint, Release Management, Security Team, and the TC needs to take responsibility for. I think that we need to have an expansive ecosystem where projects like Swift, Heat, Horizon, Ceilometer, Trove, Congress, Sahara, Zaqar, Rally, Ironic, and all the other really interesting projects can flourish. I think their inclusion in the OpenStack umbrella should be a lightweight process that is largely a self assessment and an acceptance of certain principles that are core to OpenStack. I think these projects should be self responsible for their own QA, Docs, Stable Maint, Security, and Release Management. And I think mentoring should be made available to help them with any of these. I believe a structure similar to the User Committee is probably most appropriate here. However we get this body, it should have an electorate (directly or indirectly) that represents ATCs from the broadest expanse of our ecosystem. I think the TC needs to evolve from a policy body, to a body that's primarily directly responsible for the integrated release (as I defined above). Direct responsibility means more than approving and managing gap analysis plans. It means diving directly into project code across all the integrated release projects at substantial regularity. It could mean the TC inheriting +2 on the integrated projects and horizontal efforts supporting it (like QA, Docs, and Stable Maintenance) (Note: clearly we could only do this with a strong set of expectations and checks and balances to prevent abuse, but it's an idea that's interesting to think about). I would like to think about this as a tight integrated release plus a large and solid ecosystem. These are things I'm going to push for going forward, whether or not I'm on the TC, however I think the idea of having the TC take more ownership of the integrated release, directly. We need an OpenStack base box set with more full and cohesive user experience (one that doesn't require understanding and maintaining multiple db systems), that is deployable at everything from small colleges and institutions, to giant places like wall street, telcos, and research institutions. And then we need to have space to promote great expansions to OpenStack the institutions can deploy as needed for their needs that a much freer to use exciting new technology to solve interesting problems. = Standard TC Questions = == How do you feel the technical community is doing in meeting the OpenStack Mission? == Our mission statement is: "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." (http://www.openstack.org/blog/2010/07/introducing-openstack/) I honestly feel like we're only doing an sort of OK job right now. I think that the current growth of services and they way we implement them (by bringing in a lot of new external dependencies) is not holding true to "being simple to implement". I think that's excluding the use of OpenStack at smaller institutions. If OpenStack is only in the toolchest for large sophisticated institutions, it will not become ubiquitous. Linux was deployed in production first by small ISPs, entities with only a few employees. If OpenStack can only be deployed by having a very skill integrator come on board, it by definition can't be Ubiquitous. My feelings around a smaller nucleus/layer/ring/zone/integrated release are largely shaped by my feeling that we're losing the smaller users of OpenStack. And that's something we can fix. == How do you feel the technical committee is doing in meeting the technical committee mission? == The 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. (https://wiki.openstack.org/wiki/Governance/Foundation/TechnicalCommittee) In the current TC, I'm one of the newest OpenStack community members. I was honestly surprised with how much TC time was spent evaluating new project requests (and this is growing over time). I think the TC mission for providing technical leadership and even understanding issues affecting multiple programs becomes very strained when the scope of that governance includes the whole OpenStack ecosystem. And I think it will limit the TC's effectiveness at having oversight when it is so far removed. == How would you characterize the various facets of contributor motivation? == I'm not really sure the intent of this question, but I'll take a swing at what the author might have intended. A very large amount of OpenStack work today is sponsored. Some of it is very vendor oriented for very specific features those vendors want in the OpenStack changelogs, some of it is people that love this community, and have found entities that will support that. The fact that a huge number of our community leaders are not working at the same company as when they started with OpenStack (including myself) speaks to that passion. I'd honestly like to see more small contributors, and more people feeling like they could make an impact to OpenStack even if the don't have the privilege to work on it full time. == There is no argument the OpenStack technical community has a substantial rate of growth. What are some of the consequences of this rate? == The rate of growth has very much meant that most contributors to projects only contribute to their one effort. The cultures in each project have grown quite different over time as to what's acceptable patch culture for each project, acceptable review culture, how bugs get handled, what's validated, and many more things. When I joined the projects one of the mantras for no non python OpenStack projects was that common language and common tooling would mean that developers and operators would have an easy time moving from one project to another to address an issue. I think the explosive growth we've seen, and the challenges with coherent integration of all these moving parts, has shown that there is a lot more to unified experience than common language and tooling. I think it has also very concretely strained the Horizontal efforts past their capacity points. Docs, QA, Stable Maint, Security, all very much have to now pick their battles and leave a lot on the cutting room floor. Take this example: I recently started working on the final Nova fixes for a cross project security issue that was made public 14 months ago - https://bugs.launchpad.net/keystone/+bug/1188189. It's honestly unclear if this has been completely addressed in other projects. == How would you characterize the experience new contributors have currently? == Terribad. 24 steps of CLA madness, multiple ids, signing stuff, to get to the point of submitting your first bug fix is insane. You have exactly one chance to make a first impression, and today I think the process of contributing to OpenStack prior to even uploading to Gerrit is onerous enough that we're preventing most of our best future OpenStack contributors from ever existing. This needs to change. == How would you describe our current state of communication in the OpenStack community? == I'm going to take "our" to mean all of us in the OpenStack community. And the best way I can say is fragmented. We have the mailing list, but with so many efforts being on list (Nova and Fuel being in the same list, for instance) it means that many things get lost. We have a vast array of per project IRC channels... though very little traffic on #openstack-dev. As far as I can tell only a very few core developers currently monitor #openstack-dev for interesting content, which adds huge burden to any cross project effort that's not got a dedicated cross project channel. == The technical committee interacts with the foundation board on several different fronts. How would you describe these interactions? == Confused? No, I mean I'm confused, because honestly there seems to be not that many fronts in which they interact. I was very mixed on DefCore because it seemed like so much of the important work there happened in face to face meetings in San Fran. And there kept being real confusion over intent. Beyond that I feel like there hasn't been a ton of Board / TC interaction. The joint Atlanta meetup was good, and I think some concerns that got raised in the room did get talked about. But I feel like there are actually quite different scopes of the Board trying to define the commercial ecosystem and market dynamics, and the TC trying to define a set of bits that do a thing. And hopefully keep doing that thing even when some more bits are added. Honestly, perhaps the disconnects that currently exist between the TC and the Board are largely around the fact that the only place our roles seem to overlap is near the trademark definition, and so vastly different perspectives exist based on the day to day challenges each face. = Final thoughts - caveats = I'll pre-apologize for any oddities in this write up, or if I missed context on questions that might have been surfaced on the mailing list. Or if people have noticed me absent in any community threads in the past week in which they expected to hear my voice (I have not read any email related to the project since Oct 3rd). I'm currently functioning under a bit of sleep deprevation after the arrival of our latest family member - https://twitter.com/sdague/status/519173169643388929, and will be disconnected from the community for the next couple weeks as I focus on family. I only broke the sabbatical because TC candidacy had an expiration date. Will be back roaring and raring to go by Paris. And will look forward to seeing you all there whether or not you want me back on the TC for another year. :) -Sean -- Sean Dague http://dague.net _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
