left-pad事件から8年後の回顧（2024）

• left-pad事件は、8年後もオープンソースの依存関係とパッケージ管理の権限をめぐる代表的な事例として残っており、Azer Koçuluは当時の判断をあらためて説明している
• 非公開化の判断は怒りや強欲ではなく、自己省察から生まれた選択であり、NPMが自ら定めたルールを破ったことが中核的な背景だった
• Kik Messengerからの圧力の中で、NPMはオープンソースコミュニティより別の価値を優先したと見ており、その判断がすべてのパッケージ削除につながった
• 削除対象は350個以上のパッケージだったが、利用統計やGitHubの活動だけでは実際の影響範囲を把握しにくかった
• NPMのスクリプト実行後、約10分でReactなど複数のプロジェクトが壊れたが、数時間以内にモジュールは復旧し、状況は正常化した

---

left-pad事件当時の判断

• left-pad事件から8年が過ぎ、Azer Koçuluは実際の仕事に集中するため、この話題はこれまで避けておくほうがよいと考えていた
• 2016年、大半の週末を電波の届かない人里離れた場所でキャンプしていた時期に、非公開化の判断を下した
  • それは論理や怒り、強欲ではなく、自然の中での自己省察と心から生まれた選択だったと説明している
• 判断の原則は単純だった
  • NPMが自分のパッケージ1つを独自のルールに反して削除するなら、同じ基準で自分のパッケージ全部も削除すべきだというものだった
• ルールそのものより、ルールの背後にある精神のほうが重要だと見ていた
  • 別の文脈なら、正当な理由で所有者の許可なくパッケージ削除を求めることもあり得ると認めている
  • しかしこの件では、Kik Messengerが「we’ll bang on your door」「take down your accounts」といった脅しで、NPMベースのオープンソースコミュニティに力を行使したと見ている
• この出来事を「怒った人が企業利益に抗議した」とだけ見ると、メールの日付やタイムライン、圧力の中で踏みとどまる状況、そして異なる意識状態の中で判断がどう動くかを見落としてしまう

削除の過程と影響

• NPMの立場から見れば、削除は突然でも予想外でもなかったと考えている
  • まずNPMに自分のモジュール削除を要請し、返答を待っていた
  • 締め切りを設けていなかったため、NPMにはAPIやツールを調整して移行を円滑にする機会があったと見ている
  • その代わりに、NPMはすべてのパッケージを一度に削除するスクリプトを提供した
• 自分のオープンソースでの作業は、ほとんどがUnix哲学のように一度に一つのことを行う小さなパッケージだった
  • パッケージは350個以上あり、すべて最適化されテストされていた
  • 見た目には人気がないように見え、NPMは利用統計を表示しておらず、90%はGitHubでの活動もほとんどなかった
  • 一般ユーザーの立場では、非公開化がどんな影響を及ぼすか把握するのは難しかった
• NPMが渡したスクリプトを実行したあと数分席を外し、約10分以内に友人からTwitterで話題になっていると知らされた
  • 350個以上のパッケージのうち1つがReactや複数のプロジェクトを壊していた
  • その後、短いブログ記事を書いて自分のオープンソース作業を手放し、GitHubリポジトリの所有権をボランティアに移した
  • 数時間以内にモジュールは復旧し、状況は正常に戻った
• 数か月後に仕事を辞め、アメリカを恒久的に離れ、Morocco、Jordan、Türkiye、Indonesiaで1年を過ごした
• left-padは、オープンソースに深く心を寄せていた自分の一部が消え、新しいものがその場所を占めた死と再生のような瞬間であり、今ではプログラミングと同じくらい会社を作り運営することにも情熱を持っている

[ndrgrd]

影響の大きかった事件ですが、パッケージ作者の文章を読まなくても、彼個人の過ちよりも、そこに関わった企業やシステム側の問題のほうが大きかったと思います。

[GN⁺]

Hacker Newsの意見

