TinkerPop has long held to the idea that "drivers" would be a bit like graph implementations. TinkerPop builds reference implementation of a graph and third-parties maintain "other" implementations separately. The same idea has been held for "drivers" in that we have our reference implementation of the Java driver and third-parties produce implementations for other languages.
GLVs sorta changed things though. Now we have a model where we maintain GLVs of other languages in TinkerPop itself. While somewhat risky to include the added code/complexity, maintaining the GLV in TinkerPop has a lot of good advantages for users and for growing our community. We also have come up with ways to manage the risk, by establishing a really nice initial reference implementation of gremlin-python which sets a high bar for new GLVs to come in (i.e. hooked into tinkerpop test suite, automated build mixed with maven, non-native JVM language focused, etc.). Of course, by introducing GLVs to TinkerPop though, we now have the issue of conflict with TinkerPop only having a single "reference implementation" for drivers because without a driver the GLV is pretty useless. We've mitigated that in gremlin-python so far with a simple REST implementation of a driver, but as we advance the capabilities of GLVs that approach won't be good for the long term. So - it seems like we (TinkerPop) should have a driver to go with each GLV? To me, the upsides are big for users: 1. Users don't have to hunt for drivers elsewhere - they just grab their GLV and go. I suppose there is still opportunity for third-party drivers to be built, but at least users have an immediate easy option within the Apache TinkerPop. 2. Our docs for GLV usage are completely in Apache TinkerPop and are "production ready" (i.e. not REST based then go switch to something third-party) There are some downsides which basically boil down to "Mo' code Mo' problems" but basically: 1. I believe that it will be expected that we maintain some parity in terms of features and performance with the drivers. We can't have the java driver be 10x over the python driver 2. The GLV code base becomes more complex. A high performing driver will not be trivial. 3. A whole class of downsides related to GLVs in general where we don't have the necessary language expertise to maintain it - though - again, mitigated by the high bar we set with our reference implementation for gremlin-python. Also, rather than a negative, one could also see this as an opportunity to grow the TinkerPop community. Ultimately, I think all of this is outweighed by the simple fact that we need a driver in Apache TinkerPop to fully test GLVs. Without that we're kinda of stuck ourselves.
