[openstack-dev] TC Candidacy

Elizabeth K. Joseph lyz at princessleia.com
Wed Apr 22 18:39:45 UTC 2015


confirmed


On Wed, Apr 22, 2015 at 11:19 AM, Zane Bitter <zbitter at redhat.com> wrote:
> 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Elizabeth Krumbach Joseph || Lyz || pleia2



More information about the OpenStack-dev mailing list