Open Stack

Doug Hellmann wrote:
> Where do you draw the line at "gratuitous"?

The way I interpret "gratuitous" here is: is the new project using a
technically-different approach to the same problem, or is it just
another group working at the same problem in the same way ? Is the new
project just a way to avoid openly collaborating with the existing group
? Is the new project just a way for a specific organization (or group of
organizations) to create something they have more control over ? That
would be gratuitous duplication, not motivated by a technical reason.

We don't really want copies or forks of projects that are just running
around the current group in charge. That should be solved at the
governance level (and it's the TC's role to address that).

> What benefits and drawbacks do you see in supporting multiple tools
> with similar features?

I touched on that point a bit in my answer on considering new projects.
Allowing competition gives you options and lets a thousand flowers
bloom, but at the cost of adding complexity / dilution / confusion to
the "product" and making interoperability generally more difficult.

Generally, the closer to the "core" you are, the less competition you
should allow. It's OK to have multiple options for operational tooling
or deployment. It's less OK to have two Keystones that every component
now needs to be compatible with. Of course teh area between those two
extremes is all shades of grey.

> How would our community be different, in positive and negative ways,
> if we were more strict about avoiding such overlap?

I feel like we have been pretty strict with competitive projects. I fear
that being stricter would completely close the door to potential evolution.

-- 
Thierry Carrez (ttx)