On 23/04/18 09:50, Doug Hellmann wrote:
[This is meant to be one of (I hope) several conversation-provoking
questions directed at prospective TC members to help the community
understand their positions before considering how to vote in the
ongoing election.]
In the course of evaluating new projects that have asked to join
as official members of the OpenStack community, we often discuss
whether the feature set of the project overlaps too much with other
existing projects. This came up within the last year during Glare's
application, and more recently as part of the Adjutant application.
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'd want to see sound technical reasons for taking a different approach
that addresses, or partially addresses, the same problem. If people are
starting their own projects to avoid having to work with the existing
team then I'd label that gratuitous.
Evidence of co-operation with the existing project, and the provision of
migration paths for existing operators and users, would be points in
favour of a project wanting to go down this route.
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?
We used to have that rule, of course, and the primary result was that
some folks who were for all intents and purposes part of our community
got left out in the cold, officially speaking, only because some other
folks got there first. I don't think it even contributed much to
interoperability - Monasca is the project that comes to mind, and people
who wanted to run that instead of Ceilometer did so regardless of the
official status.
On the other hand, the Telemetry projects have completely transformed
themselves since the days when people used to complain about the
scalability of Ceilometer, and they did so while maintaining an orderly
deprecation and migration of the APIs. Perhaps if if we'd doubled down
on that path we'd have ended up with less fragmentation for the same
benefit?
It's really hard to say, and I think that is perhaps the point. None of
us have all that much confidence in our ability to predict the future,
so we have chosen to err on the side of not picking winners.
cheers,
Zane.
__________________________________________________________________________
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
