OSSコミュニティとの協調

OSSのコミュニティの力学と企業の力学。まったく別々の力学で動いているのだから、それを束ねることは難しいけれど、だからと言ってまったく協力できないと言うわけでもない。バザールのわっかの中に企業が入ってきても拒まれることはない。
OSSのどの分野の開発が進んで、どの分野の開発が進みにくいのか？
OSSは趣味で作っているんだから別に開発が進まなかろうが、必要としている人が必要としているときに開発すればいいので、ほっといてくれ、という立場もわからなくもない。しかし、その分野を誰かが開発しても自分は興味がないだろうが邪魔にはなるまい。といういささか消極的な立場になってしまうのだけど、そのスタンスで話を進める。
カーネル2.2のころLinusはSMPなんて興味がないのでやりたい人がやってくれみたいなことを言っていた。（大昔の話ですまん）スケーラビリティがどうだこうだというのは、自分のワークステーションではあんまり関係ない。そーゆー分野は必要としている企業が、がんがん開発してくれ。みたいなことである。
実際IBMをはじめとする大手ハードウェアベンダがLSE (Linux Scalability Effort) http://lse.sourceforge.net/ でいろいろ開発をした。企業にとってはLinuxをスケーラビリティの必要な分野に投入することは経済的なインセンティブがあるので自社内のOS専門家を多数投入してLinux開発を加速した。良く知られている例でいえば、カーネルのグローバルロックを徹底的に見直してより粒度の小さいロックにしたり、ロックそのものをなくしたりしている。IOスケジューリングについてもいろいろ改良を重ねた。そのような分野はコミュニティと言うより企業の得意としているところである。
PostgreSQLのカンファレンスに行って、コアメンバーとも親睦を深めた。PostgreSQLの実装が、わたしの個人的な印象ではあるけど、メモリの使い方が貧弱な感じがする。shared_buffersというデータベースサーバが利用する共用メモリバッファのサイズをしていするパラメータのデフォルト値が低すぎる。というような事を、あーだこーだ議論した。「最近のサーバなんかは4GBぐらい平気でつんでいるんだから、shared_buffersなんてパラメータなんかもう必要ないでしょう。あるだけメモリどんどん使うような実装にするべきっすよ。」「うーん」「ムーアの法則つうのはメモリがコンスタントに安くなる法則なんだから、メモリをいっぱい積んだとき、一切実装を変えないで自動的に速くなるような実装にするべきでしょう。そのためにshared_buffersみたいなメモリ利用を制限するパラメータはいかんですよ。いかん。意味ない。」「うーん」「だって、そうでしょう。性能でない。じゃあ、メモリを追加しよう。メモリ安いんですから」「うーん、でもコアチームのメンバのPCは貧弱だから、そーゆー実装をあんまり評価できないんですよねえ」
つまりそーゆー分野は企業がやればいいのである。
今までは、コミュニティと企業が相互補完関係を持って発展してきたのである。企業にとっても効率よく開発が進んで利益があった。
一方でOSSそのもののマーケティングなどは商用製品ではない以上誰かが統一的なイメージ戦略をもって推進するというようなことは原理的に不可能である。不可能ではあるが必要でないと言うことはない。OSSの価値を正しく利用者に届けると言う意味でのマーケティング活動は必要だと思うが個々の企業がばらばらにやっているというのも重複が発生し効率的ではない。そこで業界でOSDLのようなNPOを設立し共通の課題について議論し解決策を探ると言うことが重要になってくる。我国ではそれを日本OSS推進フォーラムという産官学の任意団体が行っている。別に日本OSS推進フォーラムだけがそのような活動をしているわけではなく、日本Linux協会とか似たような団体はいくつかある。
コミュニティから見れば勝手にやってねという感じかもしれないが、エコシステムとして、価値の創造のサイクルが加速することはコミュニティにとって悪いことではない。一つはビジネスとして持続可能なサイクルが生じれば、今まで仕事として評価されなかったものが、仕事として評価されるようになる。夜中のハックが、昼間の給与を稼ぐ手段となる。別に夜中に好きなことをやっているんでそれで満足だと言う人は別にそれでいいわけで、そーゆー人をとやかく言うつもりはない。自分の好きなことをやって給料が貰えるということはいいことだと思うのだけど、それはまあ人それぞれなので深くは突っ込まない。
OSSの価値や課題を整理して情報として伝えると言う作業は言うことは簡単だが実際はなかなか大変である。例えばOSSサポートがどうなっているかとかどのような課題があるかとかは、わかっているようでいて多くのユーザーにわかりやすい形で示されていなかったりする。OSSそのものの開発の仕組みとかコミュニティとかの原理をある程度理解していないとサポートがどのようになされるかというような点についても理解は難しい。各OSSの限界値での性能とか信頼性なども各社ばらばらの基準でやっていたりするが、そのような作業も実のところ無駄であるし、統一的な手順がないので他社が実施した評価と比較することができなかったりする。OSSなんだから評価手順やツールなどを共通化すれば無駄な作業も減るしコストも下がるしノウハウも共有できてみんなに得である。OSSだから協調しやすいという話である。商用ソフトの場合、ベンチマーク結果を共有するなんてことは、通常はライセンス上禁止されていたりするので、ほとんど不可能である。そのため、ベンダー提供の情報を鵜呑みにするしか方法がない。
OSSだからこそできる協調の仕組みを構築することがみなにとって利益になるという構図である。