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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
