Re: Additions to Cassandra ecosystem page?

[Lorina Poland]

I agree with Ben - why can other Apache communities navigate this issue,
and Apache Cassandra cannot?

I think that we grow the community when we make people aware of how
Cassandra is used. Why make new users to Cassandra search for things that
we all know exist? Help them to discover!
I would like to open the list of C* products, C*-like products, and
C*-related software as wide as possible. Again, it can only be to Apache
Cassandra's advantage to have a large group of people using
Cassandra and Cassandra-related software. Then make Apache Cassandra so
damn good that it's what people want to use.

Lorina

On Wed, Jun 30, 2021 at 9:03 PM Ben Bromhead  wrote:

> I would be sad to see us drop this just because it's a hard discussion with
> a few different opinions. My apologies if this discussion is making folks
> feel excluded.
>
> Whilst I don't have a problem with a strict approach and it does improve
> user clarity. I can understand how it might feel exclusionary. Having
> classifications can make the tent bigger and allow for things that are API
> compatible to be celebrated (the owners of some of the API compatible
> offerings make significant contributions to the community and I would love
> for them to be on the list).
>
> Having some classification would better allow us to celebrate the different
> offerings in the community and be more inclusive without misrepresenting
> things to our users and making it easy to meet our obligations around how
> we talk about Apache trademarks.
>
> Part of demonstrating the health of the project is to talk about the
> broader ecosystem around it.  Most other communities can seem to maintain
> an ecosystem list that is fairly broad.
>
> E.g.
> Apache Kafka ->
> https://cwiki.apache.org/confluence/display/KAFKA/Ecosystem
> - Maintains a set of groupings and listings. Also listed projects could be
> considered quite competitive.
> Apache Spark -> A simple list of folk who use or do something with spark
> https://spark.apache.org/powered-by.html
> Apache Samza -> Again a simple list
> http://samza.incubator.apache.org/powered-by/
>
> Outside of the Apache landscape. The Postgres folk also simply have a list
> of derived or adjacent PG databases which is kinda cool
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.postgresql.org_wiki_PostgreSQL-5Fderived-5Fdatabases&d=DwIFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=bL2UpIjL4Mm1mCbqWThJUiPD-CmTXMALsIT2Ta-KfGk&m=CYtMBYwxhvN_OeCccFJ5-f88svNuwiGFg3pUEfeFtFw&s=yPqqmvHn4JhmTBaHeOMO4VA33OaXbTAUN53_1w1xuyw&e=
> .
>
> Personally I think including the "API compatible offerings" is fine and
> further demonstrates the power and reach of our community. For the
> commercial vendors out there we have our marketing budgets and will do fine
> (as Patrick said), but I would hate to see an opportunity to demonstrate
> the breadth and depth of our community be missed.
>
> As demonstrated with some of the above links, there should be a good
> inclusive solution out there.
>
>
> On Thu, Jul 1, 2021 at 2:33 PM Erick Ramirez 
> wrote:
>
> > >
> > > And I'm thinking of anyone that has to update this list and reason
> > through
> > > all of the complex rulesets of why or why not, It's really not fair to
> > > them.
> >
> > My proposal is that we completely drop the Cassandra Cloud Offereing
> > > section.
> > > Given that criteria, Professional Support and Education might be on the
> > > chopping
> > > block as well.
> > >
> >
> > +1 would definitely make my life easier when I'm reviewing/pushing
> updates
> > to the site. 🍻
> >
>
>
> --
>
> Ben Bromhead
>
> Instaclustr | www.instaclustr.com | @instaclustr
>  | +64 27 383 8975
>

Re: Additions to Cassandra ecosystem page?

[Ben Bromhead]

I would be sad to see us drop this just because it's a hard discussion with
a few different opinions. My apologies if this discussion is making folks
feel excluded.

Whilst I don't have a problem with a strict approach and it does improve
user clarity. I can understand how it might feel exclusionary. Having
classifications can make the tent bigger and allow for things that are API
compatible to be celebrated (the owners of some of the API compatible
offerings make significant contributions to the community and I would love
for them to be on the list).

Having some classification would better allow us to celebrate the different
offerings in the community and be more inclusive without misrepresenting
things to our users and making it easy to meet our obligations around how
we talk about Apache trademarks.

Part of demonstrating the health of the project is to talk about the
broader ecosystem around it.  Most other communities can seem to maintain
an ecosystem list that is fairly broad.

E.g.
Apache Kafka -> https://cwiki.apache.org/confluence/display/KAFKA/Ecosystem
- Maintains a set of groupings and listings. Also listed projects could be
considered quite competitive.
Apache Spark -> A simple list of folk who use or do something with spark
https://spark.apache.org/powered-by.html
Apache Samza -> Again a simple list
http://samza.incubator.apache.org/powered-by/

Outside of the Apache landscape. The Postgres folk also simply have a list
of derived or adjacent PG databases which is kinda cool
https://wiki.postgresql.org/wiki/PostgreSQL_derived_databases.

Personally I think including the "API compatible offerings" is fine and
further demonstrates the power and reach of our community. For the
commercial vendors out there we have our marketing budgets and will do fine
(as Patrick said), but I would hate to see an opportunity to demonstrate
the breadth and depth of our community be missed.

As demonstrated with some of the above links, there should be a good
inclusive solution out there.


On Thu, Jul 1, 2021 at 2:33 PM Erick Ramirez 
wrote:

> >
> > And I'm thinking of anyone that has to update this list and reason
> through
> > all of the complex rulesets of why or why not, It's really not fair to
> > them.
>
> My proposal is that we completely drop the Cassandra Cloud Offereing
> > section.
> > Given that criteria, Professional Support and Education might be on the
> > chopping
> > block as well.
> >
>
> +1 would definitely make my life easier when I'm reviewing/pushing updates
> to the site. 🍻
>


-- 

Ben Bromhead

Instaclustr | www.instaclustr.com | @instaclustr
 | +64 27 383 8975

Re: Additions to Cassandra ecosystem page?

[Erick Ramirez]

>
> And I'm thinking of anyone that has to update this list and reason through
> all of the complex rulesets of why or why not, It's really not fair to
> them.

My proposal is that we completely drop the Cassandra Cloud Offereing
> section.
> Given that criteria, Professional Support and Education might be on the
> chopping
> block as well.
>

+1 would definitely make my life easier when I'm reviewing/pushing updates
to the site. 🍻

Re: Additions to Cassandra ecosystem page?

[Melissa Logan]

Appreciate the discussion, all.

As the person who has primarily been aggregating info for this page, my
approach has been to consider what would be most useful to an end user who
wants to use / extend Cassandra -- and to be permissive about what would be
included to keep things simple (as we don't have the capability to vet and
verify each one).

That said, based on the debate here I would +1 the comment about cloud
offerings and allow others to remain -- including Professional Support and
Education, simply because those do help people use and extend open source
Cassandra.


On Wed, Jun 30, 2021 at 1:23 PM Joshua McKenzie 
wrote:

> >
> > My proposal is that we completely drop the Cassandra Cloud Offereing
> > section.
>
> +1
>
>
>
> On Wed, Jun 30, 2021 at 12:34 PM Patrick McFadin 
> wrote:
>
> > This is a very interesting thread and has had me thinking quite a bit.
> > Having to reason through who belongs on a list or not just seems very
> > polarizing to me and given the length of this thread, I think that's
> > playing out. This kind of energy is just not good for the larger
> community.
> > And I'm thinking of anyone that has to update this list and reason
> through
> > all of the complex rulesets of why or why not, It's really not fair to
> > them.
> >
> > My proposal is that we completely drop the Cassandra Cloud Offereing
> > section.
> >
> > Some reasoning.
> >
> > If somebody wants to run a cloud version of Cassandra, that's the least
> > hard thing to find. Google "Apache Cassandra" and see what pops to the
> top
> > of Google Ads. DataStax, Instaclustr, Aiven, Amazon and Microsoft all
> have
> > marketing budgets. They will be just fine.
> >
> > I would love for our ecosystem page to be a place where we celebrate and
> > encourage the supportive tooling and products that add to Apache
> Cassandra
> > and make it better for everyone to use. That should be the guiding
> > principle on addition to the ecosystem page. Celebrate not arbitrate.
> Given
> > that criteria, Professional Support and Education might be on the
> chopping
> > block as well.
> >
> > Patrick
> >
> > On Wed, Jun 30, 2021 at 1:48 AM bened...@apache.org  >
> > wrote:
> >
> > > I disagree that disclaimers dissolve many duties, responsibilities or
> > > implied communicative acts.
> > >
> > > Most people recognise disclaimers as a means of abdicating
> responsibility
> > > for the consequences of utilising an endorsement or other facility, not
> > as
> > > a communicative act indicating a lack of actual endorsement.
> > >
> > > Besides which, many here have communicated reasons they believe it is
> > > wrong to promote these other database offerings, which is a weaker
> > criteria
> > > than endorsement.
> > >
> > >
> > > From: Paulo Motta 
> > > Date: Tuesday, 29 June 2021 at 19:14
> > > To: Cassandra DEV 
> > > Subject: Re: Additions to Cassandra ecosystem page?
> > > > Listing a product on our website implicitly endorses that offering,
> and
> > > we should absolutely be restrictive about what we endorse. I’m -1
> > > unconditionally endorsing
> > >
> > > I don't think listing a product on the website means implicitly
> endorsing
> > > it if it's explicitly mentioned with a visible disclaimer that we're
> not
> > > endorsing the listed products.
> > >
> > > From my experience, an ecosystem page is an open wiki editable by
> anyone
> > > with the sole objective of allowing external users to easily find
> > anything
> > > related to the project, and not a list of "unconditionally endorsed"
> > > offerings.
> > >
> > > Why not take a community-driven laissez-faire approach and just let
> > people
> > > list whatever they want if they feel part of the community, with the
> > > explicit disclaimer that being on the list is not a project endorsement
> > of
> > > the offering? For instance, Apache Kafka uses very simple wording to
> > convey
> > > this [1]: "Here is a list of tools *we have been* told about that
> > integrate
> > > with Kafka outside the main distribution. *We haven't tried them all,
> so
> > > they may not work*!" [1]
> > >
> > > I think it's fine to bikeshed how to categorize offerings, present the
> > > list, word the disclaimer and even remove clear violations of good
> faith,
> &

Re: Additions to Cassandra ecosystem page?

[Joshua McKenzie]

>
> My proposal is that we completely drop the Cassandra Cloud Offereing
> section.

+1



On Wed, Jun 30, 2021 at 12:34 PM Patrick McFadin  wrote:

> This is a very interesting thread and has had me thinking quite a bit.
> Having to reason through who belongs on a list or not just seems very
> polarizing to me and given the length of this thread, I think that's
> playing out. This kind of energy is just not good for the larger community.
> And I'm thinking of anyone that has to update this list and reason through
> all of the complex rulesets of why or why not, It's really not fair to
> them.
>
> My proposal is that we completely drop the Cassandra Cloud Offereing
> section.
>
> Some reasoning.
>
> If somebody wants to run a cloud version of Cassandra, that's the least
> hard thing to find. Google "Apache Cassandra" and see what pops to the top
> of Google Ads. DataStax, Instaclustr, Aiven, Amazon and Microsoft all have
> marketing budgets. They will be just fine.
>
> I would love for our ecosystem page to be a place where we celebrate and
> encourage the supportive tooling and products that add to Apache Cassandra
> and make it better for everyone to use. That should be the guiding
> principle on addition to the ecosystem page. Celebrate not arbitrate. Given
> that criteria, Professional Support and Education might be on the chopping
> block as well.
>
> Patrick
>
> On Wed, Jun 30, 2021 at 1:48 AM bened...@apache.org 
> wrote:
>
> > I disagree that disclaimers dissolve many duties, responsibilities or
> > implied communicative acts.
> >
> > Most people recognise disclaimers as a means of abdicating responsibility
> > for the consequences of utilising an endorsement or other facility, not
> as
> > a communicative act indicating a lack of actual endorsement.
> >
> > Besides which, many here have communicated reasons they believe it is
> > wrong to promote these other database offerings, which is a weaker
> criteria
> > than endorsement.
> >
> >
> > From: Paulo Motta 
> > Date: Tuesday, 29 June 2021 at 19:14
> > To: Cassandra DEV 
> > Subject: Re: Additions to Cassandra ecosystem page?
> > > Listing a product on our website implicitly endorses that offering, and
> > we should absolutely be restrictive about what we endorse. I’m -1
> > unconditionally endorsing
> >
> > I don't think listing a product on the website means implicitly endorsing
> > it if it's explicitly mentioned with a visible disclaimer that we're not
> > endorsing the listed products.
> >
> > From my experience, an ecosystem page is an open wiki editable by anyone
> > with the sole objective of allowing external users to easily find
> anything
> > related to the project, and not a list of "unconditionally endorsed"
> > offerings.
> >
> > Why not take a community-driven laissez-faire approach and just let
> people
> > list whatever they want if they feel part of the community, with the
> > explicit disclaimer that being on the list is not a project endorsement
> of
> > the offering? For instance, Apache Kafka uses very simple wording to
> convey
> > this [1]: "Here is a list of tools *we have been* told about that
> integrate
> > with Kafka outside the main distribution. *We haven't tried them all, so
> > they may not work*!" [1]
> >
> > I think it's fine to bikeshed how to categorize offerings, present the
> > list, word the disclaimer and even remove clear violations of good faith,
> > but I don't think we should be over presumptuous and prescribe what is
> > allowed and forbidden on a public wiki of an open source project.
> >
> > Two objective suggestions I'd like to make are:
> > - Give more visibility/prominence to
> > auxiliary/complementary/supplementary/non-competing/open-source
> > projects/products by listing them at the top of the page, and list
> > closed-source / SaaS / API-compatible offerings under its own category at
> > the bottom of the page with maybe an additional disclaimer that not all
> > features may be available on these offerings.
> > - There are 3 sub-offerings from a single vendor in the "Professional
> > Services" category, but I think it's sufficient to list each service
> > provider once per category, since the sub-offerings can be easily found
> by
> > visiting the service provider website.
> >
> > Paulo
> > -
> >
> > [1] https://spark.apache.org/third-party-projects.html
> >
> > Em ter., 29 de jun. de 2021 às 04:48, Benjamin 

Re: Additions to Cassandra ecosystem page?

[Patrick McFadin]

This is a very interesting thread and has had me thinking quite a bit.
Having to reason through who belongs on a list or not just seems very
polarizing to me and given the length of this thread, I think that's
playing out. This kind of energy is just not good for the larger community.
And I'm thinking of anyone that has to update this list and reason through
all of the complex rulesets of why or why not, It's really not fair to
them.

