オープンソースの現実、と若干の理想(下)

オープンソースは保守が得意? オープンソースが持続可能なプロセスであるためには顧客側の意識改革も必要だ。

はじめに

「本題は次回で」と書いたくせに一ヶ月以上も経ってしまったが、前回の続きである。

前回は我ながら今ひとつ歯切れの悪い内容で、批判も多く頂戴したが、そうなったのにはそれなりに理由がある。というのは、氏が問題の記事で書いている内容にはやはり承伏しかねる部分があるのだが、一方で別のところで氏が吐露しているソフトウェア開発者としての氏の実感(と思われること)は十分共感できたので、判断に迷ってしまったのだ。

しかし、いずれにせよ前回「本題」と書いた点はオープンソースの今後にとってはかなり重要なことではないかと個人的には思うので、今回はその点を掘り下げてみたい。

オープンソースは保守が好きか

そもそも、問題の記事を読んで筆者が最初に違和を感じたのは以下の部分である。

一般にソフトウェアのライフサイクルでは新規開発後に運用と保守・機能拡張を何度か行った後に、再び新規開発をするという過程を繰り返すが、オープンソース手法はそのうちの保守や機能拡張において有効な手法なのであって、新規開発では足かせとなる危険性も高い。

筆者の実感では、これは全く逆だ。保守ほどオープンソース開発者の苦手とするものはない。逆に、妄想を現実化するという意味では新規開発はオープンソースの最も得意な分野とも言えるのである。 SourceForgeでも覗いてみれば、それこそ「新規開発」のフェーズで止まってしまったプロジェクトで死屍累々なのが分かるはずだ。

ここで言う「ソフトウェアの保守」というのは少々曖昧な概念だが、ここでは「自発的ではないハック」と定義してみたい。たとえバグ取りであっても、自分がよく使う機能にバグがあって直さざるを得ない、というケースは保守ではなくただのハック、というわけだ。ようするに、外部要因によってある意味強制されるハックのことをここでは保守と呼ぶことにする。

なぜこのような区分をするかというと、経験上ハックは楽しいが保守はつらいからである。作業自体に大差はなくても、精神的な負担はかなり違う。機会費用が違うと言ってしまっても良いかもしれない。

なぜ保守がつらいのかというと、ようは自分にとって無意味で、やる気が出ないからだ。たいがい保守というのは外部からのアクションで始まる。例えば開発者のはしくれである筆者の場合、どこかのユーザからバグ報告が飛んできて、それを検証し、おかしいところを直すという作業になる。裏を返せば、それまでは当人は気づいていない(あるいは不自由していない)ことが多い。「おかしいところ」には、純然たる不具合から、アラビア語に対応しろというような新機能のリクエストまで多種多様だが、筆者自身にとってはあまり意味がないという点では共通している。直すだけではなく、質問に返事を書くというのも広義の保守に入れて良いだろう。

例を一つ挙げてみよう。多くのオープンソース開発プロジェクトでは、安定版と開発版を分けて(典型的にはCVSのブランチを切って)管理している。で、筆者の知る限り、Linux カーネルを始めとしてほとんどのプロジェクトでは安定版のほうが管理が遅れがちだし、安定版のリリースマネージメントは至難の業だ。なぜかといえば、「しょせん開発者自身が使っていない」からである。しかも、自分が必要としない部分は当然叩かれて鍛えられていないので、バグが出る可能性も高い。まさに悪循環だ。

オープンソース開発の動機は「かゆいところを掻く」という点にある、とエリック・レイモンドは言った。実際、オープンソース開発の基本は、開発者が使いたいものを作るということに尽きる。たまに、なぜオープンソースだと開発者が「ただ働き」するのか分からないという人がいるが、いろいろ答え方はあれど一つの答え(ちょっと問題はあるのだが)は、「開発者はただ働きをしているのではなく、金の代わりに労力を出して自分の欲しいソフトウェアを神様から買っている」というものではないだろうか。で、保守は、労力に見合っただけの効用をもたらさないので、ふつうは「買わない」よなあ、と筆者は思うのである。

実のところ前回も書いたように、佐藤氏自身別のところでは以下のように書いている。

