注意!! この投稿は3年と11ヶ月くらい前に公開したものです。
そのため正常に動作しないかもしれないので、ご注意ください。

魔法のおなべとWordPress

WordPress Advent Calendar 2013 全部オレ 21日目の場合によっては俺です。

伽藍とバザール」「ノウアスフィアの開墾」を紹介したら「魔法のおなべ」も紹介しなくちゃね。今回も「魔法のおなべ」から大量に引用しつつWordPressでも「そうだよねー」的な何かを。

魔法のおなべ 」というのはエリック・レイモンドによって書かれた「オープンソース現象に生じ発展しつつある、経済的な地層を分析した」論文で、オープンソース4部作(「伽藍とバザール」「ノウアスフィアの開墾」「魔法のおなべ 」と4作目はまだ!未発表らしいw)の第3部です。

ノウアスフィアの開墾」 で、わたしたちが住む実際の世界は「交換経済」の文化で、オープンソースソフトウェア(以下FLOSS – Free/Libre Open Source Software)の文化は「贈与文化」だと説明していました。そこで、どうやってFLOSSを飯の種にするのか? ということですな。

ただ、この中ではいくつか実例が挙げられているのだけれど、さすがに13,4年前なので今とはそぐ合わない箇所が出てきてるので、どっかに現在の状況にそくした分析をしてる論文とかないかしらん?

1 魔法と区別がつかない

多 くの人にとって、オープンソース・コミュニティの成功はありえそうにない魔法の一種に見える。高品質のソフトが「無料(フリー)」で現れてくるなんての は、続けばすばらしいことではあるけれど、競争と稀少資源が支配する現実世界では、長続きするとはとても思えない。なんか落とし穴があるはずだ。

そ う、小さなソフトウェアが無料で使えるのは、なんとなく理解できる。もちろんそのソフトウェアにもよるが、単純に、開発の作業や開発者同士のコミュニケー ションの時間的な負担がそれほど大きくはないだろうから。だけど、WordPressやLinux、LibreOfficeなどかなりの大きさと高品質な FLOSSの場合はどうなのか? こうしたFLOSS開発の中心にいる人たちは、開発作業自体は他の多くの開発者がいるのでそんなに必要ではなくなるかもしれないが、送られてくるパッチに 目を通し、判断し、マージするのは単純にそれにかかる時間だけを考えても相当な負担になるはず。

  製造業的な誤解

経済学でソフト生産について論じようとするとき、ほとんどの人は「工場モデル」を仮定することが多い。このモデルは、以下の根本的な前提に基づいている。

  1. ほとんどの開発者の開発時間に対する賃金はその販売価値に基づいて決まる。
  2. ソフトの販売価値は、その開発コスト(つまり、その機能を再現するのに必要な資源のコスト)とその利用価値に比例する。

つまり、人はソフトウェアの価値の特徴が、ふつうの工業製品と同じだとつい想定しがちだということだ。でも、いまの想定はどっちも明らかにまちがっている。

ソフトウェア開発の生産性って人によってものすごい差があるものねぇ。。とはいえ、初期の構築とかでは人月で見積もりが必要なわけで。

工 場モデルでなければ、どういうモデルがいいんだろう。ソフトのライフサイクルでも実際のコスト構造を効率的に(ここでの「効率的」というのは、ふつうの 口語的な意味と経済学の専門用語での意味の両方をさす)扱うためには、サービス契約や購読など、ベンダと顧客の間の価値交換が継続的に行われるような価格構造が必要だ。だから自由市場の効率性追求条件のもとでは、成熟したソフト産業が最終的に採用するのは、こういう価格構造だろうと予想できる。

確かにレッドハットしかり、Automatticしかり、デジタルキューブしかりw。

