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