-
-
Save splatch/aebe4ad4d127922642bee0dc9a8b1ec1 to your computer and use it in GitHub Desktop.
| 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 |
Hey @elecharny,
I will try to not run too much into technical stuff again, because as I said ealier - I'm done with that. My bad luck comes from fact that I was advocating tools which pretty much have love-or-hate scale. :) I'm glad you went over mail threads listed in above message. Indeed this gist is spoiled with two separate things which are closely related to similar domain, yet projects represented mostly by majority coming from same entity.
I will start from simple fact that we are developers and we use versioning to do changes in the way that is predictable for users who run our software. I think that main driver here was that both projects are also used as product base. This makes certain changes much harder but should not make them impossible. If some changes are to big, we can use depreciation cycle, make it happen in phases and so on. I believe we both can distinguish blocking destabilizing changes to happen in product from blocking improvements in open source projects. Product and projects are not the same things even if they are coming from same code base. Rules doesn't have (or even shouldn't have) be same for both since even in companies who support OSS projects not every open source release becomes base for a product.
You point to API changes which are not neutral and you give examples of how hard it was to make ldap api changes. I don't think separating dependencies (instead of aggregating them) is uncommon thing or thing which you should postpone. That's why I proposed these changes in incubation phase of Tinkerpop so it would not result into "design lock in" which will require another major release or two to get it done. If this is not a good moment for that, when it will be better? Worth to note that before tinkerpop was even moved to ASF there was inquries about that.
Whole discussion is now moved to Cassandra mailing list and if you would like to continue it, please check dev@cassandra.apache.org.
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 :-)
Lukasz,
as much as I feel for you, this has nothing to do with the fact the project was under Datastax influence. It was just that the build was working ( "when it's not broken, don't fix it.."), and they were reluctant to change the build tool. Such a change is really disruptive for developers, who just HATE having to learn a new way to build code.
OSGi enter into a different catgory : it's really requires some code refactoring, something likely to take time and energy. Again, you are enforcing a change that is not likely to be neutral, and the team needs to be evangelized.
We went through those changes (well, we used Maven from day one but the move from maven 1 to Maven 2 was painful) at directory@apache.org, and trust me, these are disruptive changes. Typically, the LDAP API has been changed to be OSGi compliant, and it was quite a mess in term of code and build. We started to work on doing the same thing on the server, and never completed the move, for the reasons I expressed.
Frustrating ? Yes, you bet. Does it has anything to do with the fact that it was a Business driven project? I think you are off base. Advocacy is a requirement when changing such elements in a big project. Nothing new under the sun...
And I'm not a datastax person, FTR, nor do I disaprove what happen recently. I just do think that your frustration is not related to what happened. It may, but I don't think there is any correlation.