On Sat, Nov 5, 2016 at 12:37 PM, Jeff Jirsa <jji...@gmail.com> wrote:
> 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. > > > > > Jeff, I agree with you on a lot of points, but not this one: "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?" This sentiment has been used by a number of people to block things they don't want. For example, you remember when vnodes were added. Vnodes had some issues, one terrible side effect was it drastically hurt the performance of users doing Hadoop with Cassandra see below: https://issues.apache.org/jira/browse/CASSANDRA-6091 I personally ran into this. Jobs that used to kick up maybe 18 tasks kicked up thousands. Here are others with the same problem: http://grokbase.com/t/cassandra/user/133wrx46zy/vnodes-hundred-of-mapreduce-jobs Follow down into the ticket: Why are you stopping this implementation Two words: opportunity cost. I do not think you should not not take a "scratch an itch" contribution and say, "but I'm a committer and I have to deal with it forever". We are seeing a side effect of this thinking, those claiming they will have to "maintain it long term" are highly likely do be doing something else in 2-3 years. This situation is chicken and egg. You don't add anything because you do not want to be stuck maintaining things, but you still maintaining everything because you did not grow the committer base by taking new things. Relating to ant: Hive had a very large ugly ant file. It had like 9 sub projects. It had to build against N versions of hadoop. It was massive suck, far worse then Cassandra's ant file. I (hive pmc) called a vote for the person who converted that ant file maven as a committer mostly on the merits of that contribution alone. Hive has vote people onto the PMC for writing documentation.
