Chris, We should release one core driver with the db to ensure no dependency and controlling issue from any vendor.
Sent from my iPhone > On Jun 5, 2016, at 5:33 PM, Mattmann, Chris A (3980) > <chris.a.mattm...@jpl.nasa.gov> wrote: > > Thanks for the info Jonathan. I think have assessed based on > the replies thus far, my studying of the archives and > commit and project history the following situation. > > Unfortunately it seems like there is a bit of control going on > I’m going to call a spade a spade here. A key portion of your > software’s stack, a client driver to use it, exists outside of > Apache in separate communities. This is an inherent risk to the > project. Some of you cite flexibility and adaptability as reasons > for this - I’ve seen it in so many communities over the last 12+ > years in the foundation - it’s not really due to those issues. > There is definitely some control going on. I would ask you all > this - has there been a PR or patch in the past year or two that > wasn’t singularly reviewed by DataStax committers and PMC? Also, > as to the composition of the PMC when was the last time a non > DataStax person was elected to the PMC and/or as a committer? > > By itself the diversity issues alone are not damning to the > project, but taken together with the citation to other project > communities even those outside of Apache (e.g., the comments > well “Postgres does it this way, so it’s a good example to > compare us to” or “these other 4 projects at the ASF do it > like this, so X”.. [sic]) and with the perception being created > to those that don’t work at DataStax, and there is an issue here. > > I would like to see a discussion in your next board report about > the diversity and health issues of the project, and also some > ideas about potential strategies for mitigation. > > I appreciate the open and honest conversation thus far. Let’s > keep it up. > > Cheers, > Chris > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Chris Mattmann, Ph.D. > Chief Architect > Instrument Software and Science Data Systems Section (398) > NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA > Office: 168-519, Mailstop: 168-527 > Email: chris.a.mattm...@nasa.gov > WWW: http://sunset.usc.edu/~mattmann/ > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Director, Information Retrieval and Data Science Group (IRDS) > Adjunct Associate Professor, Computer Science Department > University of Southern California, Los Angeles, CA 90089 USA > WWW: http://irds.usc.edu/ > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > > > > > > > >> On 6/5/16, 1:51 PM, "Jonathan Ellis" <jbel...@gmail.com> wrote: >> >> On Sun, Jun 5, 2016 at 8:32 AM, Mattmann, Chris A (3980) < >> chris.a.mattm...@jpl.nasa.gov> wrote: >> >>> 1. Is Apache Cassandra useful *without* a driver? That is, can >>> you use the database without a driver to connect to it or in the >>> real world would your users all have to download at least one >>> driver in order to use the DB? >> >> The users do need to download a driver--but this is pretty normal for >> community-driven OSS databases. Besides the Apache projects I listed, >> PostgreSQL also runs on a community-maintained driver model. >> >> >>> 2. To confirm again, at one point at least the Java driver code >>> lived in the code-base, and further, at one point, people did >>> submit some patches to add drivers, but the PMC didn’t want to >>> maintain that code (and apparently they didn’t want to create >>> any new PMC members and/or committers to do so) and so thus >>> people started their own new projects? That right? >> >> I think that summary over-emphasizes the governance aspect at the expense >> of more important considerations: >> >> 0. The very first Cassandra driver interface was Thrift. No Thrift clients >> were ever part of the Cassandra tree. >> >> 1. When we created the CQL protocol, we initially had a Java driver in tree >> as a reference implementation. >> >> 2. But due primarily to the project management issues mentioned by Nate, >> and secondarily to the governance aspects above, we moved quickly back to >> the pure community-driven drivers approach that had worked for us before. >> >> 2a. While some Apache databases do ship a Java driver in tree, I think that >> this hinders adoption because it signals to users that non-Java drivers are >> second-class citizens. (No doubt this is not the *intent* of that >> decision, but it is a likely consequence nevertheless.) >> >> 2b. DataStax saw CQL adoption as a key driver for Cassandra adoption and >> hence its own success, and hired a team to accelerate the production of >> drivers for the new CQL protocol. These drivers are Apache licensed and >> see broad community participation, e.g. with ~70 contributors to the Java >> driver. >> >> 2c. Neither has DataStax "sucked the oxygen out of the room." Lots of >> non-DataStax drivers exist as well. >> >> As Aleksey pointed out earlier, I don't see anyone being harmed by this >> state of affairs. Cassandra PMC doesn't want to run drivers projects, >> driver authors don't want to be run by Cassandra PMC, and meanwhile users >> have Apache licensed drivers that let them be productive with Cassandra.
