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) __________________________________________________________________________ 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
