ハクソク

世界を動かす技術を、日本語で。

Left-Pad（2024）

348日前原文(azerkoculu.com)

概要

left-pad事件 から8年が経過。 当時の経緯や心境を 振り返り。 NPMやKik Messengerとのやりとり 背景説明。 事件後の人生や価値観の 変化。 オープンソースへの思いと 今後の方向性。

left-pad事件を振り返って

  • left-pad事件 から8年経過、これまで話題を避けていた理由は実務への集中
  • 沈黙は金 という考えもあったが、事件が書籍などで語られるため詳細を共有
  • 2016年当時は毎週末、電波の届かない場所で キャンプ生活
  • パッケージ削除 の決断は論理や怒り、欲からでなく、自然の中での自己対話から生まれた直感
  • NPMが自らの規約 を破り、1つのパッケージを削除したことへの対応として「全て削除」を要求
  • ルールそのものよりも ルールの精神 を重視する立場
  • 文脈次第では「善意」でパッケージ削除要請もあり得るが、今回は Kik Messengerの圧力 が背景
  • Kik Messengerから「ドアを叩く」「アカウントを削除する」といった 威圧的な脅し
  • NPMはKikを恐れ、規約違反 を選択、コミュニティの魂より「高い」ものを優先
  • 自分自身はKikの脅しを恐れず、 NPMの選択 に失望
  • 多くの人が事件を「怒った男が企業に抗議」と単純化しがち
    • メールの時系列 を見ていない
    • 圧力下で信念を貫く経験がない
    • Al-Ghazali を読んでおらず、自由人の意思決定を理解していない
  • NPMには事前通知 し、猶予を与えた上での削除依頼
  • NPM側は自ら 一括削除スクリプト を提供
  • NPM内部には 開発者軽視 の態度があり、非合理な判断の連続、責任転嫁が発生
  • 自分のOSSは Unix哲学 に則り、1つの機能に特化した350以上のパッケージ
    • 表面的には利用者が少なく、NPMも 利用状況を把握せず
  • 影響範囲の調査 や配慮なく削除を進めたNPMの姿勢に疑問

事件後の人生と価値観の変化

  • left-pad事件後、 数ヶ月で退職し米国を離れる
  • モロッコ、ヨルダン、トルコ、インドネシア で1年間放浪
  • Lycian Way などのトレイルを歩き、誰も知らない新たなキャンプ地を発見
  • left-pad事件は「 死と再生」の体験、OSSへの情熱は消失し新たな価値観が誕生
  • 現在は ビジネス、マーケティング、組織運営 にも強い関心
  • 人生は続く、新たな情熱で前進

終わりに

  • 読者への感謝 の気持ち
  • left-pad事件を通じて得た 経験と成長

Hackerたちの意見

正直、このブログ記事の半分も理解できないって認めざるを得ない。なんか背景が足りない気がするけど、「left pad guy」がポストモーテムをやってるのはいいと思う。ただ、これが変な議論に感じるんだよね。> でも、NPMが俺のモジュールが広く使われているかどうか調べる時間を取らなかった理由がまだわからないし、何かを壊さずにアンパブリッシュを処理する方法を考えるべきだったんじゃないか。確かに、NPMのアンパブリッシュメカニズムは設計ミスだったけど、彼は会社の人たちが毎回誰かがアンパブリッシュするたびに手動で確認することを期待してたのかな？それはちょっと合理的じゃないと思う。NPMの会社はNPMのレジストリをキュレーションしてるわけじゃないし、公共サービスとしてホスティングしてるだけだしね。とはいえ、著者をあまり責めるつもりはないよ。もし彼が「left-pad事件」を引き起こさなかったら、他の誰かがそのうちやってたと思うし。NPMはより良いアンパブリッシュポリシーで問題を解決したし[0]、それで終わりだね。[0] https://docs.npmjs.com/policies/unpublish#packages-published...

└

背景については、https://en.wikipedia.org/wiki/Npm_left-pad_incidentを見てね。

└

2016年3月18日、npm, Inc.のCEOアイザック・Z・シュルーターは、Kik InteractiveとKoçuluの両方に対して、kikパッケージの所有権を手動でKik Interactiveに移転することを伝えた。 > Koçuluがnpm, Inc.の決定に失望を表明し、プラットフォームの一部でありたくないと述べた後、シュルーターは彼に273のモジュールを削除するためのコマンドを提供した。[9] Koçuluは2016年3月22日にそのコマンドを実行し、以前にリリースしたすべてのパッケージを削除した。著者は単にNPMが自分に指示したスクリプトを実行しただけで、後にNPMは自らの失敗を著者のせいにしたんだよね。

└

「このブログ記事の半分も理解できないって認めざるを得ない」 それは、君がまだアル・ガザリを読んでないからだよ。（この投稿の中で一番偉そうで自己重要感満載な部分だね）

left-padがパッケージであるっていうのは、ちょっと面白いよね。小さなユーティリティ関数を書くために、どれだけのバイトがCDNやプロキシ、ビルドパイプラインを通って流れたんだろう？既存のソリューションを活用するのは大賛成だけど、文字列をパディングする必要があって「お、これ用のパッケージがあるはず」って思うのは理解できないな。

