記事一覧に戻る

GitHub の高スターリポジトリの 3 分の 1 は、2 年間動いていない

約 1 分データ分析メンテナンス

本記事は機械翻訳であり、ネイティブによる校正は行われていません。 原文を読む →

私たちはスター 1,000 以上の GitHub リポジトリを 6.7 万件以上追跡し、その状態を毎日記録しています。「最後の push からどれだけ経ったか」で並べ替えると、居心地の悪い数字が出てきます。

最終 pushリポジトリ数割合スター中央値1000 スターあたり未解決 issue
3 か月以内27,19142.9%2,42911.5
3〜12 か月9,22414.5%1,9839.1
1〜2 年6,57510.4%1,97410.1
2 年超20,43932.2%1,7729.0
push 日時が記録されている 63,429 リポジトリ。

およそ 3 分の 1 が、2 年以上一度も push を受けていません。直近 3 か月に触れられたものは半数に届きません。

この数字にはすぐ 2 つの反論が来ます。どちらももっともです。しかしどちらも、データの前で無傷では済みませんでした。

反論 1:「そんなものは全部 awesome-list だ」

直感はこうです。キュレーションされたリスト、書籍集、面接対策リポジトリはコミットを必要とせずスターを溜め込む。停止バケットを水増ししているだけで、ソフトウェアについては何も語らない、と。

この効果は実在します。プログラミング言語が検出されないリポジトリは、活発に保守されているバケットで 5.0%、2 年停止バケットで 10.8%——ちょうど 2 倍です。ドキュメント寄りの言語(Markdown、HTML、TeX、Jupyter)を加えても傾向は同じで、3.4% 対 6.0% になります。

しかし両者を合わせても、停止バケットの約 6 分の 1 にすぎません。残りの 6 分の 5 は、実際のプログラミング言語を持つリポジトリです。つまり本物のソフトウェアが、数千のスターを背負ったまま 2 年間放置されています。

その中でも規模の大きいものがこちらです:

  1. jlevy/the-art-of-command-line161.8k2.1 年沈黙
  2. justjavac/free-programming-books-zh_CN117.7k2.0 年沈黙
  3. nvbn/thefuck97.6k2.0 年沈黙
  4. fighting41love/funNLP81.9k2.2 年沈黙
  5. CompVis/stable-diffusion73.2k2.1 年沈黙
  6. prakhar1989/awesome-courses69.9k3.2 年沈黙
  7. resume/resume.github.com62.9k3.4 年沈黙
  8. xingshaocheng/architect-awesome60.8k2.3 年沈黙
  9. atom/atom60.8k3.5 年沈黙
  10. angular/angular.js58.6k2.3 年沈黙

一部は確かに参考資料です。しかし、今も人々がインストールして使っているソフトウェアも含まれています。

反論 2:「停止は放棄ではない。良いソフトウェアは完成する」

こちらのほうが強い反論です。課題をきちんと解決した小さく専門的なライブラリは、コミットを必要としません。変更の多さは健全さではなく、静かなリポジトリは単に完成したリポジトリかもしれません。

ただしそれが全てなら、issue トラッカーに痕跡が残るはずです。実ユーザーのいる放棄されたプロジェクトは誰も捌かない issue を溜め込み、本当に完成したプロジェクトはそもそも issue をあまり集めません。ですから受け手の規模で正規化した滞留量は、両グループで明確に違って見えるはずです。

そうはなりませんでした。上の表の最終列を見てください。1,000 スターあたりの未解決 issue は、どのバケットでも 9〜11.5 の範囲に収まります。活発に保守されているプロジェクトのほうが、2 年停止のものより正規化後の滞留がわずかに多いのです。

この結果は予想外でした。この列は 2 つのグループを分けるために追加したのに、分けることを拒んだのです。

この平坦な線が意味しうること

最も妥当な読み方は、放棄は双方向だということです。ユーザーが issue を叩き続けている最中にプロジェクトが黙り込むことは、普通ありません。関心は両側から同時に去ります——メンテナが push をやめる頃には、issue を出したはずの人々はとっくに別のものへ移っているのです。

「無数の放置プロジェクトと怒れるユーザー」ほど劇的な話ではありません。しかしスター数で依存関係を選ぶ人にとっては、むしろ悪い知らせです。リポジトリは、スターが多く、明らかに停止していて、なおかつ外から見て壊れているようには見えないという状態を同時に満たしうる——文句を言うはずだった人たちが、何も言わずに去ったからです。

この推論は慎重に扱うべきです。私たちが見ているのは未解決 issue 数の現在のスナップショット 1 点であり、GitHub のこの数値は PR も含みます。issue が一括クローズされたのか、メンテナがトラッカーを無効化したのか、滞留が時間とともにどう動いたのかは分かりません。平坦な線は双方向の放棄と矛盾しませんが、それを証明はしません。

実務的な結論

スター数が記録しているのは、「かつて何人がブックマークする価値があると考えたか」です。今も誰かが保守しているかは語りませんし——issue のデータを見る限り——今も誰かが使っているかについても、あまり語りません。

スター数の高さを理由に依存を採用する前に、最後の push 日を見てください。ワンクリックで確認でき、そしておよそ 3 回に 1 回はスター数と食い違います。

このデータで言えないこと

  • サンプルはすでにスター 1,000 を超えたリポジトリであり、GitHub 全体ではありません。ここでの結論は「典型的なリポジトリ」を説明しません。
  • pushedAt は任意のブランチへの push を数えます。 自動コミットも含む生存シグナルであって、有意な作業量の指標ではありません。
  • 未解決 issue 数には PR が含まれ、しかも履歴ではなく単一の現在スナップショットです。
  • 言語の判定は GitHub 自身の検出に従い、ファイルのバイト構成で決まるため予想外のラベルが付くことがあります。
  • さらに 4,123 件は利用可能な push 日時が記録されておらず、上のどのバケットにも含まれていません。

表は日次クロールとともに更新されます。同じ語彙はランキングで自分でも並べ替えられます。

本記事の数値はすべてデータベースからリアルタイムに読み込まれ、日次クロールで更新されます。