「自 由/無料(フリー)」という用語は、別の意味で誤解を招きやすい。ある財のコストが下がると、それを支えるインフラに対する投資は、減るのではなくて 増えることが多い。車の値段が下がると、自動車メカニックへの需要が上がる――それだから、いま販売価値によって対価を得ている 5% のプログラマも、オープンソースの世界で困ったりはしないことになる。

「車の値段が下がると、自動車メカニックへの需要が上がる」はすごく分かりやすい例え。ふだん使う分にはまったく困らなくて、たとえまったく故障はしなくても、定期的なメンテナンスは必須。

5 逆転した共有地

オープンソース・ソフトは広く使われることで、その価値を高める。利用者たちが自分自身のバグ修正や追加機能(コードパッチ)を追加してくれるからだ。

なので、はたから見てオープンにできるだろうになぜしないのか、たまに不思議に思うソフトがある。どれとは言わないけどw。

だ からパッチ作者たるハック素留造くんの選択肢は 2 つしかない。そのパッチを抱え込んでおくか、あるいはフリーでプールに投げ出すか。前者だと、なにも得られない。後者でも、なにも得られないかもしれない けれど、でもほかの人たちに相互に与えあうよう奨励して、いずれハック素留造くんの問題を解決してくれるような贈与につながるかもしれない。二番目の選択 は、一見愛他的だけれど、実はゲーム理論的な意味で、最適に利己的な行動になっている。

「最適に利己的な行動」というのがとてもうなずける。

6 ソース非公開にする理由

ソー スを非公開にする理由の中には、まるでまともとは思えないものもある。たとえば、ソースを非公開にすると、ビジネスシステムがクラッカーや侵入者に対 して高セキュリティになるという幻想を抱いている人もいる。もしそうなら、すぐに暗号専門家と話をしてそういう思いこみを治療してもらったほうがいいよ。 ほんとうにセキュリティに神経をとがらせているプロは、ソース非公開ソフトのセキュリティを信頼したりなんかしない。かれらはそれを、つらい経験を通じて 学びとってきたんだ。セキュリティというのは信頼性の一部だ。アルゴリズムにしてもその実装にしても、十分なピアレビュー(同業者による検査)を経たもの だけが、安全なものとして信頼できるんだ。

このへんは最近はあまり聞かなくなった気がする。それだけFLOSSが浸透してきたのかな。

7 利用価値による開発費用手当

利用価値と販売価値を区別することでぼくたちが気がつくだいじな事実は、クローズドからオープンソースに移行したときに脅かされるのは販売価値だけだ、ということだ。利用価値はまったく影響を受けない。

そして実際問題としても、オープンソースプロジェクト用のフルタイムの開発者の給料が、利用価値だけでまかなわれている重要なモデルが最低でも 2 種類ある。

7.1 Apacheの例:コストシェアリング

Apache グループに参加する。Apache サーバは、インターネットで結ばれた Web マスターたちの集団がつくった。かれらは、同じものを並行してたくさん開発するよりも、一つのコードベースの改善のために力を集中するほうが賢いと気がつ いたわけだ。こうすることで、かれらは独自開発のメリットのほとんどと、超並列ピアレビューの強力なデバッグ効果を両方とも手に入れることができた。

WordPressのコア開発はこの例ですな。WordPressのコア開発にはAutomattic以外の会社で働いている人もたくさんいる。

7.2 Ciscoの例:リスク分散

問 題は、二人ともいつまでも Cisco にいるとは考えにくいということだった。いずれ、二人とも Cisco を離れ、ソフトはメンテナンスされなくなって、腐り始める(つまり、現実世界の状況とあわなくなってくる)。自分の作品をこういう目にあわせたがる開発者 はいないし、豪気な二人は、Cisco が開発費を支払ったのは、自分たちの就職期間以上に使いものになる解決策がほしいという、もっとも至極な期待に基づいてのことだと感じていた

これはちょっと前の日本なら、終身雇用が前提にあったのでまた違う話になっていただろうけど、今の日本なら十分通用する話だと思う。

