ハクソク

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

Left-Pad（2024）

2025年6月11日原文(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を追加するのは避けたいよね。特にクライアントコードでこれが起こると、重複したコードをブラウザに送ることになるし。

Hacker Newsで議論の続きを見る