• ブログ記事の半分は文脈を取り違えているようで、よく理解できなかったが、left-padの当事者が事後分析を書いた点はよいと思う。
  ただし「NPMは自分のモジュールが広く使われているか確認し、壊さずに公開取り消しする方法を検討すべきだった」という主張は奇妙に聞こえる。NPMの公開取り消し機能の設計が間違っていたのは確かだが、誰かが公開を取り消すたびに会社の社員が手作業ですべて確認することを期待していたという意味なら、合理的には見えない。NPMという会社はレジストリをキュレーションするというより、公共サービスのようにホスティングしている側に近い。
  それでも著者を強く責めるのは難しい。彼がleft-pad事件を起こしていなくても、ほどなく別の誰かが引き起こしていただろうし、NPMはよりよい公開取り消しポリシーで問題を修正した: https://docs.npmjs.com/policies/unpublish#packages-published...

  • 2016年3月18日、npm, Inc.のCEOであるIsaac Z. SchlueterがKik InteractiveとKoçuluの双方にメールを送り、kikパッケージの所有権をKik Interactiveへ手動で移譲すると伝えた。Koçuluが失望を表明してプラットフォームを去ると言うと、Schlueterは彼が登録した273個のモジュールを削除するコマンドを提供した。
    Koçuluは2016年3月22日にそのコマンドを実行し、自分が配布していたすべてのパッケージを削除しただけで、その後NPMは自分たちの失敗を著者のせいにした。
  • 文脈は https://en.wikipedia.org/wiki/Npm_left-pad_incident を見ればよい。
  • NPMは実際にはレジストリをキュレーションしている。主に消費者に脆弱性を知らせ、悪意あるパッケージを削除するという形だ。
  • 昔Sourceforgeを使っていたときは、プロジェクトを削除するにはまず許可を得なければならないというポリシーがあり、left-pad以後その理由が理解できるようになった。

• JavaScriptとそのエコシステムを21世紀のVisual Basic疫病のように避けている立場からすると、この話で最も興味深いのは、Koçuluがしばらく技術業界と距離を置き、素晴らしいハイキング、キャンプ、トレイル探検をしていたにもかかわらず、8年後にもなお自分について説明しなければならないと感じている点だ。
  技術は気まぐれなミューズのようなものだ。私たちnerdは技術に執着し、その奉仕の中で自分をすり減らすが、技術はいつも再び光の中へ呼び戻す。
  Morris wormのとき現場にいて、数週間その影響を軽減する作業をしていた者として、現在の道具で世界を変える技術を作る能力には根本的な問題があると思う。技術の組織的・倫理的失敗を理解しようとする努力が少ないほど、技術は適用される領域で生産的な変化を生み出しにくくなる。
  私もあと1か月ほど、そして数百回のコンパイル失敗の後にはサバティカルに入ることになりそうだが、数年後に戻ってきたとき、自分が必要に合わせて別の規模と文脈で作っておいた技術空間がどう見えるのか考えてしまう。
  技術者がもっと頻繁に、もっと真剣にサバティカルを取ることが、ある程度標準になってもよいのかもしれない。そうすれば、私たちの技術的能力を押しつぶす倫理的ジレンマを理解するための文脈を得られる。

• 些細な点だが、「ほとんどのオープンソース作業はUnix哲学に従い、パッケージは一度に一つのことをした」という文は曖昧だ。
  最もobviousな例として、libcがUnix哲学に反していると考える人は普通いない。議論はコマンドやデーモンが多くのことをしすぎているのか、あるいは合成可能でないのかをめぐって起こる。最近の代表例はsystemdだ。

  • left-pad騒動はむしろ、NPMパッケージの細分化があまりにも小さくなり、パッケージの単純さの利点よりもパッケージ管理のオーバーヘッドのほうが大きくなる地点に達したことを示した。
  • libcがUnix哲学に反していると考える人はかなりいる。望むなら、今ここでそう言ってもいい。
    現代的なlibcはUnix哲学にかなり反している。伝統的なUnixのlibcはずっと単純で、多くの関数は単なるシステムコールだった。今日のlibcの一部はlibmのような別ライブラリに分離されていたし、NSSや複雑なDNS解決フレームワークのようなものはそもそも存在しなかった。
  • 「一つのことをせよ」の反対側には、その一つのこと全体をしなければならないという条件がある。
  • Unix哲学は役に立たない、あるいは有害ですらあるかもしれない。「一つのこと」がうまく定義されていないため、実際には何も付け加えず、議論だけを生むからだ。
    Eclipseも「IDEプラットフォームという一つのこと」をしていると言えるが、Unix開発者たちがそういう意味で言ったのではないと思う。同様に、11行の関数一つだけを入れたライブラリを作れという意味でもなかったはずだ。
    実際の助言は「プログラムやライブラリは、多すぎることも少なすぎることもしようとしてはならない」くらいであるべきだ。どの程度が多すぎる、あるいは少なすぎるのかは、結局多くのプログラミング指針と同じく勘と経験が必要になる。
  • Unix哲学とは、最大テキストセグメントサイズが64KiBだった16ビットミニコンピュータで、強力な対話型プログラミング環境を得る方法を教える哲学だ。今の携帯電話で使うlibcは1MiBで16倍の大きさなので、少なくともlibcの90%はUnix哲学に反している。
    Lions bookやAPUEを読み、一方でpthreadsのマニュアルやANSI Cのsetlocale()仕様を読んだうえで、この両者が同じ哲学を表していると結論づけることはできないように思える。Ayn RandがEpicurusと同じ哲学の代表者だと見るくらいの話で、どちらにも真剣に関わっていないという意味になる。

