Community development

[leventov]

@tmc what do you think about moving the project to a community development model where more people can approve and merge PRs?

PRs are piling up recently and soon enough people will start redoing each other's work (or maybe they have already started)

[t0mpl]

I imagine this project requires lot of time, maybe that would be a good idea to be able to keep Go in AI usage.

[leventov]

CC @t0mpl @odannyc @stn1slv @chriscow @sklinkert @matigumma @codexc @loffa @n-makoto @selwyn-mccracken @treywelsh @AnilKumar-Brady @astrada-c @mdelapenya @apmcodes

Unfortunately @tmc doesn't reply, even to e-mail regarding this.

What do you think about creating an org github.com/langchaingo and continue development of the project there? Please vote on this comment.

To be honest I'm not super keen on championing the maintenance of this project (although I would be willing to participate in it to some degree, e.g. reviewing some PRs), beyond creating the org and inviting people as admins to it, which is a very little thing. But maybe there are people among us who are more keen on it? Though, in any case, probably having such people is not strictly necessary for ongoing project development, as long there are no sweeping API restructurings or things like that.

[mdelapenya]

It's weird there is no response from @tmc. I pinged on Slack about the existence of the Discord server, which is no longer available, or at least I'm so dumb that I don't find it, without response either.

PRs are piling up. Issues are pilling up, and AI/GenAI are a really important space nowadays in software development (see the other langchains in Python, Java, JS).

I had the very same feeling about envisioning a "fork" to create a bigger community, I even mentioned it to some friends, although I'd like @tmc to lead this effort if possible. In any case, I'd create the org ASAP to keep the namespace for the project, and wait a sensible period of time, because maybe @tmc is not able to answer for reasons.

[matigumma]

i vote for do it
The license allows to do this

[kiview]

I'm a colleague of @mdelapenya in the Testcontainers OSS project, so I'd like to chime in as a fellow OSS maintainer.

I can understand the urge to get velocity from the community, but often there are good personal reasons why an OSS maintainer stops being active and responsive, being overwhelmed or burned-out being one of the prime reasons. So even if we consider forking to get some progress, there should always be an open door for @tmc to rejoin, I think that is the decent thing to do (and we absolutely want to avoid ending up with competing forks).

Besides, I'd like to point out that there is a pending trademark for LangChain being filed by LangChain, Inc.: https://trademarks.justia.com/980/33/langchain-98033029.html

So I think before considering any kind of forking, we also need to understand the inofficial relationship between this project and LangChain, Inc. We are speaking from experience here, since we were and still are in a very similar relationship around Testcontainers, with the trademark being held by Docker, but also being supportive of community implementations in other languages.

[chriscow]

I vote to do it with the caveat that we need to at least reach out to Langchain and see if they would support having them put the repo under their org as a community supported repo. As @kiview mentioned, LangChain will likely be granted a trademark.

If they don't want it under their org, then we should get written permission to create a new GitHub org using their name or solicit other suggestions.

[chriscow]

CC @t0mpl @odannyc @stn1slv @chriscow @sklinkert @matigumma @codexc @loffa @n-makoto @selwyn-mccracken @treywelsh @AnilKumar-Brady @astrada-c @mdelapenya @apmcodes @tmc

unless someone would rather do it, I can reach out to the LangChain team and see if they have any preferences on how we proceed

[t0mpl]

It looks like Langchain is doing business out of it, so unless they plan to actively maintain the project (at least handle PR and issues), I don't see the plus of offering them the ownership instead of doing it community-based ?

Not an expert of OS projects so I might be wrong

[matigumma]

i think we can proceed without any restriction rather than mentioned at https://github.com/langchain-ai/langchain?tab=MIT-1-ov-file#readme

[chriscow]

I sent an email to the Langchain org. It would not hurt to get their input and ideally, they would host the repo. If not I don't see why we cannot proceed.

[leventov]

LangChain's premiere library in Python and JS are 1) synchronised in terms of their design, 2) integrated with higher-level additions by the company, like LangSmith. langchaingo does neither of those. I would be suprised if LangChain would expressed interest in taking custodianship of the library, and even if they did, I'm not sure we want to do this. In any case, this may be a thing that @tmc would not approve when/if he replies, whereas just continuing developing (with merging PRs) is a simple "two-way door" decision that can surely be easily reverted at least for a few months after we create a fork.

[devalexandre]

I create a project , mylangchaingo, but I'm thinking in rename for langchaingo-community, to be reviewed and approved faster, in addition to being able to implement more resources, for anyone interested, I have some LLMS projects for GO

[AnilKumar-Brady]

I sent an email to the Langchain org. It would not hurt to get their input and ideally, they would host the repo. If not I don't see why we cannot proceed.

Any response?

[Struki84]

Hey ppl.

Wanted to chime in… I Recently DMed with @tmc about the fact langchain deleted the discord server, and we talked about setting up a new channel for the community, what we got so far is a gc on twitter :).

If any are interested, ping me on twitter(@dumbuffalo) and I’ll add you in… I’ve just DMed him about this thread, hope we hear from him soon.

Concerning joining Langchain org I wouldn’t be to hasty with that, I can think of several technical, “managerial”, and other reasons we might not wanna do that, in any way I would first try to get in contact with tmc before we proceed further with this idea.

However, anything that will get faster release cycles and pr merging on this lib I fully endorse.

I don’t think I’m skilled enough to be responsible for the release cycle and pr’s but I’m willing to help community-wise and would like to keep submitting pr’s.

In the meantime, would you ppl be interested in setting up our own community server(Disc?) of any kind so we can get this moving?

[tmc]

Hey all, it's important to me that this project succeeds and I'll be getting cycles in within the coming days to ensure that we get a new release out and ensure the long term success of the project. I'm starting a twitter/x group (as @Struki84 mentioned). Stay tuned!

[leventov]

@Struki84 to message you on twitter requires verification. In general, I'm somewhat concerned about making twitter/x the prime channel for community discussions because some people actively avoid twitter for various understandable reasons (although I'm personally not one of them). Why wouldn't we just use Github's built-in "Discussions" feature? cc @tmc

[Struki84]

@leventov I removed the verification requirement. I agree about twitter, but until we get more then a few ppl involved we might not need something more complicated, so I would think of it as a first step perhaps. Imo the discussions section is slow and ppl don't track it that much, not sure why... 🤷‍♂️

[mdelapenya]

There is also a #langchaingo channel in the Go slack workspace. A private channel for the maintainers could be created there 🤔

[leventov]

@Struki84 https://github.com/tmc/langchaingo/discussions is not complicated I guess, it already exists and used by people...

[Struki84]

@leventov yea am aware where the discussion are, I am also aware there is dozen threads with almost no replies and no contributors are using it.

[flc1125]

Hey all, it's important to me that this project succeeds and I'll be getting cycles in within the coming days to ensure that we get a new release out and ensure the long term success of the project. I'm starting a twitter/x group (as @Struki84 mentioned). Stay tuned!

Three weeks later, is there any latest news?

I agree with what @leventov said. If maintained by the community, I believe Go language may have greater development in the AI field.

[chriscow]

I never heard back from the Langchain folks. Since this thread started, I've spent a lot of time thinking about these ideas and decided to take my work in a different direction.

I like the concept of "chaining" LLM functionality, but I felt it could be achieved using the common patterns and idioms of Go projects while abstracting LLM functionality and keeping dependencies minimal.

I think I've made a good start. It follows the http.Handler / middleware pattern:
https://github.com/chriscow/minds

[Anil8753]

Can https://github.com/ollama/ollama be an alternative?

[leventov]

