My first reaction to seeing this come in was to laugh - not because it's funny, but because the only other thing I could think to do was cry. You've misinterpreted or misunderstood almost everything in this post, and instead of reflecting on your side of the interaction, you've attributed the outcome to selfishness on the opposite side.
First, let's set aside tinkerpop. This is a Cassandra list, let's focus on Cassandra. Different committers, different PMCs, different project. The thesis of your pasted gist is that you tried to contribute and were pushed away. You hypothesize that it's done with lack of will to pull in other people's work, and that this blocks outside contributors. I firmly disagree with your conclusion. Your gist details a proposed transition from ant to maven on a 6 or 7 year old project. You make a (relatively weak) case for it on technical merit. You are met with a combination of silence and resistance - a project with years of inertia, already out of the incubator, with build systems already in place, with history and convention on the side of ant has little desire to change from ant to maven, especially at the request of a person without a history of contributions to the project. If you were to submit a change to maven and disappear, who will maintain that change? Is there reason to believe you're willing to maintain it long term? Have you ever contributed non-invasive changes before, is there an evidence that this is the right thing for the project? That is - the change you proposed is invasive, not strictly necessary (wasn't a bug fix), and is being proposed by a newcomer, which isn't a problem, but it means your proposal needs significant supporting evidence to justify the disruption it would cause. This isn't the same as proposing an improvement to the database, it's changing the workflow of dozens of people and LOTS and LOTS of existing systems (CI and release workflows, for example) - you need to be able to defend and justify that change, as it likely causes ALL developers to change ALL of their workflows. And quite frankly, you didn't. You then *materially mischaracterize* the interaction "Whole discussion last for few mode days but at the end it was shut down by datastax employee", and you selectively quote part of the exchange, but leave out his closing sentence "*I don't want to give you the impression I am either a gatekeeper or shooting down your proposal. I'm just attempting to explain my perception **of the view of the existing contributors*." You indicate that the decisions made by the PMC force other companies to run forks (citing Stratio as an example). Here, again, history doesn't just find this unsupportable, but patently untrue. Time and time again the PMC made the decision to include code specifically so that Stratio wouldn't need to fork. Here's an example where code was backported to a stable release against typical convention (new features don't go into stable releases) specifically to enable Stratio not to fork: https://issues.apache.org/jira/browse/CASSANDRA-8717 Here's an example where Datastax committers not only reached out to Stratio to ensure that their software would be compatible with the upcoming major engine rewrite, but actually did the engineering work to ensure compatibility FOR them: https://issues.apache.org/jira/browse/CASSANDRA-9459 (note that it was designed by Datastax employed committers FOR Stratio, and that the patch came from Datastax committers). You indicate that discontinuation of thrift was seen by outsiders as marketing driven. The discontinuation of thrift is technical in nature - it's implementation has a ton of edge cases, it's existence introduces risk. It's more code to maintain, and it's now less performant than the native CQL. The preference for CQL over thrift evolved over time, it's easier for newcomers, it's easier for most people to reason about, and the 3.0 engine (ticket 8099) optimized storage for CQL, moving thrift to second class status. This isn't marketing, this is tech. The communication may have been poor (though to be fair, it was discussed in detail on various JIRA tickets, which is sent to various mailing lists, so it "happened" in the Apache sense). You then assert that communication with former employees indicates that collaboration with the cassandra team was hard. Easy/Hard is subjective, but what I suggest is that collaboration with the former-apache-cassandra team at Datastax requires folks to conform to the open source workflow - Datastax teams didn't get to short-cut the process and push features into the DB, they had to open tickets and get code reviewed just like everyone else. That's how things are SUPPOSED to work. Is it more difficult than sending a patch and having someone ninja it in? Absolutely. Does the team of committers have fairly high standard as to what code they'll accept? Absolutely. Is the bar TOO high? It's a distributed system with a lot of nuanced edge cases, a lot of us have been arguing that the bar may be too low. Now that I've disagreed with virtually everything you've posted, I'd like to tell you a story. I'm a fairly large Cassandra user at my day job. I run multiple clusters, some as large as 2 petabytes in size, with millions of writes per second. We don't have Apple or Netflix money, so we run lean and push the edge cases. We ran into a situation where we found it necessary to add a new compaction strategy, because the existing one for this purpose wasn't meeting our needs. As an organization, we decided I would submit it to the project so that we wouldn't have to maintain it separately. At this point it's worth noting two things: 1) At the time, I wasn't unknown to the project, but I wasn't a committer. 2) Compaction is inherently pluggable - extend an abstract class, compile a jar, drop it in. There's no REQUIREMENT that this code go into the main project to be generally useful. No fork required. 3) The code it was meant to replace came from another corporation, not Datastax, but Datastax had spent a lot of time and money on documenting, promoting, and supporting that piece of code. It was even in their 2015 "Cassandra Summit" keynote. 4) Relevant committers (those familiar with the compaction codebase) asked for proof/evidence that it was strictly an improvement, and I had no such benchmarks, because it's a very difficult subsystem to reliably benchmark given the number of tunable factors. If Datastax was really unwilling to accept community code or collaborate with outsiders, there are four good reasons why they could have shut that patch down. While it wasn't trivial, I decided to prove merit with evidence - I made it available to the community, it was adopted by other large users, enough people agreed it was generally useful, and now it's replaced it's alternative in newest versions. Moreover, following the Apache Way, I was invited to be a committer to help maintain it going forward - a step in the right direction towards project diversity. You can follow the conversation on CASSANDRA-9666 . If this is really an issue you brought to "a friend at ASF" as evidence of misconduct by the PMC at the time, which is hinted at in the fact that you felt called out by that insinuation in Kelly's original post, the fact that it's wrong on so many levels AND the fact that I see no evidence that anyone did any meaningful research to understand such a gross mischaracterization of "control" is really troubling. On Fri, Nov 4, 2016 at 5:03 PM, Łukasz Dywicki <l...@code-house.org> wrote: > Good evening, > I feel myself a bit called to table by both Kelly and Chris. Thing is I > don’t know personally nor have any relationship with both of you. I’m not > even ASF member. My tweet was simply reaction for Kelly complaints about > ASF punishing out DataStax. Kelly timeline also contained statement such > "forming a long term strategy to grow diversity around” which reminded me > my attempts to collaborate on Cassandra and Tinkerpop projects to grow such > diversity. I collected message links and quotes and put it into gist who > could be read by anyone: > https://gist.github.com/splatch/aebe4ad4d127922642bee0dc9a8b1ec1 > > I don’t want to bring now these topics back and disscuss technical stuff > over again. It happened to me in the past to refuse (or vote against) some > change proposals in other Apache projects I am involved. I was on the other > ("bad guy") side multiple times. I simply collected public records of > interactions with DataStax staff I was aware, simply because of my personal > involvement. It shown how some ideas, yet cassandra mailing list don’t have > many of these coming from externals, are getting put a side with very > little or even lack of will to pull in others people work in. This is > blocking point for anyone coming from external sides to get involved into > project and help it growing. If someone changes requires moves in project > core or it’s public APIs that person will require support from project > members to get this done. If such help will not be given it any outside > change will be ever completed and noone will invest time in doing something > more than fixing typos or common programmer errors which we all do from > time to time. Despite of impersonal nature of communications in Internet we > still do have human interactions and we all have just one chance to make > first impression. If we made it wrong at beginning its hard to fix it later > on. > Some decisions made in past by project PMCs lead to situation that project > was forked and maintained outside ASF (ie. stratio cassandra which > eventually ended up as lucene indexes plugin over a year ago), some other > did hurt users running cassandra for long time (ie. discontinuation of > thrift). Especially second decission was seen by outsiders, who do not > desire billion writes per second, as marketing driven. This led to people > looking and finding alternatives using compatible interface which might be, > ironically, even faster (ie. scylladb). > > And since there was quote battle on twitter between Jim Jagielski and > Benedict, I can throw some in as well. Over conferences I attended and even > during consultancy services I got, I’ve spoken with some people having > records of DataStax in their resumes and even them told me "collaboration > with them [cassandra team] was hard". Now imagine how outsider will get any > chance to get any change done with such attitude shown even to own > colleagues? Must also note that Tinkerpop is getting better on this field > since it has much more generic nature. > I don’t think this whole topic is to say that you (meaning DataStax) made > wrong job, or you are doing wrong for project but about letting others join > forces with you to make Cassandra even better. Maybe there is not a lot of > people currently walking around but once you will welcome and help them > working with you on code base you may be sure that others will join making > your development efforts easier and shared across community. > > Kind regards, > Lukasz > > > Wiadomość napisana przez Edward Capriolo <edlinuxg...@gmail.com> w dniu > 4 lis 2016, o godz. 18:55: > > > > On Thu, Nov 3, 2016 at 11:44 PM, Kelly Sommers <kell.somm...@gmail.com> > > wrote: > > > >> I think the community needs some clarification about what's going on. > >> There's a really concerning shift going on and the story about why is > >> really blurry. I've heard all kinds of wild claims about what's going > on. > >> > >> I've heard people say the ASF is pushing DataStax out because they don't > >> like how much control they have over Cassandra. I've heard other people > say > >> DataStax and the ASF aren't getting along. I've heard one person who has > >> pull with a friend in the ASF complained about a feature not getting > >> considered (who also didn't go down the correct path of proposing) > kicked > >> and screamed and started the ball rolling for control change. > >> > >> I don't know what's going on, and I doubt the truth is in any of those, > the > >> truth is probably somewhere in between. As a former Cassandra MVP and > >> builder of some of the larger Cassandra clusters in the last 3 years I'm > >> concerned. > >> > >> I've been really happy with Jonathan and DataStax's role in the > Cassandra > >> community. I think they have done a great job at investing time and > money > >> towards the good interest in the project. I think it is unavoidable a > >> single company bootstraps large projects like this into popularity. It's > >> those companies investments who give the ability to grow diversity in > later > >> stages. The committer list in my opinion is the most diverse its ever > been, > >> hasn't it? Apple is a big player now. > >> > >> I don't think reducing DataStax's role for the sake of diversity is > smart. > >> You grow diversity by opening up new opportunities for others. Grow the > >> committer list perhaps. Mentor new people to join that list. You don't > kick > >> someone to the curb and hope things improve. You add. > >> > >> I may be way off on what I'm seeing but there's not much to go by but > >> gossip (ahaha :P) and some ASF meeting notes and DataStax blog posts. > >> > >> August 17th 2016 ASF changed the Apache Cassandra chair > >> https://www.apache.org/foundation/records/minutes/ > >> 2016/board_minutes_2016_08_17.txt > >> > >> "The Board expressed continuing concern that the PMC was not acting > >> independently and that one company had undue influence over the > project." > >> > >> August 19th 2016 Jonothan Ellis steps down as chair > >> http://www.datastax.com/2016/08/a-look-back-a-look-forward > >> > >> November 2nd 2016 DataStax moves committers to DSE from Cassandra. > >> http://www.datastax.com/2016/11/serving-customers-serving-the-community > >> > >> I'm really concerned if indeed the ASF is trying to change control and > >> diversity of organizations by reducing DataStax's role. As I said > earlier, > >> I've been really happy at the direction DataStax and Jonathan has taken > the > >> project and I would much prefer see additional opportunities along side > >> theirs grow instead of subtracting. The ultimate question that's really > >> important is whether DataStax and Jonathan have been steering the > project > >> in the right direction. If the answer is yes, then is there really > anything > >> broken? Only if the answer is no should change happen, in my opinion. > >> > >> Can someone at the ASF please clarify what is going on? The ASF meeting > >> notes are very concerning. > >> > >> Thank you for listening, > >> Kelly Sommers > >> > > > > Kelly, > > > > Thank you for taking the time to mention this. I want to react to this > > statement: > > > > "I've heard people say the ASF is pushing DataStax out because they don't > > like how much control they have over Cassandra. I've heard other people > say > > DataStax and the ASF aren't getting along. I've heard one person who has > > pull with a friend in the ASF complained about a feature not getting > > considered (who also didn't go down the correct path of proposing) kicked > > and screamed and started the ball rolling for control change." > > > > There is an important saying in the ASF: > > https://community.apache.org/newbiefaq.html > > > > - If it didn't happen on a mailing list, it didn't happen. > > > > It is natural that communication happens outside of Jira. The rough aim > of > > this mandate is a conversation like that that happens by the water cooler > > should be summarized and moved into a forum where it can be recorded and > > discussed. There is a danger in repeating something anecdotal or 'things > > you have heard'. If that party is being suppressed, that is an issue to > > deal with. If a party is unwilling to speak for themselves publicly in > the > > ASF public forums that is on them. Retelling what others told us is > > 'gossip' as you put it. > > > > "I think it is unavoidable a single company bootstraps large projects > like > > this into popularity" > > "I don't think reducing DataStax's role for the sake of diversity is > > smart." > > > > Let me state my opinion as an open source ASF member that was never > > directly payed to work on an open source project. I have proposed and > seen > > proposed by others ideas to several open source projects inside (ASF and > > outside) which were rejected. Later (months maybe years later) the exact > > idea or roughly the same idea is implemented by different person in a > > slightly different form. There is a lot of grey area there. > > > > How does that related to this http://www.datastax.com/2016/ > > 11/serving-customers-serving-the-community ? > > > > Remember the ASF is a volunteer organization. One desired effect of the > > volunteerism is so that one single large company does not bootstrap or > > control the project. (When my proposed ideas got knocked down, I had some > > choices including complain to anyone that will listen, lick my wounds and > > press on, or become less involved.) > > > > Whatever event has happened has happened. Like you, I only know of it > > second hand so I will not comment. > > > > The volunteer committers can decide their own level of involvement. For > > example, they can "double down" and use their free time to stay > > involved. They can attempt to convince their organization that pulling > them > > back is the wrong move, or they can fall away. > > > > " The ultimate question that's really important is whether DataStax and > > Jonathan have been steering the project in the right direction" > > > > Outside of the politics/litigation it is becoming normal for an ASF > project > > to rotate the PMC chair. It keeps things fresh, and helps avoid issues > > where some may perceive control by one person/entity. Your question may > > ultimately highlight an issue as ASF sees it, namely who is "steering" > you > > mention a corporate entity in your question. > >
