Open Stack

On 19/09/14 22:37, Monty Taylor wrote:
> I think we can do what you're saying and generalize a little bit. What
> if we declared programs, as needed, when we think there is a need to
> "pick a winner". (I think we can all agree that early winner picking is
> an unintended but very real side effect of the current system)

Ooh, a challenge. I'll bite ;)

Here's a question: how many instances are there of two Stackforge 
projects working on the same problem domain? I can think of one example: 
Gnocchi and StackTach - though those are (respectively) a branch of and 
a sort-of competitor to an integrated project (where we supposedly 
"picked the winner" already).

So we have evidence of competitors surviving the picking of a winner, 
but not a lot of evidence of competition in general. (To be fair, you 
could make an argument that people are being put off starting competing 
projects by the prospect of eventually having to submit to 
winner-picking by the TC.)

Don't get me wrong, I think it's clear that our implicit hope for the 
current model - that picking a winner would mean everyone getting on 
board with that project and making it better - has failed to 
materialise. But there's also every reason to think that a model where 
we rely on competition between projects in the marketplace to determine 
a winner owes just as much to wishful thinking.

I suspect that part of the problem is that there are so many different 
things any given person could be working on to make users' lives better 
that when they see a project whose approach they don't agree with, 
they're more likely to just go work on something else than start a 
competitor or jump in to try and change the direction. (In fact, the 
people most qualified to do so are almost by definition the most busy 
already.) Maybe just throw a few rocks right before the graduation 
review, that sort of thing.

If you were hoping this email would end with some kind of proposed 
solution, prepare for disappointment.

Early winner-picking obviously sucks for the developer who realises that 
they need to make major changes and has to deal with the extra challenge 
of maintaining API compatibility and upgradability while doing it. On 
the other hand, it sucks precisely because that's great for users and 
operators. A competition model, even assuming that the competition 
actually arises, just means that the portion of operators who chose the 
'wrong' side and their users get hosed when an eventual winner emerges. 
Potential consequences include delayed interoperability, delayed 
adoption of new features altogether to avoid the risk, or even permanent 
lack of interoperability with proprietary solutions being used instead.

The only suggestion I can make is one I mentioned in another thread[1]: 
establish a design principle that the parts of the design which are hard 
to change (e.g. APIs) must be a simple as possible in order to provide 
the maximum flexibility of implementation, until such time as both the 
implementation and the need for more complexity have been validated in 
the real world.

cheers,
Zane.


[1] 
http://lists.openstack.org/pipermail/openstack-dev/2014-September/046563.html