Open Stack

Hello list,

I'm announcing my candidacy for the Technical Committee elections.

I have been serving as the chair of the Technical Committee since its
inception, but I think we are at a critical point in the evolution of
the role of the Technical Committee, and if you allow it, I'd like to be
around to help drive us through this transition.

In particular, I'd like the Technical Committee to push in 3 new
directions during the Liberty cycle:


1. Step out of the way

As I explained on [1], I think over the last cycles the TC pushed the
regulation and "ask for permission" cursor so far we actually start
preventing things from happening. I'd like us to come back to a point
where our community is more trusted by default, where it asks more for
forgiveness and less for permission. So I'd like the Technical Committee
to look into its processes and see where it can remove itself from the
action pipeline, and retreat back to being an appeals board should a
problem arise.

[1] http://ttx.re/stepping-out-of-the-way.html


2. Start addressing real issues

I think it is part of the role of the Technical Committee members to
detect, investigate and help solving issues in our development
community. As we grow, we can't expect every member to know everything
about every project in OpenStack. But each member should be able to dive
into specific project(s) and report issues to the group. Subgroups of
members should be able to work together on proposing plans to solve
long-standing issues. That means spending more than one hour per week on
TC matters, which is why I'd like us to give preference in TC elections
to candidates who have enough time on their hands, as explained on [2].

[2] http://ttx.re/tech-committee-candidates.html


3. Push toward both ends of the scale space

Taking a step back on those last 5 years, I think the natural forces
behind OpenStack development made us cover the middle-tier of usage
quite well: reasonably large private IaaS systems (~10k VMs) with a need
for extra features and accepting the resulting complexity. They did not
make us cover the hyper-scale end (public clouds with millions of VMs in
a very active usage pattern) that well, because that end
is a specific use case that needs specific trade-offs, and not so many
users need/push those. And it did not make us cover the basic system
end, where people want to deploy a base IaaS compute system without
bells and whistles, and without a team of 100 admins, most of them SDN
specialists.

Our development ecosystem won't naturally go and cover those use cases
(lack of business and/or market), but those are essential long-term. We
all need extremely-large OpenStack public clouds to burst hybrid
workloads to. And we all need people to be able to experiment with
OpenStack in POCs, labs and universities. This is the two directions I
want to encourage in the near future.


More generally, I think it is the role of the Technical Committee
members to provide a long-term vision. To influence where we are going,
beyond where the market forces push us. To inspire our developers to
work (or support work) to cover areas that their employer might not
immediately care about in the short term. To make OpenStack better and
more universal in the long run.

Thanks for your consideration,

-- 
Thierry Carrez (ttx)