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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
