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 <b...@instaclustr.com> 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 <erick.rami...@datastax.com> > 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 > <http://twitter.com/instaclustr> | +64 27 383 8975 >
