Focusing specifically on the Dart PR, I think we can defer discussions of tiers of GLVs. It sounds like folks like the idea of reviving the Tinkubator, so for purpose of the PR, perhaps it should target that space for now. As a space for "ideas" that live in the repo until we're ready to promote them, i think that might help lower the bar a bit to accepting contributions like this one.
That said, I think there still should be some thinking on the long term impact of carrying and maintaining a larger more diverse monorepo. As long as AI continues to improve, we should likely envision a greater ability to well maintain and offer more official features, particularly ones that provide connection into developer ecosystems untapped by TinkerPop. I think there's considerable value in defined ways for agents to work with TinkerPop in predictable fashion in any environment. I don't think TinkerPop is better for having the tools that enable that to be widely distributed and possibly unmaintained. I've always thought that, but prior to the advent of well running agents, no other option was possible so we were far more cautious. There's much to be considered in what this might look like and how Tinkubator would work. If we consider Dart, it could be the start of drivers evolving separately from the server and core as I would think a tinkubator Dart would be released as 0.1.0 which would be out of line with all software releasing on the same version. The implications of that aren't completely clear to me, but should be explored. I mentioned this earlier, but Airflow has done a solid job, even prior to agents, in managing a hub of tons of their third-party contributed providers. So, while they have a different provider model, I'm relatively convinced it can be done and done well particularly with good automation backboned by agents. I'd acknowledge some pitfalls. The project is more exposed the wider its official surface area is. More dependencies to keep in line and test. A serialization or protocol change in the server/core, already a heavy decision, becomes carries even more weight. Ensuring alignment of drivers in terms of configurations and features requires attention (a key reason I'd hope to come up with classification for different types of them). Opens up potentially hard decisions on what to do with no use or low use packages (how easy will it be to deprecate something and drop it once it's out there). So much to be considered, but I think too big an opportunity to not be on the positive and optimistic side of it. On Mon, Jun 8, 2026 at 8:35 PM Cole Greer <[email protected]> wrote: > Thanks for kicking off the discussion here Stephen. > > In the short term, I think the return of the Tinkubator is the right home > for > newly-developed feature-frugal GLVs. The foundational/lite GLV model might > be right long-term, but I'm not sure I'm ready to adopt it right now. > > Looking at the current gremlin-dart PR as a case study, I actually don't > want > to accept it into TinkerPop in a "reduced state" without real intention > for it to > one day "graduate" into a proper GLV. I think the Tinkubator is the right > platform for this. It gives us a good home for an experimental driver > which is > lacking some features and has unproven demand. From there, we can throw > some marketing behind it, assess the demand and decide where to move > forward. With proven demand, I'd ideally like to see us eventually close > the > feature gap and graduate gremlin-dart as a foundational GLV. If in 1-2 > years > time we see gremlin-dart is getting consistent usage, but not enough > developer investment to close the feature gap, then at that point I think > we > should consider a secondary graduation path to a "lite" driver. > > I think the Tinkubator itself would be good platform for us to move faster > with > more experimental concepts. I've been thinking about putting together some > semi-standardized DSLs for common graph algorithms (beyond the current > computer steps) as well as potential integrations with agentic memory > systems. The Tinkubator would be a good place for us to try new things > without committing to long-term support for experiments which ultimately > bear little value. > > Regards, > Cole > > On 2026/06/08 12:04:25 Stephen Mallette wrote: > > A pull request landed over the weekend offering a Dart GLV. As little as > a > > year or two ago, I think there would have been concerns for long standing > > support of such a contribution. We might have asked that the contribution > > live in its own repo for a while to see how its usership developed. It > > might have fast-tracked committership discussions. I'm not sure any of > that > > is the path anymore as I'd fully expect to see more pull requests like > this > > in the future with agents churning them out in a day or so and, on the > > TinkerPop side, agents enabling management of a larger and larger code > base > > without nearly as much overhead. > > > > Perhaps there needs to be some revised thinking around how TinkerPop > > considers language variants, particularly as they advance in > functionality > > (think how 4.x gets us subgraph and executable Gremlin subsets). I think > > TinkerPop might consider the idea of having two types of language > variants: > > > > 1. foundational - these would be like the ones officially supported right > > now, with a full capability set and clear user base, and acts as a > primary > > driver for a specific environment/runtime - like, Java for the JVM, over > > say Scala or Kotlin > > 2. lite - something that doesn't fall into "complete" for some reason - > > like say Clojure or Groovy would fall here as they would probably be > > written as wrappers to Java or Dart because it lacks a feature required > of > > foundational or simply because it's "new" and the user base isn't clear. > In > > Dart's specific case it could graduate to foundational should those > issues > > resolve because it targets a specific runtime we don't currently reach. > > > > Lite would still get the same treatment as foundational from a release > > perspective and, while that traditionally creates added burden on the > > release manager, agents will be helping in this area too as the release > > process automates and simplifies. I don't know that there is an argument > > using release complexity anymore - consider Apache Airflow managing the > > release of dozens/hundreds of their third-party contributed "providers", > > including TinkerPop. > > > > I'm not sure I have this all thought out, but it begs discussion because > I > > don't think the old ideas around this work well anymore. I sense that > > agents should let TinkerPop feel less constrained about the languages it > > supports and offer a clear way to accept and offer them as official ways > to > > work with TinkerPop-enabled graphs. > > > > A couple of side points to all this...First, perhaps language variants > > could be separated from the core release cycle at some point, now that we > > have a stable serializer/protocol. Not sure what that would look like but > > it would give releases a bit more flexibility. TinkerPop might need that > > flexibility as the variants become more feature-rich and numerous. We > > could, again, look to Airflow for their management processes > > for inspiration. Second, perhaps we should consider reviving the > > Tinkubator, an early holding place for TinkerPop ideas that weren't > really > > ready for release. That might let TinkerPop have a place for clear > > experimentation. That space might be useful in a time where agents let us > > move so quickly on ideas that we might get ahead of ourselves, but don't > > want to leave an idea untried. > > >
