Original article:https://httpie.io/blog/stardust
HTTPieは概ねcurlっぽい、そしてcurlよりもユーザフレンドリーで使いやすいコマンドラインのHTTPクライアントです。
以下は本リポジトリを襲った悲劇について、HTTPieのCEOであるJakub Roztocil( Twitter / GitHub / Webサイト )によって書かれた記事、How we lost 54k GitHub starsの日本語訳です。
How we lost 54k GitHub stars
HTTPie for Terminalは、最初のコミットから10周年を迎えました。
これが何かを簡単に説明すると、オープンソースのCLI HTTPクライアントです。
HTTPieの特徴は、ターミナルへの出力を限りなくユーザフレンドリーにするために一から構築されているところです。
2012年2月25日に雨のコペンハーゲンから実行した最初のパブリックリリース以来、我々はこのプロジェクトをずっとGitHub上でホストしてきました。
数年前にメンバーになって以来、私はGitHubのファンです。
(OctocatのプリントされたTシャツを着て出歩くタイプです)
アバウトページにファンディングで0.00ドルの資金調達したことを誇らしげに掲げたり、サンフランシスコのオフィスにはおいしいクラフトビールが幾つもあることを紹介していたような時代のことです。
私自身が必要としていたAPIのテスト用ライブラリが、より広い開発者コミュニティの興味を引くかもしれないと思っていたので、GitHubを選択したのは自然の成り行きでした。
そして実際、それは大きく注目を集めました。
HTTPieがHacker Newsで初めてトップの話題になり、GitHubコミュニティが形成されていくところを見たときの興奮を覚えています。
何年もプロジェクトを改善し続けた結果、HTTPieは広く採用されるようになり、最も人気のあるAPIツールのひとつになりました。
GitHubコミュニティは、54000のスター、1000人以上のウォッチャーを集めるほどにまで成長しました。
GitHubには289000000のパブリックリポジトリがありますが、HTTPieはその中でも80位、すなわち上位99.99997203%に入る人気のリポジトリでした。
この地味なコマンドラインツールが、これほどまでに多くの人々を引き付けているなんて信じられない思いがあります。
そして、この成長にはGitHubが重要な役割を果たしたことは間違いありません。
我々がGitHubのソーシャルコーディング機能による恩恵を受けたのと同じように、GitHubも我々のプラットフォームをホストすることによる恩恵を受けたことでしょう。
この10年間で、おそらく何百万人もの開発者が我々のGitHubページを訪れました。
そのおかげで、GitHub(マイクロソフト)はオープンソースとコミュニティを大切にする企業であることが証明されました。
我々は相利共生な関係でした。
Losing 54k GitHub stars
もしあなたが我々のGitHubリポジトリに☆を付けた54k人のユーザだったとしたら、少し前に、そうではなくなりました💔
What happened?
不幸な出来事の連続で、私は誤ってプロジェクトのリポジトリを一瞬だけプライベートに設定しました。
そしてその瞬間、GitHubに10年かけて築いてきた我々のコミュニティは消え去ってしまったのです。
What does it mean?
ダウンストリームのメンテナ、およびこれまでhttpie/httpieの通知をウォッチしていたユーザは、再度リポジトリを見る必要があります。
ちなみに最近、セキュリティリリースを行いました。
スターも同じです。
あなたがもし過去10年の間にリポジトリに☆を付けた54k人のひとりだったとしたら、その☆はもうあなたの中にはありません。
Why did you make the repo private‽
どうしてリポジトリをプライベートにしたの？
これはGitHubの仕様です。
すなわち、リポジトリをプライベートにすると、全てのウォッチャーと☆は永久に失われてしまうのです。
そしてそのことを我々は認識していたので、httpie/httpieをプライベートにするつもりは毛頭ありませんでした。
では、何故？
理由は、httpie/httpieとは無関係なリポジトリだと思いこんでいたからです。
私が実際に行おうとしていたのは、HTTPieの組織のほうのプロフィールを隠すことです。
私が最初に行ったのは、それとはさらに別の行動でした。
すなわち、私の個人プロフィールであるjakubroztocil/jakubroztocilリポジトリをプライベートにしたのでした。
GitHubは、プロフィールとリポジトリについて、ユーザと組織をほんとど同じように扱っています。
組織のプロフィールについて、さきほどと同じことを行うだけだったので、私は何も考えずに手を動かすだけモードに入りました。
そのせいで、作業対象のリポジトリが組織ではなくプロジェクトになっていたことに気付くことができませんでした。
私は自分の過ちを見過ごしたまま、httpie/.githubではなくhttpie/httpieをプライベートにする準備を進めていたのです。
But there’s a confirmation, right‽
でも確認のダイアログが出ますよね？
たしかに確認はあります。
これは、私のようなユーザが愚かな選択をしないようにするためのものです。
「このリポジトリのウォッチャーと☆が永久に失われますYou will permanently lose all stars and watchers of this repository」と、恐ろしいことがはっきりと書かれています。
問題は、commitも☆も全くないリポジトリと、10年の歴史と55kの☆を持つリポジトリにおいて、この警告が全く同じことです。
この警告は要するに、「あなたは家を壊そうとしています。中にいる人はみんな死んでしまいます。」という意味です。
しかし、そもそも空き家を壊そうとしていると思っているので、住所を間違えているとは夢にも思っていません。
ここでちょっとした質問です。
以下の2つのダイアログのうち、どちらが消してしまっても何ら問題ないリポジトリで、どちらが10年の歴史を持つリポジトリでしょう。
このダイアログはもっと具体的であるべきで、すなわち、「55k人が死にますよ！」と言っておくべきだったわけです。
そうだったとすれば、私はきっと立ち止まれたことでしょう。
So you made it private, just flip the switch!
すぐに元に戻そう！
組織のページに戻ると、空のReadmeがあるだけでした。
最も人気のあるリポジトリがどこにもなくなっているのです。
私の混乱は想像に難くないでしょう。
私は自分の過ちに気付いたあと、リポジトリの設定に戻り、すぐにプライベートから戻そうとしました。
しかし、GitHubは30分の間、その作業を赦してくれませんでした。
何故そんなに時間がかかったかというと、それは10年にわたって積み上げてきたウォッチャーと☆をカスケード削除するのにかかった時間だからです🥁
そして、そのプロセスを止める方法はありませんでした。
私にできたことは、GitHubのサポートに書き込みを行い、☆の数が0になるのをじっと待って、その後リポジトリを再度パブリックにすることだけでした。
Why doesn’t GitHub restore it‽
GitHubはリポジトリを復元してくれなかったの？
GitHubは当然バックアップを持っています。
そして、リポジトリを誤ってプライベートにすることで失われたものを元に戻すことも可能です。
何故断言できるかというと、GitHubチーム自身が、自身のGitHub Desktopリポジトリをプライベートにして、その後☆を復元したことがあるからです。
以下はGitHubのCEOによる状況説明です。
しかし我々に対しては、副作用とコストを理由に、復元を拒否されました。
かかった費用を補償することも提案しましたが、残念なことに、それも拒否されました。
彼らには、自分たちのプラットフォームでも最も古く人気のあるリポジトリのひとつであるプロジェクトのコミュニティを復活させるより優先されなければならないことがあるのです。
ということで、GitHubの公式回答は以下のとおりです。
GitHubは、リポジトリをプライベートにすることで受けた被害を復元することが可能です。
ただし、それはGitHubのプロジェクトである場合に限られます。
コミュニティのプロジェクトである場合は、ツイートする程度が精いっぱいです。
Lessons learned
Never let a good water crisis go to waste
我々は、良い危機を無駄にしてはいけない。
我々の選択肢は限られていますが、少なくとも幾つかの教訓は、共有する価値があると考えました。
Lesson #1: UI/UX design
確認ダイアログは、考えさせないようにデザインされるべきです。
ユーザが破壊的変更を行おうとしているときに、ユーザがその意味を考える必要があるような抽象的な言葉で表現するべきではありません。
特に、アクションの副次的作用として連鎖的な削除がなされる場合はなおさらです。
例として、HTTPie for Desktopでは、不可逆的な操作にこのような表示をしています。
当然、ダイアログの内容はその副作用の重さに比例したものであるべきです。
副作用が全くない場合は、静かなダイアログであるべきです。
さもないと、ユーザは感覚が麻痺してしまい注意力を失ってしまうでしょう。
Lesson #2: Database design
データベースは論理削除にしよう。
人間だれしも間違いがあります。
どうしても物理削除にしなければならないなら、遅延削除にしましょう。
Lesson #3: Relationship with GitHub
我々の人為的なミスであり、GitHubには我々を助ける義務はないと明言しました。
10年にわたる我々の互助的な関係は、GitHubの利用規約に定められているだけのものでした。
それ以上のものがあると考えるのは、甘い考えでした。
とはいえGitHubには、オープンソースやコミュニティの精神に反する行動をとり、世間の怒りを買って元に戻したという歴史もあります。
またMicrosoftも、近年はオープンソースに積極的であるものの、決して昔からそうだったわけではありません。
What’s next?
我々は、GitHubとMicrosoftが機械的な態度を改め、いつの日かプロジェクトのコミュニティを復活させてくれることを願っています。
彼らはその手段も能力も持っているのです。
また、今後他のコミュニティが同じ轍を踏まないためにも、UIやデータベースの設計を改善してくれることを望みます。
それまでの間、このストーリーを広め、リポジトリのウォッチと☆を再度付けてくれると助かります。
我々としては、Octocatシャツを着ることをしばらく控えることになりそうです。
Epilogue
☆が星屑となったにも関わらず、HTTPieはこれまでになかったほど順調にいっています。
私のサイドプロジェクトとして始まったHTTPieは今や会社組織となり、HTTPieはAPI開発プラットフォームとして成長しつつあります。
HTTPie for Web & Desktopのクローズドベータもたいへんな高評価をいただいており、まもなく一般公開されるのが楽しみです。
HTTPieに関する最新情報を知りたい方は、Discordに参加するかTwitterをフォローしてください。
コメント欄
dev.toのコメント欄
「ひどい話もあったものだ。より人道的な代替を探すべき時なのでは。たとえばCodebergとか。」
「今見たら12.5k☆まで復活してた。かなり立ち直れたみたい。」
「これを受けて、GitLabの開発チームにアクセス権変更時に詳細を表示するようなイシューを投げたよ。まあ元々GitLabはプライベートにしても☆は失われないけどね。」←GitLabの中の人
「まだ大丈夫、commitもissueもPRも残ってる。☆とlikeは違うものだし、☆を求めるのはYoutuberがいいねボタンを求めるようなことだ。」
「『有名なプロジェクトだから』というところ以外は、全てにおいて正しいと思う。」
「このプロジェクト初めて知った。良いツールだったので新しく☆を増やしたよ。」
「AWSで同じ目に合ったよ。1ページに削除ボタンがふたつあって、サービスではなくECSクラスタごと削除してしまった。」
感想
GitHubの現在の☆数によるランキングはこちらで見ることができます。
2022/04/25時点で1位のfreeCodeCampですら345k☆であり、意外とあんまり多くないですね。
現在の80位付近には59.5kのangular/angular.js、59.3kのapple/swift、57.6kのsveltejs/svelte等が並んでおり、HTTPieはリセットさえされなければ、それらに匹敵するほどの有名なプロジェクトだったわけです。
※このランキングわりとアバウトっぽくてリロードするたびに変動したりする。
ほんの少しの操作ミスで、この積み重ねが灰燼に帰したときの衝撃は計り知れないものがありますね。
なお、今見たら19.1kまで増えていました。
だいぶ盛り返したとはいえ、最盛期の1/3なのでまだまだ全然足りません。
最終的には当人のミスなので、GitHubだけを責めるのはちょっと違うのではないかと思います。
実際プライベート/パブリックの切り替えにおいてはわざわざリポジトリ名を入力する必要があるので、少し気を付けていれば気付けていたはずのものですしね。
ただやはり、GitHub側にも多少なり融通は効かせてほしいところです。
特に自分のときだけはやっているというのは、かなり印象が悪いですね。
なおこの件に対して、GitHubはめっちゃ密やかな改修を行っています。
どこが変わったかわかりますか？
プライベートにすることで失われるウォッチャーと☆の具体的な数が表示されています。
そう、「55k人が死にますよ」がしっかり表示されるようになったというわけです。
GitHub側は何も言ってないのですが、まあタイミング的にこの件が契機になったのは間違いないでしょう。
ただこの件、変更履歴に見当たらないんだけど。
ということで、みんなもリポジトリの管理には気をつけましょう。
さて私のリポジトリも☆を失わないように気を付けなければ……そもそも☆がない！！