Open Stack

+1 to the finding of a middle ground.

The problem I've seen with your suggested OpenSource solution is the current social monetary system of OpenStack makes it extremely difficult.

Each project currently prints its own currency. Reviews. It takes quite a few Reviews (time/effort) on a project to gain enough currency that you get payed attention to. And, one project doesn't honor another projects currency.

When these sorts of major cross project things need to be done though, you need to have folks with capital in many different projects and its very difficult to amass that much.

There is no OpenStack level currency (other then being elected as a TC member) that gets one project to stop and take the time to carefully consider what someone is saying when bringing up cross project issues.

Without some shared currency, then the problem becomes, the person invested in getting a solution, can propose and prototype and implement the feature all they want (often several times), but it never actually is accepted into the projects because a project:
 a) doesn't take the time to really understand the problem, feeling its trivial and just not accepting any reviews
 b) doesn't take the time to really understand the problem, so minimize it in their mind to a 'you should just use existing thing X...' or a heavy handily propose alternate solutions that really aren't solutions.
 c) they decide its better handled by another project and stall/block reviews, trying to push the implementation to go elsewhere. When multiple projects decide this, the ball just keeps getting bounced around without any solution for years.

The status quo is not working here. The current governance structure doesn't support progress.

Thanks,
Kevin
________________________________________
From: James Bottomley [James.Bottomley at HansenPartnership.com]
Sent: Wednesday, July 20, 2016 8:31 AM
To: OpenStack Development Mailing List (not for usage questions); Clint Byrum
Subject: Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins for all)

On Wed, 2016-07-20 at 11:58 +0200, Julien Danjou wrote:
> On Tue, Jul 19 2016, Clint Byrum wrote:
>
> > Perhaps if we form and start working together as a group, we can
> > disect why nothing happened, build consensus on the most important
> > thing to do next, and actually fix some architectural problems.

Architecture is often blamed for lack of interlock but most people
forget that the need for interlock often isn't appreciated until after
the components are built.  This is why a lot of people embrace agile
methodology (an excuse for not seeing the problem a priori).

Conversely, architects who try to foresee all interlocks often end up
with a combinatorial explosion that makes it a huge burden simply to
begin the project (and then often get sidelined as 'powerpoint
engineers').

The trick is to do something in the middle: try to foresee and build
the most common interlocks, but sidestep the combinatorial explosion by
building something simple enough to adapt to any interlock requirement
that arises after completion.

> >  The social structure that teams have is a huge part of the
> > deadlock we find ourselves in with certain controversial changes.
> > The idea is to unroll the dependency loop and start _somewhere_
> > rather than where a lot of these efforts die: starting
> > _everywhere_.
>
> I agree with your analysis, but I fail to see how e.g. a group of
> people X stating that Y should work this way in Cinder is going to
> achieve any change if nobody from Cinder is in X from the beginning.
>
> This is basically what seems to happen in many [working] groups as
> far as I can see.

So this is where the Open Source method takes over.  Change is produced
by those people who most care about it because they're invested.  To
take your Cinder example, you're unlikely to find them within Cinder
because any project has inertia that resists change.  It takes the
energy of the outside group X to force the change to Y, but this means
that X often gets to propose, develop and even code Y.  Essentially
they become drive by coders for Cinder.  This is where Open Source
differs from Enterprise because you have the code and the access, you
can do this.  However, you have to remember the inertia problem and
build what you're trying to do as incrementally as possible: the larger
the change, the bigger the resistance to it.  It's also a good test of
the value of the change: if group X can't really be bothered to code it
(and Cinder doesn't want it) then perhaps there's not really enough
value in it anyway and it shouldn't happen.

This latter observation is also an improvement over the enterprise
methods because enterprise architects do often mandate interlocks that
later turn out to be unnecessary (or at least of a lot less value than
was initially thought).

I suppose the executive summary of the above is that I don't think
you're describing a bug, I think you're describing a feature.

James