My proposal is that we completely drop the Cassandra Cloud Offereing
section.

Some reasoning.

If somebody wants to run a cloud version of Cassandra, that's the least
hard thing to find. Google "Apache Cassandra" and see what pops to the top
of Google Ads. DataStax, Instaclustr, Aiven, Amazon and Microsoft all have
marketing budgets. They will be just fine.

I would love for our ecosystem page to be a place where we celebrate and
encourage the supportive tooling and products that add to Apache Cassandra
and make it better for everyone to use. That should be the guiding
principle on addition to the ecosystem page. Celebrate not arbitrate. Given
that criteria, Professional Support and Education might be on the chopping
block as well.

Patrick

On Wed, Jun 30, 2021 at 1:48 AM bened...@apache.org 
wrote:

> I disagree that disclaimers dissolve many duties, responsibilities or
> implied communicative acts.
>
> Most people recognise disclaimers as a means of abdicating responsibility
> for the consequences of utilising an endorsement or other facility, not as
> a communicative act indicating a lack of actual endorsement.
>
> Besides which, many here have communicated reasons they believe it is
> wrong to promote these other database offerings, which is a weaker criteria
> than endorsement.
>
>
> From: Paulo Motta 
> Date: Tuesday, 29 June 2021 at 19:14
> To: Cassandra DEV 
> Subject: Re: Additions to Cassandra ecosystem page?
> > Listing a product on our website implicitly endorses that offering, and
> we should absolutely be restrictive about what we endorse. I’m -1
> unconditionally endorsing
>
> I don't think listing a product on the website means implicitly endorsing
> it if it's explicitly mentioned with a visible disclaimer that we're not
> endorsing the listed products.
>
> From my experience, an ecosystem page is an open wiki editable by anyone
> with the sole objective of allowing external users to easily find anything
> related to the project, and not a list of "unconditionally endorsed"
> offerings.
>
> Why not take a community-driven laissez-faire approach and just let people
> list whatever they want if they feel part of the community, with the
> explicit disclaimer that being on the list is not a project endorsement of
> the offering? For instance, Apache Kafka uses very simple wording to convey
> this [1]: "Here is a list of tools *we have been* told about that integrate
> with Kafka outside the main distribution. *We haven't tried them all, so
> they may not work*!" [1]
>
> I think it's fine to bikeshed how to categorize offerings, present the
> list, word the disclaimer and even remove clear violations of good faith,
> but I don't think we should be over presumptuous and prescribe what is
> allowed and forbidden on a public wiki of an open source project.
>
> Two objective suggestions I'd like to make are:
> - Give more visibility/prominence to
> auxiliary/complementary/supplementary/non-competing/open-source
> projects/products by listing them at the top of the page, and list
> closed-source / SaaS / API-compatible offerings under its own category at
> the bottom of the page with maybe an additional disclaimer that not all
> features may be available on these offerings.
> - There are 3 sub-offerings from a single vendor in the "Professional
> Services" category, but I think it's sufficient to list each service
> provider once per category, since the sub-offerings can be easily found by
> visiting the service provider website.
>
> Paulo
> -
>
> [1] https://spark.apache.org/third-party-projects.html
>
> Em ter., 29 de jun. de 2021 às 04:48, Benjamin Lerer 
> escreveu:
>
> > If I have to choose between the four choices that you proposed I would
> then
> > choose (1) List no alternative offerings at all.
> >
> > Le mar. 29 juin 2021 à 09:34, bened...@apache.org 
> a
> > écrit :
> >
> > > I don’t think it is intractable to come up with a definition that we
> use
> > > for inclusion.
> > >
> > > 1. List no alternative offerings at all.
> > > 2. List only those offerings that deploy precisely a released version
> of
> > > Cassandra.
> > > 3. List only those offerings that 

Re: Additions to Cassandra ecosystem page?

[bened...@apache.org]

I disagree that disclaimers dissolve many duties, responsibilities or implied 
communicative acts.

Most people recognise disclaimers as a means of abdicating responsibility for 
the consequences of utilising an endorsement or other facility, not as a 
communicative act indicating a lack of actual endorsement.

Besides which, many here have communicated reasons they believe it is wrong to 
promote these other database offerings, which is a weaker criteria than 
endorsement.


From: Paulo Motta 
Date: Tuesday, 29 June 2021 at 19:14
To: Cassandra DEV 
Subject: Re: Additions to Cassandra ecosystem page?
> Listing a product on our website implicitly endorses that offering, and
we should absolutely be restrictive about what we endorse. I’m -1
unconditionally endorsing

I don't think listing a product on the website means implicitly endorsing
it if it's explicitly mentioned with a visible disclaimer that we're not
endorsing the listed products.

>From my experience, an ecosystem page is an open wiki editable by anyone
with the sole objective of allowing external users to easily find anything
related to the project, and not a list of "unconditionally endorsed"
offerings.

Why not take a community-driven laissez-faire approach and just let people
list whatever they want if they feel part of the community, with the
explicit disclaimer that being on the list is not a project endorsement of
the offering? For instance, Apache Kafka uses very simple wording to convey
this [1]: "Here is a list of tools *we have been* told about that integrate
with Kafka outside the main distribution. *We haven't tried them all, so
they may not work*!" [1]

I think it's fine to bikeshed how to categorize offerings, present the
list, word the disclaimer and even remove clear violations of good faith,
but I don't think we should be over presumptuous and prescribe what is
allowed and forbidden on a public wiki of an open source project.

Two objective suggestions I'd like to make are:
- Give more visibility/prominence to
auxiliary/complementary/supplementary/non-competing/open-source
projects/products by listing them at the top of the page, and list
closed-source / SaaS / API-compatible offerings under its own category at
the bottom of the page with maybe an additional disclaimer that not all
features may be available on these offerings.
- There are 3 sub-offerings from a single vendor in the "Professional
Services" category, but I think it's sufficient to list each service
provider once per category, since the sub-offerings can be easily found by
visiting the service provider website.

Paulo
-

[1] https://spark.apache.org/third-party-projects.html

Em ter., 29 de jun. de 2021 às 04:48, Benjamin Lerer 
escreveu:

> If I have to choose between the four choices that you proposed I would then
> choose (1) List no alternative offerings at all.
>
> Le mar. 29 juin 2021 à 09:34, bened...@apache.org  a
> écrit :
>
> > I don’t think it is intractable to come up with a definition that we use
> > for inclusion.
> >
> > 1. List no alternative offerings at all.
> > 2. List only those offerings that deploy precisely a released version of
> > Cassandra.
> > 3. List only those offerings that deploy precisely a released version of
> > Cassandra with modifications that extend a list of public APIs.
> > 4. List only those offerings that deploy precisely a released version of
> > Cassandra with modifications that extend a list of public APIs, or are
> > themselves published under ASL v2.
> >
> > Listing a product on our website implicitly endorses that offering, and
> we
> > should absolutely be restrictive about what we endorse. I’m -1
> > unconditionally endorsing competing products, and products that are not
> > themselves clearly some derivative work that is accessible to the
> community
> > under similar terms.
> >
> > If we cannot agree on a set of conditions, options (1) and (2) are
> simple,
> > easy to administer, adequately restrictive and not inconsistently
> > permissive.
> >
> > I don’t think this website is going to drive a lot of traffic to any of
> > these businesses, so I doubt any of them should be upset at any loss of
> > revenue. The question is simply one of principle for us as a project.
> >
> >
> >
> > From: Benjamin Lerer 
> > Date: Tuesday, 29 June 2021 at 08:10
> > To: dev@cassandra.apache.org 
> > Subject: Re: Additions to Cassandra ecosystem page?
> > I feel that we are going into a too restrictive direction. I believe that
> > we have more to win by being open and welcoming.
> > -1 for the strict approach and for the licences.
> >
> > Le mar. 29 juin 2021 à 00:40, Ben Bromhead  a
> écrit :
> >
> &g

