The OpenStack Technical Committee (the "TC") is:

one of the governing bodies of the OpenStack project. It is an elected group that represents the contributors to the project, and has oversight on all technical matters.

A portion of the TC is elected every 6 months for a year long term by OpenStack contributors. TC members are usually well known and respected in the community. They get elected by virtue of long tenure and a history of valuable contributions that are visible to a wide swath of the contributors.

I have neither the long tenure nor the depth and breadth of contribution that would warrant being a suitable candidate for the TC. Nor would I likely tolerate the style and pace of process in the group.

However, it is interesting to think about what issues I would want to keep at the front of my mind if I were representing the "contributors to the project". These are the issue that I think are relevant to not just the quality or existence of OpenStack itself but the quality and experience of contributing to it.

Product Not Kit

In a recent email thread I had a misconception cleared up. From the start I've been thinking that the OpenStack community is creating a thing which is OpenStack, a product for clouds. That thread said "OpenStack is a community creating a collection of tools for building clouds" and indicated that it is a "kit" not a "product".

That may be true, at least to some, but I think it is a mistake. We cannot effectively reach our goal of interoperable but disparate clouds if everyone can build their own custom cloud by picking and choosing their own pieces from a collection. Nor can we can create something that has the unity of purpose that leads to quality.

One of the roles of the TC should be to gather and establish the vision that unifies the purpose.

Shrink The Tent, Open The Field

The big tent has opened the doors for a lot of projects to make use of the OpenStack CI and benefit from the brand. That's great for them, but is it great for OpenStack? It dilutes the "unity of purpose". There's nothing wrong with many of these projects, but is there any reason they should be a part of OpenStack?

The big tent, though big, implies certain approaches to solving problems, technical and social. That these work well for the existing OpenStack projects is an accident of history. New projects which do not specifically address OpenStack needs should not limit themselves to those constraints simply to gain a marketing advantage or credibility in some environments.

Being outside the big tent makes it easier for a tool to satisfy a diversity of systems, including but not limited to OpenStack. We don't want to recapitulate the errors of Zope in OpenStack do we?

By saying "no" to candidate projects more often, the TC can help to keep the OpenStack ecosystem healthy: keeping it small and focused, with contractually strong APIs, and allowing it to continue to be an exceptionally active member of and user of the larger open source community. Think global, act local and all that.

Developers Unite

Two more recent email threads have explored ideas on how to change the design summit so that it can be more effective for technical contributors. It's been a productive discussion with several interesting ideas. A common fear, however, comes from contributors who are worried that without the availability of the marketing side of the current summits their existing difficulties getting justification for travel will be compounded.

This is appalling. Presumably when the various companies involved in OpenStack chose to be involved, they knew it was not just an open source project but a broadly distributed open source project. They also knew, if they've been paying attention for the last decade or so, that while it can be extremely effective to do development in a distributed fashion there are huge advantages to doing design and planning (the actual deciding of what to develop) in person. Getting the developers together is a cost of doing business. If the employers want quality grist for their products they have to pay up.

It's unclear how the TC could put any weight on this issue but it, at least, shouldn't be let to lie without comment and resistance.

Stop Calling It Cross Project

A frequent moan in the OpenStack community is the difficulty that so-called cross-project tasks have in getting the attention they need in face of project tasks. I think that's what you get if you insist on treating the product as a kit and the project as a tent. These needs are not cross-project tasks; they are OpenStack tasks.

A good example is the state of the messaging bus. We appear to accept its shortcomings with relative aplomb and limit our choice of solutions to things it can cope with. It's 2016, the messaging bus should be the sine qua non that we buff to a high gloss.

We, as a community need, to treat OpenStack tasks as such. The TC, as the people with "technical oversight over all of OpenStack" need to push harder (yes, they already do push, but harder) to orchestrate and encourage building a quality OpenStack that has a clear purpose.

P.S. When I write things like this someone, a pragmatist, will often show up to remind me of a harsh economic reality that I'm forgetting. Thanks, but that's probably not necessary: Though I'm rarely accepting of perceived economic constraints I'm far too aware of them.