Open Stack

Excerpts from Jay Pipes's message of 2014-08-20 14:53:22 -0700:
> On 08/20/2014 05:06 PM, Chris Friesen wrote:
> > On 08/20/2014 07:21 AM, Jay Pipes wrote:
> >> Hi Thierry, thanks for the reply. Comments inline. :)
> >>
> >> On 08/20/2014 06:32 AM, Thierry Carrez wrote:
> >>> If we want to follow your model, we probably would have to dissolve
> >>> programs as they stand right now, and have blessed categories on one
> >>> side, and teams on the other (with projects from some teams being
> >>> blessed as the current solution).
> >>
> >> Why do we have to have "blessed" categories at all? I'd like to think of
> >> a day when the TC isn't picking winners or losers at all. Level the
> >> playing field and let the quality of the projects themselves determine
> >> the winner in the space. Stop the incubation and graduation madness and
> >> change the role of the TC to instead play an advisory role to upcoming
> >> (and existing!) projects on the best ways to integrate with other
> >> OpenStack projects, if integration is something that is natural for the
> >> project to work towards.
> >
> > It seems to me that at some point you need to have a recommended way of
> > doing things, otherwise it's going to be *really hard* for someone to
> > bring up an OpenStack installation.
> 
> Why can't there be multiple recommended ways of setting up an OpenStack 
> installation? Matter of fact, in reality, there already are multiple 
> recommended ways of setting up an OpenStack installation, aren't there?
> 
> There's multiple distributions of OpenStack, multiple ways of doing 
> bare-metal deployment, multiple ways of deploying different message 
> queues and DBs, multiple ways of establishing networking, multiple open 
> and proprietary monitoring systems to choose from, etc. And I don't 
> really see anything wrong with that.
> 

This is an argument for loosely coupling things, rather than tightly
integrating things. You will almost always win my vote with that sort of
movement, and you have here. +1.

> > We already run into issues with something as basic as competing SQL
> > databases.
> 
> If the TC suddenly said "Only MySQL will be supported", that would not 
> mean that the greater OpenStack community would be served better. It 
> would just unnecessarily take options away from deployers.
> 

This is really where "supported" becomes the mutex binding us all. The
more "supported" options, the larger the matrix, the more complex a
user's decision process becomes.

>  > If every component has several competing implementations and
> > none of them are "official" how many more interaction issues are going
> > to trip us up?
> 
> IMO, OpenStack should be about choice. Choice of hypervisor, choice of 
> DB and MQ infrastructure, choice of operating systems, choice of storage 
> vendors, choice of networking vendors.
> 

Err, uh. I think OpenStack should be about users. If having 400 choices
means users are just confused, then OpenStack becomes nothing and
everything all at once. Choices should be part of the whole not when 1%
of the market wants a choice, but when 20%+ of the market _requires_
a choice.

What we shouldn't do is harm that 1%'s ability to be successful. We should
foster it and help it grow, but we don't just pull it into the program and
say "You're ALSO in OpenStack now!" and we also don't want to force those
users to make a hard choice because the better solution is not blessed.

> If there are multiple actively-developed projects that address the same 
> problem space, I think it serves our OpenStack users best to let the 
> projects work things out themselves and let the cream rise to the top. 
> If the cream ends up being one of those projects, so be it. If the cream 
> ends up being a mix of both projects, so be it. The production community 
> will end up determining what that cream should be based on what it 
> deploys into its clouds and what input it supplies to the teams working 
> on competing implementations.
> 

I'm really not a fan of making it a competitive market. If a space has a
diverse set of problems, we can expect it will have a diverse set of
solutions that overlap. But that doesn't mean they both need to drive
toward making that overlap all-encompassing. Sometimes that happens and
it is good, and sometimes that happens and it causes horrible bloat.

> And who knows... what works or is recommended by one deployer may not be 
> what is best for another type of deployer and I believe we (the 
> TC/governance) do a disservice to our user community by picking a winner 
> in a space too early (or continuing to pick a winner in a clearly 
> unsettled space).
> 

Right, I think our current situation crowds out diversity, when what we
want to do is enable it, without confusing the users.