Re: Additions to Cassandra ecosystem page?

[Paulo Motta]

> Listing a product on our website implicitly endorses that offering, and
we should absolutely be restrictive about what we endorse. I’m -1
unconditionally endorsing

I don't think listing a product on the website means implicitly endorsing
it if it's explicitly mentioned with a visible disclaimer that we're not
endorsing the listed products.

>From my experience, an ecosystem page is an open wiki editable by anyone
with the sole objective of allowing external users to easily find anything
related to the project, and not a list of "unconditionally endorsed"
offerings.

Why not take a community-driven laissez-faire approach and just let people
list whatever they want if they feel part of the community, with the
explicit disclaimer that being on the list is not a project endorsement of
the offering? For instance, Apache Kafka uses very simple wording to convey
this [1]: "Here is a list of tools *we have been* told about that integrate
with Kafka outside the main distribution. *We haven't tried them all, so
they may not work*!" [1]

I think it's fine to bikeshed how to categorize offerings, present the
list, word the disclaimer and even remove clear violations of good faith,
but I don't think we should be over presumptuous and prescribe what is
allowed and forbidden on a public wiki of an open source project.

Two objective suggestions I'd like to make are:
- Give more visibility/prominence to
auxiliary/complementary/supplementary/non-competing/open-source
projects/products by listing them at the top of the page, and list
closed-source / SaaS / API-compatible offerings under its own category at
the bottom of the page with maybe an additional disclaimer that not all
features may be available on these offerings.
- There are 3 sub-offerings from a single vendor in the "Professional
Services" category, but I think it's sufficient to list each service
provider once per category, since the sub-offerings can be easily found by
visiting the service provider website.

Paulo
-

[1] https://spark.apache.org/third-party-projects.html

Em ter., 29 de jun. de 2021 às 04:48, Benjamin Lerer 
escreveu:

> If I have to choose between the four choices that you proposed I would then
> choose (1) List no alternative offerings at all.
>
> Le mar. 29 juin 2021 à 09:34, bened...@apache.org  a
> écrit :
>
> > I don’t think it is intractable to come up with a definition that we use
> > for inclusion.
> >
> > 1. List no alternative offerings at all.
> > 2. List only those offerings that deploy precisely a released version of
> > Cassandra.
> > 3. List only those offerings that deploy precisely a released version of
> > Cassandra with modifications that extend a list of public APIs.
> > 4. List only those offerings that deploy precisely a released version of
> > Cassandra with modifications that extend a list of public APIs, or are
> > themselves published under ASL v2.
> >
> > Listing a product on our website implicitly endorses that offering, and
> we
> > should absolutely be restrictive about what we endorse. I’m -1
> > unconditionally endorsing competing products, and products that are not
> > themselves clearly some derivative work that is accessible to the
> community
> > under similar terms.
> >
> > If we cannot agree on a set of conditions, options (1) and (2) are
> simple,
> > easy to administer, adequately restrictive and not inconsistently
> > permissive.
> >
> > I don’t think this website is going to drive a lot of traffic to any of
> > these businesses, so I doubt any of them should be upset at any loss of
> > revenue. The question is simply one of principle for us as a project.
> >
> >
> >
> > From: Benjamin Lerer 
> > Date: Tuesday, 29 June 2021 at 08:10
> > To: dev@cassandra.apache.org 
> > Subject: Re: Additions to Cassandra ecosystem page?
> > I feel that we are going into a too restrictive direction. I believe that
> > we have more to win by being open and welcoming.
> > -1 for the strict approach and for the licences.
> >
> > Le mar. 29 juin 2021 à 00:40, Ben Bromhead  a
> écrit :
> >
> > > On Thu, Jun 24, 2021 at 2:38 AM Joshua McKenzie 
> > > wrote:
> > >
> > > >
> > > > The obvious core responsibility of the website should be to ASLv2
> > > > permissively licensed Apache Cassandra and secondarily to CQL as a
> > > protocol
> > > > IMO. I don't think we as a project should be tracking derivative
> works,
> > > > forks, or other things built on top of the code-base and certainly
> not
> > > > things with wildly varied licensing (AGPL, proprietary closed, etc).
> >

Re: Additions to Cassandra ecosystem page?

[Benjamin Lerer]

If I have to choose between the four choices that you proposed I would then
choose (1) List no alternative offerings at all.

Le mar. 29 juin 2021 à 09:34, bened...@apache.org  a
écrit :

> I don’t think it is intractable to come up with a definition that we use
> for inclusion.
>
> 1. List no alternative offerings at all.
> 2. List only those offerings that deploy precisely a released version of
> Cassandra.
> 3. List only those offerings that deploy precisely a released version of
> Cassandra with modifications that extend a list of public APIs.
> 4. List only those offerings that deploy precisely a released version of
> Cassandra with modifications that extend a list of public APIs, or are
> themselves published under ASL v2.
>
> Listing a product on our website implicitly endorses that offering, and we
> should absolutely be restrictive about what we endorse. I’m -1
> unconditionally endorsing competing products, and products that are not
> themselves clearly some derivative work that is accessible to the community
> under similar terms.
>
> If we cannot agree on a set of conditions, options (1) and (2) are simple,
> easy to administer, adequately restrictive and not inconsistently
> permissive.
>
> I don’t think this website is going to drive a lot of traffic to any of
> these businesses, so I doubt any of them should be upset at any loss of
> revenue. The question is simply one of principle for us as a project.
>
>
>
> From: Benjamin Lerer 
> Date: Tuesday, 29 June 2021 at 08:10
> To: dev@cassandra.apache.org 
> Subject: Re: Additions to Cassandra ecosystem page?
> I feel that we are going into a too restrictive direction. I believe that
> we have more to win by being open and welcoming.
> -1 for the strict approach and for the licences.
>
> Le mar. 29 juin 2021 à 00:40, Ben Bromhead  a écrit :
>
> > On Thu, Jun 24, 2021 at 2:38 AM Joshua McKenzie 
> > wrote:
> >
> > >
> > > The obvious core responsibility of the website should be to ASLv2
> > > permissively licensed Apache Cassandra and secondarily to CQL as a
> > protocol
> > > IMO. I don't think we as a project should be tracking derivative works,
> > > forks, or other things built on top of the code-base and certainly not
> > > things with wildly varied licensing (AGPL, proprietary closed, etc).
> > >
> > > To go that route we either become fully inclusive of everything or
> become
> > > Kingmakers, and either way there's the consequence of inconsistent
> levels
> > > of vetting, maintenance, and dilution of what it means to "be
> Cassandra".
> > > There's plenty of other websites for other projects and everyone has
> > access
> > > to search engines.
> > >
> >
> > This makes sense to me as a line in the sand to draw if we are going
> down a
> > strict path.
> >
> > It would be up to whoever wants to be added to the list to demonstrate
> this
> > is the case.
> >
> > There would still be some degree of honesty required as well on the
> service
> > providers part.
> >
>

