GitHubとソフトウェアに対する犯罪

 (eblog.fly.dev)
1 ポイント 投稿者 GN⁺ 22 시간 전 | 1件のコメント | WhatsAppで共有
  • GitHubは開発インフラの中核のように使われているが、頻発するインシデント・遅いページ・ブラウザ表示崩れのため、基本的な信頼性が揺らいでいると評価されている
  • Microsoftはagentic workflowsによって負荷が急増したと明かしたが、GitHubやCopilot・agent機能を自ら押し込み、利用を促してきたという批判も強まっている
  • 最小リポジトリ実験では、GitHubは291件のリクエストと圧縮応答15MiB、展開後544,564行をダウンロードし、Codebergの11件のリクエストと大きな対照をなした
  • フロントエンド測定では、GitHubは通常ヒープ約69MiB、rust-langのpull requestページは148MiBを使用し、テキスト中心のページとしては過度に無駄が多いと評価されている
  • 結論として、GitHubの無駄は単なる製品劣化ではなく、ユーザーの問題解決よりもAI機能と投資家中心の優先順位を前面に出したソフトウェアの失敗だということだ

GitHubの信頼性と優先順位

  • GitHubはソフトウェア開発インフラの中核のように使われているが、ダウンタイム・性能低下・ブラウザ互換性の問題により、基本的な信頼性に疑問が持たれている
  • GitHub Status記録には毎月数十件のインシデントがあり、公式ステータスページやSLAの基準でも違反と見なせそうな状況がある
  • FirefoxとSafariで頻繁に表示が崩れ、pull requestのコメント・レビュー画面が遅く、RAM使用量やヒープスパイクが過剰だという批判を受けている
  • GitHub Actionsは遅く、ドキュメントも不十分で、ログ画面は長年にわたりメモリリークとブラウザクラッシュを引き起こしてきたとされる
  • setup-goのような基本アクションのキャッシュ動作も、無効化がないか過度に単純だと評価されている
  • githubstars.comのようにスター購入を公然と宣伝するサイトがあり、Carnegie Mellonの論文の「fake stars are highly related to malicious activities」という文言も引用されている
  • GitHubが本来目指すべき対象は高性能・高可用性・大容量の分散システムだが、実際の製品は基本信頼性よりAI機能とagentのフローを優先していると評価されている

「Agentic」な負荷とMicrosoftの責任

  • GitHubは'an update on github availability'で、2025年12月後半以降、agentic development workflowsが急激に加速し、リポジトリ作成・pull request活動・API利用・自動化・大規模リポジトリのワークロードが急増したと明らかにした
  • この説明は負荷増加を外部要因のように扱っているが、GitHubと親会社MicrosoftがAIや「agents」を複数の製品に押し込み、自ら利用を促してきたという批判につながっている
    • GitHubのほぼすべてのページの上部バーにはAIボタンが3つあり、そのうち2つはagent開始専用で、多くのページでは4つある
    • 一般的なリポジトリのランディングページ右上エリアには、Copilotを起動する方法が4つある
    • GitHubは数年にわたりツール利用コストを補助して採用を促しており、これは自分自身に分散型サービス拒否を補助金付きで仕掛けたのと同じだという批判リンクが示されている
  • Microsoftは、1つのpull requestがGitリポジトリ、マージ可能性チェック、branch protection、GitHub Actions、検索、通知、権限、webhooks、APIs、バックグラウンドジョブ、キャッシュ、データベースに影響しうると説明している
  • 大規模環境では小さな非効率でもキューの深刻化・キャッシュミス・DB負荷・インデックス遅延・リトライトラフィック増幅につながりうるが、GitHubの非効率は「小さい」レベルではなく、巨大で圧倒的だと評価されている
  • Microsoftは「availability first, then capacity, then new features」と述べたが、GitHub公開changelogでは当該アップデート以降30日間のパッチノートで「copilot」は59回、「agent」は8回登場し、「performance」と「reliability」は0回だった
    • changelogのフィルターにはcopilotカテゴリが個別に存在するが、performanceやreliabilityカテゴリは存在しない
    • Visual Studio CodeもGitHubおよび「agentic」機能と直接統合されており、内蔵ターミナルのような基本機能が悪化する一方でagent機能が追加されているとの批判を受けている
  • Microsoftが「unnecessary work」の削減、キャッシュ改善、重要サービスの分離、単一障害点の除去、性能に敏感な経路の移行、隠れた結合度の削減、blast radiusの制限、graceful degradationの実施を進めると述べた点は、システム設計が誤っていたことの認定と解釈されている

