Open Stack

Hello Stackists,
I'd like to announce my candidacy for the OpenStack Technical Committee.

I'm running because I don't think that the diversity of perspectives 
amongst TC members reflects the diversity of our community. We're 
fortunate to have a few people whose brilliance often transcends the 
scope of their day-to-day focus, but I don't think that can outweigh the 
fact that (by my, arguable, count) 12 out of 13 are focused primarily on 
Nova and the projects (including cross-project efforts) that evolved 
directly out of it.

When a group of people share a common vision and goal, they can pretty 
much always figure out a way to work together toward it. When they 
don't, they have to invent rules and structure and bureaucracy to keep 
everyone in line.[1] I... think we need to work more on the vision thing 
;) Thierry calls it 'stepping out of the way', but I think of it as 
stepping up, out of the weeds, to look at the bigger picture.

My hope is that in a decade or two, developers will prefer to write 
their new applications against Open Source implementations of open APIs 
- and not just to avoid lock-in, but because they'll be as good or 
better than proprietary alternatives. Linux has already made that a 
reality at the level of individual servers - and while offering refuge 
from proprietary Unixes (Unices?) for legacy applications was no doubt a 
critical (and lucrative) part of getting there, it's much more important 
in the long run that it's also the preferred platform for new 
development. Today a growing fraction of applications are bigger than a 
single server, and I believe that OpenStack represents our best 
opportunity to make sure that in the future open source cloud APIs will 
be the preferred choice too.

The big tent is a great start - it allows a project to assure 
contributors that they are committed to truly open[2] governance long 
before it matures to the point where it could have been incubated under 
the previous process. And after all, the most powerful technologies 
we've developed are social, and we shouldn't be reluctant to use them. 
However, if only a small section in the middle of the tent is 
waterproof, then the big tent exists in name only. We have to make sure 
we continue to help and guide all of the projects as they grow and 
mature - getting them in the tent is only the first step. I am strongly 
opposed to the TC using the tagging system to identify use cases it 
thinks are important - the community can and will decide for itself what 
is important. (Of course I support using the tagging system to provide 
more information that the community can use to evaluate projects for 
themselves, and more long-form documentation of use cases where that is 
lacking.) I believe in abundance, not scarcity: when our community 
provides space for participants to work on problems they care about we 
don't weaken the existing projects, we actually strengthen the community 
by increasing its critical mass. (In other words, we may have a 
task-allocation problem, but we shouldn't mistake it for a 
project-allocation problem since it will require different solutions.)

Right now we're missing a lot of fundamental building blocks - like 
user-configurable authorisation, and public-facing asynchronous 
messaging - that we need to allow workloads running in a cloud to 
interact with it. As a result, a lot of projects that should be tightly 
(small-i) integrated (but loosely coupled!) with each other are 
developing in an ad hoc manner, and a lot of technical problems are 
being solved over and over, often badly. The pre-big-tent regime gave an 
incentive to new projects not to work together, and we need to reverse 
that effect. The TC needs to boost the confidence of OpenStack 
developers to simplify things by taking dependencies on other projects 
where appropriate, and I think the best way to do that is to kick off an 
ongoing discussion about the vision for and design of OpenStack at a 
level above that of indivudual projects. (We've made a good start on 
cross-project co-ordination at a _lower_ level, like the API working 
group, but to do so at a higher level will require the TC's blessing.)


In case you don't know me, I'm a core developer of Heat and I've been 
involved in OpenStack since the Heat project kicked off about 3 years 
ago. I'm also a former elected PTL, and I've been working closely with 
the TC since Heat applied for incubation back around the time of the 
Grizzly summit. I've attended most TC meetings for at least the past 18 
months, so I'm already up to speed with what has been happening. 
Finally, I currently lead a team at Red Hat developing (upstream!) tools 
for updating OpenStack deployments - which is another way of saying that 
few people are more motivated to make deployment easier than I ;)

Thanks for reading this far. Please make time to read the other 
candidate bios (especially Jay's), think about _your_ vision for 
OpenStack, engage with the process and VOTE! It's really important.

cheers,
Zane.

[1] This isn't an original idea, nor likely an accurate paraphrasing of 
it - I stole it from a source I can't pinpoint at the moment.
[2] https://wiki.openstack.org/wiki/Open