Re: Additions to Cassandra ecosystem page?

[bened...@apache.org]

I don’t think it is intractable to come up with a definition that we use for 
inclusion.

1. List no alternative offerings at all.
2. List only those offerings that deploy precisely a released version of 
Cassandra.
3. List only those offerings that deploy precisely a released version of 
Cassandra with modifications that extend a list of public APIs.
4. List only those offerings that deploy precisely a released version of 
Cassandra with modifications that extend a list of public APIs, or are 
themselves published under ASL v2.

Listing a product on our website implicitly endorses that offering, and we 
should absolutely be restrictive about what we endorse. I’m -1 unconditionally 
endorsing competing products, and products that are not themselves clearly some 
derivative work that is accessible to the community under similar terms.

If we cannot agree on a set of conditions, options (1) and (2) are simple, easy 
to administer, adequately restrictive and not inconsistently permissive.

I don’t think this website is going to drive a lot of traffic to any of these 
businesses, so I doubt any of them should be upset at any loss of revenue. The 
question is simply one of principle for us as a project.



From: Benjamin Lerer 
Date: Tuesday, 29 June 2021 at 08:10
To: dev@cassandra.apache.org 
Subject: Re: Additions to Cassandra ecosystem page?
I feel that we are going into a too restrictive direction. I believe that
we have more to win by being open and welcoming.
-1 for the strict approach and for the licences.

Le mar. 29 juin 2021 à 00:40, Ben Bromhead  a écrit :

> On Thu, Jun 24, 2021 at 2:38 AM Joshua McKenzie 
> wrote:
>
> >
> > The obvious core responsibility of the website should be to ASLv2
> > permissively licensed Apache Cassandra and secondarily to CQL as a
> protocol
> > IMO. I don't think we as a project should be tracking derivative works,
> > forks, or other things built on top of the code-base and certainly not
> > things with wildly varied licensing (AGPL, proprietary closed, etc).
> >
> > To go that route we either become fully inclusive of everything or become
> > Kingmakers, and either way there's the consequence of inconsistent levels
> > of vetting, maintenance, and dilution of what it means to "be Cassandra".
> > There's plenty of other websites for other projects and everyone has
> access
> > to search engines.
> >
>
> This makes sense to me as a line in the sand to draw if we are going down a
> strict path.
>
> It would be up to whoever wants to be added to the list to demonstrate this
> is the case.
>
> There would still be some degree of honesty required as well on the service
> providers part.
>

Re: Additions to Cassandra ecosystem page?

[Benjamin Lerer]

I feel that we are going into a too restrictive direction. I believe that
we have more to win by being open and welcoming.
-1 for the strict approach and for the licences.

Le mar. 29 juin 2021 à 00:40, Ben Bromhead  a écrit :

> On Thu, Jun 24, 2021 at 2:38 AM Joshua McKenzie 
> wrote:
>
> >
> > The obvious core responsibility of the website should be to ASLv2
> > permissively licensed Apache Cassandra and secondarily to CQL as a
> protocol
> > IMO. I don't think we as a project should be tracking derivative works,
> > forks, or other things built on top of the code-base and certainly not
> > things with wildly varied licensing (AGPL, proprietary closed, etc).
> >
> > To go that route we either become fully inclusive of everything or become
> > Kingmakers, and either way there's the consequence of inconsistent levels
> > of vetting, maintenance, and dilution of what it means to "be Cassandra".
> > There's plenty of other websites for other projects and everyone has
> access
> > to search engines.
> >
>
> This makes sense to me as a line in the sand to draw if we are going down a
> strict path.
>
> It would be up to whoever wants to be added to the list to demonstrate this
> is the case.
>
> There would still be some degree of honesty required as well on the service
> providers part.
>

Re: Additions to Cassandra ecosystem page?

[Ben Bromhead]

On Thu, Jun 24, 2021 at 2:38 AM Joshua McKenzie 
wrote:

>
> The obvious core responsibility of the website should be to ASLv2
> permissively licensed Apache Cassandra and secondarily to CQL as a protocol
> IMO. I don't think we as a project should be tracking derivative works,
> forks, or other things built on top of the code-base and certainly not
> things with wildly varied licensing (AGPL, proprietary closed, etc).
>
> To go that route we either become fully inclusive of everything or become
> Kingmakers, and either way there's the consequence of inconsistent levels
> of vetting, maintenance, and dilution of what it means to "be Cassandra".
> There's plenty of other websites for other projects and everyone has access
> to search engines.
>

This makes sense to me as a line in the sand to draw if we are going down a
strict path.

It would be up to whoever wants to be added to the list to demonstrate this
is the case.

There would still be some degree of honesty required as well on the service
providers part.

Re: Additions to Cassandra ecosystem page?

[Benjamin Lerer]

>
> I'm also comfortable with a strict approach where we just list actual
> Apache Cassandra offerings, that also provides good solid clarity to
> users.


That sounds like a reasonable proposal. I just do not know how we can do
that in practice. What is a actual Apache Cassandra offering and how do we
check that it is effectively one ?
What if the offering offers some secondary indices that are not delivered
with Apache Cassandra (it is the first pluggable thing that came to my
mind) or the code being used is a C* fork?

Two things that I found interesting are:
1 ) some companies that propose offerings only using some parts of Apache
Cassandra are contributing to the project in diverse ways
2)  the offer descriptions seem honest to me. They do not claim that they
run the official Apache Cassandra if they do not.

So, I would be more in favor of a welcoming approach in the hope that
people will be honest and that it might also lead them to invest and
contribute to the project.
The other advantage of that approach being that it will not put any
pressure on us to ensure that an offering is an actual Apache Cassandra
offering (which I am absolutely not interested in doing ;-))



Le ven. 25 juin 2021 à 15:28, Erick Ramirez  a
écrit :

> I'm a huge +1 to the sentiments here.
>
> I have to confess that I've been responsible for publishing the updates for
> several months now with Mick's mentoring. I publish the content I was
> requested to push to the site but as far as review is concerned, the only
> review I do is mostly around grammar and formatting and make sure that the
> updates render correctly on the site.
>
> It would be ideal if there was a charter from the community I could refer
> to so it wouldn't seem like I'm unilaterally rejecting some entries but not
> others. I'm glad we've got this thread because I could use it to support
> what I do on the site. Cheers!
>

Re: Additions to Cassandra ecosystem page?

[Erick Ramirez]

I'm a huge +1 to the sentiments here.

I have to confess that I've been responsible for publishing the updates for
several months now with Mick's mentoring. I publish the content I was
requested to push to the site but as far as review is concerned, the only
review I do is mostly around grammar and formatting and make sure that the
updates render correctly on the site.

It would be ideal if there was a charter from the community I could refer
to so it wouldn't seem like I'm unilaterally rejecting some entries but not
others. I'm glad we've got this thread because I could use it to support
what I do on the site. Cheers!

Re: Additions to Cassandra ecosystem page?

[Aleksey Yeschenko]

+1

