lodashがイシュー破産を宣言し、すべてのイシューと開いているPRをクローズした
Lodashがイシュー破産を宣言し、すべてのイシューとオープンPRを終了 (twitter.com/danielcroe) 1 ポイント 投稿者 GN⁺ 2023-09-18 | 1件のコメント | WhatsAppで共有 lodashがイシュー破産を宣言し、すべてのイシューと開いているPRをクローズした 関連記事 gh-dash - GitHubのPRとIssueダッシュボードをCLIで表示 7 ポイント · 0件のコメント · 2022-04-03 GhosttyがGitHubを離れます 5 ポイント · 3件のコメント · 2026-04-29 GitHub以前のオープンソースの世界 4 ポイント · 3件のコメント · 2026-04-29 GitHub Repo Trends 7 ポイント · 1件のコメント · 2022-08-03 オープンソースプロジェクトが今後は外部貢献を受け付けないと宣言 10 ポイント · 0件のコメント · 2026-01-22 1件のコメント GN⁺ 2023-09-18 Hacker News のコメント これは本当に両義的。ひとつには、とても良い。到底たどり着けないと分かっていながら、上から削り取るように進めるバックログ整理ミーティングを経験したことがない人なんているのだろうかと思うし、その感覚は確かに惨めなものだ。 一方で、Issue が消えたわけではなくタグが変わっただけで、すべてがタグ付けと整理の問題なら、完全に空の Issue 一覧という疑似ユートピアをコントロールしようとするより、流れに任せればいいのではとも思う。そういうメモを見える場所に残しておく利点もきっとあるはずだから。大掃除の最中に捨てると決めたのに、無意識が「あとで必要になるかもしれないから取っておけ」と言ってくる感覚に似ている。 それでも全体としては賛成寄り。少なくとも解放感と、新しい Issue に向けて気持ちを入れ直す効果はありそう。 もう少し文脈を補うと、作者は全面的な書き直しを進めている。 書き直し版を先にリリースしてから、既存の Issue を deprecated として閉じるほうが、よりすっきりしていたように思う。書き直しブランチの Issue はバージョンタグで分けられたはずだし。新バージョンがまだ終わっていない状態で閉じると、コントリビューターがもうサポートされていないことを知らずに、既存バージョンに新しい Issue を開くかもしれない。 とはいえ、Issue を無視してコードベースの問題を放置しているわけではなく、プロジェクト全体が新しく整備されている最中だ。 https://twitter.com/jdalton/status/1571863497969119238 ユーザーの立場からすると、こうした「整理」が Issue を閉じるという意味なら問題がある。製品にまだ存在している Issue なら、ドキュメント化という意味でも、同じ問題に遭遇したユーザーが簡単に見つけて追記できるようにするためにも、開いたままにしておくべきだ。 プロジェクトが Issue の存在を認めて開いたままにするほうが、より誠実だと思う。開発者の立場で Issue 数が気になるなら、古い重要でない Issue を隠すフィルターを使うほうがよさそう。 私も両義的だ。ひとつには、JavaScript の作業に戻るたびに lodash を探してしまう。一方で、このライブラリの半分弱くらいは、ぜひ標準ライブラリに入っているべきだと思う。 こういう作業こそ大規模言語モデルが得意であるべきことではないのか？ チケット要約のことだ。 だから Basecamp はバックログを維持しない。重要なことはまた浮上してくるものだ。 jwz はこう言っていた。 私がオープンソースソフトウェアプロジェクトに報告したバグが閉じられる最もよくあるパターンはこれだと思う。バグを報告すると、1年、ときには2年読まれないままになり、ある日そのモジュールがゼロから書き直される。そして新しいメンテナーには、新バージョンが旧バージョンに存在した既知の問題を実際に解決したかどうか確認する気がない。 メンテナーが少ない、あるいは1人プロジェクトなら、単独メンテナーが数日から数週間かけて検証する代わりに、バグ報告者たちがそれぞれ10〜15分ずつ使って、問題がまだ存在するか確認するほうが合理的ではないかと思う。 特に再現が難しい、あるいは複雑なバグなら、そもそもメンテナーが自分の環境で再現できるかどうかも不確かだし、報告者のほうがそのバグを観察することに慣れている可能性が高い。 より大きなチームがある場合や、商用サービスに付随するプロジェクトなら、このバランスは少し変わるかもしれない。 多くの自由／オープンソースプロジェクトで見られるのは、腕まくりして取り組もうとする人は非常に少ない一方で、そのプロジェクトが自分にどれほど不可欠かを知らせたり、要求したり、多くの提案をしたりすることにはかなりの時間を使うという点だ。 大多数はウィッシュリストを伝えるために新しい Issue を作るか、非常に曖昧なバグ報告を残す。そのうち一部はまともなバグ報告を出すこともあるが、貢献意欲はたいていそこまでだ。 個人的には、よく見かけるコメントの大半を外交的に扱う気になれないので、プロジェクトメンテナンスには向いていない性格だ。 それでも、自分が報告する Issue については原因を追跡し、可能なら修正する PR を出して、自分の役割を果たそうといつも努めている。 その変形もある。あるメジャーバージョンについて Issue が報告されたが、新しいメジャーバージョンが出たので、書き直しでもなく段階的変更にすぎないのに、問題がもう存在しないかもしれないという理由で以前のリリースの Issueをすべて閉じるやり方だ。 通るべきだが現在はスキップとしてマークされたテストを含む PR を作ればいい。そうすれば再構築するときに進捗を確認し、改善されたかどうかを見るための簡単な道筋ができる。 本当に気にしている問題なら、テストを付けるべきだ。 セキュリティ上の発見事項もそのように処理されることがある。 クローズドソースソフトウェアプロジェクトでも、私の経験は同じだ。 lodash の作者である John-David Dalton は[昨年こう][1]書いていた。 lodash の書き直しでは、技術的負債の破産を宣言する。TypeScript と Rollup でゼロから始める。FP ラッパーはない。その流行は終わった。あの厄介ごとをコードベースに持ち込んだ人の同僚たちに哀悼の意を表する。チームにも人にもまったく優しくない。 100%そのまま進むのかは分からないが、かなり近そうだ。 [1]: https://twitter.com/jdalton/status/1571863497969119238 「その流行は終わった。あの厄介ごとをコードベースに持ち込んだ人の同僚たちに哀悼の意を表する。チームにも人にもまったく優しくない」って、元の作者は本人ではないのか？ まるで自分が批判している複雑さを、別の誰かが追加したかのように聞こえる。本人が導入したのなら、振り返りや学びとして語るというより、流行に合わせてプロジェクトを開発してきて、今やその流行が終わったので次へ進む時だ、という言い方に見える。 FP ラッパーとは何だったのか、どんな流行だったのか？ JavaScript 周りの Issue には詳しくないのだが、この文脈で関数型プログラミングの何が問題なのか？ よくやった リストの先頭のPRをいくつか見るだけでも、こんなものがある コメントに単語を1つ追加、開発サービス宣伝用の設定ファイル追加、varをletに変える、コア関数の確立された挙動を変更する、セミコロンを削除する、など ほとんどはライブラリを改善しようという善意で開かれたのだろうが、ある時点でメンテナーにとっては単なるスパムになるか、さらに悪いことに、対応できないほど罪悪感を増やす負担になる 有名人が絶え間ない注目を避けて精神を守るためにボディーガードを雇い、ファーストクラスやプライベートジェットに乗るように、有名なオープンソースプロジェクトではどんな対策が可能なのか気になる 個人的にはオープンソースのメンテナーとして、誤字修正、文言修正、自動リファクタリングのPRが一番好きだ。レビューにほとんど労力がかからないので、ほぼいつも非常に早くマージする 一番時間がかかるのは巨大な機能を実装するPRだ。レビューと議論が多く必要なので、詳しく見るのを先送りしがちになる 一時期、有名プロジェクトに些細なPRを出すのが流行っていた。履歴書を埋めるための試みだったのだと思う varをletに変えるだけのPRを、複数のJavaScriptプロジェクトに繰り返し投げていた特定のGitHubユーザーがいた GitHubプロフィールを埋めるためのように感じる より大きなニュースは、LodashがNode.jsからBunへ移行するという点だ: https://github.com/lodash/lodash/commit/97d4a2fe193a66f5f96d... すごい 自分のパッケージをBunに移すことに興味が出始めていたが、互換性や、Bunが本当に生き残り続けるのかが心配でためらっていた。「Modern Yarn」で少し痛い目を見たこともある。だがlodashが移行するのを見ると、もう少し真剣に検討したくなる これは確かに大きなニュースだ。特に最近のv1.0リリースにもかかわらず、Windowsで性能問題があることを考えるとなおさらだ オープンソース開発者にプロジェクトの運営方法をあれこれ言うのは避けようとしている。自分もオープンソース開発者だし、他人にそうされると腹が立つから ただ、自分がイシューを書いて問題解決を手伝うのにかなり時間を使ったユーザーだったり、修正や新機能に取り組んでPRを送った人だったりしたら、今かなりやる気をそがれていただろうと思う しかしほとんどのユーザーは、イシュー作成にごくわずかな時間しか使っていない。バグ報告の大半はひどいものだ イシューは閉じられただけで、消えたわけではない。まだ関連があるなら、後でまた依頼できると思う issue bankruptcyタグを付けて363件のイシューを閉じた: https://github.com/lodash/lodash/issues?q=is%3Aissue+is%3Acl... PRも325件が同じ扱いだ: https://github.com/lodash/lodash/pulls?q=is%3Apr+is%3Aclosed... イシュー破産は現実にある。個人的経験から言うと、ある時点でオープンソースのメンテナンスは現実世界で生きることと両立しにくくなる 作業は無償で、しばしば感謝されない。もちろん常にそうではない。問題は複雑で、仕事・家族・休息といった現実の責任と競合する。人々は簡単にいら立ち、定期的に議論を吹っかけてきたり、ドキュメントを代わりに読んでくれと言ってきたりする。オープンソースが有名になると、巨大な責任もついてくる プロジェクトを率いる人たちが「もういい」と言って、もっと重要なことへ去っていくことで、オープンソースのエコシステムに大きな崩壊が起きるのではないかと予想している それは理解できる。最近では、些細ではない個人プロジェクトは実際のプロジェクトというより、依存症や自傷行為に近いとまで思うようになっている ただし、オープンソースのエコシステムは狂ったように非効率だ。lodash、underscore、そして無数の他のライブラリがあるが、すべてが存在する必要はない。1つのことだけをするライブラリも多く、たいていはこうしたライブラリの部分集合だ こうしたものの大半はミニファイアやツリーシェイキングと一緒に使われ、使わない機能は取り除かれる。重いライブラリも簡単に最適化され、ほとんどは分離された部分で構成されているので、わざわざ軽量ライブラリが必要なわけではなく、開発労力はおおむね線形に増える プログラマーが優雅さと単純さを何より好み、少しでも良くするために何度も書き直したがる、という点さえなければ、皆が今使っている時間の4分の1だけを使うようにしても、オープンソースには十分な人手があると思う Lodash は優れたライブラリだと思う。自分が手がけるほぼすべてのプロジェクトで、多少は使うことになる。 ただ、JavaScript がどんどん良くなるにつれて、Lodash を使う量は徐々に減っている。使うたびに、自分がやろうとしていることに組み込み機能がないか確認している。PR に「これは Lodash は不要です」というリンクを付けてコメントすることもかなりよくある。 それでも、これがプロジェクトから手を引く兆候でないことを願っている。 確かに便利ではあるけれど、結局必要ならユーティリティは自前で作ったバージョンのほうを好む気がする。 とても同意。スプレッド構文、文字どおり ... ひとつだけでも得られた効果は大きかった。https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... イテレーターヘルパーも近くリリースされる予定なので、大いに助けになるはず。非同期イテレーターヘルパーはしばらく遅れそうだ。https://github.com/tc39/proposal-iterator-helpers 以前は、作業していたコードベースで関数を創造的に呼び出すために、毎週何度も .apply() を使わなければならない感じだった。https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... 今ではそれはすべてなくなり、チームメンバーの50%が .call と .apply を知っているかどうかも半々くらいだと思う。 Chrome 117 には Object.groupBy() が入り、lodash を使うことになる最後の多くの場面を取り除くのに大きく役立つはずだ。https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... 8年前から lodash や underscore.js は使っていない。map、filter、find などで簡単にできないことが何なのか、よく分からない。 Issue トラッカーには2つの用途が重なっている。ひとつはメンテナーがやるべきことを追跡する方法で、もうひとつは、より広いコミュニティとユーザーがソフトウェアの欠陥を追跡する方法だ。 「Issue 破産」の宣言は前者の用途では理にかなっているが、後者の用途では、現行バージョンに存在する Issue に関する価値ある情報を消してしまうことになる。
1件のコメント
Hacker News のコメント
これは本当に両義的。ひとつには、とても良い。到底たどり着けないと分かっていながら、上から削り取るように進めるバックログ整理ミーティングを経験したことがない人なんているのだろうかと思うし、その感覚は確かに惨めなものだ。
一方で、Issue が消えたわけではなくタグが変わっただけで、すべてがタグ付けと整理の問題なら、完全に空の Issue 一覧という疑似ユートピアをコントロールしようとするより、流れに任せればいいのではとも思う。そういうメモを見える場所に残しておく利点もきっとあるはずだから。大掃除の最中に捨てると決めたのに、無意識が「あとで必要になるかもしれないから取っておけ」と言ってくる感覚に似ている。
それでも全体としては賛成寄り。少なくとも解放感と、新しい Issue に向けて気持ちを入れ直す効果はありそう。
書き直し版を先にリリースしてから、既存の Issue を deprecated として閉じるほうが、よりすっきりしていたように思う。書き直しブランチの Issue はバージョンタグで分けられたはずだし。新バージョンがまだ終わっていない状態で閉じると、コントリビューターがもうサポートされていないことを知らずに、既存バージョンに新しい Issue を開くかもしれない。
とはいえ、Issue を無視してコードベースの問題を放置しているわけではなく、プロジェクト全体が新しく整備されている最中だ。
https://twitter.com/jdalton/status/1571863497969119238
プロジェクトが Issue の存在を認めて開いたままにするほうが、より誠実だと思う。開発者の立場で Issue 数が気になるなら、古い重要でない Issue を隠すフィルターを使うほうがよさそう。
jwz はこう言っていた。
特に再現が難しい、あるいは複雑なバグなら、そもそもメンテナーが自分の環境で再現できるかどうかも不確かだし、報告者のほうがそのバグを観察することに慣れている可能性が高い。
より大きなチームがある場合や、商用サービスに付随するプロジェクトなら、このバランスは少し変わるかもしれない。
多くの自由／オープンソースプロジェクトで見られるのは、腕まくりして取り組もうとする人は非常に少ない一方で、そのプロジェクトが自分にどれほど不可欠かを知らせたり、要求したり、多くの提案をしたりすることにはかなりの時間を使うという点だ。
大多数はウィッシュリストを伝えるために新しい Issue を作るか、非常に曖昧なバグ報告を残す。そのうち一部はまともなバグ報告を出すこともあるが、貢献意欲はたいていそこまでだ。
個人的には、よく見かけるコメントの大半を外交的に扱う気になれないので、プロジェクトメンテナンスには向いていない性格だ。
それでも、自分が報告する Issue については原因を追跡し、可能なら修正する PR を出して、自分の役割を果たそうといつも努めている。
本当に気にしている問題なら、テストを付けるべきだ。
lodash の作者である John-David Dalton は[昨年こう][1]書いていた。
まるで自分が批判している複雑さを、別の誰かが追加したかのように聞こえる。本人が導入したのなら、振り返りや学びとして語るというより、流行に合わせてプロジェクトを開発してきて、今やその流行が終わったので次へ進む時だ、という言い方に見える。
よくやった
リストの先頭のPRをいくつか見るだけでも、こんなものがある
コメントに単語を1つ追加、開発サービス宣伝用の設定ファイル追加、
varをletに変える、コア関数の確立された挙動を変更する、セミコロンを削除する、などほとんどはライブラリを改善しようという善意で開かれたのだろうが、ある時点でメンテナーにとっては単なるスパムになるか、さらに悪いことに、対応できないほど罪悪感を増やす負担になる
有名人が絶え間ない注目を避けて精神を守るためにボディーガードを雇い、ファーストクラスやプライベートジェットに乗るように、有名なオープンソースプロジェクトではどんな対策が可能なのか気になる
一番時間がかかるのは巨大な機能を実装するPRだ。レビューと議論が多く必要なので、詳しく見るのを先送りしがちになる
varをletに変えるだけのPRを、複数のJavaScriptプロジェクトに繰り返し投げていた特定のGitHubユーザーがいたGitHubプロフィールを埋めるためのように感じる
より大きなニュースは、LodashがNode.jsからBunへ移行するという点だ: https://github.com/lodash/lodash/commit/97d4a2fe193a66f5f96d...
自分のパッケージをBunに移すことに興味が出始めていたが、互換性や、Bunが本当に生き残り続けるのかが心配でためらっていた。「Modern Yarn」で少し痛い目を見たこともある。だがlodashが移行するのを見ると、もう少し真剣に検討したくなる
オープンソース開発者にプロジェクトの運営方法をあれこれ言うのは避けようとしている。自分もオープンソース開発者だし、他人にそうされると腹が立つから
ただ、自分がイシューを書いて問題解決を手伝うのにかなり時間を使ったユーザーだったり、修正や新機能に取り組んでPRを送った人だったりしたら、今かなりやる気をそがれていただろうと思う
issue bankruptcyタグを付けて363件のイシューを閉じた: https://github.com/lodash/lodash/issues?q=is%3Aissue+is%3Acl...PRも325件が同じ扱いだ: https://github.com/lodash/lodash/pulls?q=is%3Apr+is%3Aclosed...
イシュー破産は現実にある。個人的経験から言うと、ある時点でオープンソースのメンテナンスは現実世界で生きることと両立しにくくなる
作業は無償で、しばしば感謝されない。もちろん常にそうではない。問題は複雑で、仕事・家族・休息といった現実の責任と競合する。人々は簡単にいら立ち、定期的に議論を吹っかけてきたり、ドキュメントを代わりに読んでくれと言ってきたりする。オープンソースが有名になると、巨大な責任もついてくる
プロジェクトを率いる人たちが「もういい」と言って、もっと重要なことへ去っていくことで、オープンソースのエコシステムに大きな崩壊が起きるのではないかと予想している
ただし、オープンソースのエコシステムは狂ったように非効率だ。lodash、underscore、そして無数の他のライブラリがあるが、すべてが存在する必要はない。1つのことだけをするライブラリも多く、たいていはこうしたライブラリの部分集合だ
こうしたものの大半はミニファイアやツリーシェイキングと一緒に使われ、使わない機能は取り除かれる。重いライブラリも簡単に最適化され、ほとんどは分離された部分で構成されているので、わざわざ軽量ライブラリが必要なわけではなく、開発労力はおおむね線形に増える
プログラマーが優雅さと単純さを何より好み、少しでも良くするために何度も書き直したがる、という点さえなければ、皆が今使っている時間の4分の1だけを使うようにしても、オープンソースには十分な人手があると思う
Lodash は優れたライブラリだと思う。自分が手がけるほぼすべてのプロジェクトで、多少は使うことになる。
ただ、JavaScript がどんどん良くなるにつれて、Lodash を使う量は徐々に減っている。使うたびに、自分がやろうとしていることに組み込み機能がないか確認している。PR に「これは Lodash は不要です」というリンクを付けてコメントすることもかなりよくある。
それでも、これがプロジェクトから手を引く兆候でないことを願っている。
...ひとつだけでも得られた効果は大きかった。https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... イテレーターヘルパーも近くリリースされる予定なので、大いに助けになるはず。非同期イテレーターヘルパーはしばらく遅れそうだ。https://github.com/tc39/proposal-iterator-helpers以前は、作業していたコードベースで関数を創造的に呼び出すために、毎週何度も
.apply()を使わなければならない感じだった。https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... 今ではそれはすべてなくなり、チームメンバーの50%が.callと.applyを知っているかどうかも半々くらいだと思う。Chrome 117 には
Object.groupBy()が入り、lodash を使うことになる最後の多くの場面を取り除くのに大きく役立つはずだ。https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...map、filter、findなどで簡単にできないことが何なのか、よく分からない。Issue トラッカーには2つの用途が重なっている。ひとつはメンテナーがやるべきことを追跡する方法で、もうひとつは、より広いコミュニティとユーザーがソフトウェアの欠陥を追跡する方法だ。
「Issue 破産」の宣言は前者の用途では理にかなっているが、後者の用途では、現行バージョンに存在する Issue に関する価値ある情報を消してしまうことになる。