AgentSpaceとMobileSpacesの公開を近々止める予定です。JDKのインストール方法や環境変数とは何かなどの当方が関知しない質問が非常に多く、これ以上を公開を続けることは困難と判断しました。ながらくのご利用ありがとうございます。

すなわち、氏自身が典型的な「保守」ワークで疲れてしまい、ソフトウェア公開をためらうような事態となっているのである。同情を禁じ得ない。

余談だが、実際、初心者の相手をするのは大変なのだ。ここで言う初心者とは、その分野の知識が無い人というより、「そもそも自分が何を分かっていないか分かっていない人」のことである。こういう人の相手をするのは本当に時間を食う。逆に、自分が何を分かっていないか分かっている人の場合は、答える方も張り合いがあるので、不思議なことに気分的には大して負担にならないものだが、閑話休題。

保守が得意と思われると困る

さて、なぜこのような話に目くじらをたてるかと言えば、端的に言えば、 保守にはお金が欲しいからである。筆者個人が欲しいということも、まあ、否定はしないが、それより何度も言うように、オープンソースが持続可能なプロセスとして続いていくためにはきちんと対価が得られる (可能性がある)ということが極めて重要だと思うのだ。

例えば役人や企業の人と話していると、こういったたぐいの会話になることがある。

「オープンソースを導入するとTCOが削減できるんですよね」
「オープンソースを導入すればアメリカの会社に金を払わなくていいから貿易赤字が解消できる」
「オープンソースには保証がないから不安だ」

これらは、確かに一文一文をみる限りそれほど間違っているわけではない。しかし、全部併せて考えてみるとちょっとおかしい。

なるほど一般的には、オープンソースソフトウェアはタダで手に入る。ゆえに、ライセンス料に限って言えばタダになる。もしかするとTCOは一部削減できるかもしれないし、ゲイツにこれ以上貢がなくても良くなるかもしれない。大いに結構なことだ。それに、オープンソースのライセンスがNO WARRANTYを謳っているのも確かだろう。

しかし、ソフトウェアにはどのみち保守が必要なのだ。あなたが直さない限り、あなたの要望はいつまでたっても現実化しない。それをあなた以外の誰がやるんですか、と問うた時に、えっ、オープンソースは保守が得意じゃないんですか?と言われる事態を筆者は恐れているのである。童話のこびとさんじゃあるまいし、自分のならともかく、他人の要望を(利他の精神かなにかで)せっせと実現するわけがないじゃありませんか。

長期不況のせいか、特に日本で最近顕著のように思うのだが、オープンソースのメリットとしてコスト削減ばかりが強調されているきらいがあるように思う。確かにライセンス料の支払い総額は減るだろう。しかし、それがコストの削減にストレートにつながるとは限らない。オープンソースには保証がないから困るというのは、これまでは(少なくとも顧客側から見ると)ライセンス料と保守契約の料金が込みだったということを暗に示しているように思うのだが、だったら保証を金を出して買えと言いたいのである。また、そういう考え方が当たり前にならない限り、良質な保守サービスを提供するきちんとしたオープンソースSI企業が育たないだろう。オープンソースには、単にライセンス料がタダという以上のメリットがあるし、またそれを顧客側にも積極的に伝えていかなければならない。そういった意味でも、これまでたびたび批判してきた「我流オープンソース」のたぐいは問題なのである。

逆にサービスを提供する側から見ると、ようするに、オープンソース開発者のやりたくないこと、言い換えれば相対的に不得意なことを、商売として金を取って専門的にやればいいということになる。極言すれば、いわゆるソフトウェア産業はそういう方向でしか生き残れないと筆者は考えている。それはプロプライエタリであってもいいのだが、プロプライエタリであることは現在ではコスト高(あるいはハイリスク)の要因と見なされかねないようにも思う。いずれにせよ、今まで以上の高い技術レベルが要求されるようになるし、またそうでなければ生き残っていけない(言い換えれば、どのみち技術があれば生き残れる)時代になるだろう。

というわけで、「オープンソースはソフトウェア産業を滅ぼすか」というようなよくある話に突入していくわけだが、それはまた稿を改めて書くことにしよう。