> On 24 Jun 2021, at 10:22, Sam Tunnicliffe  wrote:
> 
> +1
> 
>> On 23 Jun 2021, at 22:31, Jeff Jirsa  wrote:
>> 
>> This would be my preference.
>> 
>> 
>> On Wed, Jun 23, 2021 at 2:22 PM Ben Bromhead  wrote:
>> 
>>> I'm also comfortable with a strict approach where we just list actual
>>> Apache Cassandra offerings, that also provides good solid clarity to users.
>>> 
>>> On Thu, Jun 24, 2021 at 3:06 AM bened...@apache.org 
>>> wrote:
>>> 
>>>> +1
>>>> 
>>>> From: Brandon Williams 
>>>> Date: Wednesday, 23 June 2021 at 15:44
>>>> To: dev@cassandra.apache.org 
>>>> Subject: Re: Additions to Cassandra ecosystem page?
>>>> On Wed, Jun 23, 2021 at 9:38 AM Joshua McKenzie 
>>>> wrote:
>>>>> 
>>>>> The obvious core responsibility of the website should be to ASLv2
>>>>> permissively licensed Apache Cassandra and secondarily to CQL as a
>>>> protocol
>>>>> IMO. I don't think we as a project should be tracking derivative works,
>>>>> forks, or other things built on top of the code-base and certainly not
>>>>> things with wildly varied licensing (AGPL, proprietary closed, etc).
>>>> 
>>>> I agree.  I don't see how it makes sense for us to promote less
>>>> compatible derivatives with more restrictive licensing.  Imitation may
>>>> be flattery but as you pointed out, we don't need to be the ones
>>>> advertising it.
>>>> 
>>>> -
>>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>>>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>>> 
>>> 
>>> 
>>> --
>>> 
>>> Ben Bromhead
>>> 
>>> Instaclustr | www.instaclustr.com | @instaclustr
>>> <http://twitter.com/instaclustr> | +64 27 383 8975
>>> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Additions to Cassandra ecosystem page?

[Sam Tunnicliffe]

+1

> On 23 Jun 2021, at 22:31, Jeff Jirsa  wrote:
> 
> This would be my preference.
> 
> 
> On Wed, Jun 23, 2021 at 2:22 PM Ben Bromhead  wrote:
> 
>> I'm also comfortable with a strict approach where we just list actual
>> Apache Cassandra offerings, that also provides good solid clarity to users.
>> 
>> On Thu, Jun 24, 2021 at 3:06 AM bened...@apache.org 
>> wrote:
>> 
>>> +1
>>> 
>>> From: Brandon Williams 
>>> Date: Wednesday, 23 June 2021 at 15:44
>>> To: dev@cassandra.apache.org 
>>> Subject: Re: Additions to Cassandra ecosystem page?
>>> On Wed, Jun 23, 2021 at 9:38 AM Joshua McKenzie 
>>> wrote:
>>>> 
>>>> The obvious core responsibility of the website should be to ASLv2
>>>> permissively licensed Apache Cassandra and secondarily to CQL as a
>>> protocol
>>>> IMO. I don't think we as a project should be tracking derivative works,
>>>> forks, or other things built on top of the code-base and certainly not
>>>> things with wildly varied licensing (AGPL, proprietary closed, etc).
>>> 
>>> I agree.  I don't see how it makes sense for us to promote less
>>> compatible derivatives with more restrictive licensing.  Imitation may
>>> be flattery but as you pointed out, we don't need to be the ones
>>> advertising it.
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>> 
>> 
>> 
>> --
>> 
>> Ben Bromhead
>> 
>> Instaclustr | www.instaclustr.com | @instaclustr
>> <http://twitter.com/instaclustr> | +64 27 383 8975
>> 


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Additions to Cassandra ecosystem page?

[Jeff Jirsa]

This would be my preference.


On Wed, Jun 23, 2021 at 2:22 PM Ben Bromhead  wrote:

> I'm also comfortable with a strict approach where we just list actual
> Apache Cassandra offerings, that also provides good solid clarity to users.
>
> On Thu, Jun 24, 2021 at 3:06 AM bened...@apache.org 
> wrote:
>
> > +1
> >
> > From: Brandon Williams 
> > Date: Wednesday, 23 June 2021 at 15:44
> > To: dev@cassandra.apache.org 
> > Subject: Re: Additions to Cassandra ecosystem page?
> > On Wed, Jun 23, 2021 at 9:38 AM Joshua McKenzie 
> > wrote:
> > >
> > > The obvious core responsibility of the website should be to ASLv2
> > > permissively licensed Apache Cassandra and secondarily to CQL as a
> > protocol
> > > IMO. I don't think we as a project should be tracking derivative works,
> > > forks, or other things built on top of the code-base and certainly not
> > > things with wildly varied licensing (AGPL, proprietary closed, etc).
> >
> > I agree.  I don't see how it makes sense for us to promote less
> > compatible derivatives with more restrictive licensing.  Imitation may
> > be flattery but as you pointed out, we don't need to be the ones
> > advertising it.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
>
>
> --
>
> Ben Bromhead
>
> Instaclustr | www.instaclustr.com | @instaclustr
> <http://twitter.com/instaclustr> | +64 27 383 8975
>

Re: Additions to Cassandra ecosystem page?

[Ben Bromhead]

I'm also comfortable with a strict approach where we just list actual
Apache Cassandra offerings, that also provides good solid clarity to users.

On Thu, Jun 24, 2021 at 3:06 AM bened...@apache.org 
wrote:

> +1
>
> From: Brandon Williams 
> Date: Wednesday, 23 June 2021 at 15:44
> To: dev@cassandra.apache.org 
> Subject: Re: Additions to Cassandra ecosystem page?
> On Wed, Jun 23, 2021 at 9:38 AM Joshua McKenzie 
> wrote:
> >
> > The obvious core responsibility of the website should be to ASLv2
> > permissively licensed Apache Cassandra and secondarily to CQL as a
> protocol
> > IMO. I don't think we as a project should be tracking derivative works,
> > forks, or other things built on top of the code-base and certainly not
> > things with wildly varied licensing (AGPL, proprietary closed, etc).
>
> I agree.  I don't see how it makes sense for us to promote less
> compatible derivatives with more restrictive licensing.  Imitation may
> be flattery but as you pointed out, we don't need to be the ones
> advertising it.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>


-- 

Ben Bromhead

Instaclustr | www.instaclustr.com | @instaclustr
<http://twitter.com/instaclustr> | +64 27 383 8975

Re: Additions to Cassandra ecosystem page?

[bened...@apache.org]

+1

From: Brandon Williams 
Date: Wednesday, 23 June 2021 at 15:44
To: dev@cassandra.apache.org 
Subject: Re: Additions to Cassandra ecosystem page?
On Wed, Jun 23, 2021 at 9:38 AM Joshua McKenzie  wrote:
>
> The obvious core responsibility of the website should be to ASLv2
> permissively licensed Apache Cassandra and secondarily to CQL as a protocol
> IMO. I don't think we as a project should be tracking derivative works,
> forks, or other things built on top of the code-base and certainly not
> things with wildly varied licensing (AGPL, proprietary closed, etc).

I agree.  I don't see how it makes sense for us to promote less
compatible derivatives with more restrictive licensing.  Imitation may
be flattery but as you pointed out, we don't need to be the ones
advertising it.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Additions to Cassandra ecosystem page?

[Brandon Williams]

On Wed, Jun 23, 2021 at 9:38 AM Joshua McKenzie  wrote:
>
> The obvious core responsibility of the website should be to ASLv2
> permissively licensed Apache Cassandra and secondarily to CQL as a protocol
> IMO. I don't think we as a project should be tracking derivative works,
> forks, or other things built on top of the code-base and certainly not
> things with wildly varied licensing (AGPL, proprietary closed, etc).

