Thank you for your comments, David. I think TinkerPop definitely fits into the Apache ecosystem. Out of the box it has integrations with Apache Spark and Apache Giraph. If you pull in Titan as the graph implementation, it uses Apache Cassandra or Apache HBase. It is worth noting that Apache Falcon and Apache Atlas are using TinkerPop (with Titan), although they haven't moved to the TinkerPop3 version yet. A member of the TinkerPop community presented on TinkerPop at Apachecon in Austin in March. There was some discussion at Apachecon about whether Apache Flink could leverage the TinkerPop Graph APIs. I think there have been similar discussions about GraphX from Apache Spark.
I think the reason you are seeing the word "vendor" splashed around the mailing list is because TinkerPop is a graph abstraction. For example, other than TinkerGraph, it doesn't ship with an OLTP graph implementation. The project has been very deliberate about what features to include such that vendors can comply with the TinkerPop Graph APIs without pulling along vendor-specific baggage. Perhaps it would be better if there were a fully-featured TinkerPop reference implementation. As far as decision making, I've noticed that a lot of discussion for features is within the JIRAs themselves, but those notifications still end up on the mailing list. There was recently a call for a community vote whether to bump support to Hadoop 2.x, and that ended up getting many responses from the community. To sum up, I think there is a community here in TinkerPop that already plays well within Apache. If there is an opportunity to correct course to become better aligned with the Apache Way, I think it is definitely something this community can make possible. On Sun, Oct 4, 2015 at 1:50 PM, David Nalley <[email protected]> wrote: > First my apologies on the delay of this response, with ApacheCon > wrapping up, more international travel for most of us, and another > impending conference, I've been slower than normal. > > > Let me first start of though expressing a bit about both the structure > and culture of the ASF. From a structural perspective, we really > aren’t that unique. The number of organizations who have copied our > organizational structure and governance model is a list scores long. > Not all are perfect implementations, but rarely a month goes by in > which we don’t hear ‘We modeled our project or organization based upon > what works at the ASF’ At the end of the day, we are a corporation, > organized as a public benefit charity, with a Board of Directors > providing oversight of hundreds of projects. The board very rarely, if > ever, interferes with technical decisions or the technical direction > of the projects. But that is merely an organizational structure. The > thing that sets the ASF apart is its culture, all of the above can be > (and has been) replicated a number of times elsewhere, but culture and > involvement as a group is important, and it’s also one of the things > that is most tenuous when new projects come to the ASF. And while > software is the ‘work product’ that we deliver, we consider the > community of people who come together to build software, write > documentation as well as all of the other tasks like testing, bug > triaging, etc as far more important, and we want the community to have > a connection with the other project communities and people at the ASF. > > > I don’t have concerns about compliance with release policy, or other > process issues. That seems pretty squared away. > > So with that out of the way, I have some primary concerns, and I may > list some that others brought up during conversations in Budapest. > > > First up is that the project doesn’t care about being a part of the > larger Apache community. Members of the project have explicitly said > so. This is the biggest problem for me, though some of the other are > pretty serious in their own right. > > > Vendors having status - this is something that’s come up before. Folks > involved at the ASF are expected to act independently, as individuals. > In terms of the project, getting influence because you are employed by > a software vendor is problem. I see the phrase ‘vendors’ far too > often. We shouldn’t be building software for ‘vendors’, our software > is for the public at large, and a vendor employee that uses the > software should have to earn merit in the same way as anyone else. > Despite this being discussed several times, no change seems apparent. > > > Decision-making is happening elsewhere. This is something that was > called out in Budapest. The primary venue for decision making in > Apache projects is the mailing list. Unfortunately we see > pronouncements of decisions that were made, but precious little > decision making, debate, etc. > > > Any of these issues alone is problematic and terribly worrisome, and > would block graduation. In aggregate it’s even more bleak. > > > The following statement is not original with me, but I think it > actively sums up the situation, and reflects how I feel about the > situation. “They want to cloak themselves in the Apache name, gain > the protection and reputation that the ASF brings with it, but they > don’t want to change the way they operate, or adopt the ASF culture.” > > > In addition to those issues, I think there are a few more - that > perhaps are worrying but not rising to the same level. One of those is > that since joining the ASF diversity of the project (in terms of > employers of committers/PMC) has gotten substantially worse. > > --David > > > On Fri, Oct 2, 2015 at 3:08 PM, David Nalley <[email protected]> wrote: > > Hi folks, > > > > A number of the mentors (Daniel, Rich, and I), along with several > > other IPMC members were in Budapest for ApacheCon; while there we > > discussed the state of > > Tinkerpop, it's incubation, and a number of other topics. I wanted to > > bring one of those topics here to foster a larger discussion, and > > perhaps for the community to decide on a way forward. > > > > After a lot of deliberation and thinking both together and > > individually, I think we reached an inflection point for ourselves. > > While I don't want to speak for the others, > > I will state my opinion. I think it's become apparent that Tinkerpop > > as a project and a community is not a fit for the Apache Software > > Foundation, and I see little potential for that to change. > > This is not a statement that Tinkerpop is bad or evil. The ASF isn't > > the only place projects live to be successful, nor is the Apache Way > > the only method that successful projects adopt. > > > > That said, the ASF cares deeply about it's existing culture and that > > the communities that are here adopt "the Apache Way"; that's actually > > a core tenant to accomplish during incubation. That leads > > me (speaking only for myself) to believe that you would thrive better > > elsewhere, rather than chafing and being unhappy, and eventually > > failing to graduate. > > > > --David > -- Have a good one, Jason