└

最大限のコード再利用、コピペは負け組のやることだよ。

└

ムハ、ユニックス流。

└

パッケージの元の実装[1]は、望ましいO(n)ではなくO(n^2)の操作になってしまったようだね。[1] https://en.wikipedia.org/wiki/Npm_left-pad_incident

└

この議論の一部は、ウェブ開発者たちがleft-padのようなマイクロパッケージに頼りすぎていることへの警鐘だったと思う。人気やGitHubのスターのためにパッケージを公開する文化もあったし、NPMを通じてインストールできるものを実装するのは「車輪の再発明」だと主張する開発者もいた。今、俺はシンプルさに関係なくマイクロパッケージを好む開発者たちと一緒に働いてるけど、彼らにとっては「メンテナンスが少ない」って意味なんだよね。どういうことだろうね。

└

ほんと、プロジェクト内で誰かが既に書いたユーティリティ関数を使うのと、エコシステム内で誰かが公開したパッケージを使うのって、質的に何が違うの？明らかに同じことじゃないけど、十分に進んだツールがあれば、同じように扱いたいって思うのはそんなに遠いことなのかな？

└

今のAIって似てるよね？簡単なウェブ検索で解決できるプロンプトがどれだけあるか。コピー＆ペーストだけど、ちょっと手間がかかる感じ。

└

これが一番の理由だね。ライブラリ間の再利用が重要だから。10個のライブラリを使ってるとき、それぞれが自分のleftpadを追加するのは避けたいよね。特にクライアントコードでこれが起こると、重複したコードをブラウザに送ることになるし。

ちょっとしたことだけどね。> 「私のオープンソースの仕事はほとんどがUnixの哲学に従っていて、パッケージは一度に一つのことしかしないんだ。libcがUnixの哲学に反しているなんて言った人はいないよ。最近の例で言えば、systemdみたいに、コマンドやデーモンがやりすぎかどうか、あるいは組み合わせられないかっていう議論がある。」

└

逆に、left-padの騒動は、NPMのパッケージの細分化があまりにも小さくなりすぎて、パッケージのオーバーヘッドがそのシンプルさの利点を上回ってしまったことを示してるよね。

└

「ユニックス哲学」って、実は役に立たない哲学だと思う。むしろ役に立たないどころか、無駄なこともある。だって「一つのこと」って定義が曖昧だから、実際には何も生まれないし、ただ議論を呼ぶだけ。Eclipseが「一つのこと」をやってるって言えるかもしれないけど、IDEプラットフォームとしてね。でも、ユニックスの開発者たちがそれを意図してたとは思わない。ライブラリを11行の関数だけのものを書くために作ったとも思えない。実際のアドバイスは「プログラムやライブラリは、やりすぎず、やらなさすぎないようにすべき」って感じだよね。どれくらいがやりすぎか、やらなさすぎかはどうやって判断するの？多くのプログラミングガイドラインと同じように、結局はセンスと経験が必要なんだよ。

└

「一つのことをやる」の反対は、全部をやらなきゃいけないってことだよ。

└

誰もlibcがUnix哲学に反してるとは言ってないよ。たくさんの人がそう言ってるけどね。もしよかったら、今俺がそのことを提案してあげるよ。現代のlibcはUnix哲学に真っ向から反してる。昔のUnixはもっとシンプルなlibcを持ってて、多くの関数はただのシステムコールだった。今のlibcの一部はlibmみたいな別のライブラリに分けられたり、NSSや複雑なDNS解決フレームワークみたいなものは全く存在しなかったりする。

└

Unix哲学は、最大テキストセグメントサイズが64KiBの16ビットミニコンピュータで強力なインタラクティブプログラミング環境をどう作るかを教えてくれる。俺がこの携帯で使ってるlibcは1MiBで、16倍大きい。だから少なくともlibcの90％以上はUnix哲学に反してると思う。ライオンズの本やAPUEを読んで、一方でpthreadのマニュアルやsetlocale()のANSI C仕様を読んで、同じ哲学を表してるって結論に至る人がいるとは思えない。それは、アイン・ランドがエピクロスと同じ哲学の代表者だと思うようなもので、どちらにも真剣に向き合ってないことを示してるよ。

kikパッケージのバージョン履歴はちょっと変だね。9年前にセキュリティホールディングパッケージに置き換えられたんだ。[0] https://www.npmjs.com/package/kik?activeTab=versions

└

はは、結局、これ全部が…何もなかったってこと？

└

これが一番の皮肉だと思うんだ：kikパッケージ、彼らがどうしても欲しかったkikは、結局は大したことないものだった。しかも、Kikは無責任でかなりクズだった。彼らには暗号に関する論争もあったけど、私が覚えている主なことは、Kikがポルノ、特に児童ポルノの取引に関して問題が多いってこと。これについてはこのダークネットダイアリーズのエピソードで話されてるよ：https://darknetdiaries.com/episode/93/。だから、その観点から見ると、Azer Koçuluが彼らに「消えろ」って言ったのは、ちょっと嬉しいね。

