- 速度と成熟したソフトウェアの領域に新たな要素を加えた terminal emulator が、GitHubから別の協業コードリポジトリへ移行中
- Mitchell Hashimotoは2008年2月にGitHubユーザー1299番として登録して以来、ほぼ毎日使ってきており、かつてはGitHubを 最も幸せな気持ちにしてくれる場所 だと考えていた
- この1か月ほど、サービス信頼性の低下 が作業に影響した日がほぼ毎日記録されており、執筆当日もGitHub Actionsの障害で約2時間PRレビューができなかった
- GitHubはもはや楽しい場所ではなく、18年使った末に離れることを決めたが、real results and improvements があれば戻る可能性は開かれている
- Ghosttyの移行は複数のcommercial・FOSS providerと協議しながら incremental に進められており、GitHubにはread-only mirrorを残す形で進行する
GhosttyとGitHub利用の背景
- 現在の主力プロジェクトは Ghostty で、速度と成熟したソフトウェアの領域に「interesting new wrinkles」を加えた terminal emulator プロジェクトだ
- Ghosttyの開発にはGitHubを使ってきており、Mitchell Hashimotoは2008年2月にGitHubユーザー1299番として登録して以来、ほぼ毎日利用してきた
- GitHubは「最も幸せな気持ちにしてくれる場所」であり、新婚旅行中でも時間を作ったほど長く愛着を持ってきたサービスだった
- ソーシャルメディアをdoom scrollingする代わりに、ずっと以前からGitHub issuesを見ており、休暇中でもGitHubプロジェクトのソースコードやOSSプロセス、maintainerの対応を学んでいた
毎日の作業を阻む障害
- 最近ではGitHubに対する感情は大きく変わり、GitHubが毎日のように自分を失敗させ、その問題を個人的に感じる状態になった
- 主な原因は サービス信頼性の低下 で、この1か月の間、GitHub障害が作業能力に悪影響を与えた日ごとに日誌へ「X」を付けていた
- その日誌にはほぼ毎日「X」があり、執筆当日でさえ GitHub Actions outage のため約2時間PRレビューができなかった
- この記事は、pull requestがElasticsearchのSNAFUのため完了できなかった4月28日の incident の数日前に書かれた
- こうした障害が毎日何時間も作業を止めるのであれば、GitHubはもはや「serious work」のための場所ではない
開発フローと感情的な断絶
- GitHubはもはや楽しい場所ではなく、「I want to ship software and it doesn't want me to ship software」という言葉の通り、ソフトウェアの出荷を妨げる存在になった
- GitHubの改善は望んでいるが、同時にコードを書かなければならず、GitHubではもはやコーディングを続けられない状態だ
- 18年使った末に離れなければならないという結論に達しており、real results and improvements があれば戻る可能性は開かれている
- 単なる言葉や約束ではなく、実際の結果と改善こそがGitHub復帰の条件だ
Ghosttyの移行方法
- Ghosttyは別の collaborative code locker への移行作業を進めている
- 複数のproviderと協議中で、対象にはcommercial providerとFOSS providerの両方が含まれる
- GitHub依存を完全に取り除くには時間がかかり、可能な限り incremental に進める計画だ
- GitHubにはGhosttyのread-only mirrorを残し、個人プロジェクトもMicrosoft所有のサービスに引き続き置く予定だ
- Ghosttyは本人、maintainer、open source communityが最も大きな影響を受けるプロジェクトであり、今回の変更の焦点となっている
GitHubの立ち位置とMicrosoftの文脈
- MicrosoftがGitHubを買収した後、WindowsやAzureのエコシステムに縛られていない開発者にとって、より使いにくいRedmond中心のサービスになるのではないかという懸念があった
- その懸念はおおむね現実にはならず、GitHubはコードを扱い共有する de facto place として定着した
- Hashimotoの経験は、その地位が揺らぎ得ることを示しており、Microsoftが Windows has serious quality problems を認めた時期とも重なっている
- Windowsの品質問題の一因として、あまりにも多くのツールにAIを無理やり注入したことが挙げられており、Hashimotoが見たGitHubの不安定化の増加も、MicrosoftのAI偏重と同じ時期に現れている
1件のコメント
Hacker Newsの反応
会社がCircleCIからGitHub Actionsへすべてを移行しようとしていたまさにそのタイミングでGitHubの安定性が崩れて、本当に腹が立つ
しかも Azure Repos/Pipelines のほうがこれより良かったというのがいちばんひどい
GitHubはまだAzureインフラへの移行中で中途半端な状態なのかもしれない、という話も聞いたが、信頼は湧かない
言い訳かもしれないが、かなりもっともらしくは聞こえる
Forgejoみたいなものを使いたい気持ちもあるが、開発者は12人ほどで、正直自分一人しか使ったことがない
本当に基本的なので壊れる部分があまりなく、同じ理由でチケットシステムもとても気に入っている
必要な機能だけがあり、管理職がフィールドを100万個追加してレポーティングやburndown chartみたいなもので苦しめることもできない
https://news.ycombinator.com/item?id=47616242
https://isolveproblems.substack.com/p/how-microsoft-vaporize...
GitLabも別に良くはない
リリースの深刻なバグは無視しながら、現実的な改善がゼロの愚かなUI修正には予算が無限にあるように見える
8〜9年前に初めてGitLabを使い始めたときは本当に良くて、数年後に会社がGitHubへ移ったときは大きな後退のように感じた
GitLabには小さなUX上の便利機能がたくさんあり、粗い部分はあったものの、全体としてよく設計されているように見えた
ところがその後、状況はずっと悪化し、UXは数え切れないほど変わり、そのたびに悪くなっているように思える
粗い部分は直らず、新しい粗い部分ばかり増えていく
ここ数年で有用な機能が追加または改善された例は思い浮かびにくく、GitHubもひどいのだからGitLabが明確により良い代替になって市場を取ってほしかっただけに本当に残念だ
数日間原因が分からず右往左往し、次のアップデートでようやく問題を警告されて、repair commandを実行して整え直した
ユーザーは約10人、リポジトリは多くても50個程度のとても小さなサーバーだった
GitHub、Bitbucket、Codebergなどは問題なかったのに、GitLabは本当にバグが多く、FirefoxではSSHキーの更新が不可能で、GitLab-Firefox互換性バグだという明確な表示もなかった
新しいSSHキーのアップロードをChromeで試してみようと思いつくまでほぼ1時間かかり、その後はGitLabを二度と触りたくないと思った
GhosttyがGitHubを離れた最新のプロジェクトになったので、次は誰が去るのか気になってくる
みんなが来週水曜までにGitHubを離れて自前のForgejoサーバーを立てるとは思わないが、人々がようやくGitHub離れを検討し始めたという点はGitHubにとって心配すべきことだと思う
平均的なソフトウェアエンジニアはVCSやforgeにまったく興味がなく、その両方に関する知識もとても浅い
ただ仕事をして自分の生活に戻りたい人たちにとっては、そこまで重要ではない
自分だけだろうか、それともMSFTによる買収以降、問題がずっと悪化したのだろうか？
その間にどれだけ大きくなったのだろう？ 10倍？ 100倍？ それ以上？
ある会社が何かを買ったら、その次の問題は誰がそれを所有するのかだ
新しい会社の中で誰が「良い状態を保ち続けること」の責任を持つのかが核心で、買収後にそれまでその仕事をしていた人たちが残っていたとしても、動機の問題は別だ
Microsoftには深刻な問題がある
少なくとも10社を接着剤で貼り合わせてMicrosoftと呼んでいるような継ぎ目が見え、Xbox部門の障害がツール部門に悪影響を与えたり、その逆になったりする評判リスクも大きい
多くの項目で焦点が足りず、プレスリリースをやめたあと、このエベレスト級の技術的負債を片付ける「service pack 2」の瞬間が必要だった
Embrace, extend, and extinguish
「GitHub user 1299、2008年2月登録」と言っているが、自分が**GitHub user #**の何番なのかはどうやって分かるのだろう？
curl [https://api.github.com/users/YOUR_USER_HERE](<https://api.github.com/users/YOUR_USER_HERE>;)を実行して、payloadの中のidを見ればいい"id": 2851またはアバターのHTMLソースを見ればいい: https://avatars.githubusercontent.com/u/2851?v=4
正直、数百万番台だと思っていた
/u/#の形になっている自分は約400万番台だ
この20年近くにわたって収集されたユーザー活動統計で見れば、継続的かつ長期的な作業量と、実際に他人が使うソフトウェアを毎日書いているという点で、自分は上位1%ユーザーかそれに近いと確信している
自分もかなり早い時期からのGitHubユーザーだが、ごく初期というほどではなく、GitHubの指標が悪化していても依然としてデプロイしている
ソフトウェアを書くのにGitHubは必要ないからだ
Hashimotoのコメントは不安定に見えるし、彼が落ち着きを取り戻すことを願うが、もしそれが彼ではなかったなら、このコメントを読んで何か問題があると思っただろうし、だから実際そうなのだと思う
そうでないなら、障害に不満を言う人を裁くのはかなりお門違いで不快に感じる
そういうのは主にRedditで見るやり方だ
「自分のマシンでコーディングするのを妨げるわけではない」というふうに本質を外す人が出てくるのはあまりにも予想どおりなので、元のブログ記事でもすでにその点に先回りして触れていた
誰かのメンタルヘルスについてああいう気持ち悪い人格攻撃をするべきではない
しかし文章を読んでみると、彼の感情的な反応が状況と釣り合っていないように見えるのも確かだ
それでもプロジェクトの規模によっては、イシュー対応やレビュー処理などでGitHubがフルタイムの仕事になることもあり、PRの説明やコメントをコミットメッセージの代わりに文書の一部として使うのも珍しくない
だからGitHubの可用性は多くの会社にとって本当に大きな障害になりうる
今この瞬間もGitHub APIの問題が進行中だ
核心の質問は、最良の代替が何かということだ
無料版でも大きな不満はない
公開コードは全部そこにミラーしても構わない
テストを回す場所が必要なら、自前のインフラを作ればいい
これまでになく簡単なのに、なぜそんなブラックボックスに依存するのか？
GitLabよりずっと速い