フロントエンドがバックエンド問題を示唆する理由

  • GitHubの信頼性問題の根はバックエンドとデータベースにあるが、外部からは見えず、その代わり毎回ダウンロードされるHTML・JavaScript・CSSのようなフロントエンドコードは観察できる
  • ピザ店の客席にネズミが見えたら厨房が清潔だとは信じがたいのと同じように、GitHubフロントエンドの目に見える腐敗はバックエンド問題を示唆するが、証明はしないと見られている
  • GitHub、GitLab、Codebergのリポジトリランディングページは、リンク一覧、小さなUX要素、ボタン、タブ、検索欄で構成され、インタラクティブなメディアや画像のような高コスト要素はほとんどない
  • この種のページは良好なインターネット接続でなくても、ほぼすべてのコンピュータや携帯電話で低コストに動作すべきであり、GitHubは過去にはiPhone 4と3G接続でも実際にそう動いていたとされる
  • 機能が同じなら、最良のコードとはネットワーク帯域、CPU時間、RAMを最も少なく使い、バグが最も少ないコードだと定義される
  • フロントエンドのバグ数を直接知ることはできないが、歴史的研究ではバグ数は通常コード行数に比例するとされている
    • Steve McConnel, Code Complete, 2nd Ed (2004)では、出荷ソフトウェアの業界平均エラー数は1000行あたり1～25件と引用されている
    • Microsoft Applications Divisionは、社内テスト中には1000行あたり10～20件の欠陥、出荷製品では1000行あたり0.5件の欠陥を経験したと引用されている

実験設計と収集方法

  • 交絡要因を減らすため、インターネット速度を「fast 3G」接続に制限した
    • ネットワーク条件変動の影響を減らし、地方のような理想的でない状況でのGitHub顧客体験をシミュレートするための設定である
  • 3つのサービスすべてで同一の最小リポジトリghsucksを使用した
    • 単一ブランチmaster
    • 単一ファイルREADME.md
    • issue・タグなど付加要素は0件
  • 同じブラウザと同じコンピュータを使用した
    • Firefox
    • Apple Macbook Pro M5 Max
    • 48GiB RAM
  • 各サービスで4種類のページを調査した
    • 「landing」ページ: コードレイアウト
    • 「pull requests」または「merge requests」ページ
    • 「issues」ページ
    • 「settings」ページ
  • クリーンキャッシュ状態でHTTP Archive(HAR)を収集してネットワークリクエストを分析し、読み込み完了後にヒープスナップショットを取得して定常状態のRAM使用量推定値を得た
  • HAR分析には自作のanhar、圧縮サポート分析にはtestcompress、クロスチェックにはpagespeed.web.devを使用した

ヒープ使用量とメモリの浪費

  • 基本的なリポジトリページのヒープ使用量は、GitHub 69MiB、GitLab 68MiB、Codeberg 14MiB、eblog.fly.dev 1.3MiBと測定された
  • https://github.com/rust-lang/rust/pulls の最初の Issue ページのレンダリングには 148MiB の RAM が使われた
  • 148MiB は初代 iPhone より多いメモリであり、リンクがいくつかあるテキスト中心のページとしては 極端な浪費 と評価されている
  • 比較対象として挙げられた機器のメモリは、Apple iphone 1 128MiB、iphone 4 512MiB、Sony playstation 2 32MiB、Nintendo wii 88MiB などである

