James, You bring up a very pertinent point that we brought up to Stack the last time. There are projects that one could argue may have the same risk as Trafodion of not prevailing if a company does not survive. But I guess that risk is mitigated somewhat to where those companies, such as Cloudera, are in their market presence versus Esgyn perhaps. But the other reason provided was the involvement of many folks associated with Kudu, as an example, with other open source projects. Our committers have not had as much involvement with other projects, perhaps because the complexity and the backlog of what we need to accomplish for our customers is large enough that it has not afforded us time to contribute towards other open source projects, even though we have always had the intent with HBase, ORC, etc.
We have a good number of customers in China and a modest presence in the US. But our customers so far themselves may not have the open source culture, or the resources to contribute to the project itself. Plus, most of our code is in C++, although we have provided guidance to new developers on how to contribute towards the fair amount of code that we do have in Java. So, certainly these have hindered the growth of the community. There is increasing frustration within Esgyn about open source and open sourcing anything into Apache since there is a huge cost to the company of maintaining an extra set of threads and versions, with no obvious path to TLP because of the reasons mentioned. It seems that satisfying the decision makers, despite personal declarations of developers that they would be involved with the project beyond Esgyn, and that it would be crazy to think that no one would be interested in picking up such an incredible IP if anything were to happen to Esgyn -- this is decades of hundreds of million dollars of investment, into an incredible database technology, capable of running TPC-C and TPC-DS at very impressive numbers compared to the competition, with all queries executing while fully complying with the specs on the syntax (that no other vendor has been able to achieve in the Big Data world). Full Hybrid Transactional/Analytical Processing support on Hadoop with unmatched performance on both ends of the spectrum. Maybe we are just horrible at Marketing that a jewel of an engine like Trafodion must fight to get to TLP after all that we have done to try to make it ready for it. So, this is an ongoing struggle. From what I understand all projects are supposed to have 2-3 mentors. We have had Stack who has done a great job. But we need other strong mentors who can actively back the project and present its value to the Apache Foundation and what we have accomplished to qualify for TLP. We have requested more mentors, but the same decision makers on TLP, seem to have ignored those requests. So, go figure how the Apache foundation and its community works. I probably have stepped beyond the line in what I have said out of my own frustrations. These in no way reflect the views of Esgyn but as an individual associated with Apache Trafodion, as they should. Rohit -----Original Message----- From: James Taylor [mailto:[email protected]] Sent: Tuesday, February 21, 2017 12:28 PM To: [email protected] Subject: Re: [DISCUSSION] Work towards graduation On Fri, Feb 17, 2017 at 4:55 PM, Stack <[email protected]> wrote: > > Is there general agreement with Pierre's belief? If there were no Esgyn, > would Trafodion prevail? Asking here so we are prepared when question > comes up on the general incubator list. > > Did that question come up wrt Cloudera and Kudu for graduation?
