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の使用をやめる、というのはご自由にどうぞ、と思いますが、現実的な落とし所は、きちんと信頼できる開発元のライブラリを使いましょう、以上のものはないかな、と思います。
ソフトウェアの世界はこれまで何度も螺旋を描いてきた
ソフトウエアの進化って一方方向ではないんですよね。いろいろな方向を模索しながら発展しています。何かがブームになったら、そちらばっかり見ちゃう人がいるんですが、かならず揺り返しが来るものだと思っています。
- コンパイル時に静的に決定する処理のフロー(関数呼び出し)に、実行時に変更可能という柔軟性が加わった(ポリモーフィズム)
- かと思いきや、JITの技術により、動的なコードを静的化して高速化する逆方向の進化もあった
- マシンスペックが上がったので、コードの速度よりも書きやすさ！LLブームが到来！
- かと思いきや、エラーチェックの書きやすさやコード補完のメリットも見直されて、TypeScriptやGoが人気に。PythonやRubyも型アノテーションを導入
- 時代は仮想化！複数のサーバを1つの物理環境にまとめたり、ハードの故障でもイメージを移せば即座に復旧！
- かと思いきや、そこまで完全に仮想化しなくてもいいじゃんね？カーネルの機能を使って名前空間だけ分けたDockerの方が高速で容量喰わなくていいよね？
- AWS！クラウド！プライベートサーバは時代遅れ！データセンターは自前で持つ時代じゃないよね？
- かと思いきや、やっぱりコストを考えると、大規模なところは自前でサーバ運用した方が安上がりだよね。Dropboxとか。
他にも似たようなものはいろんなところにあると思います。デスクトップGUIは捨てたはずなのに、ブラウザ上でMVCとは・・みたいなとか。とはいっても、逆向きの流れが来た時も、前の流れを否定するだけのものではなくて、前のメリットも取り入れた新しいソリューションになっているはずです。
そういう意味で、時代の最先端を追いかけ続けなくてもいいかなって思っています。新しい物が次々と出てきて、覚えたことが無駄になる、みたいに言われますが、僕の感覚だと「あ、また戻ってきた」という感じ。新しいけどローテク(技術的には大したことがない)なものよりも、古くてもすごい技術というのを持つ方が、生存確率は上がると思っています。僕の経験上も、新しくなくても、じっくり学んだものの方が役に立っていますし、メリットがあるすごい技術なら、いつか必ずそこに戻ってくるはずですし、無駄にはならないはず。
まあ癇癪を起こす自由も尊重されるべきだと思う
— 渋川よしき (@shibu_jp) March 23, 2016
