時々、フェードアウトする代わりに、良いことをするレイジフォークが生まれることもある。2014年か2015年のio.jsのノードからのフォークが思い浮かぶ。確か、ノードを前に進めるために必要な変更や改善がたくさんあったけど、Joyentが足を引っ張ってたんだよね（V8のアップグレードがその一つだったかもしれないけど、もう長いこと前のことだから確かには覚えてない）。コアの開発者たちも、全てが進むのが遅いことにうんざりしてた。だから、彼らのグループがノードからio.jsをフォークして、アップグレードや他の改善を行った結果、最終的にはそれがコアノードに戻ってきて、みんなが満足する結果になった。でも、少しでも状況が違っていたら、みんながノードじゃなくてio.jsを使っていたかもしれないと思う。

フォークの「反対側」がそれを少しネガティブに見るのは全く驚きじゃないね。フォークを計画している人も、メインラインのプロジェクトのメンテナーをその瞬間、少しネガティブに見てるだろうし。彼らはどれだけ敵対的になってもいいけど、それはフォークの決定にはほとんど関係ないみたい。もしメインラインがパッチを受け入れないとか、別の方向に行きたいなら、フォークするのは全然妥当だし、彼らの帝国を維持できる。それでいいんじゃない？ 東に行きたくないなら、東に行くフォークがあれば、同じく東に行きたいユーザーも満たされるし。

ライセンスがオープンソースなら、メンテナはフォークされると文句を言うことしかできないよ。自分の（比喩的な）耳を塞いで、作業を続けるしかないんだ。

GitHub Pagesの問題を無視すると、Jekyll 4.xでやってほしいことって何？

昔は、ウェブって趣味を匿名のサポートしてくれる人たちと共有する場所だったし、暗号通貨は数字を使って賢いことをすることを意味してた。私の経験上、欲望やお金、サイコパスがダンバー数を超えるものを台無しにするのはほぼ確実だよね。遊び場が麻薬王たちに乗っ取られるのは悲しいことだ（比喩的にね）。それに対する答えは持ってないけど、私の中心的なトラウマだよ。

同じようなスタイルのプロジェクトはたくさんあると思う。ただ、開発者の数は爆発的に増えて、ニッチで解決策のない問題の数は劇的に減ったね。

共有から伝道へと明確にシフトしたよね。例えば、Cは共有され、C++は伝道された。違いは、人々に自分のものを採用させるためにかける努力だよ。Javaなんかは超伝道されたし、サンはそれで運命が逆転するかもって思ってた。Linuxは最初は「どうぞ、うまくいくといいね」って感じだったけど、そこからエコシステムを作る人たちが集まってきた。

依存関係の膨張や依存関係の腐敗が、解決策をあまり永続的でなくし、メンテナンスの負担を増やしてる。依存関係ゼロの古いプロジェクトはまだ残ってるけど、変動する依存関係に基づいて作ったプロジェクトは腐ってきてる。

それに、修正を求める人はたくさんいるけど、実際に貢献する人はあんまりいないんだよね。

このフレーミングは、「問題解決型」プロジェクトと「パーソナルブランド」プロジェクトの比率が変わったと仮定しているけど、ちょっと反論したいな。根本的な比率は大体同じだと思うよ。変わったのは、何が公開されるかってこと。オープンソースプロジェクトを運営する作業（問題の整理、セキュリティの公開、貢献ガイドライン、CI、リリースのペース、依存関係のメンテナンス）は、元の問題を解決する作業よりも遥かに大変なんだ。「私のプライベートなワークフローツール」って考えの人たちは、そういう税金を負担できないから、ますます公開しなくなってる。一方で、ブランド構築のメリットを求める人はそれを引き受ける意欲があるから、ブランド構築が目的なんだよね。だから、目に見えるOSSの風景はブランドカテゴリーを過剰に表現している。解決策の共有が死んだわけじゃなくて、解決策の共有には10倍のメンテナンスコストがかかるようになったから、ほとんどの人がそれを避けるようになったんだ。自分のdotfilesでもそういうのを見てるよ。小さなツールがいっぱいあって、「共有」ってまだ「gistを落とす」って意味だったら喜んで共有するんだけど、もうそうじゃないんだよね。

