この手の連載を書く時には,ネットを歩き回ることは良いネタ探しになります。

 特に,間違ったオープンソース論や分析を見ていると,「ここはつっこんでおかねば」と思います。とは言え,自分の雑文と違い名のあるメディアでの連載ですから,いかに間違いだとは言え個人攻撃に走るのは間違いであるだけではなく危険です。ましてや,間違いではなくて「単なる見解の違い」である場合,振り上げた拳を自分の頭に落としてしまうことにもなりません。

 ですから,直接的に「○○さんの××という主張はおかしい」という文章を書くのは良いこととは言えません。「おかしい」と感じた部分だけを拾い上げ,そのエッセンスについてつっこむべきです。今回は,某所で拾った「企業でオープンソースを使うことはうしろめたいと考えられているのではないか」ということについて考えたいと思います。

企業で使われるオープンソースの現状

 今日,オープンソースなソフトウエアをまったく使っていない企業は,なかなか見つからないんじゃないかと思います。非IT系の企業であっても,大抵何らかの形でオープンソースとかかわりはあるんじゃないでしょうか。もちろんアンケートを取った時に「あなたの会社ではオープンソースを使っていますか」と問われれば,「いいえ」と回答するところは少なくないでしょう。ただ,その「いいえ」の中のかなりの部分は「意識して使っていない」というだけだと思います。極端な話,組み込みシステムのものも含めれば,かなりのところまで浸透しています*1。あるいは,「レンタルサーバー」といった形で使われているものもあるでしょう。

 具体的なデータについては,あちこちに調査結果がありますから,そちらを探して読まれることをお勧めします。国内のもの国外のもの,新しいもの古いものいろいろありますので,それらを比較してみるのも面白いと思います。*2

 大雑把にどんなものが使われているかと言えば,サーバーのOS(LinuxやBSD)であったり,サーバー上の基本ソフト(Apacheやlighttpd, PostfixあるいはMySQLやPostgreSQL)であったり,CMSやblogだったりが主でしょう。あるいはOpenJDKだったりRuby on Railsだったりするかも知れません。もっと先進的なところだと,CRMやERPと言った業務アプリケーションなのかも知れません。

 こういったソフトウエアの開発主体を見てみましょう。

名称 開発主体 ウェブサイト
Linux The Linux Foundation http://www.linux-foundation.org/
FreeBSD The FreeBSD Project http://www.freebsd.org/
NetBSD The NetBSD Foundation http://www.netbsd.org/
OpenBSD The OpenBSD Foundation http://www.openbsd.org/
Apache Apache Software Foundation http://www.apache.org/
Postfix Wietse Venema (IBM) http://www.postfix.org/
MySQL Sun Microsystems http://www.mysql.com/
PostgreSQL PostgreSQL Global Development Group http://www.postgresql.org/
Java Sun Microsystems http://java.sun.com/
FireFox Mozilla Foundation http://www.mozilla.org/

 ここに挙げたのは,よく名前が知られていて明確に組織があるもの(の一部)です。この他にもコミュニティ主導のものはたくさんあります。また,ここにある「組織」も実体はコミュニティなものもあります。

*1 携帯電話やAV機器でLinuxを使っているものは少なくありません。MacOS Xのかなりの部分がオープンソース由来のコードです。もちろんFirefoxやOpenOffice.orgもオープンソースですね。

*2 例えばこんな調査があります。
http://itpro.nikkeibp.co.jp/article/NEWS/20060217/229632/

企業で使われるオープンソースの条件

 こうやって挙げられるものは様々あると思いますが,大抵は前回までに書いているような,品質や機能に一定以上の評価が与えられている,「定番」ソフトウエアであるのが普通です。よほど技術に自信があってキワモノ好きの会社でない限り,「定番」でないソフトウエアを選択することはまずありません。

 企業にとって「定番」であることには意味があります。具体的にいくつか挙げてみると,

  • 機能や品質に定評がある
  • 情報の入手がしやすい
  • サポートしている業者が多い
  • 技術者の確保がしやすい
  • ディストリビューションに最初から入っていることが多い

     などがあると思います。冷静に企業の都合を考えてみれば,どれも一々納得の行くことだと思います。つまり,企業がソフトウエアに期待する要件と「定番」であることは,だいたい一致しているわけです。

     かつて,オープンソースがまだ企業に普及していなかった頃,オープンソースには信用がありませんでした。もっと正確に言えば,オープンソースに信用がなかったため,オープンソースが企業では使われなかったのです。企業でのソフトウエアの導入は,一部の例外を除けば実用性を期待するわけですから,実用となった実績に乏しいものはいくら評判が良くても使えません。その制約を突破することができたものが,少なくともハッカー同志では信用のあった「定番」ソフトウエアだったわけです。

     「定番」となったソフトウエアは,様々な生存競争を勝ち抜いて来たという実績の結果だというのは,前回までにお話しましたが,それらには共通する特徴があります。それは何かと言えば,色々な意味での「安定感」です。例えば,

  • 仕様が安定している
    改良されても今までの延長上であることが期待されます
  • 品質が安定している
    虫が少ないとかドキュメントが整備されているとかです
  • 供給が安定している
    プロジェクトが勝手に終わったりしない

     というようなことです。安定感のあるソフトウエアには安心感があります。それを早く獲得したソフトウエアが,広く使われるようになるわけですが,この「安心感」があるということは,企業が採用する時にはかなり優先度の高いファクターです。

     そしてこの中で一番重要な「安定感」は,最後に挙げた「供給が安定している」ということです。プロジェクトが続いていれば,多少品質が低いことがあっても改善されることが期待できますし,長く続いたプロジェクトであれば仕様も安定しているでしょう。また,今使っているソフトウエアから他のソフトウエアに移行することは,かなりのコストとリスクのあることですから,多少何かが起きたくらいでは移行したくはないものです。

     供給を安定させるためには,「開発主体」が安定していることが求められます。どんなに優れたソフトウエアであっても,個人的モチベーションや好奇心だけで作られたものが定番化しにくいのはそのためです。もちろんプロジェクトの最初は個人的なモチベーションだけでも構いませんが,なるべく早い時期にそういった「個人的モチベーション」から離れる必要があります。前節で挙げたソフトウエアはどれも有名どころの定番ですが,明確に組織があるものです。これ以外でも定番として使われるものは大抵組織や企業,またしっかりしたコミュニティのあるものです。つまり,既にしっかりエコシステムができているということです。