小飼弾のアルファギークに逢いたい♥

#14 ミラクル・リナックス よしおかひろたか

この記事を読むのに必要な時間:およそ 5.5 分

ピアレビューのプロセスとOSS

弾:そのときに,オープンソースでどうやってものを直していくかっていうメソドロジーを確保されてたっていうふうに見てもいいんでしょうかね?

よ:バグを直すという意味では一緒でしょうね。コミュニケーションの面でも一緒で,バグをどういうふうに直すかっていうところで,大聖堂,多くの人は伽藍(がらん)って言うんだけど,大聖堂とバザールのベストプラクティスは180度違うって世間では見られてるんだけど,実は根っこの部分は非常に似てて,パッチの作り方でも,良いパッチの作り方と悪いパッチの作り方って間違いなくあるじゃないすか。

弾:あります。

よ:自分はこういうふうにやりますっていうときに,いろんなピアレビュー注4のプロセスがあって,私がたとえばSQL でこうしますってメーリングリストで投げると,その道の専門家が,それよりこうじゃないとかああじゃないとか,そこにはこういう問題があるよっていうピアレビューのプロセスが回るわけです。もちろんそれが正しい場合もあるし,レビュアの意見が納得できる場合もあればできない場合もあって,いや,私はここはこうだから,こういう実装したんだっていうコミュニケーションが始まって,結果として,なんとなく,みんなが納得できる収まりどころに収まるという。そこはプロプライエタリだろうがオープンソースだろうが一緒で,みんな良いものを作りたいと思ってるのは確かですよ。だけどピアレビューの数で言うと,現状の非常に活発な,オープンソースでかつバザールモデルがうまくいってるところのほうが多いんですね。オラクルでも数百人,カーネルのエンジニアがいるから,かなり十分な量でピアレビューのプロセスが動くけど,たとえばUnicodeの具体的で固有のことに関して,SQLの文法のこういうところに関わっていてという話になると,数人程度になっちゃうんですよ。

弾:両方知ってる人なんていないでしょうね。僕も前者に関してはたぶん日本でも詳しいほうに入ると思うんですけど,SQLとどういうふうになるのかっていうとちょっと。

よ:ですよね。そういう部分はあるんだけど,パッチを作って,リグレッションテストを通してOKであればコミットして,次のバージョンに入れてくというところのベストプラクティスは,オープンソースのバザールモデルでかなり適用可能な部分がある注5⁠。もう一つ言えるのは,そういう大規模でいろんな人とコラボレーションした経験は,みんなでシェアしたほうが得なわけじゃないですか。プロプライエタリな世界にいるとその会社でしかぐるぐる回さないけど,オープンソースだとそういう経験を,たとえば弾さんやPostgreSQLの石井さん注6と話しができたり,そっちのほうが心地良いというのを私は感じたんです,10年くらい前に。でもその当時,データベースの実装について語ろうとしたら,オラクルの本社に行くしかなかったんですよ。あるいはマイクロソフトのSQL Serverの部隊に行くしかなかった。だけど,そんなのなかなかチャンスはないわけじゃない?

弾:ないです。

よ:それがオープンソース時代になって,別にそんなところに就職しなくても,やりたきゃやれるわけですよ。

弾:そうですね。

よ:それは私にとってもすごいブルースカイなんだな。すごい景色が見えたわけですよ。こりゃあ,すげぇやと。日本語や英語で,自分の好きな技術に関してとことん,朝まで議論できる。それは心の底から揺さぶられるものがありました。

注4)
同僚間でのレビュー。
注5)
リグレッション(回帰)テストは,プログラムの修正時,その修正による影響の発生がないかどうかを確認するテスト。よしおかさんによると,オープンソースの場合,リグレッションテストが必ずしも整備されておらず,大きな課題になっていると思うが,原理として,パッチ→リグレッションテスト→コミットというのはオープンソースでも適用可能だと信じているとのこと。
注6)
日本PostgreSQLユーザ会初代理事長で,現在,SRA OSS,Inc.日本支社長の石井達夫さん。

OSSで飯を食うこと

