エコシステムの適切なサイズとコンパクト化
去年の終わり頃に気になる記事がいくつかありました。
去年の12月に行われたYAPC::Hokkaido 2016 SAPPOROでのsyohexによる発表資料も、同じようなテーマとして気になりました。
実際のところそれぞれのプロジェクトがどうなのかはよく知らないので深くは触れられませんが、一般論としては気になっているのは、最近のOSSプロダクトは特定プロダクトが1個だけで独立しているわけではなく、その周囲に複数のサブプロジェクトなりエコシステムが作られやすいという点です。それはモジュールであったりプラグインであったりパッケージであったり、テーマのようなものも含まれるかもしれません。
そのような、サブプロジェクトによる大きなエコシステムを作っていく流れは、規模が大きくなっていく過程では非常に有益です。メインプロダクトの作者が面倒を見られる大きさには限界があり、そのようなコントロールを積極的に行わなくても自律的に動くサブプロジェクトとして機能拡張ができる、ということは、そのプロダクトの開発者・利用者両方にとってメリットになります。
ですが、いったん活発に拡大していく時期が過ぎ去り、プロダクトの発展が停滞し始めてしまうと、メリットであったはずのものがそのままデメリットとして機能してしまうおそれがあります。そもそも作者がコントロールしなくて済むはずのものだったのに、いったんサブプロジェクトを利用するものが増えてしまうと、誰かが責任を持ってコントロールしなければいけなくなってしまう。下手に放置すると、そこに依存するいろんなものが壊れ始めてしまう。その流れに抗うべくいくつかのサブプロジェクトに手を差し伸べた人も、気をつけないと消耗してしまい、無理に手を出さなければ保守できたはずだったものまで巻き込んで放棄せざるを状態になってしまうのは不幸なことです。そしてある程度以上壊れてしまうと、部分的にではあれ、一気に衰退に向かってしまう危険性もあります。
そもそもの問題として、ボランタリーなエコシステムが拡大を続けることを期待することは危険すぎます。拡大とは言わずとも、一定規模を長期間に渡って維持し続けることすら簡単ではないでしょう。ある程度以上大きくなったプロジェクトの場合、どこかの時点で「撤退戦」のようなことを避けることは難しいのかもしれません。
そのような持続可能なプロジェクトを目指すことは、都市計画における「コンパクトシティ」に似ているような気もします。一方、コンパクトシティの実現については、さまざまな困難が語られます。
都市計画とOSSプロジェクトでは、共通要素よりは相違点が多そうですが、「多くの人々により自由に拡大されてきたものを人為的な制限により縮小させる」ことの難しさという意味では似ているところがありそうです。とはいえOSSについても、現状維持にコストがかかり、そのコストを負担する人が減少してきた場合、何かしらの方策で規模の縮小を迫られることになるのではないでしょうか。
新年早々縁起の良い話ではないですし、具体的な対応策はないのですが、あるいはこういうタイミングだからこそ考える時間を取れるということもあるので、改めて書いておきます。
