GhosttyがGitHubを離れます

(mitchellh.com)

5 ポイント投稿者 GN⁺ 1 일 전 | 3件のコメント | WhatsAppで共有

繰り返されるGitHub障害が、PRレビューや日常作業を実際に妨げるレベルに達し、分散型Gitリポジトリだけでは解決できないissues・PR・Actionsへの依存が明らかになった
この1か月、ほぼ毎日GitHubの問題が作業に影響し、執筆当日もGitHub Actions障害により約2時間PRレビューが止まった
移行先はまだ決まっておらず、商用サービスやFOSSプロバイダーを複数検討しながら、GitHub依存を段階的に減らしていく計画
現在のURLには読み取り専用ミラーを残し、今回の変更はまずGhosttyのみに適用され、他の個人プロジェクトは当面GitHubに残す
今回の決定は2026年4月27日の大規模障害に合わせて急いで出したものではなく、数か月前から議論されており、復帰は約束ではなく実質的な改善が確認できた場合にのみ可能

移動の背景

GhosttyはGitHubを離れることを決め、最近繰り返される障害が実際の作業を妨げるレベルに達したと見ている
この1か月、GitHub障害が作業に影響した日を別途記録しており、ほぼ毎日問題が続いていたと明かしている
執筆当日もGitHub Actions障害のため、約2時間PRレビューを進められなかった
issues、PRs、Actionsのような周辺インフラが問題の中心であり、単にGitが分散型であるというだけでは解決できないと断言している
1日に何時間も作業が止まる状態が続き、もはや本格的な作業空間とは見なしにくいと判断した

計画と範囲

Ghosttyの移行先はまだ確定しておらず、商用サービスやFOSSプロバイダー複数社と協議を続けている
GitHub依存を一度に断つのではなく、段階的に削減していく計画
現在のURLには読み取り専用ミラーをGitHub上に残す予定
今回の変更はまずGhosttyのみに適用され、個人プロジェクトや他の作業は当面GitHubに残す
Ghosttyは自身とメンテナー、オープンソースコミュニティに最も大きな影響を与えるプロジェクトであるため、今回の変更の焦点もここに置かれる

追加の文脈

2026年4月27日の大規模障害と時期は重なったものの、GitHub離脱計画は数か月前から議論しており、最終決定だけが今週下された
本文は大規模なElasticsearch障害の前に書かれており、記事中で言及された当日の障害はそれとは別個の障害だった
GitHubが実際に改善されれば、いつか戻る可能性はあるが、復帰条件は言葉や約束ではなく、実質的な結果と改善でなければならない

3件のコメント

carnoxen 22 시간 전

すでに別の場所（Codeberg など）へ移った人たちは、今回の事態を見て、移っておいて本当によかったという思いをいっそう強くするのではないでしょうか。

xguru 1 일 전

Mitchell Hashimoto が HN のコメントでも本当に涙が出たと書いていたので見てみたら、
https://x.com/mitchellh/status/2049213597419774026
GitHub ユーザー1299番で、2008年2月に登録したそうです。

最近は GitHub の問題が多いようですね。数時間前にも GitHubで現在障害発生中が上がっていました。

GN⁺ 1 일 전

Hacker Newsの意見

mitchellh: この記事を書きながら本当に泣いたし、誇張でもない
GitHubは単なるSaaSではなく、自分にとってはずっと大きな意味を持っていたので、その関係は少し不健全なくらい深くなっていた
数か月にわたって断続的に話し合い、ここ数週間で真剣に議論し、数日前に最終決定したが、自分で文章を公開してみて初めてあまりにも現実味を帯びてきた
馬鹿にする人もいるかもしれないが、自分はGitHubを本当に大切に思っているし、また本来の道を取り戻してほしい
- 感情を抱くのは構わないし、自分も似たように感じる
  私はGitHub User 22723で、今のアカウント数が約1億8000万件くらいあることを考えると、ほとんど同じ時期から一緒にいたようなものだ
  自分なりに言えば、大切に思っている人たちが残ってより良くしていかなければ、GitHubは良くなれない
  Herokuを6年ほど前に離れたときは、ほぼ10年近く満足して使っていたのにダッシュボードを二度と開かず、結局Salesforceが本当に壊してしまったと感じた
  でもGitHubはそう簡単には離れられない
  agentic codingや爆発的成長を同時に経験して混乱した面はあるが、これはHeroku/Salesforce的な破局とは違って見える
  AIコーディングの増加や邪悪なMicrosoftだけで説明するより、規模と開発者の足元の地形そのものが変わったと見るほうがもっともらしい
  また戻りたくなるほど上手くやってくれることを願っているし、開発者の生活の中心にあるものに強い感情を抱くのはまったく馬鹿げたことではない
