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