I agree.  I don't see how it makes sense for us to promote less
compatible derivatives with more restrictive licensing.  Imitation may
be flattery but as you pointed out, we don't need to be the ones
advertising it.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Additions to Cassandra ecosystem page?

[Joshua McKenzie]

>
> With it we could simply organize the offers by level of CQL compatibility.

I would suggest another category along the lines of "Cassandra Protocol
> compatible offerings"

The obvious core responsibility of the website should be to ASLv2
permissively licensed Apache Cassandra and secondarily to CQL as a protocol
IMO. I don't think we as a project should be tracking derivative works,
forks, or other things built on top of the code-base and certainly not
things with wildly varied licensing (AGPL, proprietary closed, etc).

To go that route we either become fully inclusive of everything or become
Kingmakers, and either way there's the consequence of inconsistent levels
of vetting, maintenance, and dilution of what it means to "be Cassandra".
There's plenty of other websites for other projects and everyone has access
to search engines.


On Wed, Jun 23, 2021 at 5:39 AM Benjamin Lerer  wrote:

> Brian Houser proposed to build a tool for the next release to validate the
> level of CQL compatibility. With it we could simply organize the offers by
> level of CQL compatibility.
>
> Le mer. 23 juin 2021 à 10:24, bened...@apache.org <
> pub...@belliottsmith.com>
> a écrit :
>
> > If we are going to include copycats, let’s (in all seriousness) at least
> > be fun about it and put them under the heading “Copycats”
> >
> > We should also include a disclaimer that they may not be feature
> > compatible. Since due diligence on this is hard even for subject matter
> > experts, it would be nicer still if we put a bit of detail explaining
> some
> > of the differences before putting them on the website, but I doubt anyone
> > has the time for that (so I still slightly prefer we don’t include them).
> >
> >
> > ________
> > From: Ben Bromhead 
> > Sent: Wednesday, June 23, 2021 4:56:34 AM
> > To: Cassandra DEV 
> > Subject: Re: Additions to Cassandra ecosystem page?
> >
> > There is certainly a lack of clarity in the grouping, as a number of
> those
> > services are not offering Apache Cassandra. I would suggest another
> > category along the lines of "Cassandra Protocol compatible offerings".
> >
> > That way users can easily distinguish between ecosystem offerings where
> > "the driver works, but certain features might not", vs an actual Apache
> > Cassandra offering.
> >
> > We could then also add things like Yugabyte and Scylla into that
> category.
> >
> > On Wed, Jun 23, 2021 at 11:15 AM Jonathan Koppenhofer <
> j...@koppedomain.com
> > >
> > wrote:
> >
> > > No major opinion on the "cloud offerings" piece, but I agree people
> > should
> > > know what they are getting into, and be able to make an informed
> > decision.
> > > However, if someone is going down that path, I would hope they do the
> > > due-diligence to make sure it fits their requirements.
> > >
> > > 1 small update I would suggest. It seems like Datastax Spring Boot
> entry
> > > would go in development frameworks as opposed to the sidecar section.
> > >
> > > On Tue, Jun 22, 2021, 5:39 PM bened...@apache.org  >
> > > wrote:
> > >
> > > > Under Cloud Offerings, are we comfortable implicitly endorsing “API
> > > > compatible” offerings that aren’t actually Cassandra, and also don’t
> > (as
> > > > far as I am aware) fully support Cassandra functionality? Should we
> at
> > > > least mention that this is the case?
> > > >
> > > >
> > > > From: Melissa Logan 
> > > > Date: Tuesday, 22 June 2021 at 21:39
> > > > To: u...@cassandra.apache.org ,
> > > > dev@cassandra.apache.org 
> > > > Subject: Additions to Cassandra ecosystem page?
> > > > Hi all,
> > > >
> > > > The Cassandra community recently updated its website and has added
> > > several
> > > > new entries to the Ecosystem page:
> > > https://cassandra.apache.org/ecosystem/
> > > > .
> > > >
> > > > If you have edits or know of other third-party Cassandra projects,
> > tools,
> > > > products, etc that may be useful to others -- please get in touch and
> > > we'll
> > > > add to the next round of site updates in July.
> > > >
> > > > Thanks!
> > > >
> > > > Melissa
> > > > Apache Cassandra Contributor
> > > >
> > >
> >
> >
> > --
> >
> > Ben Bromhead
> >
> > Instaclustr | www.instaclustr.com<http://www.instaclustr.com> |
> > @instaclustr
> > <http://twitter.com/instaclustr> | +64 27 383 8975
> >
>

Re: Additions to Cassandra ecosystem page?

[Benjamin Lerer]

Brian Houser proposed to build a tool for the next release to validate the
level of CQL compatibility. With it we could simply organize the offers by
level of CQL compatibility.

Le mer. 23 juin 2021 à 10:24, bened...@apache.org 
a écrit :

> If we are going to include copycats, let’s (in all seriousness) at least
> be fun about it and put them under the heading “Copycats”
>
> We should also include a disclaimer that they may not be feature
> compatible. Since due diligence on this is hard even for subject matter
> experts, it would be nicer still if we put a bit of detail explaining some
> of the differences before putting them on the website, but I doubt anyone
> has the time for that (so I still slightly prefer we don’t include them).
>
>
> 
> From: Ben Bromhead 
> Sent: Wednesday, June 23, 2021 4:56:34 AM
> To: Cassandra DEV 
> Subject: Re: Additions to Cassandra ecosystem page?
>
> There is certainly a lack of clarity in the grouping, as a number of those
> services are not offering Apache Cassandra. I would suggest another
> category along the lines of "Cassandra Protocol compatible offerings".
>
> That way users can easily distinguish between ecosystem offerings where
> "the driver works, but certain features might not", vs an actual Apache
> Cassandra offering.
>
> We could then also add things like Yugabyte and Scylla into that category.
>
> On Wed, Jun 23, 2021 at 11:15 AM Jonathan Koppenhofer  >
> wrote:
>
> > No major opinion on the "cloud offerings" piece, but I agree people
> should
> > know what they are getting into, and be able to make an informed
> decision.
> > However, if someone is going down that path, I would hope they do the
> > due-diligence to make sure it fits their requirements.
> >
> > 1 small update I would suggest. It seems like Datastax Spring Boot entry
> > would go in development frameworks as opposed to the sidecar section.
> >
> > On Tue, Jun 22, 2021, 5:39 PM bened...@apache.org 
> > wrote:
> >
> > > Under Cloud Offerings, are we comfortable implicitly endorsing “API
> > > compatible” offerings that aren’t actually Cassandra, and also don’t
> (as
> > > far as I am aware) fully support Cassandra functionality? Should we at
> > > least mention that this is the case?
> > >
> > >
> > > From: Melissa Logan 
> > > Date: Tuesday, 22 June 2021 at 21:39
> > > To: u...@cassandra.apache.org ,
> > > dev@cassandra.apache.org 
> > > Subject: Additions to Cassandra ecosystem page?
> > > Hi all,
> > >
> > > The Cassandra community recently updated its website and has added
> > several
> > > new entries to the Ecosystem page:
> > https://cassandra.apache.org/ecosystem/
> > > .
> > >
> > > If you have edits or know of other third-party Cassandra projects,
> tools,
> > > products, etc that may be useful to others -- please get in touch and
> > we'll
> > > add to the next round of site updates in July.
> > >
> > > Thanks!
> > >
> > > Melissa
> > > Apache Cassandra Contributor
> > >
> >
>
>
> --
>
> Ben Bromhead
>
> Instaclustr | www.instaclustr.com<http://www.instaclustr.com> |
> @instaclustr
> <http://twitter.com/instaclustr> | +64 27 383 8975
>

