> > 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. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