リクエスト量とレスポンス規模の比較

  • anhar は HAR JSON を解析し、レスポンスの HTML・CSS・JavaScript を deno fmt で自動整形したうえで、リクエスト・レスポンスサイズ、MIME ごとの合計、ロード時間、レスポンス行数を計算する Go プログラムである
  • 主な指標は、リクエストサイズ、実際に受信した圧縮済みレスポンスサイズ、deno fmt 適用後の展開レスポンスサイズと行数、基本 HTML のロード時間である Content-Load、すべてのコンテンツのロード時間である Load である
  • Codeberg リポジトリページ は全体で 11件のリクエスト、リクエスト 9KiB、レスポンス 1MiB、展開レスポンス 1MiB、展開後 3,480行、Content-Load 2.934s、Load 3.172s と測定された
  • GitHub リポジトリページ は 291件のリクエスト、リクエスト 178KiB、圧縮レスポンス 15MiB、展開レスポンス 22MiB、展開後 544,564行、Content-Load 843ms、Load 21.330s と測定された
    • application/javascript: 214件のリクエスト、レスポンス 12MiB、展開レスポンス 19MiB、展開後 481,849行
    • text/css: 42件のリクエスト、レスポンス 2MiB、展開後 60,016行
    • GitHub pulls: 266件のリクエスト、圧縮 14MiB、展開 20MiB、展開後 487,922行、Content-Load 592ms、Load 6.754s
    • GitHub settings: 255件のリクエスト、圧縮 14MiB、展開 20MiB、展開後 486,067行、Content-Load 778ms、Load 6.963s
  • GitLab は GitHub より小さいが、それでもなお重い
    • GitLab リポジトリ: 78件のリクエスト、レスポンス 8MiB、展開後 101,682行、Content-Load 6.880s、Load 12.941s
    • GitLab merge_requests: 65件のリクエスト、レスポンス 7MiB、展開後 90,567行、Content-Load 6.947s、Load 12.096s
    • GitLab edit: 117件のリクエスト、レスポンス 7MiB、展開後 71,916行、Content-Load 6.964s、Load 13.302s
  • GitHub は空のリポジトリ表示にも 約54万行 のコードとデータを取得しており、これは DOOM 35K行、Windows Quake 120K行、MS-DOS 4.0 332K行、Zig toolchain 460K行より多いという比較が示されている
  • 個別ページが CSS ファイル 40個と数百の JavaScript を取得する構造が問題視されている
  • Webpack のチャンク分割は理論上、コア機能と選択機能を分け、キャッシュや CDN に有利になりうるが、ここでは各ファイルごとに独立した HTTP リクエストが必要なため、ロードを遅くする結果になっていると解釈されている
  • 空ページを見るために 22秒 待つのは受け入れがたく、1GiB/s 超の高速回線と高性能な一般向けプロセッサ環境でも、リポジトリがある程度使えるようになるまで 1秒以上かかると評価されている

圧縮サポート比較

  • 圧縮は、クライアント・サーバー・経路上の中間装置の負荷を下げる有用な方法として示されている
  • gzip は実績のある圧縮標準であり、すべての Web サイトが対応すべきで、zstd は性能特性に優れるがより現代的な方式のため、対応は「あると望ましい」水準として扱われている
  • testcompress は URL が gzip と zstd 圧縮に対応しているかをテストし、対応していない場合はレスポンス本文を直接圧縮して潜在的な削減量を示す Go プログラムである
  • eblog.fly.dev/startingsystems3.html: 対応エンコーディング zstd gzip、元サイズ 575.77KiB、gzip 67.64KiB、zstd 60.17KiB
  • github.com/ef0xa/ghsucks: 対応エンコーディング gzip、元サイズ 224.70KiB、gzip 43.27KiB、zstd 37.96KiB
  • gitlab.com/efronlicht/ghsucks: 対応エンコーディング gzip、元サイズ 43.08KiB、gzip 11.48KiB、zstd 11.34KiB
  • codeberg.org/efronlicht/ghsucks: 対応エンコーディング n/a、元サイズ 43.88KiB、gzip 13.00KiB、zstd 12.79KiB