• この件で最も強く印象に残ったのは、JavaScriptコミュニティが依存関係に頼りすぎていたという点だった。
  11行のコードパッケージ https://en.wikipedia.org/wiki/Npm_left-pad_incident#Backgrou... の公開を取り消しただけなのに、なぜあれほど多くの非難が向けられたのか分からない。それによってどれほど大きな挫折が生じるかを完全には理解していなかった、という点も記事では述べている。
  NPMには利用統計がなく、GitHubでの活動もほとんどなかったため、ユーザー側からはパッケージ公開取り消しの影響を把握できなかった。根本原因はakoculuがパッケージを取り下げたことではなく、依存関係の過剰、npmのポリシー、そしてコードをキャッシュしたりベンダリングしたりしないビルドシステム側により近いと思う。

• Azer KoçuluはNPMエコシステムの災厄だったことなどない。誰もleft-padを使えと強制していなかったし、あれほど多くのプロジェクトに入り込んだ理由は、汚い推移的依存関係のせいだ。
  一方でJon Schlinkertは、こうしたマイクロライブラリを意図的に作り、広く使われているまともなプロジェクトであるhandlebars-helpersに入れておきながら、実際に使っているプロジェクトへ統合する意思はまったくなさそうに見える。釣られたいならhandlebars-helpersを使えばいいし、そうでないならそのライブラリを使うのをやめればいい。

  • そのうえ彼は、NPMが直接提供したスクリプトを実行しただけだ。マイクロパッケージの状況が馬鹿げていたのは確かだが、Azer Koçuluに落ち度はない。
    NPMが彼のパッケージを強制的に奪い、実行すれば危険なのが明らかなスクリプトを提供したことが問題だった。Azer Koçuluが非難されたこと自体が滑稽だ。
    Jon Schlinkertは典型的なマーケティング型の迷惑人物に見えるし、個人的にはNPMとGithubから禁止されるべきだと思う。

• kikパッケージのバージョン履歴がおかしい。9年前にセキュリティ用の占有パッケージに置き換えられている: https://www.npmjs.com/package/kik?activeTab=versions

  • 最大の皮肉は、Kikがあれほど切望していたkikパッケージが、結局のところ実質的には何でもなかったという点だ。
    Kikは不注意で、かなり醜悪な会社だと分かった。暗号資産関連の論争もあったが、記憶に残っている核心は、Kikでポルノ、とりわけ児童性的搾取コンテンツが横行していたという点で、このDarknet Diariesのエピソードでも扱われている: https://darknetdiaries.com/episode/93/
    そういう観点では、Azer Koçuluが彼らに失せろと言ったのはかなり痛快だ。
  • 結局、このすべては何でもないもののために起きたということなのだろう。

• left-padがパッケージだったこと自体がかなり面白い。ごく小さなユーティリティ関数を使うために、CDN、プロキシ、ビルドパイプラインなどを通じてどれほど多くのバイトが行き交ったのかと考えさせられる。
  既存の解決策を活用するのはよいことだが、文字列のパディングが必要なときに「たぶんこれ用のパッケージがあるだろう」と考えるのは、あまり理解できない。

  • 当時の議論の一部には、left-padのようなマイクロパッケージに際限なく依存していたWeb開発者たちに必要な警鐘だった、という流れがあった。
    人気を得てGitHub starsを集めるためにパッケージを公開する文化もあったし、NPMでインストールできるものを自分で実装すると「車輪の再発明」だと主張する開発者たちもいた。今でも、単純な機能であってもマイクロパッケージを好む開発者たちと多く仕事をしているが、彼らにとってそれは「メンテナンス削減」を意味する。
  • パッケージの元の実装 https://en.wikipedia.org/wiki/Npm_left-pad_incident も、望ましいO(n)ではなく O(n²) の動作になっていたように見える。
  • プロジェクト内で誰かがすでに書いたユーティリティ関数を持ってきて使うことと、エコシステム内で誰かがすでに公開したパッケージを持ってきて使うことのあいだに、質的な差が本当にそれほど大きいのかと思う。
    両者が当然同じではないにせよ、十分に発展したツールがあるなら、両者を似たように扱いたいと思うことが理解できないほど隔たっているわけではなさそうだ。
  • 今のAIも似たようなものではないかと思う。単純なWeb検索で解決できるプロンプトがどれほど多いことか。
    コピー＆ペーストに一段階足しただけだ。
  • コード再利用の最大限の誇示であり、コピー＆ペーストは敗者のすることだ。