I think it's best to create a new org just for the purpose of temporary support of the development. When/if @tmc appears again. Btw in that twitter group chat that was created he also doesn't respond lately.

[FluffyKebab]

Hello, I am an early contributor and maintainer here. I have been busy for around a year, but I am planning to be more active, at least the next couple of months. If there are any PRs or issues I should prioritize looking at, let me know.

I was a little disappointment to see the state of the repo when I checked it out recently. I think that the lack of maintainers is the main cause of this problem.

[Struki84]

@FluffyKebab welcome back, good to have you!

I volunteer as tribute! :D - I've been using this fw for over a year now, both professionally and as a hobby and have a ton of feedback and upgrades in the pipeline. But before submitting the bigger ones I would love to sync with you and @tmc about the future of langchain-go especially given all the changes the python bros made.

AFAIK langchain completely ditched chains and agents in favor of langgrpah, and for that purpose I started to play with it a bit in my fork: https://github.com/Struki84/GoLangChain/tree/my-sandbox I also had to make some changes on my langcgaingo fork to make it work, but anyway, the point is I would be interested in maintaining both of the fws in greater capacity.

Finally(@flc1125 ), a short update, I did get a chance to DM with tmc after NYE, he ensured me that he's planing to get things going again in the next couple of weeks, so I implore the community a bit of patience as wheels are in motion.

[leventov]

@Struki84 It may also be a good idea to consider separating the core, which is just glue for different providers, local LLM options, databases, and the like behind shared Golang interfaces, and the "chaining"/"graphing"/"agent" stuff, whether within the repo or outside it, such as @chriscow's https://github.com/chriscow/minds.

The former seems most universally useful. It could also be compatible with all of the latter (maintained on the library level, or idiosyncratic forks of those by people within their private application project repos.

These functionalities are already separated into modules (chains, agents). But some extra steps that might be useful:

• Explicitly encourage users to fork the modules like chains or agents for their projects.
• Optimise these modules for easy extensibility if forked, not necessarily if used as a library dependency. This may simplify the code and reduce the accidental complexity (API surface) of these modules, which in turn will make them even more easily comprehensible and hence forkable by users.
• Indeed, more generally speaking, optimise the readability (understandability) of these modules, rather than functionality that would stay "black box" for the users. In John Ousterhout's terms, this means keeping these modules shallow rather than deep. The standard Ousterhout's recommendation of "making modules deep" would hence be reversed here.
• Primarily extend the functionality of these modules for demonstration (testing, proof-of-concept) of more workflow (pipeline, chain, graph, agent) patterns rather than more minutiae variations or specialisations of these patterns, or other small, "accidental" functionalities.
• Change the support guarantees for these modules: don't guarantee strict backward compatibility. This would free the project developers to make more experiments with these modules, treat them more like an experimental ground rather than dependable frameworks. This will also be "licensed"/enabled by the explicit guideline for forking these modules into their project's repos rather than depending on them, as mentioned above.

Apart from the general argument for this kind of change: these higher-level abstractions like chains, graphs, etc. tend to quickly become abandonware (as, apparently, already happened with Python's langchain), there are extra amplifying arguments in the context of langchaingo:

• Unlike Python's langchain which is steered by a company that can make decisive changes such as compatibility breaking, v1/v2/v3 etc., chain -> graph shifts, etc., the more "community" nature of langchaingo would make such changes much harder because no one holds enough authority for doing such decisive changes. This raises the risks of turning langchaingo into a bag of abandonware that is hard to update because everyone is "afraid" of upsetting potential users of some functionalities, unfortunate patterns are stuck, etc.
• The nature of Go is less sympathetic to high-level, control flow abstractions such as chains, agents, etc. to be factored and composable with other code. There are programming languages that are amenable to making these kinds of high-level abstractions shared and modularisable from other source code, such as Scala and Clojure, perhaps TypeScript. Python -- already to a much lesser degree. But Go is explicitly not designed for this kind of thing.