GitHubは沈みつつある

 (dbushell.com)
2 ポイント 投稿者 GN⁺ 3 시간 전 | 2件のコメント | WhatsAppで共有
  • Microsoftによる買収以降、GitHubの**可用性（uptime）**は目に見えて悪化しており、公式ステータスページでさえ懸念される数値を示し、非公式ステータスページはさらに深刻な状況を伝えている
  • Copilotの乱発とAI生成の低品質コード（スロップ）の氾濫によって、GitHubが自らをDDoSしているような状況が起きており、ボットと偽スター経済がプラットフォームの信頼を損ねている
  • Gitはオープンソースの分散型バージョン管理システムであり、GitHubがなくても動作するため、GitHubをGitそのものと同一視する認識から脱する必要がある
  • Codeberg、Tangled、Gitea、GitLab、セルフホストのForgejoなど、さまざまな代替Git forgeが存在し、移行を今すぐ始めるべきである
  • 複数の著名な開発者がGitHub離れを宣言する記事を相次いで公開しており、GitHub依存から脱することがエコシステム全体の課題として浮上している

GitHubを離れるべき理由

Git ≠ GitHub

  • GitHubは「ソース管理」の同義語のようになっているが、GitはGitHubではないという事実を知らない利用者があまりにも多い
  • GitとGitHubは同じものではなく、Gitの中核技術はオープンソースであり分散型でもあるため、すべてのリポジトリは対等で、中央集権的なサービスがなくても動作できる
  • 中央集権型サービスは社会的な利便性の産物であり、GitHubはもともと便利な付加ツールにすぎなかったが、Microsoftはそれを高価な負債へと変えてしまった
  • ネットワーク効果は強力だが、GitHubの偽スター経済には価値がなく、ボットとslopがあふれている状態だ
  • GitHub Actionsは過度に複雑なCIパイプラインの一部である。別の解決策を探すのは面倒ではあるが、GitHubの安定性を信頼できるのかを自問すべきだ
  • 船は沈みつつあるのだから、すべてを一度に移さないとしても、移行プロセスを直ちに始めるべきである

代替手段と移行方法

  • 最も近い脱出経路は別の中央集権型Git forgeへ移ることであり、登録後にリポジトリを新しいupstreamへpushすればよい
  • 一部のサービスは移行を自動化し、Issueの取り込みもサポートできるが、GitHubのIssueをそのまま残しておくという選択も可能である
  • 以下の代替案はいずれも完璧な選択肢ではなく、共通点はGitHubではないということだけだ

  • 中央集権型Git forgeの代替

    • Codeberg — 非営利・コミュニティ主導のプロジェクトであり、実績のある安全な代替手段。Forgejoの代表的インスタンスでもある
    • Tangled — アルファ段階のスタートアップで、AT protocol統合が興味深い選択肢。小規模な個人プロジェクトで検討に値する
    • Gitea — クラウド管理型Gitホスティングを提供しており、Codeberg/Forgejoが分岐した元のオープンソースプロジェクト
    • GitLab — エンタープライズ級で重く混乱しがちだが、組織内の意思決定には向いているかもしれない選択肢
    • Bitbucket — 推奨はされないが、「GitHubではないもの」というカテゴリには入る
    • Game of Trees, Radicle, Sourcehut — 追加の代替案であり、自分で調査する必要がある

  • セルフホスティング

    • 組織や個人はGit forgeをセルフホストでき、actionsやreleasesも運用可能である
    • 推奨されるセルフホスティングの選択肢はForgejoである
      • Forgejoインスタンス間の連合に関する議論があり、Tangledも連合に関する記事を出しているが、近いうちに実現することはなさそうだ
    • 公開コラボレーションが必要なら、Codebergにコピーをpushする方法も使える
    • GiteaとGitLabもセルフホスティングの選択肢を提供しているが、GitLabは相対的にはるかに重い
    • GitHubだけでなく他のforgeもGitそのものとは別物であり、forgeの付加機能が本当に必要なのかを見直すことができる
    • GitはSSHだけでも直接利用できる 
      git clone user@192.168.1.67:/path/to/repo
  • コラボレーションの方法は別問題だが、Linuxが電子メールのメーリングリストでパッチをやり取りしながら保守できているのなら、規模の問題だけで不可能だと断じるのは難しい
  • 中央集権型Git forgeは現実的な妥協案かもしれないが、GitHubのように崩れる可能性を念頭に、常に脱出計画を持っておくべきである

関連記事

2件のコメント

 
kimjoin2 1 시간 전

提供されている機能を考えると、99%以上も出してくれているのが驚くほどです
 