PageSpeed モバイル結果

  • pagespeed.web.dev のモバイル計測で、Codeberg は First Contentful Paint 1.2s、Largest Contentful Paint 1.3s、Interaction to Next Paint 86ms で PASS を獲得
  • eblog.fly.dev は First Contentful Paint 1.1s、Largest Contentful Paint 1s、Interaction to Next Paint N/A で PASS を獲得
  • GitHub は First Contentful Paint 1.8s、Largest Contentful Paint 2.1s、Interaction to Next Paint 242ms で FAIL
  • GitLab は First Contentful Paint 2.1s、Largest Contentful Paint 2.4s、Interaction to Next Paint 243ms で FAIL

サービス別評価

  • GitHub

    • 約300ファイル、コードとデータ約550,000行を取得し、推定バグ数は550件とされる
    • Content-Loadは約800ms、全体のLoadは約7s、定常状態ヒープは約69MiBと要約される
    • gzipはサポートするがzstdはサポートしない
    • 評価はFで、コードの重さが非常に大きいと評される
    • GitHubは使用有無にかかわらず、すべてのページですべてのテーマを取得していると指摘される
    • pagespeed.web.dev がJavaScriptとCSS 528KiBが完全に未使用であると示しており、この部分から削減できるとみられる
    • GitHubにとどまるのであれば、GitHub自身のSLAに違反していると見なし、返金を受けるためにサポートチケットを提出するよう提案される

  • GitLab

    • Content-Loadは約7s、Loadは約13sで、70ファイル以上・7MiB、約10,000行を取得する
    • 定常状態ヒープは約68MiBで、gzipはサポートするがzstdはサポートしない
    • 評価は**D+**で、GitHubほど浪費的ではないが、リソースを取り込みすぎて適切に使えていないと評される
    • JavaScriptとCSSを1MiB以上取得するが、実際にはまったく使われていない部分があり、使われるコードにも3MiBチャンクがあってパースだけで255msかかる
    • ランディングページにCSS 55,000行は不要であり、CSSとJavaScriptの両方を現在の10分の1程度まで減らせると判断される

  • Codeberg/Forgejo

    • Content-Loadは2.9s、Loadは3.1sで、11ファイル・1MiB、約1,100行を取得する
    • 定常状態ヒープは約14MiBで、gzipとzstdの両方をサポートしない
    • 評価は**C+**で、基本はできているが細部への注意と経験が不足していると評される
    • HTML minifyをしていない点は小さな問題だが、圧縮をサポートしない点は大きな欠落と評価される
    • JavaScriptとCSSの大半はページ描画に不要だが、描画を妨げる形で読み込まれている点が問題として挙げられる
    • JavaScriptとCSSのペイロードを結合してリクエスト数を減らし、HTMLを含むHTTPペイロードでgzipとzstd圧縮をサポートすべきだという提案が出る
    • 自由ソフトウェアであるため、別インスタンスやセルフホスティングへ移行できる点が利点として挙げられる

  • eblog.fly.dev

    • eblog.fly.dev/startingsystems3.html はContent-Load 76ms、Load 1.1s、5ファイル 766KiB、約3,800行と測定される
    • 単一のHTMLファイルは576KiBで、zstdにより約70KiBまで圧縮される
    • 定常状態ヒープは約11MiBで、zstdとgzipの両方をサポートする
    • 評価は**A-**で、全体としては良いが、HTMLは圧縮を考慮しても肥大で反復的であり、1回のリクエストで済むページに5回のリクエストが必要だと評される

単なる製品劣化ではなくコストの問題

  • 「enshittification」は、良い製品がユーザーとビジネス顧客に有利な形で始まり、その後ユーザーに不利になり、さらにビジネス顧客にも不利になって運営者に有利になる過程として要約される
  • MicrosoftとGitHubは Embrace, Extend, Extinguish とも無関係ではないが、ここでの問題はユーザーやビジネス顧客だけでなくMicrosoftにもコストを生む点で異なるとみられる
  • 膨れ上がったコードベースはサーバー・帯域幅コストを直接増やし、不安定で肥大化したコードベースの維持にエンジニア時間を間接的に消費させる
  • GitHubのエンジニアが約800人で、1人あたり週40時間・年48週勤務と仮定すると、年間1,536,000エンジニア時間に相当する
  • フロントエンド問題の大半は、pagespeedの勧告に従うだけでも有能なエンジニアなら1週間以内に修正または緩和できるとみられる
  • 低レベルな改善がコスト削減につながるにもかかわらず放置される理由は、無関心、極端な無能、あるいはAIと投資家中心のリーダーシップに阻まれている状態のいずれかと解釈される
  • ソフトウェアは一度正しく書けば、完全に、永遠に、無料で複製して誰もが使えるという点で、強力で美しい道具だと描写される
  • GitHubや類似サービスの浪費と無能は、単なる悪い製品ではなくソフトウェアに対する犯罪だという結論につながる

