未来のいつか/hyoshiokの日記

hyoshiokの日々思うことをあれやこれや

OSSに対する企業の貢献

OSSに対する直接的な貢献というのは、狭義にはソースコードの提供である。通常は元となるソースに対しての差分をパッチという形で提供することになる。あなたがプログラマなら diff とか patch というコマンドはおなじみであろう。そのパッチをメンテナと呼ばれるコアな開発者にメールなどで送りつける事が狭義の貢献である。メンテナはそのパッチをみてよければ採用しよくなければ採用しない。良い悪いというのはどうやって判断するのか?オープンソースの七不思議である。ある人のパッチは受け入れられてある人のパッチは受け入れられない。ある種の経験則はもちろんあるがその経験則を厳密に記述する事は難しい。少なくともわたしにはその経験則を記述する程の経験はないのでそれは出来ないが、インターネットのどこかにはそのような経験則を記述した文書があるはづである。(多分Eric Raymondあたりが記述しているはづだ)
商用ソフトウェアの場合はコードの変更は担当者が行うので受け入れるも受け入れないもなくて各社の社内規約に従って淡々とコードが追加されていく。オープンソースの場合その明文化された「社内規約」に相当するものがないので、ある種の秘密クラブの掟みたいな空気によって様々な意志決定がなされる。新参者は空気を読め、空気をという話である。
昨年IPA(情報処理推進機構)の支援をうけSamba国際化というプロジェクトをやった。うちの精鋭エンジニア、若手バリバリをアサインして行った。日本には日本Sambaユーザー会というのがあって、Sambaの日本語化などをやっていた。日本のユーザー会の人々の悩みはコードを書いてSambaに貢献する人の絶対数が不足しているということであった。特に新版のSamba 3.0では国際化部分が大幅に変更されているため従来の日本語処理部分と非互換あるいはバグが発生していることが知られているのだがそれを直す人がいないという問題があった。Sambaのコア開発者の一人である、monyoさんとして知られるたかはしもとのぶさんなどはその問題に早くから警鐘を鳴らしていた。我々のプロジェクトは国際化にまつわる様々なバグを修正するというものである。技術的なチャレンジと言うよりも淡々とバグを修正しその修正を受け入れてもらうという非常に地味なプロジェクトである。
IPAから予算を受け企業がOSSにどのように貢献しうるのか、そのモデルケースになるということも我々のチャレンジでもあった。ソースコードが公開されているのだから(それがオープンソースである)そのソースコードを変更し、バグを修正する事は難しくない。ちょっとした技術力があれば誰でも出来る事である。難しい点はその変更をオリジナルのコードに受け入れてもらう事ができるかどうかである。実はその点に関しユーザー会の人々にさんざん脅かされていた。いわく、ガイジンは国際化の事なんかまったく考えていないから日本語処理のパッチを送っても無視されるだけだ、いわく、連中はXXXだから話にならない、いわく、…。もちろんその手のお話は多かれ少なかれあるのかもしれないし、ある種の真実を言っているのかもしれない。しかしわたしは根拠無くユーザー会の一部の人達の主張は正しくないと考えていた。少なくともわたしの経験から言ってSamba開発者がわれわれの問題を理解しないとしたら(問題を正しく理解していないように見えたら)それは多くの場合、それは自分達の説明が悪いと言う事である。少なくともわたしの経験からそのような印象を持った。
偉そうな事を言えば、わたしはソフトウェア国際化のプロである。素人ではない。経験も積んでいる。海千山千の修羅場もくぐった。オープンソースだろうが商用ソフトだろうが結局は同じである。てな感じのいささか不尊な思いもなくはなく、Samba国際化プロジェクトでオープンソースの定番のソフトウェアコミュニティにデビューを果たした。わたし自身はパッチを作ったのではなく若手バリバリの連中を監督するプロジェクトマネージャとして参加したのだがそれはそれで非常に楽しかった。若手の作ったコードをレビューしながら、お気楽に「こーゆーコードはいかがなものかな」などと言って変更を要求したりする。
それはともかく、わたしが感じていた事は、このプロジェクトの成否をうらなうのは、コードそのものではなく、Sambaのコアメンバーとのコミュニケーションに尽きると思っていた。先に指摘したように技術的なチャレンジではなくコミュニケーションそのものだと考えていた。それがチャレンジであると。
Sambaコミュニティにどのようにして受け入れられるか?どのようにして respect されるか?それがチャレンジである。
プロジェクトの実施計画の中でわれわれの一つのアイデアは、最初にテストケースを定義し、テストを作り、そしてテストをするということである。つまり最初にSamba 3.0の国際化の問題を徹底的に洗い出す。そしてその後その問題を解決していくというアプローチをとった。こう書いてしまうと当り前すぎて身もふたもないのだが、先に国際化の実装をするのではなく、先にテストを行いバグを徹底的に洗い出すというアプローチである。流行りの言葉でいうとテストファーストである。そして発見したバグはどんどんSambaのバグデータベースに登録した。 http://www.miraclelinux.com/technet/samba30/index.html#reports
例えばテストケースが100個定義されているとして、それを網羅するテストをせっせと作る。その時の進捗は100個のうち何個テストプログラムができたかということになる。当然不具合が見付かる。そうするとそれをバグデータベースに登録する。全部のテストケースを網羅するテストが実施されたとすると、今度はその発見されたバグを直すというのが我々のプロジェクトのゴールとなる。例えば修正すべき30個バグがあるとすると、それをいくつ直したかが進捗である。
ソフトウェア開発の進捗管理というのは難しいテーマであるが、テストを先に行い、そのテストに全て合格する事をゴールにすると、進捗が極めて明確に可視化できる。発見された30個のバグのうち何個を直したかが進捗である。数値化できるのである。
テストプログラムは全て自動的に実行できるようにして毎晩実行することにした。シリコンバレーの常識のデイリービルドとリグレッションテストである。最初のフェーズは毎日毎日少しずつテストが増えて行くフェーズである。もちろんそれに比例して不具合(バグ)も増えて行く。厳密に言うとバグが増えるのではなく、発見されるバグが増えるのである。バグはもとから存在しているのだから。ある時点で想定したテストプログラムが全て出来上がる。そうすると既知のバグ数というのがでてくるのであとはそれを淡々と修正していく。
Sambaのプロジェクトではそのテストプログラム(スクリプト)もオープンソースとして開発した。そして我々の最初の貢献は発見したバグをひたすらバグデータベースに登録しまくった点である。それだけの話といっちゃあそれだけの話である。当り前すぎて身もふたもない感じがするがそれだけの話である。
そしてそれと並行して当該バグに対する修正(パッチ)をバグデータベースや開発者メーリングリストへ送りまくった。新機能の追加よりもバグ修正は受け入れられやすい。そしてそのような貢献を続けていくことによって我々自身のコミュニティによる評価がどこの馬野骨かわからない連中という認識から、だんだんその書いたコードによってコミュニティに評価されていくというプロセスをたどる。respect をうけるようになってくる。いきなり大きなコードを送り付けるのではなく、小さなバグの修正をひたすら送り付けて徐々にコミュニティの中に受け入れられて行くという作戦である。そしてこれは思いの他うまくいった。
Samba コミュニティと強い関係をもつためにコア開発者を日本に呼ぶと言うアイデアもあったが結局それは実現しなかった。そこでわたしが米国に行って直に我々のプロジェクトをフェースツーフェースで紹介した。その後、メールのやりとり以外、チャット、電話会議などを行いわれわれの意図などを伝える努力をした。我々はひたすらテストを行いバグを修正をした。そしてこのプロセスがコミュニティによって評価されていったのである。
我々はこのプロジェクトを通じ、OSSに対して企業が様々な形で貢献できると実感した。特にコードを開発するという点での貢献というのは非常に大きいと感じた。Samba国際化プロジェクトに関してはIPAという外部の予算を利用する事によって可能になったのだが、適切なビジネスモデルさえ構築できれば企業はOSSに多大なる貢献をしうる。
われわれの成果は全てオープンソースであるので、その成果はコミュニティの共有財産になる。コミュニティと企業は対立するのではなく、Win-Winの状況がそこには生まれるのである。