GN⁺ 3 시간 전
Hacker Newsの意見

  • みんなこれを Microsoftによる買収 や無能さのせいにしたがるけれど、GitHubが公開した資料を見ると、AIのせいでGitHubにコミットされるコード量が10倍に増え、その余波がCI、Actions、コード収集など全般に広がったのはかなり明らかに見える
    投稿者はMS Copilotのような妙な要素を原因として挙げているが、因果関係というより嫌いなものを並べ立てている感じだ
    肝心の、部屋の中の象である AI発のコード爆増 は無視している

    • 本文のグラフを見ると、ダウンタイムのパターンは 2020年1月 から始まっている
      OpenAIがGPT-3.5を出したのは2022年11月、実質的には12月で、説明されているような大規模言語モデル/エージェントによるコーディングが本格化したのは2024年になってからで、実際には2025年により近い
      だとすると、AIの話が始まる前、買収後およそ4年間の悪い可用性はどう説明できるのか?
    • その記事を読んで私もまったく同じ反応だった
      Microsoft批判に乗るのはいいが、部屋の中の象を見落としてはいけない
      明日完璧なGitHub代替が現れたとしても、何がその場所のインフラを数百万行の AI生成コード によって壊されるのを防げるのか?
      集中型コードホスティングはAIのせいでほぼ死ぬことになる気がする。ソーシャルメディアで起きていることと似ている
    • GitHubは買収後、良い方向に変わったことがない
      10年は長い時間で、その結果が表れている
      GitHub Actions、Copilot、そしてオフにもできない醜いAI検索。Azureへの移行まで
      Microsoftは ネットワーク効果 を壊すことに成功し、障害はラクダの背を折った最後の藁だ
    • たとえそれが事実だとしても、Microsoftは クラウドプラットフォーム全体 を持つ会社だ
      自前で巨大なコードベースを抱え、従業員も約20万人いる
      とりわけプライベートリポジトリ無料化のような判断を意識的に下してきたのだから、これは言い訳にはなりにくい
    • MicrosoftがGitHubをAzureクラウド上のWindowsで動かしているのではと想像することがある
      GitHubが落ちるたびに、「誰かがGHが動いているWindows Serverを更新して全部再起動しなければならなかったんだろう」と思う
      99%事実ではないと確信しているが、そう考えると気が楽になるし、障害のたびに少し笑える

  • 今日GitHubでリポジトリを見ようとした
    「xxx commits」リンクを押してコミット履歴を見ようとしたら、secondary rate limit に引っかかったので待てというメッセージが出た
    このネットワークでGitHubを見るのは私だけだし、接続もCGNではなく専用IPだ

    • サイトをまともにたどる唯一の方法は ログインした状態 で見ることだ
    • 私もまったく同じで、かなり頻繁に起きる
    • Slackにある正常なリンクを押したのに、自分には404が出て他の人には普通に開けることがよくある
    • デスクトップなら Ctrl + Shift + R でページキャッシュをリフレッシュすればよい
      そうするとページは正常に読み込まれる
    • これは典型的なテックブロ式のガスライティングだ
      実際には何年も前からrate limitではなく、ほとんどデフォルト拒否に近いのに、文言を現実に合わせて変えるのを拒んでいる

  • 「GitLab - エンタープライズ級というのは、肥大化していて分かりにくいが上司には印象的に見えるという意味だ。選ぶのに会議が何度も必要ならこれを選べばいい。」
    笑った

    • 会社でGitLabを使っているが、正直がっかりしている
      いちばん単純なことをやるにもUIが複雑すぎる。たとえばMRを承認するには、実質メニューになっているボタンを押さなければならないし、diffは読みづらく、「To-do list」にはすでにマージ済みのMRまで入っている。どうしてそれが実行可能なやることリストになるのか?
      すでにマージ済みのMRが「To-do list」に残る問題は何年も前に報告されているのに、改善は速くなさそうだ
      一方でBitbucketに対する反発は少し意外だ。UIはとても単純で明快だし、新しく参加した人たちもそう感じている。Script Runnerを使えばかなり驚くようなこともできるし、巨大なリポジトリもうまく扱える
    • 面白いけれど事実ではない
      GitLabがGitHubより特別に肥大化していたり分かりにくかったりするわけではない
      本当の エンタープライズ級ソフトウェア と見るのも難しい。そういうものが欲しければJiraか、Microsoftが作る何かを見ればよい
    • くすっとした
      私たちはセルフホストのGitLabを使っていて、gitと コンテナレジストリ があるので私が選んだ
      Web UIをあまり使わないなら、インターフェースが確かに分かりにくく感じられるかもしれない

  • 月5ドルあればサーバー1台をホスティングして複数のプロジェクトを載せられる
    リポジトリに星が100万個付くわけではないが、自分の用途には十分動くし、必要な人にアクセス権も与えられる

  • このグラフをどう見ればいいのかよく分からない
    一方ではGitHub買収のせいで 可用性 が悪化したのかもしれない
    他方では、買収前の可用性が100.00%と出ているのが怪しくて、単にステータスページがよりきちんと更新されるようになっただけではないかとも思う
    最近GitHubに可用性の問題があるのは分かるが、グラフ上の問題は2020年に始まっていて、大きく悪化しているようには見えない

  • 主要なオープンソースリポジトリは結局、放っておくことが不可能なように感じる
    SourceForgeが壊れていったのを覚えているので、GitHubでも同じことが起きているのを見るのは本当に悲しい
    ちなみにURLを「dBus hell」と読んでしまった。みんな一度は経験あるだろう

    • いや、dBu単位ベースのnushellだから dBu Shell だ

  • 会社を経営していたらどうするか、よく考える
    すべてのコードレビューを メール でやるのを本当に見てみたい
    リポジトリはgit専用のSSHアクセスだけできるシンプルなVPS風サーバーでよく、レビュー対象コード用に for-review/ ブランチ名前空間を用意し、CIはブランチの出現を待つボットにして、refに注釈やタグを付けて通過可否を示せばよい。結果をメールスレッドに返信することもできる
    メーリングリストには当然Webアーカイブビューアを付ければ過去のレビューも見られる。こういう解決策はすでにたくさんあり、ただのHTMLだ
    チャットはIRCにしてボットがチャンネルを保存すればいい。ものすごく簡単だ
    システム全体は、より強いハードウェアが必要なCI実行機を除けば、とても安いサーバーで動かせる
    GitHubはソフトウェアプロジェクト運営に必要なものより、はるかに過剰に設計されている。Linuxカーネルを見ると単純なメーリングリストを使っていて、史上もっとも成功したソフトウェアプロジェクトだと言っても大きな異論はない
    ただしイシュー/バグ追跡はもう少し怖い。自分で解決策を作ろうとして深みにはまり、会社の本業よりそちらにのめり込んでしまいそうだからだ。もしかするとバグ追跡ソフトウェア会社になればいいのかもしれない

    • 理想的には、コードレビューも バージョン管理 され、簡単にアクセスできる記録があるとよい
      つまりコメントが正確にどの行に付いていたのか、その行がいつ変わったのかを見て、前後に行き来したい
      メールはこのデータをやり取りするプロトコルとしては十分かもしれないが、メールクライアントはそれを見やすく表示する方法ではないと思う
      もしかすると分散型コードレビューシステムも必要かもしれない

  • 東欧に住んでいるのにも利点がある
    タイムゾーンのおかげで大きなGitHub障害にほとんど気づかない
    無料ホスティングとActionsをかなり気前よく提供している点にも満足している

  • ホームサーバーに Forgejo を入れてからは振り返っていない
    唯一の問題はDigitalOcean App PlatformやVercelなどにアプリをホスティングするときで、これらはGitHubにしか接続できない

    • DigitalOcean App Platform はGitHubだけでなくGitLabでもデプロイをサポートしている
      ただしセルフホストのGitLabインスタンスではなく、gitlab.comでホストされているインスタンスを使わなければならない
      すでにセルフホストのforgeをデプロイしているなら、gitlab.comを橋渡しとして使ってDigitalOcean App Platformに接続できる。gitlab.comのアカウントを一度作り、セルフホストのforgeがgitlab.comへ複製を送るようにすればよい。実際にはGitLabを使う必要はあまりない
      それでもDigitalOceanがIaaS/PaaSを売る会社なのに、自社インフラ上で動くセルフホストのForgejoのようなものに接続させてくれないのは意味が分からない
      実際にはセルフホストforgeをホストしたい人は多いが、自分で設定して運用したい人は少ないことを考えると、DigitalOceanがForgejoや代替を持ち込んで、年20ドルのような大幅割引価格の準マネージドなワンクリックデプロイオプションを提供し、App Platform連携を第一級でサポートしないのも不思議だ
    • GitHubを避けるべき理由はすべて、DigitalOcean App Platform とVercelを避けるべき理由でもある
      DigitalOceanは使っているが、VPSしか使わない
      こういう中間レイヤーにベンダーロックインされず、統制を保ちながら、できるだけ汎用的なスタックレイヤーを目指すべきだ
    • 似たような立場だ
      Forgejoフォーク以前の数年前からGiteaに乗り換えていて、後悔はない
      GitHubが必要な場合は、リポジトリをそこにミラーリングして動かせていた。ただしコードを同期するのは面倒だ
    • Appleの Xcode Cloud も似た状況だ

  • GitHubが苦しんでいるのは、AIで強化されたコーディングのせいで、この1年でコミット数が 14倍 に増え、その速度がいまだに加速中だからだ
    サイトは追いつくのに苦労している
    GitHub COOがここで確認している: https://x.com/kdaigle/status/2040164759836778878
    プラットフォーム活動が急増中だ。2025年にはコミットが10億件あったが、今では週2億7,500万件なので、成長が線形に維持されるだけでも今年は140億件ペースだ。もちろん線形では終わらないだろう
    GitHub Actionsは2023年の週5億分から、2025年には週10億分に増え、今週は現時点ですでに21億分だ
    そのため、より多くのCPU、サービス拡張、GitHub中核機能の強化にものすごい勢いで取り組んでいる