On Mon, 23 Apr 2018, Doug Hellmann wrote:
Where do you draw the line at "gratuitous"?What benefits and drawbacks do you see in supporting multiple tools with similar features? How would our community be different, in positive and negative ways, if we were more strict about avoiding such overlap?
This is a tough question. We've held API stability and interoperability as such important factors that any discussion of overlapping of competing projects has to consider whether we are willing to bend on that. It's also never been entirely clear the extent to which new projects eat into the resource pool that is available to existing projects. But if we set aside those issues for a moment: I would say that "gratuitous" overlap would be when a project wants to provide a service similar to one that already exists and has failed utterly to engage with the existing service. It would not, however, be gratuitous if a potential project, after presenting their alternate proposal to the similar project and getting a "not interested" or "we can't attend to that any time in the next $TIME_PERIOD", chose to go ahead. For example, one can imagine a world where someone thinks up a project to create a different service for managing VMs. One that intends to "innovate" in the compute API space (breaking compatibility with nova's API) and manage compute nodes using etcd in a way somewhat like Kubernetes. Nova is approached and says "yeah, interesting, but not going to happen, we are booked up solid for the next two years". If the people involved in the potential project are numerous and diverse enough to have a chance of getting something done, then I think they should be encouraged, for the sake of innovation, diversity, attracting new contributors and leapfrogging ourselves into the future. It's quite likely that during discussions a "compute api v2.x compatibility layer" would be negotiated. A real world example where things could have gone better is with Mogan: https://review.openstack.org/#/c/508400/ There are some fairly obvious costs from overlapping projects: * potential drains on the resource pool * confusion and churn for people downstream (packagers, client makers, deployers, every day users) These are potentially countered by: * new or rejuvenated contributors, inspired by new stuff * advancements in capability provided by new technologies * a potential for positive and collaborative competition between the two related projects People's needs evolve and change. OpenStack needs to as well. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent
__________________________________________________________________________ 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