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

Rico Lin rico.lin.guanyu at gmail.com
Mon Apr 23 17:00:10 UTC 2018


*Thanks, Doug for bringing out this campaign questionI think we have a
start now with providing a decent map to show services in OpenStack and
fill in with projects. What we should have and will be nice is to ask
projects to search through the map (with a brief introduction of services)
when they're registering. To prevent overlapping from the very beginning
seems to be the most ideal, which might also mean it's actually our
responsibility to search through what exactly a project aims to and what
kind of feature it will provide when we allow people to register a project.
We can also discuss about to let projects know that we encourage new ideas
but we not encourage provides overlapping features just because you think
the service is bad and you don't like to fix it (IMO to encourage people to
point out problems and even try to fix it is very important when talking
about continuing efforts). And to give credits instead of warnings might
work better.* How (and whether) the community would be able to replace the
implementationof any given component with a new set of technologies by
"startingfrom scratch".With try to make such action as a long-term
community goal, might be possible to said we're able to do it (if this new
technology does matters, like containerize), and it might be even better
than wait for people to pick up the job and keep asking him `are we there
yet?`. We have to be really careful to prevent changing the behavior of
services or cause a huge burden to developers.* Where do you draw the line
at "gratuitous"?When a project is about more than 80% chances to dead or no
maintainer, and pure overlapping effort.* What benefits and drawbacks do
you see in supporting multiple toolswith similar features?It's good and
allow people from multiple tools to help construct the bridge to us
together. What I concern is we should try to decide a pattern and make it a
success instead of letting parallel jobs works on similar features. So we
can have a preview version of all other paths. And if we can make sure our
success path first, we can even look back and provide features plus bug
fixes to other tools. That brings a question back, `what're users using the
most?`* How would our community be different, in positive and negative
ways,if we were more strict about avoiding such overlap?To allow
concentrate our development energy on features, also to prevent lack of
diversity/ideas/activity for those projects we promise to provide guideline
when we allow them to stay under TC's governance. What we should also try
to prevent it when it's overlap but exists project didn't provide fair
communication or close their mind to new features/fixes. Which we should
strong/change part of our TC resolutions and prevent this because that
might just lead to a negative way that people quitting on providing new
innovation.*



May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin


2018-04-23 21:50 GMT+08:00 Doug Hellmann <doug at doughellmann.com>:

> [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"?
>
> 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?
>
> Doug
>
> [1] https://governance.openstack.org/tc/reference/new-projects-
> requirements.html
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180424/e8e57c6a/attachment.html>


More information about the OpenStack-dev mailing list