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

[Sean McGinnis]

> 
> 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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Thierry Carrez]

Rico Lin wrote:
> I 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.

I like the idea of asking a new project to tell us where they expect to
fit in the OpenStack Map[1]. Projects don't exist in a vacuum and the
more they fit in the existing layout / buckets the best the overall
"product" (framework of cooperating components) will look.

Personally I find that every time I have trouble placing a new project
on the map, it's symptomatic of a deeper issue (like unclear scope /
usage definition) that needs to be discussed early rather than late.

[1] https://www.openstack.org/openstack-map

-- 
Thierry Carrez (ttx)

__
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

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

[Rico Lin]

*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 :

> [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-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



--
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

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

[Zane Bitter]

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

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

[Graham Hayes]

On 23/04/18 14: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"?

Does the project basically promise "$OTHER_PROJECT but better"?
For example, for me, if a project re-created another projects API - I
would call that gratuitous.

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

It depends on the context - for example with deployment tooling,
companies may have pre existing DC orchestration tools, and having
and OpenStack deployment tool in $CONFIGMGMT can help people run
quicker.

Having 2 image stores, not so much, as there is then confusion about
what tool to deploy, or deploy both, and any issues may need to have 2
different solutions, or at least 2 patches.

There may be circumstances where 2 tools make sense (e.g. Messaging as a
Service did have 2 projects, but they served 2 different use cases, so
it made sense)

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

For deployment tooling - having the one true way to deploy OpenStack
would have made a lot of the work I have done in the last 4 or 5 years
redundant :) - We would probably be using bash scripts, but not having
people re-create the flow of installing OpenStack in $CFGMGMT_TOOL
de-jour in OpenStack may have focused resource. Or just forced
deployment teams out of OpenStack to somewhere else.

OS packing is definitely a good thing for duplication.

I don't think we have many service project areas that we have
duplication that would not have failed some of the stricter "culture
fit" discussions we have now had in the post Big Tent OpenStack.

We would have probably blocked things like Octavia (as Neutron LBaaS
existed), Designate (as Nova DNS was a thing back then), Monasca,
Neutron itself (as Nova Network was a thing).

> Doug
> 
> [1] 
> https://governance.openstack.org/tc/reference/new-projects-requirements.html
> 
> __
> 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
> 



signature.asc
Description: OpenPGP digital signature
__
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

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

[Chris Dent]

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__
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

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

[Thierry Carrez]

Doug Hellmann wrote:
> Where do you draw the line at "gratuitous"?

The way I interpret "gratuitous" here is: is the new project using a
technically-different approach to the same problem, or is it just
another group working at the same problem in the same way ? Is the new
project just a way to avoid openly collaborating with the existing group
? Is the new project just a way for a specific organization (or group of
organizations) to create something they have more control over ? That
would be gratuitous duplication, not motivated by a technical reason.

We don't really want copies or forks of projects that are just running
around the current group in charge. That should be solved at the
governance level (and it's the TC's role to address that).

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

I touched on that point a bit in my answer on considering new projects.
Allowing competition gives you options and lets a thousand flowers
bloom, but at the cost of adding complexity / dilution / confusion to
the "product" and making interoperability generally more difficult.

Generally, the closer to the "core" you are, the less competition you
should allow. It's OK to have multiple options for operational tooling
or deployment. It's less OK to have two Keystones that every component
now needs to be compatible with. Of course teh area between those two
extremes is all shades of grey.

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

I feel like we have been pretty strict with competitive projects. I fear
that being stricter would completely close the door to potential evolution.

-- 
Thierry Carrez (ttx)

__
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

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

[Zhipeng Huang]

I think this depends on the nature of the project.

For deployment tools, as we also have witnessed in OPNFV, it tends to have
multiple solutions. So it is normal to have multiple such projects although
they are solving the same problem generally speaking.

For projects that has a clear definition on a specific set of features of
functionalities which are critical to any cloud infrastructure, then
overlapping should be strictly avoided. I don't think for a team that
proposes a new project that got a significant overlap with existing project
has seriously studies the community or a good intention to collaborate
within the community.

Of course there will be exceptions for implementations in different langs
but generally I would prefer to take a strong stance on strictly avoiding
the overlap. The benefit we would got as a community is that we will have
developers working on projects that is clearly defined both individually
and collaboratively without any confusion.






On Mon, Apr 23, 2018 at 9:50 PM, 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"?
>
> 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-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
__
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

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

[Doug Hellmann]

[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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev