Open Stack

> 
> Our current policy regarding Open Development is that a project
> should cooperate with existing projects "rather than gratuitously
> competing or reinventing the wheel." [1] The flexibility provided
> by the use of the term "gratuitously" has allowed us to support
> multiple solutions in the deployment and telemetry problem spaces.
> At the same time it has left us with questions about how (and
> whether) the community would be able to replace the implementation
> of any given component with a new set of technologies by "starting
> from scratch".
> 
> Where do you draw the line at "gratuitous"?

I'm sure I can be swayed in a lot of cases, but I think if a new project can
show that there is a need for the overlap, or at least explain a reasonable
explanation for it, then I would not consider it gratuitous.

For example, if they were addressing a slightly different problem space that
has some additional needs, but as part of meeting those needs they need to have
a foundation or component of it that is an overlap with existing functionality,
then there may be some justification for the overlap.

Ideally, I would first like to see if the project can just use the services of
the other project and just build on top of their APIs to add their additional
functionality. But I know that is not always as easy as it would first appear,
so I think if they can state why that would be impossible, or at least
prohibively difficult, then I think an overlap would be OK.

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

It definitely can cause confusion for downstream consumers. Either for those
looking at which services to select for new deployments, or for consumers of
those clouds with knowing what functionality is available to them and how they
access it.

Hopefully more clearly defined constellations would help with that.

A blocker for me would be if the newer project attempt to emulate the API of
the older project, but was not able to provide 100% parity with the existing
functionality. If there is overlap, it needs to be very clearly separated into
a different (although maybe very similar) API and endpoint so we are not
putting this complexity and need for service awareness on the end consumers of
the services.

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

I think a positive could be that it stimulates more activity in a given area so
that ultimately better and more feature rich services are offered as part of
OpenStack clouds. And as long as it is not just gratuitous, it could enable new
use cases that are not currently possible or outside the scope of any existing
projects.

I really liked the point that Chris made about it possibly revitalizing
developers by having something new and exciting to work on. Or for those
existing projects, maybe getting them excited to work on slightly different use
cases or collaborating with this new project to look at ways they can work
together.

As far as negative, I think it is very similar to what I pointed out above for
deployers and users. It has the potential to cause some confusion in the
community as to where certain functionality should live and where they should
go to if they need to interact or use that functionality in their projects.

One of the negatives brought up in the Glare discussion, since that was brought
up, would be for other projects if they had to add conditional code to
determine if they are interacting with Glance or with Glare for images. I think
that falls under the points earlier about there needs to be a clear separation
and focus on specific use cases so there are not two options doing very similar
things, but with APIs that are not compatible or close but different. I would
hope that we do not allow something like that to happen - at least without a
very good reason for needing to do so.