ここにトップ10のnpmパッケージのメンテイナーがいるよ。これには完全に納得。どこかの時点でNPMはコミュニティとの協力をやめちゃったんだ。マイクロソフトの買収でそれが確定したけど、その前から明らかにおかしかった。npmの機能にはたくさんのひびが入っていて、コミュニティやメインラインのNodeチームともうまく協力できていなかったし、商業的な成功を目指す姿勢は本当に嫌な感じで強引だった。チームメンバーの評判もあまり良くなかったしね。確かオークランドのオフィスにも行ったことがあるけど、そこでのやり取りは…まあ、あまり良い印象じゃなかったな。公開解除の問題は当時よく知られていた。みんなleft-padのせいでインターネットが壊れたって責めてたけど、npmの管理不行き届きについては誰も責めなかった。記憶が正しければ、彼らはメンテイナーの意向に反してパッケージを強制的に復活させたんだ。これは、彼らが主張していた人々からの離脱で、最悪の場合は法的にも疑わしい。これ以降、彼らはプラットフォーム上の悪用についてあまり気にしなくなったし（core.jsの広告スパムとかね）、その後はコミュニティとのスタンダードや互換性についてもあまり協力しなかった。npm@5のリリースは大失敗だった。パッケージロックファイルの導入は最悪の結果になったし、次のNode.jsのメジャーリリースと同時に出すために急いでいたように思う（Nodeチームがnpmが準備できるのを待たなかった気がするけど、npmが営利企業、あるいは少なくともそう振る舞っていることを考えると、それは良いことだと思う）。その時期、無限に続く重大なバグと、コミュニティにプレッシャーをかけたことでの非難、そしてその神聖な態度は、npmがもはやFOSSの代理人ではないことを示すさらなる証拠だった。left-padがその前か後かは覚えてないけど、頭の中ではそれがエコシステムの長い衰退の一部だったと思ってる。npmのパッケージは今やミームだし、些細なタスクをこなす小さなパッケージが多くて、みんなそれを笑いものにしてる。振り返ってみると、あれがベストな選択だったとは言えないかも。でも、文脈が重要なんだよね。npmは新興の人気技術のための初めての非常にアクセスしやすいパッケージマネージャーで、ほぼ完全にコミュニティ管理されていて、クエリシステムも良くて、GitHubの「ソーシャルコーディング」の精神とも密接に統合されていた。Nodeのライフサイクルの初期に存在していて、ES5が利用可能になる前（まだvarやprototypeを使ってた！）、JavaScriptのベストプラクティスが本当に存在する前だった。Node.jsがJoyentからコミュニティに渡される前、Io.jsのフォークやNode 0.10/0.12の長い停滞からの脱出の前だった。誰もが物事を最適に行う方法を知らなかった。著者の気持ちは完全に理解できる。セキュリティの観点からは、left-padが起こったことに感謝してるよ。たとえそれが著者の意図ではなくても、企業の利益に依存することがコミュニティにどんなリスクをもたらすかを人々に強く意識させたから。サプライチェーンのセキュリティや冗長性について多くの会話が始まったし、それは難しいことだけど、長い目で見れば業界を少し良くしたと思う。良いフォローアップだね、こんなに長い間読んでなかったのに。

└

これはプログラミング言語のための最初のパッケージマネージャーじゃなかったし、あんな小さなパッケージの無意味さを指摘してた人もたくさんいたよ。npm（そして一般的にJS）は、主に流行の犠牲者だね。

npmでherokuのユーザー名を持ってたけど、公式のherokuウェブサイトからのリクエストで譲ったよ。

└

それめっちゃクールだね！何か報酬を求めた？短い「アイコニック」なユーザー名って結構レアだよね。

└

それに、herokuは「ドアを叩く」とか「アカウントを削除する」って脅してこないだろうね。

この事件を覚えてるよ。これが、僕がJSエコシステム全体に興味を失った理由の一つなんだ。

└

なんでこれがJSだけに関係してるの？例えば、俺がXYZって名前のPython/Rust/Goとかの公開パッケージを持ってて、後からXYZって会社が商標の問題でそのパッケージをリリースさせようとしたら、従わざるを得ないじゃん。そうなると、俺のパッケージ全部が同じ運命を辿るかもしれないし、それに依存してる人たちは大変なことになるよね。パッケージのサイズがここでどう関係するのか全然わからない。

ユニックス哲学は「一つのことをやって、それをうまくやる」ってことだよね。Left-Padはその二つ目を忘れちゃった。こんな単純な実装を使ってるプロジェクトがたくさんあるのは驚きだった。非単純な実装の方が速くて、ずっと小さいのに。

俺にとって、たくさんの会社がビルドの依存関係を全て内部でミラーリングしてないのがすごく不思議。クリーンビルドを完全にオフラインでできるべきだし、ダウンロードキャッシュに運を頼るべきじゃないよ。

al-Ghazaliの部分は、あまりにも傲慢で気取ってて、読む気が失せたよ。全然無理。