npm周りでごたごたがありました。その前にはCocoaPodの問題もありました。その前にはGemの話も話題になりましたよね。
うんこれ。2年ぐらい前にnode.jsで開発していた時にも、node.jsのnpmのエコシステムいつか破綻するよなぁって思ってた。で、去年cURL as DSL作ったんだよね。Rubyのコード生成はまだないけどね。 https://t.co/1C0yw0KPib
— 渋川よしき (@shibu_jp) March 6, 2016
上記のツイートはgemに絡んでのツイートであって、コンテキストはnpmではなかったのだけど、なんか予言めいたツイートに見えちゃったのかもしれないけど偶然です。ここまで、いくつかの文化の変化がありました。
- SourceForgeやCodeplex、Google Codeのような、プロジェクトが唯一の名前空間という世界があったが(今もないわけではない)、GitHubやBitbucketのような、個人や組織が名前空間としてあって、その中で自由に作り放題の世界ができた。
- 地道にパッチを送って、信用貯金を得てコミット権を得るという文化から、どんどんプロジェクトを作って、フォークしてPull Requestで開発を行っていく文化になった。
- かつてライブラリは、システムにインストールするものだったが、node.jsがプロジェクトごとにローカルにライブラリ庫を持てるようにした。Pythonはvirtualenvなどの後付の仕組みでそれを実現していたが、それが標準になった。プロジェクト間のコンフリクトを恐れずに気軽にダウンロードできるようになった。
新しいことを始めたり、コードを改善する上での敷居がどんどん低くなって、コードを書く自由が飛躍的に高まりました。今回起きたnpm、CocoaPod、Gemの話はこれらの流れとは逆行する話です。作る自由というのは壊す自由と表裏一体です。変更やアップロードが取り消したりすることができなければ、作るのにみんな慎重になります。無茶できるのは、セーフティネットがあるからです。そういう意味で、「unpublishを禁止しよう」というのはちょっと違うかなぁと思います。それでは防ぐことはできません。
作者が癇癪を起こしてパッケージを消すという行為を防げるパッケージ管理システムは存在しないよね。unpublishを否定すればって書いてあるまとめ記事あったけど、中身を空にしてuploadされたらどうしようもない。
— 渋川よしき (@shibu_jp) March 23, 2016
壊れたアップロードもできないように制約をかけるべきか？マイナーバージョンアップでは、使われているすべてのパッケージで壊れないかを自動テストすべきか？というのを考えていっても、どんどん不自由になるだけです。
ちなみに、npmの対応を問題視している人もいますが、たぶん運営側になったらこのような対応をせざるを得ないかなって思います。全世界から使われるサービスで、「この国のこの法律に反しているんだけど」って言われた時にどこまで対応すべきか、無視すべきか、そこをきっちりガイドライン化できる人はたぶんいない。自分の国の著作権の扱いだけでもみんな頭を抱えている状態ですし、法的アクションを起こした人優先にせざるを得ないかなぁと思います。そうでなければnpm社が潰される可能性もゼロではないし、npm全体のエコシステムがまるごと潰されるよりは、指摘があったトカゲの尻尾を切り離す方が全体の保持になると思いますし。
The npm Blog − kik, left-pad, and npmなるほど。そもそも名前に関する紛争解決ガイドラインがあって、semverを使ってユーザーに負担にならないように名前を移管することが推奨されてるのか
2016/03/24 14:15
Github社だって、指摘があったらリポジトリをクローズします。知人がこれをされたことがあるのですが、反論の余地は与えられなかったとのこと。ここに消えていったリポジトリの墓標があります。他の知人で、Bitbucketでリポジトリをクローズされた人もいます。まあこれはプライベートリポジトリが無制限になった時にエロ動画をたくさんアップしたという事案なのでアレですが・・・
使う側での防衛方法としては、リスクを恐れてgithubやnpmの使用をやめる、というのはご自由にどうぞ、と思いますが、現実的な落とし所は、きちんと信頼できる開発元のライブラリを使いましょう、以上のものはないかな、と思います。
