Open Stack

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160720/807333ce/attachment.pgp>