[openstack-dev] [tc] campaign question: How should we handle projects with overlapping feature sets?

Chris Dent cdent+os at anticdent.org
Mon Apr 23 16:02:41 UTC 2018


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


More information about the OpenStack-dev mailing list