- もどかしさがそのまま伝わってくるし、それを表現することが大げさだとも思わない
  仕事をしようとしているのに邪魔されている感じ、ソフトウェアをデプロイしたいのにサービス側がそれを望んでいないように感じるところが特に響く
  こういう感情はGitHubだけの話ではなく、最近のWeb全体がより雑で低品質になっているように思える
  常時障害、バグ、UIの細かなトゲ、未完成機能が多すぎて、いったい何が起きているのか分からない
- 感情を抱くことを笑う人なら、最初から耳を傾ける必要もない
  人のためのergonomic softwareを作ってくれてありがとう
- Spool of Wire Guyミームがまさにこの感情を説明してくれる
  他人の目には取るに足らなく見えても、当人にとっては長年積み重なった愛着と思い出が詰まった物だという比喩だ
  https://knowyourmeme.com/memes/spool-of-wire-guy
- これはまったく誇張ではない
  人生には好きなものや愛するものがあり、自分が応援していた陣営が悪くなれば悲しむのは当然だ
  私もこういう理由で笑ったりはしないし、そういうものを笑う人には腹が立つ
  ただ、GitHubが立ち直るという点については正直楽観できない
GitHubが組織として崩れていく様子を見守るのはかなり驚きだった
Microsoftへの編入、Copilotへのリソース移動、組織構造、vibe codingなどいろいろな説明が出ているが、理由が何であれ深刻な問題があることは否定しにくい
非公式ステータスページが示す記録もかなりひどい
内部の視点は聞いてみたいが、今は惰性で持ちこたえている沈みゆく船のように見えるし、ソフトウェア業界全体が揺れている時期に惰性だけで持ちこたえるのは難しそうだ
1. https://mrshu.github.io/github-statuses/
- わざわざ内部者の視点がなくても、だいたい何が起きているかは見える
  大企業に買収されたサービスがよくたどる形で運営されている
  最初はまともでも徐々に悪化し、やがて崩壊し、すべてが数字のゲームになる
  Microsoft、Oracle、VMware、CA、Salesforceまで似た例は多く、M&Aをうまく扱えるチームはごくまれだ
- 現在の数値である87.25% uptimeだと、部分障害を1日3時間ほど経験している計算になる
  https://onlineornot.com/uptime-calculator/87.25
- 数年前から、GitHubがSourceForgeのようになるまでどれくらいかかるのか気になっていた
  まともなリーダーなしに大きくなりすぎると、結局は崩れると思う
- さらに悪いのは、非公式ステータスページにも出てこない障害が頻繁にあることだ
  実際の数値は体感的にはもっと悪い
- これを全部Microsoftのせいにするのは記憶の美化に近いと思う
  GitHubは買収前から、その日その日でサイトがちゃんと動くかどうかがコイントスのような時期があった
  ちょうど良い場所に良いタイミングでいたから成功したのであって、本質的にはあちこち継ぎはぎした雑なシステムだった