• 「NPM側には開発者を見下す全般的な態度が見られ、それが一連の不合理な判断を生み、最終的にすべてのコストを私のせいにすることになった」というくだりがあるが、NPMはこの事件の後もあまり学ばなかったように思う。

• この事件は起きてよかった。名前の先取りは実際の問題であり、曖昧な場合はユーザーが最も驚かずに済むほうを選ぶべきだ。
  利用統計がなかったことも大きな問題だったし、単に公開取り消しできてしまったことも大きな問題だった。インフラが、主張の強い個人が作った些細な10行のコードに依存していることも、当時も今も実際の問題だ。この状況で本当に誰かに責任があるとは言いにくく、誰も誰かに借りがあるわけではないが、誰もが学ぶことはできる。

• top 10入りする npm パッケージをいくつか保守している立場から見ると、この記事は完全に筋が通っている
  ある時点から、NPM はコミュニティと協力しなくなった。Microsoft による買収でそれが固定化されたが、ずっと前から明らかだった
  npm の運営方法には多くのひび割れがあり、コミュニティやメインラインの Node チームとも十分に協力しておらず、商業的な持続可能性へ向けた強引な押し進め方は非常に不快で高圧的に感じられた。チームメンバーの何人かにも、やや荒っぽい評判があった
  Oakland のオフィスを訪れたこともあるが、かなり興味深いやり取りがあり、特に好意的なものではなかった。ただ、詳しい内容は伏せておく
  当時、公開取り消しの穴はよく知られていた。誰もが left-pad がインターネットを壊したと非難したが、その全体を深刻に誤って管理した npm の責任を問う人はほとんどいなかった
  記憶が正しければ、npm は保守者の意思に反してパッケージを強制的に復旧した。これは良く見ても、彼らが仕えると主張していた人々との断絶であり、悪く見れば法的にも疑わしい。その直後からプラットフォームの悪用にもあまり気を払わなくなり、core.js の広告スパムのようなことが起き、標準や互換性などの面でもコミュニティときちんと協力しなかった
  npm@5 リリースは惨事だった。パッケージロックファイルの導入はこれ以上悪くなりようがないほどで、記憶では次の Node.js メジャーリリースに合わせて出そうという圧力があった。Node チームは npm の準備が整うのを待たなかったように感じたが、npm が営利企業である、あるいは少なくともそう振る舞っていたことを考えれば、それはむしろ良いことだったと思う
  終わりのない致命的バグが続いていた時期のコミュニティ対応、圧力をかけるコミュニティを恥じ入らせようとする態度、敬虔ぶった姿勢は、npm がもはや自由・オープンソースソフトウェアの代弁者ではなかったことの証拠だった。left-pad がその前だったか後だったかは覚えていないが、頭の中ではエコシステムが長く衰退していく一つの流れとして残っている
  今では npm パッケージは、些細な作業をする小さなパッケージ群のミームになっており、誰もが嘲笑している。振り返れば最善ではなかったかもしれない。だが文脈が重要だ。npm は、新しく台頭していた人気技術のための、最初の非常に使いやすいパッケージマネージャであり、ほぼ完全にコミュニティによって管理され、検索システムも優れていて、GitHub の「ソーシャルコーディング」の精神とも密接に統合されていた
  Node の初期に存在しており、ES5 すらなかった時代で、var と prototype を使っていた頃だった。JavaScript のベストプラクティスもまだ確立されておらず、Joyent が Node.js をコミュニティに引き渡す前で、io.js フォークや Node 0.10/0.12 の長い停滞から抜け出す前でもあった
  誰も最善のやり方を知らなかった
  筆者のことは完全に理解できる。セキュリティの観点では、left-pad が起きたことに本当に感謝している。筆者の意図がそうでなかったとしても、自分たちが仕えると主張するコミュニティから切り離された 企業の利害に依存するとどのようなリスクが生じるのかを、人々にはっきり示した。サプライチェーンセキュリティや冗長性などに関する多くの議論を始め、長期的には業界を少し良くした

  • プログラミング言語向けの最初のパッケージマネージャでもなかったし、その程度に小さなパッケージが愚かだという点は、すでに多くの人が指摘していた
    npm、そして JavaScript 全般は、主に 流行の犠牲者だ