伽藍とバザールとWordPress

WordPress Advent Calendar 2013 全部オレ 3日目の俺です。

今日は、いまでは当たり前となった「バザール方式」のソフトウェア開発とWordPressの開発について論じる、ほどには残念ながらわたしは賢くないwので、「伽藍とバザール」から引用しつつ「だよねー」的な何かを書いてみます。

伽藍とバザール」というのはエリック・レイモンドによって書かれたソフトウェアの開発方式についての論文で、オープンソース4部作(「伽藍とバザール」「ノウアスフィアの開墾」「魔法のおなべ 」と4作目はまだ!未発表らしいw)の第1部です。

この論文では、一人もしくは少数精鋭のプログラマーが大聖堂を建てるがごとく粛々とソフトウェアを開発してるさまを「伽藍」と例え、大勢のプログラ マーが寄ってたかってワイワイガヤガヤと開発するさまを「バザール」と例えて、それまで常識とされてきた「伽藍」方式の開発方式をはるかにしのぐ勢いと品 質で開発が進む「バザール」方式のLinuxカーネル開発がどようにして進められ、なぜそれが上手く機能しているのかを解き明かしつつ、その手法を別のソフ トウェア開発に適用して「バザール」方式の有用性を説いています。

初出は1997年ですが、オープンソースソフトウェア(以下、FLOSS – Free/Libre Open Source Software)の開発に関わる方にはいまでも十分読む価値がある論文だと思います。また論文といってもお硬いものではなく山形浩生さんの訳もくだけた 感じですし、それほど長いものでもないので、FLOSSには興味があるだけという方でも十分楽しめるかと。

伽藍とバザール

だから リーヌス・トーヴァルズの開発スタイル――はやめにしょっちゅうリリース、任せられるものはなんでも任して、乱交まがいになんでもオープンにする――には まったく驚かされた。静かで荘厳な伽藍づくりなんかない―― Linux コミュニティはむしろ、いろんな作業やアプローチが渦を巻く、でかい騒がしいバザールに似ているみたいだった(これをまさに象徴しているのが Linux のアーカイブサイトで、ここはどこのだれからでもソフトを受け入れてしまう)。

WordPressを始めたMatt Mullenwegもだいぶんはじめの頃からメインのコミットをライアンに任せたりしてましたもんね。そしてもうしばらく前からは、新しい機能やテーマごとのリーダーにリードを任せて分散的に開発がガンガン進んでる感じ。

よいソフトはすべて、開発者の個人的な悩み解決から始まる。

WordPressのプラグインなんかはその典型でしょうね。わたしの唯一のプラグインもそうですw!

ユーザを共同開発者として扱うのは、コードの高速改良と効率よいデバッグのいちばん楽ちんな方法。

お金を払ってるユーザーならユーザーが大事なのは当然ですが、無料で使ってるユーザーがなぜ大事な財産になるかという最大の理由のひとつかと。

はやめのリリース、ひんぱんなリリース。そして顧客の話をきくこと

リーヌスは、ハッカー/ユーザたちをたえず刺激して、ごほうびを与え続けたってことだ。刺激は、全体の動きの中で一員となることでエゴを満足させられるという見込みで、ごほうびは、自分たちの仕事がたえず(まさに毎日のように)進歩している様子だ。

オープンソースの開発者はときにエゴのない聖人みたいに言われることがあるけど、そんなことはなくてやはり「エゴ」を満足させるというは大きなモチベーションだと思う。

このプロジェクトを使って、リーヌス・トーヴァルズがうまくやっ た点についての自分の理論を試すことにした、と書いた。試すって、どういうふうに?(という疑問は当然起こるだろう)。それは以下の通り:

  1. はやめしょっちゅうのリリースを心がけた(間が 10 日以上開いたことはほとんどない。集中して開発しているときは、1 日 1 回)。
  2. だれかが fetchmail の件で連絡してきたら、その人をベータリストに加えてリストを増やした。
  3. リリースごとに騒々しいアナウンスをベータリストに送りつけて、みんなに参加をうながした。
  4. そしてベータテスタたちの言うことをきいて、設計上の判断について意見を求め、パッチやフィードバックを送ってくれたら必ずほめた。

