- left-pad事件は、オープンソースコミュニティとNPM、そして企業の間にあるルールと価値観の衝突を示す代表的な事例である
- パッケージ削除の決定は、論理や怒り、貪欲さによるものではなく、誠実さと内面的な原則から生まれた行動である
- NPMがKik Messengerの要求に屈し、自らのルールを破った状況で、筆者はすべてのパッケージを削除することを選んだ
- 事件後、オープンソースへの情熱が変化し、事業、マーケティング、チーム運営など新しい分野へと関心が移っていった
- left-pad事件は、開発者やスタートアップ業界にオープンソースの本質と意思決定の複雑さを改めて考えさせるきっかけとなった
事件の背景と決断
- left-pad事件から8年が過ぎた時点で、筆者は個人的な経験と思いを共有している
- 事件当時、ほとんどの時間を電波の届かない自然の中で過ごしながら自己を見つめ直しており、パッケージ削除の決定もその過程で下した選択だった
- この決断は、論理的判断や怒り、貪欲さではなく、自らの内面的な原則、つまり「NPMが自分たちのルールを破るなら、自分の全パッケージも削除されるべきだ」という信念から始まった
- 厳格な「ルール主義者」というよりは、ルールの精神そのものをより重視する姿勢だった
- Kik Messengerのような企業がオープンソースコミュニティに脅威を与え、力を行使する状況で、NPMは自ら定めたルールを無視し、企業利益を優先した
NPMとコミュニティの対立構造
- 筆者はKikの脅しを恐れてはいなかったが、NPMはKikを失うことを恐れていた
- この事件を単に「怒った男が大企業に抵抗した」と解釈するのは、事件の文脈や時間的な流れ、決断の重みを見落とした単純化された見方である
- NPM側にとっても突然あるいは予想外の出来事ではなかったにもかかわらず、全体として開発者に高圧的な態度を取り、一連の整合しない判断によってすべての責任を筆者に転嫁した
パッケージ構造と影響
- 筆者のオープンソース活動の大半はUnix哲学に従って小さな役割に分かれており、350個以上のパッケージで構成されていた
- 表面的には利用の痕跡がほとんどなかったが、NPMが利用統計を公開していなかったため影響範囲を把握できない状況だった
- ユーザーはパッケージ削除の実際の波及効果を知る手段がなく、NPMも影響調査や無分別な削除による問題の防止に努力しなかった
8年後の変化と成長
- left-pad事件の数か月後に本業を辞めてアメリカを離れ、モロッコ、ヨルダン、トルコ、インドネシアなど新しい環境で自分自身の道を探していった
- オープンソースへの情熱が断ち切られる死のような瞬間と、新しい関心事として再び生まれ変わる瞬間を経験した
- 現在は事業、マーケティング、会社やチームの運営など多様な分野に、プログラミングと同じ情熱で取り組んでいる
- 人生は続いていくというメッセージを伝えつつ、left-pad事件は自由な決断とコミュニティの価値、そして意思決定プロセスの複雑さを振り返るきっかけとして残っている
2件のコメント
影響の大きかった事件ですが、パッケージ作者の文章を読まなくても、彼個人の過ちよりも、そこに関わった企業やシステム側の問題のほうが大きかったと思います。
Hacker Newsの意見
正直に言うと、このブログ記事の半分は何を言っているのかよく分からず、何か文脈を取り逃している気がするが、「left pad guy」が出来事を整理している点は気に入っている。
ただ、次のような主張には少し違和感がある。
left-pad の後で、その理由をはっきり理解した。
細かい話だが、
今私がスマートフォンで使っている libc は 1MiB あり、伝統的な Unix の16倍も大きい。
少なくとも libc の90%は Unix 哲学に反しているという結論になる。
Lions Book や APUE を読んだ後で pthreads のマニュアルや ANSI C の setlocale() 仕様を見ると、まったく別の哲学だと分かる。
異なる哲学なのに同じだと見なすなら、その二つの哲学のどちらにも真剣に共感していない証拠だ。
なぜなら「one thing」の意味が明確でないため、実際には何の助けにもならず議論だけを生むからだ。
Eclipse も「IDEという一つのこと」だけをしていると言えるが、それが Unix 開発者たちの意図したものではない。
11行の関数しかないライブラリを作れという意味でもない。
本当の助言は「プログラムやライブラリが多すぎることも少なすぎることもしないようにしよう」程度であるべきだ。
どこまでが多くてどこまでが少ないかを判断するのは、結局のところ経験と感覚の問題だ。
この文章を書いてくれた akoculu に感謝したい。
私はこの事件が、JavaScript コミュニティ、すなわち依存関係に依存しすぎたエコシステムの明確な事例だと思う。
なぜ多くの人がそこまで彼を責めるのか分からない。
彼は11行のコードしかないパッケージを unpublish しただけで、その副作用を完全には予測できなかっただろう。
著者自身も記事でこう述べている。
kik パッケージのバージョン履歴が妙だ。
9年前にセキュリティホールディングパッケージへ置き換えられている。
kik パッケージのバージョン履歴
この件で最大の皮肉は kik パッケージだ。
kik がそこまでして欲しがっていた kik パッケージは、結局まったく役に立っていない。
しかも Kik という会社自体が、不注意で問題の多い企業だったことが明らかになっている。
暗号資産をめぐる論争もあったし、児童ポルノなどの流通プラットフォームとして半ば公然と語られていた会社でもある。
参考: Darknet Diaries エピソード93
だから Azer Koçulu が Kik にきっぱりと拒否した点は、むしろ痛快ですらある。
結局この一連の出来事は……結局何の意味もなかった、ということ？
left-pad がパッケージとして存在していること自体がかなり面白い。
文字列パディング関数ひとつのために、CDN、プロキシ、ビルドパイプラインなどを通じて膨大なバイトが移動している。
既存のソリューションをうまく活用することには同意するが、単に文字列の前を埋める関数について「たぶんパッケージがあるだろう」と考えるようになった状況は理解しがたい。
当時の議論の一部は、Web 開発者によるマイクロパッケージへの盲目的な執着に警鐘を鳴らすきっかけになった。
人気や GitHub star のためにパッケージをリリースする文化もあった。
その一方で、npm でインストールできるものならどんな関数でも自分では実装したがらない文化も強かった。
今一緒に働いている開発者の多くも、いまだに単純なパッケージを好むことが多い。
彼らにとっては「保守負担が減る」という理屈だ。
なんとも皮肉な現実だ。
パッケージの元の実装もまた、O(n) ではなく O(n^2) の非効率な処理を引き起こしていたようだ。
Wiki 参照
他人のプロジェクト内のユーティリティ関数を参考にすることと、エコシステム全体にすでに広まっているパッケージを使うことの間に、品質上の大きな差はあるだろうか。
同じではないが、十分に発達したツール群を持つ環境では、この二つのアプローチは実際それほど遠いものではないと思う。
可能な限りコード再利用を追求する風潮、copy-paste は時代遅れのやり方だという強迫観念。
これって AI と似た状況ではないだろうか？
単純な検索で解ける問題を、無数のプロンプトとともに AI にまた尋ねる現実。
C&P に不要な段階を一つ余分に載せた構造だ。
Unix 哲学は「一つのことをうまくやる」ことだ。
left-pad は二つ目の条件（うまくやる）を満たしていなかった。
これほど多くのプロジェクトが素朴な実装をそのまま使っていたことに驚いた。
より最適化された実装は、より速く、より小さくできるはずだ。
JavaScript 文化には詳しくないが、npm ダウンロード数を競う風潮があったように記憶している。
left-pad は週140万ダウンロード、is-even は16万ダウンロード。
冗談半分で、あるいはライブラリの人気指標を上げるために、マイクロパッケージを依存関係に追加する人もいた。
React ベースの有名ライブラリの内部に is-even のようなパッケージを入れることに反対する声もあった。
「自分で書けるコードでも必ず持ってこい」というような厳格な原則があったからだ。
関連ストーリー: is-odd パッケージが1週間で300万回インストールされた理由
「非素朴な実装(nonnaive implementation)」の例が気になる。
npm の人気パッケージメンテナーだ。
本当に共感できる。
npm はある時点からコミュニティ協業から離れ始めた。
Microsoft に買収されてさらに強固になったが、その前から兆候は多かった。
npm のさまざまな運営方法、コミュニティや Node チームと非協力的だった態度、商業化にばかり注力した姿勢、一部メンバーの評判など、いろいろと引っかかる点が多かった。
Oakland のオフィスを訪れた記憶があるが、その日のやり取りはあまりよいものではなかったので、詳しくは話さない。
unpublish の欠陥は当時みんなが認識していた問題だった。
誰もが「left-pad がインターネットを壊した」といった調子で著者だけを責めたが、実際には npm の杜撰な運営の問題のほうが大きかったと思う。
記憶が正しければ、メンテナー本人の意思に反してパッケージを強制的に復旧させており、これは npm が自分たちが代弁すると主張するコミュニティから完全に乖離した措置だった（少なくとも法的にも奇妙だ）。
その後 npm は abuse やスパムなどの管理にもほとんど関心を示さず（core.js の広告スパムなど）、コミュニティとの標準や互換性の議論もほとんど行わなかった。
npm@5 のリリースも大失敗で、パッケージロックファイルの導入も大混乱だった。
（Node チームが npm の準備を待たずにリリースしたのは、むしろよい判断だったと思う。）
その時期のコミュニティとの対話は、大きなバグ、コミュニティへの責任転嫁、高圧的な態度などでめちゃくちゃだった。
これは npm がもはやオープンソース精神の代弁者ではなくなっていたことの証拠だ。
left-pad がその前だったのか後だったのか記憶が曖昧だが、当時エコシステム全体が長期的な停滞と混乱の時期にあった。
npm パッケージは些細な関数でも独立パッケージ（ミーム）のように見られがちだが、文脈を考えれば、npm は emergent popular technology（新たに台頭した人気技術）に対する最初のアクセスしやすいパッケージマネージャーであり、コミュニティ主導で運営され、GitHub とも有機的に統合されたシステムだった。
Node の初期（ES5 もなく、
varやprototypeを使っていた時代）、Joyent が Node.js をコミュニティに引き渡す前、Io.js フォークや Node 0.10/0.12 の長期停滞期以前のことだった。誰もが何がベストプラクティスなのかをまだよく分かっていなかった時代だ。
著者の立場には本当に共感する。
セキュリティの観点から見ると、left-pad 事件は、意図せずしてエコシステム内の企業と共同体が分離している現実、そしてサプライチェーンセキュリティへの大きな目覚めをもたらした事件だった。
冗長性の強化とセキュリティに関する重要な議論を促した。
結果として業界がよりよくなるきっかけだったと思う。
久しぶりに読み返すと興味深い。
npm はどの言語においても最初のパッケージマネージャーではなかったし、こうした小さすぎるパッケージが多いことについては、すでに多くの人が警告していた。
npm と JS エコシステム全体がトレンドの犠牲になったのだと思う。
left-pad 当時の関連議論
Hacker Newsの議論
なぜ Java には Apache Commons や Google Guava のような信頼できるユーティリティライブラリがあるのに、JS にはそういうものがないのだろう？
JavaScript にも Lodash のような信頼されるユーティリティライブラリは存在する。過去に比べれば、その大半の機能は今では標準ライブラリに取り込まれている。
実際、Lodash は left-pad 事件の3か月前から pad/padStart/padEnd 機能を提供していた。
Lodash pad ドキュメント
最も重要な原因は文化であり、その次に、よく設計された標準ライブラリ、そして300個を超える無意味なパッケージを依存関係にねじ込むのを防ぐツールの有無だと思う。
Maven は本当によく設計されたツールで（皮肉にもいつも悪口を言われるが）、Java が成功した秘密の要因だ。
npm のような商業的妥協がないのは、Java には十分に支援された非営利・コミュニティ基盤の Apache Foundation があるからだ（こうした構造は非常にまれで、Java の複雑な法的歴史のおかげで生まれた幸運な結果でもある）。
（JS にも優れたライブラリは多い。問題は、パッケージ管理が過度に中央集権的で、管理が杜撰だったことだ。）
Google Guava は lodash により近く、left-pad とは違う。
昔は Jquery や Underscore のようなライブラリがその役割を果たしていた。
ビルドに必要なすべての依存関係を社内でミラーしていない会社が多いのは本当に不思議に感じる。
ビルド工程全体をオフラインでクリーンビルドできるべきで、ダウンロードキャッシュだけに頼るのは運任せだ。
私のプロジェクトでは常に dependencies を内部にベンダリングしている。
予測可能で、オフラインでもビルド可能で、ストレージコストも安い。