Re: Additions to Cassandra ecosystem page?

[bened...@apache.org]

If we are going to include copycats, let’s (in all seriousness) at least be fun 
about it and put them under the heading “Copycats”

We should also include a disclaimer that they may not be feature compatible. 
Since due diligence on this is hard even for subject matter experts, it would 
be nicer still if we put a bit of detail explaining some of the differences 
before putting them on the website, but I doubt anyone has the time for that 
(so I still slightly prefer we don’t include them).



From: Ben Bromhead 
Sent: Wednesday, June 23, 2021 4:56:34 AM
To: Cassandra DEV 
Subject: Re: Additions to Cassandra ecosystem page?

There is certainly a lack of clarity in the grouping, as a number of those
services are not offering Apache Cassandra. I would suggest another
category along the lines of "Cassandra Protocol compatible offerings".

That way users can easily distinguish between ecosystem offerings where
"the driver works, but certain features might not", vs an actual Apache
Cassandra offering.

We could then also add things like Yugabyte and Scylla into that category.

On Wed, Jun 23, 2021 at 11:15 AM Jonathan Koppenhofer 
wrote:

> No major opinion on the "cloud offerings" piece, but I agree people should
> know what they are getting into, and be able to make an informed decision.
> However, if someone is going down that path, I would hope they do the
> due-diligence to make sure it fits their requirements.
>
> 1 small update I would suggest. It seems like Datastax Spring Boot entry
> would go in development frameworks as opposed to the sidecar section.
>
> On Tue, Jun 22, 2021, 5:39 PM bened...@apache.org 
> wrote:
>
> > Under Cloud Offerings, are we comfortable implicitly endorsing “API
> > compatible” offerings that aren’t actually Cassandra, and also don’t (as
> > far as I am aware) fully support Cassandra functionality? Should we at
> > least mention that this is the case?
> >
> >
> > From: Melissa Logan 
> > Date: Tuesday, 22 June 2021 at 21:39
> > To: u...@cassandra.apache.org ,
> > dev@cassandra.apache.org 
> > Subject: Additions to Cassandra ecosystem page?
> > Hi all,
> >
> > The Cassandra community recently updated its website and has added
> several
> > new entries to the Ecosystem page:
> https://cassandra.apache.org/ecosystem/
> > .
> >
> > If you have edits or know of other third-party Cassandra projects, tools,
> > products, etc that may be useful to others -- please get in touch and
> we'll
> > add to the next round of site updates in July.
> >
> > Thanks!
> >
> > Melissa
> > Apache Cassandra Contributor
> >
>


--

Ben Bromhead

Instaclustr | www.instaclustr.com<http://www.instaclustr.com> | @instaclustr
<http://twitter.com/instaclustr> | +64 27 383 8975

Re: Additions to Cassandra ecosystem page?

[Ben Bromhead]

There is certainly a lack of clarity in the grouping, as a number of those
services are not offering Apache Cassandra. I would suggest another
category along the lines of "Cassandra Protocol compatible offerings".

That way users can easily distinguish between ecosystem offerings where
"the driver works, but certain features might not", vs an actual Apache
Cassandra offering.

We could then also add things like Yugabyte and Scylla into that category.

On Wed, Jun 23, 2021 at 11:15 AM Jonathan Koppenhofer 
wrote:

> No major opinion on the "cloud offerings" piece, but I agree people should
> know what they are getting into, and be able to make an informed decision.
> However, if someone is going down that path, I would hope they do the
> due-diligence to make sure it fits their requirements.
>
> 1 small update I would suggest. It seems like Datastax Spring Boot entry
> would go in development frameworks as opposed to the sidecar section.
>
> On Tue, Jun 22, 2021, 5:39 PM bened...@apache.org 
> wrote:
>
> > Under Cloud Offerings, are we comfortable implicitly endorsing “API
> > compatible” offerings that aren’t actually Cassandra, and also don’t (as
> > far as I am aware) fully support Cassandra functionality? Should we at
> > least mention that this is the case?
> >
> >
> > From: Melissa Logan 
> > Date: Tuesday, 22 June 2021 at 21:39
> > To: u...@cassandra.apache.org ,
> > dev@cassandra.apache.org 
> > Subject: Additions to Cassandra ecosystem page?
> > Hi all,
> >
> > The Cassandra community recently updated its website and has added
> several
> > new entries to the Ecosystem page:
> https://cassandra.apache.org/ecosystem/
> > .
> >
> > If you have edits or know of other third-party Cassandra projects, tools,
> > products, etc that may be useful to others -- please get in touch and
> we'll
> > add to the next round of site updates in July.
> >
> > Thanks!
> >
> > Melissa
> > Apache Cassandra Contributor
> >
>


-- 

Ben Bromhead

Instaclustr | www.instaclustr.com | @instaclustr
 | +64 27 383 8975

Re: Additions to Cassandra ecosystem page?

[Jonathan Koppenhofer]

No major opinion on the "cloud offerings" piece, but I agree people should
know what they are getting into, and be able to make an informed decision.
However, if someone is going down that path, I would hope they do the
due-diligence to make sure it fits their requirements.

1 small update I would suggest. It seems like Datastax Spring Boot entry
would go in development frameworks as opposed to the sidecar section.

On Tue, Jun 22, 2021, 5:39 PM bened...@apache.org 
wrote:

> Under Cloud Offerings, are we comfortable implicitly endorsing “API
> compatible” offerings that aren’t actually Cassandra, and also don’t (as
> far as I am aware) fully support Cassandra functionality? Should we at
> least mention that this is the case?
>
>
> From: Melissa Logan 
> Date: Tuesday, 22 June 2021 at 21:39
> To: u...@cassandra.apache.org ,
> dev@cassandra.apache.org 
> Subject: Additions to Cassandra ecosystem page?
> Hi all,
>
> The Cassandra community recently updated its website and has added several
> new entries to the Ecosystem page: https://cassandra.apache.org/ecosystem/
> .
>
> If you have edits or know of other third-party Cassandra projects, tools,
> products, etc that may be useful to others -- please get in touch and we'll
> add to the next round of site updates in July.
>
> Thanks!
>
> Melissa
> Apache Cassandra Contributor
>

Re: Additions to Cassandra ecosystem page?

[bened...@apache.org]

Under Cloud Offerings, are we comfortable implicitly endorsing “API compatible” 
offerings that aren’t actually Cassandra, and also don’t (as far as I am aware) 
fully support Cassandra functionality? Should we at least mention that this is 
the case?


From: Melissa Logan 
Date: Tuesday, 22 June 2021 at 21:39
To: u...@cassandra.apache.org , 
dev@cassandra.apache.org 
Subject: Additions to Cassandra ecosystem page?
Hi all,

The Cassandra community recently updated its website and has added several
new entries to the Ecosystem page: https://cassandra.apache.org/ecosystem/.

If you have edits or know of other third-party Cassandra projects, tools,
products, etc that may be useful to others -- please get in touch and we'll
add to the next round of site updates in July.

Thanks!

Melissa
Apache Cassandra Contributor