gistfile1.txt

I am using Cassandra since few years now and I went into few troubles till now which simply
pushed me away from even trying to become part of "open source" Cassandra community.

Since I worked with Apache projects ealier on I was looking forward to modernize way how
cassandra was built. Project uses ant script and it's not problem that it was not modern
enough, but it simply caused some troubles which hit me. I invested fair amount of time
in collecting project dependencies and separating source roots (server/client etc), but
project team simply refused this direction. Whole discussion started here:
http://mail-archives.apache.org/mod_mbox/cassandra-dev/201503.mbox/%3C287F5EBC-3C2E-44FE-B652-D0A267646ABF@code-house.org%3E
People who worked on project were rather defensing any changes in this area despite of
some other community members supporting idea:
http://mail-archives.apache.org/mod_mbox/cassandra-dev/201504.mbox/%3CCA+PAuzd_R8X-cVEpXsaoobz3pNrcAqPPMmv9VHmjPiQ=12Ek6A@mail.gmail.com%3E
Quote
> It would be great if we had more small modules/projects in separate POM. It
> will be more easier to work on small part of the project, and as a
> consequences, I'm sure you will have more external contribution to this
> project.
Whole discussion last for few mode days but at the end it was shut by datastax
employee:
http://mail-archives.apache.org/mod_mbox/cassandra-dev/201504.mbox/%3CCAFqWSgfydgjAD1Neh42M4Kx48frpr+HTwZcCmJJ9pKjY2f1Pew@mail.gmail.com%3E
Quote:
> This is a community process, and I'm trying (and apparently failing) to
> help you understand at least how *I* understand it to work, and the
> problems I see with what you're proposing. The silence on the list suggests
> there is significant inertia and no other strong advocates for this change.

Similar topic went back this year:
http://mail-archives.apache.org/mod_mbox/cassandra-dev/201605.mbox/%3CCABokNM4caL6iRB9mQkwBowoYUnJ5N-FDmwPkDTBe_vhGLyV-2g@mail.gmail.com%3E
And was shut with even shorter answer:
http://mail-archives.apache.org/mod_mbox/cassandra-dev/201605.mbox/%3CCAAafH9TnJVVoX3FSv+HDRMcCj9udFXVhEdn8RsWuKSQAi=rGXA@mail.gmail.com%3E
Quote:
> No

I had similar troubles with Tinkerpop project lead by datastax people which refused
my proposals of code restructurization to better support OSGi metadata. Even if
reasoning about code separation was technically valid it was refused and whole osgi
support proposed was also put on side:
http://mail-archives.apache.org/mod_mbox/tinkerpop-dev/201503.mbox/%3CCAA-H439PeF+VNttbW805U8iZpiBEN3m4Rbi9kfntb4Ngu_XefA@mail.gmail.com%3E
> OSGi support is not high on the priority list for us right now.  It is
> something I think we are open to considering in the future depending on the
> impact it has to our project but it is not currently a roadmap item.

I spent fair amount of time working on both topics as non paid open source community
member trying to improve projects I used to make it easier to build and easier to adopt
in various deployments. My attempts were put a side because they were not on road map
for project which is theoretically lead by community. Some people could also complain
on the way how Cassandra depends internally on CQL client interface which is moved away
from Apache project to github, but this could be a separate topic on its own.

As said ealier on in this message - I step back from any interactions with Datastax
project communities since it was nothing but time waste. I think with apache board
actions its final time for Datastax to understand open source is not just a marketing term.
Communities built around apache projects are not only to take advantages of some company
work, but also to get back things which are not relevant to company, or even whole community,
however might be relevant to some members. At the end of day these people may deploy the same
project (which is for someone else base of commercial product) in different ways.

As long as their patches are improving overall quality of documentation/code/architecture changes
should be discussed and not refused with typical "product roadmap" arguments. We form community
because we can work together on code. Not vice versa.

Best regards,
Lukasz

Hi Lukasz,

proposing structural changes in incubation is way easier than when the project is already years old :-) I do think that a well organized PMC should welcome changes, but it may take some time, and advocacy too. And I do agree that a simple 'no' as a response to a suggested change is not showing a great will in community building ;-)

Anyway, I just wanted to point out that Cassandra probably had many other issues than what you pointed out, but again, I understand your frustration, and I hope it's going to be eased now :-)