15年前、GitHubは「コードを書いてピザをドアの下に滑り込ませる」みたいな同じ考えの開発者にとって、強いシグナルだったんだよね。でも、時間が経つにつれてそのシグナルの意味が薄れて、みんな他のこと、例えばスターとかブランドとかを重視し始めた。フロントエンドのマーケティング系の人たちとJSフレームワークの爆発が、この流れを引き起こしたんじゃないかな。今や、どこにでもバイブの合ったプロジェクトがあって、良いものと悪いものを見分けるのが本当に大変だよ。今でもGitHubを使ってるけど、あのスターがまだ一部の市場では有効だと思ってるのかもしれない。でも、もしかしたら自分を騙してるだけかも。あるいは、ロケット絵文字の発明がこの現象の原因かもしれないね。

大体、CSのキャリアアドバイスはいつも「自分のプロジェクトをいくつか見せること」だったから。完全に一人でやるか、貢献者になるか。時間が経つにつれて、企業文化や履歴書重視の開発文化も影響を受けてきたんだよね。

「古いって呼んでくれてもいいけど、昔は『オープンソースプロジェクト』っていうのは『問題があったから、これが解決策だ。同じ問題を抱えてる人は自由に使ってね』って意味だったんだ。最近はもっとこうなってる: - パーソナルブランドを築く - スキルを見せる - 誰かを出し抜こうとする、特に自分のPRをマージしなかったから - 時にはただ楽しむために。Linux、MySQL、PostgreSQL、Apache、Python、ほとんどのウェブブラウザやインターネットで使われている大規模なサーバーコードは、ずっと「オープンソースプロジェクト」だったけど、単に人々がその解決策をそのまま共有するだけじゃなかった。役立つプロジェクトは常にコミュニティを育ててきた。中には露出や履歴書のためにオープンソースプロジェクトを作ろうとする人もいるけど、それは通常、メンテナーが消える心配をしなきゃいけないほどのトラクションを得るプロジェクトとは関係ないと思うよ。あなたは2つの異なる概念を混同してるんじゃないかな。

それは間違ってないけど、使ってるライセンスがめっちゃ重要だよ。もしコードが本当にオープンソースで、OSSライセンスなら、そのまま使ったり、学んで自分で書いたりできるよ。アプリにそのまま組み込むこともできるしね。コードはそのままにして、依存関係を外せばいい。フリーソフトウェアはまた別の話だよ。GPLとかはウイルスみたいなもんだから、GPLソフトを使って上記のことをすると、いろいろ影響が出るよ。学ぶだけでもリスクがあるし、リライトするなら変数名の変更だけじゃダメだよ。もし昔ながらのやり方で、「好きにやって、これを仕事にするつもりはない」って感じで、みんなに実際に利益をもたらしたいなら、フリーライセンスよりOSSライセンスをおすすめするよ。一方で、ターゲットが他のフリー開発者なら、フリーライセンスが理にかなってる。将来的にプロジェクトを商業化するつもりなら、AGPLみたいな攻撃的なフリーライセンスがいい選択だね。結局、ライセンスの選択は自分の目標に合ったものにすべきだよ。

時代が違うね。セキュリティアップデートのためのパッチが必要になるのが急速に増えてる。

これだよね。根本的な問題は、人々がすべてのソフトウェアは必ず信頼できないものだと考えていることなんだ。実際には、自分たちが完璧に信頼できるソフトウェアを作れないから、他の人も同じだと思ってしまう。そんな狭い視野だと、ソフトウェアは常にアップデートが必要だと思うよね。メンテナンスする人が、終わりのないモグラ叩きをしているようなもんだから。すべての技術が変わるわけじゃないし、低レベルのエンジンAPIは非常に安定していて、基本的に変わらないことが多い。じゃあ、その上に作られたソフトウェアが変わる必要はあるの？ OPによると、AIの混乱時代に必要な信頼できるソフトウェアは「死んだプロジェクト」のカテゴリーに入るらしい。だから、彼らは他のAIの混乱の上にAIの混乱を作る運命なんだ。頑張ってほしいね。