関連記事

1件のコメント

 
GN⁺ 22 시간 전
Lobste.rs の意見

  • Trac と Sourcehut もこの比較に含まれているとよかった

  • AIエージェントのボタンが4つあるのは滑稽だし、記事に出てくる相対的な数値も興味深いが、GitHubを擁護したいわけではまったくないとしても、記事の細部の一部は文脈が足りず、著者の主張を支えるには十分ではないように見える
    アイドル時のメモリ使用量は、GitHubがCodebergより多くの仕事をしているという兆候かもしれないが、48GB RAM のコンピュータでの絶対的なRAM使用量をApollo誘導コンピュータと比較して有意な結論を出すのは難しい
    縮小されたJavaScriptバンドルを整形してコード行数を見積もり、依存関係を除いたZigプロジェクトの行数と比較するのも、リンゴとオレンジの比較だ。Zig実行ファイルを逆コンパイルして何行になるか見てみろという話
    Codebergに対する「リクエスト数を減らすためにJavaScriptとCSSのペイロードを結合すべきだ」という勧告も理解できない。HTTPリクエストの「追加オーバーヘッド」を語っているのを見ると、著者が HTTP/2 を知っているのかも疑わしい
    Webページの性能についてはまだ言いたいことがたくさんあるが、別記事にするとして、似た話題についてより良い観点としては、Danluuの2017年のWeb肥大化の記事を読み返すのを勧める: https://danluu.com/web-bloat

  • 著者が見ているなら、Casey Muratori と Uncle Bob の論争を見てみるとよいかもしれない。前者がとても興味深い性能低下を見つけている
    「我慢できなくてChromeのパフォーマンスキャプチャを見たら、犯人がわかった :) 『emoji picker』だった！」
    「コードはざっとしか見ていないが、問題は文字を入力するたびに『emoji picker』が後ろにさかのぼって、今入力したものが絵文字かどうかを調べていることのようだ」
    うげぇ。ただしこの場合の犯人はGitHubのフロントエンドコードではなく、Chromiumベースのブラウザかもしれない

  • 「Codebergは独立した寄付に依存し、自由なボランティアが提供する製品だ」という表現は正確ではない
    Codebergは 会員 に依存している。会費だけでなく方針の面でもそうで、現状では会費だけではフルタイム職員を雇うには足りないためボランティアに大きく頼っているが、私の理解では契約者もいる
    Codebergを深く追っているわけではないが（sourcehutのほうを好んでいる）、協同組合であることが価値提案の中核のひとつだ。支出も透明に公開しようと努めている。例: https://blog.codeberg.org/codebergs-budget-of-2026.html
    Codebergを使っているなら、今すぐ会員加入を検討してみるとよい: https://join.codeberg.org/

  • GitHubは本当に嫌いだ。私の問題は稼働時間ではなく、ばかみたいに遅くてメモリを食うことだ。「このサイズのdiffはデフォルトでは表示しません」って本気か
    妥当な開発フローも壊れている。PRをリベースするとレビューのフィードバックやコメントが消え、コミットをsquashするとレビューのフィードバックやコメントも消える
    特定コメントへのリンクがあっても、そのコミットが消えればコメントも一緒に消える \o/
    バグ修正があるとPRを作れと言われ、そのバグが別の変更で直っていても、PRとバグが同じレベルに存在するので死んだPRがレビューキューに永遠に残る
    このコミットがどのバグを直したのか知りたくても、PRの履歴しか見せてくれない。バグではなくPRを見ろという感じで、バグを知りたければ自分で探しに行くしかない

    • 「pull request」 という概念自体は、git と同じく Linuxカーネル開発 から来ている。カーネルメンテナに、パッチをmainlineに「pull」してくれと頼む流れだ
      GitHubはこの流れを「fork」ボタンでより手軽にし、中央集権的なユーザー名を導入してより「ソーシャル」にしたうえで、IssueトラッカーとWikiをくっつけて世界を制した。ビジネスとしては天才的だったのは確かだ
      しかし全体の流れは、今でも離れた場所にいる人たちがパッチを「pull」してくれと頼むオープンソース開発向けのままだ
      実際のメカニズムが「ブランチについて議論し、マージを承認する」である密接な開発チームが、なぜ 「pull request」 を使わなければならないのか理解できない。何からpullするというのか？ 同じリポジトリにあって、すでに変更をpushしているのに
      用語の問題を抜きにしても、累積変更、安定したコメント、変更セットdiffが欠けているのはおかしい
      また退屈なGitHubへの不満を書いてしまってすまない。もっと良い代替はあるのだろうか？ もちろん誰かに使わせることはできないが…

  • 「軸ラベルや個々のデータポイントがないグラフはいつでも疑わしい」という反応を、GitHubが公開したグラフについて何度か見たことがある
    グラフには最大値が表示されているので、y軸の中間値はそれぞれ45M、0.7B、10Mくらいだと視覚的に推定できる。もちろん、こっそり対数スケールで、負荷が100000倍になったわけでないならだが
    ここで悪いグラフを「怪しい」とまでは呼ばず、単に コミュニケーションが下手 なのだと思う。個人的には生のggplot出力のほうがいつも好きだ
    全体的な感情には同意するが、太った馬や多くの表のあたりでは少しついていきづらかった。ただ、GitHubの欠点を全部列挙していたのなら、私も気が狂って太った馬に乗って夕焼けの中へ消えていく夢を見始めていたかもしれない
    私も似たように列挙を始めたが、UX/性能の問題が12個くらいになったところで諦めた。この記事の徹底した分析は良いし、GitHubチームがちゃんと精査してくれることを願う
    以前も言ったように、MicrosoftはGitHubに 性能エンジニア を何人か割り当てるべきだ。重要業績評価指標に性能指標が実際に入るまでは、この肥大化は続き、他のプラットフォームがより魅力的に見えるだろう。次のGitHub CEOがいるなら、これを優先してほしい

    • グラフのy軸が0から始まると仮定している。こういう ビジネス風グラフ では、そうでないことが非常に多い
      「驚異的な成長」を主張しながら、グラフの線は図全体を対角線に横切っているのに、y軸は100から101までしかない、というのはよくある話だ

  • 「GitHub Actionsのログがメモリリークして何年も私のブラウザを殺してきたし、stdoutをどこかにそのままpipeする方法もまだない」という話には同意する
    残念ながら Forgejo もこれを受け継いでしまっている。ビルド失敗通知を受けてスマホで素早く確認したいことがあるのだが、かなりの割合でスマホのブラウザが出力内容そのものを読み込めない

  • この記事を開いたとき、GitHubの稼働時間についてのまた別の不満だと完全に思っていたが、実際にはGitHub、GitLab、Codebergの現在の問題を落ち着いて理性的に評価し、解決策まで提案している記事で、うれしい驚きだった
    Tangled も比較に含まれているとよかった
    著者は、サイトがモバイルでも読めるようにCSSを少し書いてほしい。ブラウザのリーダーモードを使う必要があった
    同意できない唯一の点は、どのサイトもJavaScript/CSSファイルを1つより多く読み込むべきではないという主張だ
    あの55万行のJavaScriptが全部1ファイルだったら、解析と実行にもっと長くかかるだろう。CSSはバンドルしてもいいが、たとえば共通チャンク1つとルート別チャンク1つを持つパターンは有用かもしれない。こうしたアプローチ、あるいは似た方式は広く使われると思う

  • このページは読めたものではない
    それにGitHubが嫌いなら使わなければいい。こんなに長い不満のリストを集める時間があることに驚く。仕事で金をもらって使っているのでもなければ、別のものを使えばいい