HashimotoがGitHubとオープンソースの世界に抱いている誠実な愛情は理解できる
ただ、非自由ソフトウェアは本質的に疑わしく非倫理的だというRichard Stallman的な態度がもう少しあれば、こうした傷は減っていただろうと思う
GitHubは2008年も今も、他人のサーバー上で他人のルールに従って動き、結局は所有者の利益のために運営される非自由ソフトウェアだった
私も長く使ってきたし、仕事の都合で使わざるを得ないことも多かったが、感情的な愛着は持たなかった
free-softwareであるgitの上に築かれていながら、構造的にユーザーをプラットフォームに縛りつけようとする点は常に気に障っていた
メールアカウントと利用規約への同意が必要で、米国の制裁法のせいでイランでは動作すらしないソフトウェアを愛することはできなかった
だからghosttyがGitHubを離れることは、ためらいなく歓迎できる
- その通り
  KDEではGitHubを真剣に検討したことはほとんどなく、自前のgit infraを運用していて、後にGnomeと一緒にGitLabと協力し、Enterprise Edition機能のうち本当に必要なものをCommunity editionに移すようにした
  この16年間で、数時間に及ぶgit障害は正確に1回だけだった気がする
- 結局はすべてvalue propositionの問題だと思う
  自分の時間とお金を投じる価値があるかどうかだけを見ればいい
  Netflixの値上げやゲームの話のように感情的な消耗が大きくなることはあるが、価値がなければただ離れればいい
  もちろん、初期のコンピューティング時代の思い出のような感情的なつながりが生まれることは理解できる
- しばらくこうした技術を注視していた
  イシュートラッカーのようなものをgit repoの中に組み込む方向が、ますます理にかなっていると感じる
- 同意する
  こうした苦しみはclosed source softwareの問題を最後まで見通せなかったことから生じていると思う
  Hashicorpを売ってからは、敬意がかなり薄れた
以前、MitchellがXでGitHubを批判していたスレッドで、GitHubは彼をCEOとして迎えるべきだという返信を見たが、かなり一理あると感じた
こういう船を立て直すリーダーは単なる管理者ではなく、強い確信と実行力、人材を引き寄せる力を併せ持つ人でなければならない
結局、新しいGitHubが現れると思うし、OpenClawや昔のGitHubがSVN・SourceForge時代にそうだったように、うまく噛み合えば急速に成長できる
すでにその座を狙う試みも多いように見える
- 問題は、GitHubがやっていることが多すぎる点にある
  それでも中核サービスという観点で見ると、特に複雑なプロジェクトでは良いUIがまだないと感じる
  一方でjujutsuは基本的な方向性はかなり良さそうだが、依然としてまともなforgeがない
- 今こそfossilを見直す時なのかもしれない
  コード、Wiki、Issueが事実上一つのツールとして分散管理されている
- ユーザーがGitHubに期待していることと、所有者であるMicrosoftがGitHubに期待していることが食い違っている
  ビッグテック経営陣が望むような形でAIがソフトウェア開発を代替するなら再び一致するのかもしれないが、今人々が欲しいのは安定したgit remoteであって、現実には不安定なホストと中途半端なvibe coding機能が混ざって出てきている
- GitLabは正直かなり良いし、全体として過小評価されている
- 私は今でも分散・連合型git forgeを期待している
  皆がGitHubに集まる最大の理由は、self-hosted forgeごとにサインアップを許可していなくてもIssueやPRで簡単に協業できることだが、それはすべてのコードを一つの崩れかけたインフラに押し込まなくても解決できる
  現実化は難しいだろうが、実現したら本当に素晴らしい
開発者エコシステムが5年後どう変わるのか、GitHubが5年後にどんな姿になっているのか、かなり気になる
私はGitHubのWebはほとんど開かず、github cliをよく使う
ghだけでも大抵必要なことは足りるし、ActionsはGitHub上で動き、エージェントが結果を取ってきてIssueを見てコードを直すという形で、ワークフロー全体がすでに変わりつつある
GitHubがもはや楽しい場所ではなく、仕事もデプロイもできないように妨げてくるという感覚に共感する人が多いなら、Redmondは強く対応すべきだ
この感情が実際に大きく広がれば、Microsoftにとって致命傷になり得る
8年前にほぼ80億ドルを投じて開発者を中核に据え、Minecraftにも20億ドルを払って若い開発者層までつなぎ止めようとした
すでにOSとサーバー領域を失っているのに、開発者まで失えば21世紀のXeroxのような道をたどるかもしれない
- これはかなりHNっぽい誇張だと思う
  MicrosoftはゲームもモバイルもAIもそれほど圧倒的ではないか、負ける可能性が高そうに見えるが、WordとExcelさえあればいい膨大な数の一般ホワイトカラー労働者を今でも抱え込んでいる
  テックには関心がなくてもOfficeには縛られている人があまりに多い
  Claudeが初期にちゃんと身につけた実用スキルの一つが.docx作成だったという事実も、それを示している