直面している現実：何年も「ただ動く」ソフトウェアは、アプリケーションレベルだけじゃなくてエコシステムレベルでの依存関係の衛生が必要なんだ。Common LispやC、あるいはほとんどのGoをそんな風に書けば、20年後もコードは動くよ。でも、現代のフロントエンドフレームワークやバックエンドフレームワークに依存した瞬間、そのリリースペースに従わなきゃいけなくなる。しばしば「年に2回、ものを非推奨にします」って感じだし。フレームワークの作者には自分たちのインセンティブ（関連性、雇用、採用の流れ）があって、あなたのプロジェクトの長寿を最適化しているわけじゃない。今日、20年持つコードを書く唯一の方法は、(a) 本当に安定性を重視するエコシステム（Lisp、C、一部のErlang/OTP、Postgres）で作業するか、(b) 現代のスタックのコストを受け入れて、それに明示的に予算を組むことだ。ほとんどのチームはどちらもやらないから、プロジェクトが一番早く腐るんだ。

またこれか！ソフトウェアは成熟していて、かつ役に立つこともあるんだ。成熟していて役に立つソフトウェアに出会ったら、まずはそのGitリポジトリを自分のストレージにクローンして、プロジェクトの状態を保存するべきだよ。その後、自分のリポジトリで作業して、コミュニティのためにプルリクエストを出すべきなんだ。でも、誰もそのプルリクエストを使わないなら、次に進むべきだね。

言語によって、こういうことに対する期待や文化は全然違うよね。npmパッケージが2年間更新されてなかったら、ちょっと疑っちゃう。ダウンロード数をチェックしたり、GitHubのイシューを見たりして、どんな問題があるか調べるし、他に使われてるものがないかGoogleで探す。clojarsのパッケージが6年間更新されてなかったら、もう考えもしないよ！

インターネットに接続されてるものや、サードパーティのシステムと統合されてるものは、永遠に定期的にメンテナンスしなきゃいけないんだよね。自己完結型のものはずっと持つけど。アプリが必要なものは買わないようにしてるのが主な理由。だって、いつかそのアプリがメンテナンスされなくなって、動かなくなっちゃうから、ハードウェアが壊れちゃうんだよね。

そんなプロジェクトに時間を投資してきたけど、道を見失って完全にメチャクチャになっていくのを見るのは心が痛むね。フォークして元の根源に戻りたくなるけど、それにはさらに多くの時間を投資する必要があるから、また別の問題が出てくる。

本当にその通り。みんながそのプロジェクトが何をすべきかについて自分の考えを持っていて、その実装が特定のユースケースには素晴らしいけど、他の人には全然ダメだって説明するのが難しい。AIがこれをさらに悪化させてるよね。

ソロメンテナに「これが進む方向だよ」って言っても、彼らはみんなを喜ばせるために小さな貢献を受け入れ続けるだけなんだ。悪いアイデアじゃないけど、結局はめちゃくちゃなゴミの山になっちゃう。

あんまり興味のない機能をPRで投げ込んでくる人もいるよね。その後、その提出者が去って、時間が経ったらその機能に関するバグやリクエストが報告され始める。

もっと重要なのは、そういう見込みのあるメンテナが、あなたが築いた評判を使ってマルウェアを出荷することがないってどうやって知るの？オープンソースプロジェクトにとって、死ぬことが最悪の事態じゃないからね。

これは基本的にGitHubでホストされているオープンソースの問題だよね？ GitHubは組織外の人からのPRをオフにすることを許可してないから。昔からこのポリシーを変えてほしいと頼まれてるのに、全然反応がないから、別の場所にプロジェクトをホストするのも一つの手だよね。そうすれば、同じポリシーやスパマーの量が少ないところでできるし。もちろん、GitHubでホストする利点は得られないけど、そこにホストするコスト/ベネフィット比は時間とともに変わってきた。