confirmed
On Wed, Apr 22, 2015 at 11:19 AM, Zane Bitter <zbit...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Elizabeth Krumbach Joseph || Lyz || pleia2 __________________________________________________________________________ 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