こういう単純な方法の見返りはすぐにやってきた。プロジェクトの始めから、ぼくは他の開発者なら死んでもいいと思うような質の高いバグレポート をもらっ たし、しかもそれになかなかいいフィックスまでついてきた。よく考えられたコメントももらったし、ファンレターもきたし、賢い機能の提案ももらった。

WordPressもメジャーバージョンのバージョンアップの間隔がずいぶん短くなった。そこにはやはり開発者やユーザーを絶えず刺激し続けるという目論見もあるんだろうなぁ。。

「目玉の数さえ十分あれば、どんなバグも深刻ではない」。これをぼくはリーヌスの法則と呼んでる。

ここに、伽藍建築方式とバザール式のちがいの核心部分があるんだと思う。伽藍建設者的なプログラミングの見方では、バグや開発上の問題はやや こしく、潜 伏した深い現象だ。問題を全部ほじくりだしたと確信できるようになるには、少数の人が何ヶ月も専念してチェックしなきゃならない。だからリリースの間隔も 開いてくるし、長く待たされたリリースが完璧じゃないときには、どうしても失望も大きくなる。

一方のバザール的見方だと、バグなんてほとんどは深刻な現象じゃないという前提にたつことになる――少なくとも、リリースを一つ残らず、千人 の熱心な共 同開発者が叩いてくれるような状況にさらされたら、どんなバグも早々に浮上してくると考える。よって、たくさんなおしてもらうためにリリースも増やすし、 有益な副作用としては、ときどきヘマが出回っちゃっても、あんまり失うものは大きくないってわけ。

WordPressに注目する目玉の数も今やすごいことになってる。それにしたがい、(コードの汚さや古さが時にディスられることがあるけれども)これだけ複雑になっても安定してきてると思う。 あと、たしかにWordPressでもときどきヘマが出回っちゃってるけどねw

9 バザール方式の前提条件とは

これは説明するまでもないだろう。開発コミュニティをつくるには、人を引きつける必要がある。自分のやっていることに興味を持たせて、各人の やっている 仕事量についてみんなが満足しているように気を配る必要がある。技術的な先進性は、これを実現する役にはおおいに立つけれど、でもそれだけではぜんぜん足 りない。その人が発する個性も大事だ。

リーヌスがナイスガイで、みんなかれを気に入って手伝いたくなってしまうのは、偶然ではない。ぼくがエネルギッシュで外向的で、大人数を動か すのが好き で、コメディアンの話術や本能をちょっと備えているのも偶然じゃない。バザールモデルが機能するためには、人を魅了する能力が少しくらいでもあると、きわ めて役に立つのだ。

まぁマットも(そんなによく知ってるわけじゃあないけど)じかに会ってみるとほんとにナイスガイなアメリカ人だなと。インタビューの受け答えもほんとにこなれてるし。

あと、ちょっと話はずれるけど、福岡のIT関連コミュニティに顔を出してるかたは、この「リーヌスがナイスガイで、みんなかれを気に入って手伝いたくなってしまうのは、偶然ではない。」というところを読んででbaserCMS江頭さんが頭に浮かぶんじゃなかろうかw。

ちなみに

これが書かれたのはもう15年以上前の1997年で、ここには「オープンソース」という単語はほとんど出てきません。出てくる部分も後から追記されたものです。

なぜかというと「オープンソース」という単語はこの論文がきっかけになって作られたから! その経緯についてはオープンソースイニシアチブ 設立の経緯(可知さんの訳だ!)にあるので興味がある方は読んでみるといいです。

あと、ここではバザール方式の開発方法はオープンソースと密接に結びついて語られることが多いですが、ただただしさんの次の見方は読んだ時はさすがだなあと。

で、アプリケーションが将来オープンになるかというとたぶんならなくて、なぜなら勝ち組サービスを保有するベンダーは十分に大きくなって、自社 内に「バザール」的なエコシステムを構築できてしまうからだ。Googleしかり、Facebookしかり。彼らは優秀でモチベーションの高いハッカーを 大勢雇って、社内におけるコードの所有権を曖昧にすることで、コードをオープンにすることなく効果的なバザール開発をしてしまっている。
esrオープンソース三部作を読み返した」より

あとあと、合わせてartonさんの「伽藍、バザール、ノウアスフィア、おなべ(1)」も読むとより理解が深まるかと。

ということで、この流れで言うと明日は「ノウアスフィアの開墾とWordPress」になりそうだ。