8 販売価値の困るところ

オープンソースだと、ソフトから直接の販売価値を捕捉するのはちょっとむずかしい。

主要なオープンソース・ライセンスは、直接の販売収入獲得に役立つような、利用や再配布や改変に関する制限のほとんどを禁止しているけれど、その理由は 3 つあって、しかもそれが相互に強化しあっている。

ここ、山形浩生さんの訳では最初の動詞としての「capture」を「捕捉」と訳して、そのあとの名詞としての「capture」を「獲得」と訳してるけど、なんでだろう? 最初のも「獲得」のほうが良さそうだけど。

で、その理由のほうは本文をどうぞ 😉

9 間接販売価値モデル

さはさりながら、間接的な販売価値みたいなものを捕捉できるような、ソフト関係サービスの市場をつくる手はある。この種のモデルとしては、すでに存在するものが 5 つ、アイデアレベルのものが 2 つある(将来はもっと出てくるかもしれない)。

この章も現在から見るとちょっと古くなっているけど、今のWordPressを取り巻く経済的な状況にあえて当てはめるとすれば

9.3 レシピをまいて、レストランを開け

このモデルでは、あるソフトウェアを使って、クローズドなソフトのポジションを確立するのではなく(これだと、「ロスリーダー・市場ポジション確保」ケースになる)、サービスのポジションを確立する。

かな。ネット上を検索すればあらゆるレシピがそろってるけど、実際それを作るとなると、素人だと失敗したりものすごく手間がかかったりするののに対し、レストランを開くようなプロのコックに頼んだほうがはるかに効率よく作れるれるし、はるかに失敗が少ない。

途中を飛ばして結論へw。この飛ばした部分も古くなりつつあるけど興味深いのでぜひ本文をどうぞ

15 結論:革命のあとの人生

オープンソースへの転換が完全に終わったあとのソフトウェア界は、どんな様子になっているだろう。

インフラ(インターネット、Web、OS、競合製品の間の境界を越えて行き来しなければならない、通信ソフトの低レベルの部分)はほとんどすべて オープンソースになるだろう。ユーザの連合や、営利目的のディストリビューションやサービス企業が、今日の Red Hat みたいな役割を果たしつつ、協力しながらそれを維持することになる。

一方のアプリケーションは、たぶんいちばん非公開のままでとどまりや すい。非公開アルゴリズムや技術の利用価値が十分に高い(そして信頼性の低さ からくるコストが低くて、供給元の独占からくるリスクもがまんできる)場合はあるだろう。このとき、消費者たちは非公開ソフトに対してお金を払い続ける。 これは、ネットワーク効果の小さい、スタンドアローンの垂直市場にあてはまり続ける可能性が高い。前にあげた製材所がこの一例だ。1999 年の人気分野としては、生物学的認証ソフトもそういうソフトの例としてあげられるだろう。

ミドルウェア(たとえばデータベース、開発ツー ル、あるいはアプリケーションのプロトコルスタックの、カスタム化したトップエンドなど)は、もっ と両者が混ざってくるだろう。ミドルウェアのカテゴリーが非公開になるかオープンになるかは、どうも失敗コストによるみたいだ。それが高いと、市場から もっとオープンにしろという圧力がかかる。

1999年に書かれた未来の予想。

ここでいってるインフラはAWSとかとは別の層の話ですね。ネームサーバソフトとかの話かな。

アプリケーションは、ワードやエクセルなど今では十分に代替可能なFLOSS製品があるにも関わらずクローズドな製品が生き残ってますな。あと、iPhoneやAndroidのアプリもしかり。

ミドルウェアの予想も、データベースを例に挙げればMySQLやオラクルDB(いまや両方をオラクルが持ってるとは!)合っている様子。

今日はここまで。

伽藍とバザール」「ノウアスフィアの開墾」「魔法のおなべ 」と来たので、次は「ハロウィーン文書」にも行きたいところ。