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 <jmcken...@apache.org> 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 <pmcfa...@gmail.com> > 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 <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 <pauloricard...@gmail.com> > > > Date: Tuesday, 29 June 2021 at 19:14 > > > To: Cassandra DEV <dev@cassandra.apache.org> > > > 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 < > b.le...@gmail.com> > > > 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 < > 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 <b.le...@gmail.com> > > > > > Date: Tuesday, 29 June 2021 at 08:10 > > > > > To: dev@cassandra.apache.org <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 <b...@instaclustr.com> a > > > > écrit : > > > > > > > > > > > On Thu, Jun 24, 2021 at 2:38 AM Joshua McKenzie < > > > jmcken...@apache.org> > > > > > > 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. > > > > > > > > > > > > > > > > > > > > > -- Melissa Logan (she/her) Principal, Constantia.io meli...@constantia.io Cell: 503-317-8498 LinkedIn <https://www.linkedin.com/in/mklogan/> | Twitter <https://twitter.com/Melissa_B2B> Schedule a meeting: https://calendly.com/constantia_melissa
