+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.bottom...@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 __________________________________________________________________________ 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
