LangChainから見る、OSS成長の力学

こんにちは、[kzk_maeda](https://twitter.com/kzk_maeda)と申します

普段はatama plusという会社でSRE/DRE/EMをしつつ、AWS Community Builderとしてコミュニティ活動したりしています。

また趣味でGAI/LLM界隈はうすーくウォッチしており、LangChain系のイベントに登壇したり、Bedrock触ったりしています。

その活動の中でLangChainにコントリビュートする機会が何度かあったのですが、この異常なペースで成長しているOSSに興味があり、なぜここまで巨大なOSSとして成長できているのかを考察してみようと思います。

※ちなみに以前イベントで喋った以下の話を、別の角度からやってみようという記事です

https://speakerdeck.com/kzkmaeda/20231011-langchainkontoribiyutonosu-me

※世の中にはいろんなVCSがありますが、今回はGitHubベースで調査していきます。
※[langchain-ai](https://github.com/langchain-ai)のOrgには複数のrepoがありますが、今回はPython版の[LangChain](https://github.com/langchain-ai/langchain)を対象にします。

# OSSの世界を俯瞰してみる
まずはGitHUbが毎年公開しているOSSの動向について調査されたOctoverseの2023年版を見てみましょう。

https://github.blog/2023-11-08-the-state-of-open-source-and-ai/#the-state-of-open-source

この記事によると、2023年に最もcontributeされたOSSにLangChainがランクインしています。
意外だったのは、LangChainよりもStable Diffusionの方がcontributionを集めているところですね、text-to-imageのキャッチーさで世の中（特にSNSの世界）への浸透は進んでいるイメージですが、contributionの数がかなり多いところは想定外でした。

記事内でも言及されているように、2023年はOSSの世界でもGenerative AI躍進の年だったようです。

> Generative AI grows fast in open source and public projects. In 2023, we saw generative AI-based OSS projects, like langchain-ai/langchain and AUTOMATIC1111/stable-diffusion-webui, rise to the top projects by contributor count on GitHub. More developers are building LLM applications with pre-trained AI models and customizing AI apps to user needs.

# LangChainへのcontributionの特徴

次に実際のLangChainへのcontributeの実態を見てみましょう。
gitcompareを使って、LangChainと、上で出ていたStable Diffusion、あとcontribute数上位常連のvscodeを比較してみます。

https://gitcompare.com/report?packages=automatic1111%2Fstable-diffusion-webui&packages=langchain-ai%2Flangchain&packages=microsoft%2Fvscode

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/130140/a1da4021-4c1d-8dda-81fa-c59a00525a64.png)

全体的な規模はOSSの重鎮であるvscodeに遠く及びませんが、ここでLangChainに関して特筆すべき点は、Contributorsの数の多さとPRのペースの速さかと。

PR数はvscodeの1/3ほどの数まで伸びているし、contributors数に至ってはすでにvscodeの半数を超えています。

contribution指標全体では見えてこない、LangChainの圧倒的な成長スピードは、この異常な民主制にあるのではないかと考えます。

なぜそれが実現できているのか、その理由について考察していきたいと思います。


# なぜLangChainはこれだけのcontributorを集めることができたのか？

## 技術領域が時流にマッチしている
これはもうすでにGitHubの記事でも振れられているし、今更言及するまでもありませんが、このGenerative AI黎明期において各種LLM系アプリケーションを実装するのに便利なツール系が揃っているライブラリは非常に時流を捉えていて、その勢いが大前提としてあったのは大前提ですね。

## contributionのハードルの低さ
### コミュニティがいい感じで未成熟
僕が初めてcontributeしたのがver0.0.2xxくらいの時で、まだまだ成長過渡期の最中ではあったのですが、当時からそこまでしっかりとしたcontribution guideみたいなものはなかったと記憶しています。

https://x.com/LangChainAI/status/1678412042007453699?s=20

(最初にcontributeしたときの記念tweet）

当時、OSSへの貢献もそこまでしたことがなかった僕でもPR出してみようかなと思えたのは、このいい意味でのラフさも要因の一つだったかなと思います。
コミュニティが完全に成熟していて、新規のcontributorに手厚いオンボーディングを施してくれる親切なコミュニティもあり、それももちろんいいことなのですが、僕はこのまだまだ成熟していないコミュニティに貢献することの意義を感じたので、「PR出してみよっかな、なんか違っててもそんな怒られなさそうだし」くらいの気持ちで貢献することができました。

最近はcontribution guideも充実してきて（ついに[CONTRIBUTING.md](https://github.com/langchain-ai/langchain/blob/master/.github/CONTRIBUTING.md)から[guids](https://python.langchain.com/docs/contributing/)が外出しされましたね）、よりコミュニティとしての成熟度が高まってきているのですが、初期に異常なペースでcontributorを集められたことはLangChainの成長に大きく寄与したのではないかと思います。

### 機能展開しやすい設計
コミュニティはいい感じで未成熟でしたが、ライブラリとしての設計は初期からちゃんと作られていた印象があります。
後述する「領域特性」にも関連するのですが、LangChainはコアロジックに手を入れずとも、周辺システムへの機能追加・改修によってcontributeすることが可能なOSSとなっています。

周辺システムに変更を加える際、必要となるのは
- LangChainの作法を知ること
- 周辺システムのAPI仕様を知ること

の二つがあるかなと思いますが、前者について、InterfaceがTypeHint付きで定義されていて、また、先人たちの類似の実装もrepo内に多数転がっているので、後者のAPI仕様さえ知っていれば比較的気軽に実装することができます。

具体例として、例えばDocumentLoaderに対して何らかのシステムのAPIを呼び出せるようにしようと思った時、まずはDocumentLoader系の他サービスの実装を見て回ることで脳内に実装のイメージをつけることができます。
https://github.com/langchain-ai/langchain/tree/master/libs/langchain/langchain/document_loaders

そして、Interfaceを実装することで実現しているということのあたりをつけると、実際のInterfaceを参照しながら実装することで簡単にDocumentLoaderの対象サービスを追加できるという感じです。
https://github.com/langchain-ai/langchain/blob/master/libs/community/langchain_community/document_loaders/base.py#L15

後は必要なドキュメントや、ものによってはテストを書いてPRを出せば、コアコミッターが気づいてくれ次第コミュニケーションをとっていけばOKです！

### 領域特性
LangChainはLLMアプリケーションを実装するためのライブラリということで、いわゆるLLMに対する深い造詣がないとContributeできないのでは、という先入観があると思います。僕も使い始めた頃ありました。

しかし、上で述べたように、LangChainはLLMアプリケーションを作りやすくするためのライブラリなので、LLM自体の深い知識というより、それをどうやって使いたいかというHowの部分に強い関心があるものだと理解しています。

なので、DocumentLoaderやCache、Memory、AgentなどさまざまなComponentが存在していますが、どれもLLMの専門的な知識が求められるというよりは使い方に関する洞察があれば十分に読めるし書けるコードだと思います。

また、設計パートでも述べましたが、LangChainは多くのサービスと連携できることで価値を高めていけるライブラリです。
なので、LLMと連携したい新しいサービスが出てきたら、既存の実装を参考にしながら横展開していくことで気軽に機能追加できる、という特徴があり、それもまた多くの人のcontributeを促しているものだと思います。

## contributorへの承認
PRが取り込まれると、それがTwitter(X)で連絡されて、また頑張ろうという気持ちになれます。

他のOSSをあまり知らないのですが、OSS Contribute初心者の自分はこれでとてもやる気が出て、細かいPRも含めて他にも出してみようという気持ちになりました。

https://x.com/LangChainAI/status/1678412042007453699?s=20

(再掲：最初にcontributeしたときの記念tweet）

コミュニティは未成熟だと先ほど述べましたが、この辺りのモチベーションコントロールというか、承認欲求を擽る感じとか、とてもうまいなって思います。
きっと公式に煽られてcontribute積みまくっている人がたくさんいると思います。

# 今後の考察
最後に、素人ながら今後の成長について考えてみたいと思います。

例えばDocument Loader系など、機能の水平展開生が高い領域はcommitの伸びが鈍化していくと思われます。
世の中にはLLMと連携できると嬉しいサービスはまだまだあるとは思いますが、一定メジャーどころは取り込み切っているのかなという印象があり、今までのスピードで横展開系のサービスが増えていくことはなくなっていくだろうな、と。

一方で、既存のサービスに対する機能追加や修正、ドキュメンテーションはまだまだ貢献の余地ありそうです。
LangChainのドキュメントを読みながら実装した人だとわかる人多いと思うのですが、多くのドキュメントは正常系の最低ラインしか書かれておらず、APIパラメータや異常終了処理などは実際のコードを見にいかないとわからないことが多いです。
なので、既存サービスへのドキュメンテーションの追加は大きく歓迎され、コミュニティが成熟していくにつれで関連したPRは増えていくのかなと思っています。
（あるいはドキュメントだけ別のrepoに切り出して、よりcontributeのハードルを下げるとか、ドキュメントの多言語化とかもあり得そうですね）

また、記事執筆時点での最新バージョンはv0.0.350で、現在までpatch versionでのリリースのみが行われており、まだmajorのv1が出ていない状態である、というのも今後の成長速度に大きく寄与してくると思われます。
major versionが入ると、一定以上品質に対するハードルが上がる気はするので、リリース頻度も鈍化して、より成熟したライブラリになっていくかなと。
ただ、現在でも後方互換を保てていないような変更はコミュニケーションの段階でちゃんと指摘されるので、品質が低いということが言いたいわけではなく、ハードルの問題だけですね。


# 最後に

たいしたContributeできていない身ではありますが、LangChainのOSSとしての面について考察してみました。
OSSなので、使うだけじゃなくてみんなで貢献して育てていくのも醍醐味だと思います！日本発のContributorを増やして、世界に存在をアピールしていきましょう！！