問題はGitそのものではなく、その上に載っているIssue・PR・Actionsのようなインフラだ
提案としては、別のforgeに移るとしてもgit-bugを一緒に使うとよい
IssueやPRなどをブランチではなく特別なrefに入れてgit自体に保存し、複数のプロバイダーとの双方向同期もサポートしている
fossilのような他のVCSもIssueをrepoと一緒に保存するが、Issueは文書のようにコードに意味を与える一部なので、そのほうが自然だと思う
- 数日前、同僚がOpenAI Symphonyに触発されたローカルKanbanボードとともにagentic workflowへ完全に傾いていくのを見て、fossilを思い出した
  すべてがrepoの中に入っていれば便利ではある
  ただ、今やそのすべてをほとんど制約のないLLM coding agentも一緒に扱うようになるので、アクセス範囲をロックするのはさらに難しくなる
- git-bugは素晴らしいが、PRを扱えず、コミット権限のないユーザーがバグを送る方法もまだない
  後者についてはWeb UIのような方向で進めていると理解しているが、それまでは一般ユーザーがIssueを上げられるようにするには、結局公開インフラが必要だ
  自分のプロジェクトではhttps://github.com/stryan/materiaで使っていて、リポジトリとIssueの中央集約には向いている
  ただしランダムなユーザー入力については、いまだにGitHub Discussionsを擬似バグトラッカーのように使っている
  バグならgit-bugに追加し、GitHub issuesと同期して公開で見えるようにしているが、大規模なユーザーのバグ報告にはこの方式はあまり合わない
  このワークフローの発想は皮肉にもghosttyとmiseから得たもので、どちらもまずdiscussionでバグを受け付け、実行可能なものだけタグ付きIssueを作っている
- Mitchellがいら立ちの末に、Linusのように週末のうちに分散Issue・PR・Actionsインフラを自分で書いてしまうのではないかと想像してしまう
- これは初めて知ったが、そのspecial refの仕組みは本当にかっこよく見える
  良い情報だった
GitHubの品質が大きく落ちた最大の原因が何なのか気になる
AI生成コードがコードベースの品質を落としたという説明もあるし、Microsoft買収後に悪いエンジニアリング文化が広がったという説明もある
両方がある程度混ざっているのかもしれない
- 自分が聞いた説明ではAzure migrationが最ももっともらしかった
  https://news.ycombinator.com/item?id=45517173
- 第三の要因としては記録的な利用増加も入れるべきだ
  https://github.blog/news-insights/company-news/an-update-on-github-availability/
- agentic codingが本格化する前から、すでに下降線だった
  Microsoftの文化とインフラが混ざった結果のように見えるし、今では他のMicrosoftサービスと似た品質に感じる
  付け加えると、dotnet CLIバイナリはホスティングが不安定すぎてCIがよく壊れるので、自分で再ホストしなければならない
- 悪くなり始めたのはMS買収後で、かなり悪くなったのはMSがAIを強く押し始めてからだった
- 結局のところ、私はuptimeとUX/UIが核心だと思う
  Pull Requestページで結果が不完全に表示されたり、Elasticsearchインデックスを再構築している間はデータ自体は消えていないのに、再インデックスが終わるまで一覧がまともに出ないといった事故がそのまま起きている
今後数か月以内にGhosttyプロジェクトの移転先をもっと詳しく共有すると言っていたが、それだとGitHub IssuesやPRが1日のうち時々アクセス不能になる問題への対応として、数か月にわたってさらにアクセス不能な状態を作ることになるようにも見える
少し感情的に急いで下した決断のようでもあり、本人にもGhosttyにもコミュニティにも、必ずしも利益になるとは思えない
少なくともバックアップ経路は用意してから動いてほしい