弾:そこまでは同感なんですけど,ここからちょっと質問が少し厳しめになります。確かに診療報酬はばかでかいですよね,オープンソースは。ただしこれで飯を食うとなると,いまだにこれでいけるんだっていうモデルが確保されてないですね。

よ:それはたぶん私に対する叱責の部分も含めてなんだと思うけど,オープンソースで飯を食うということに関しては,10年くらい前,日本に戻ってきてからの,自分に対する宿題であり,ミラクル・リナックスを作ったっていうことでもあり,それに関する答えは出てないというのはおっしゃるとおりだと思う。とはいえ,10年前はその道筋,あるいはオープンソースで飯を食うという発想すら…。

弾:ありませんでした。私もあくまでも道楽と(捉えてました⁠⁠。

画像

よ:だけどそれが,飯を食うということを大きな声で議論してもいいという社会になったことはまず1点,違いとしてある。で,ミラクル・リナックスがぼろもうけできてるかっていうと,それはできてはないけど,50人の社員は食うには困ってない,食えてる。そこは誇ってもいいかなと。さらに言うと,最初の1,2年…3期くらいは利益は出てなかったんですけど,そのあとは,ここは胸張っていいと思うんだけど,利益は出ています。決算に関しては公表してないので,この場では言えないんですけど。日本で何社か株式公開してる会社があるので,たぶん同業他社をベンチマークとして見ていただければいいと思うんだけど,それらと比べて弊社が点数として劣っているかというと私はそんなことは全然ないなぁと思っています。とは言うものの,マーケットシェアで1位をとらなきゃいけないとか,あるいは同業他社でレッドハットさんが相当強いとか,そういうところで言えば,経営者として落第点というのは間違いない。

弾:とりあえず,サポートでは飯は食えるだろうというのはわかってきました。まさにレッドハット,IBMがやってることですよね。ソースは無償だけど,サービスは無償じゃありませんよというビジネスモデルですよね。

ハッカーを育てる

よ:そういう意味でいうと,大手ベンダさんに対するバックエンドサポートを提供してて,我々のカーネルハッカーが提供できる価値っていうのがあって,それをお金にするということではいくつか大手ベンダさんにはそういうサービスを提供させていただいています。サポートサービスのおもしろいところは,いわゆる単なるQ&Aだと誰でもできるんだけど,カーネルのディープなところに関しては,なかなか簡単には真似できない部分があるわけですよ。それこそ深い知識とか経験がないと,商売として提供するのは難しいので,そうなってくると,そのサービスに対するある種のコピーを誰か同業他社がすぐ提供できるかって言ったらすぐはできないから競争力があって,単価も高くできるじゃないですか。真似できないサービスを提供するというのは商売の王道で,そこは我々のカーネルチームが付加価値として大手ベンダさんに提供してるところです。だけど,組織としてはさらにバックエンドのチームとして,たとえばジュニアな小飼弾を雇用して2年後に小飼′(ダッシュ)くらいにしなきゃいけないわけです。それは経営の仕事なので。そこがLinuxとかオープンソースで我々の会社がどうにかこうにか目指しているところなんですよ,まさに。それができればそれはすごいコピーしにくいサービス,商品だから,そこは世界に冠たる小飼さんの会社だとか,そういう形になってくる。それはPerlだけじゃなくて,Apache,JBoss,なんでもいいんですよ。定番のオープンソースに対するサポートインフラとそういうタレントをちゃんと持っている芸能プロダクションみたいな。

弾:たぶんそれで一番うまくやってるのがIBMでしょうね。

よ:Linuxテクノロジー・センターなんてハッカーの巣窟ですからね。

著者プロフィール

小飼弾(こがいだん)

ブロガー/オープンソースプログラマー/投資家などなど。ディーエイエヌ(有)代表取締役。1999~2001年(株)オン・ザ・エッヂ(現(株)ライブドア)取締役最高技術責任者(CTO)。プログラミング言語Perlでは,標準添付最大のモジュールEncodeのメンテナンス担当。著書に『アルファギークに逢ってきた』(2008年5月,技術評論社)。ブログは『404 Blog Not Found』

URLhttp://blog.livedoor.jp/dankogai/