オープンソースは「いくさ」だ！！（その２）
ソースコードをオープンにした段階で、公開したソースコードそのものでお金をもらうことは非常に難しいと思います。もちろんMySQLのように有償サポートを提供したり、商用ライセンスの「エンタープライズ版」を提供するなどビジネスチャンスはあり、私の会社もどうやってPandaプロジェクトを継続するためのビジネスモデルを構築するか現在頭をひねっていますが、あくまでそれは「付加価値提供」に対してお金をチャージすることになっていきます。
では直接的な金銭報酬を得る以外のオープンソースを続ける動機は何になるかといえば「名をあげる」ことだと思います。Pandaのように会社でオープンソースプロダクトを提供することで、いろいろなニュースサイトに取り上げられ、商談のチャンスもあがってきます。
また個人でオープンソースを公開する人も、有名なオープンソースプロジェクトのコアメンバーだったり、自分でいくつもライブラリープログラムを作ったりしていると、履歴書の見栄えもグンとあがってきます。
私が開発に使うRuby On Railsという開発フレームワークではWorking With Railsという開発者向けコミュニティサイトがその良い例です。
そこはどれだけ人気があるか(Popularity),本を執筆したり、カンファレンスで話したりなどの権威があるか(Authority)、といった項目に加えて、どれだけオープンソースプロジェクトに貢献しているか(Contribution)などによってランク付けされています。 よく開発者のブログにいくと、「もしこのブログや私のライブラリーを気に入ってくれたらWWRで自分に投票してね」みたいな記述も見かけます。
 |
| Working With Rails |
将来のビジネスチャンス、または個人の自尊心向上にも書かせない「功名」ですが、自分たちのプロジェクトの価値を判断される基準が、「どれだけそのプロダクトが使われているか」といった結果的なのものだけでなく、ソースコードの読みやすや、テストコードの多さに影響を受けるのもオープンソースプロジェクトならではだと思います。
オープンソースの場合、何かそのコードで見つかったバグを解析したり、新たな機能を拡張するなどの理由で、不特定多数のエンジニアがソースコードを目にする機会が格段に増えてきます。そういった際に「ゲ、このコードキタネ」とか「このコード全然テストがないじゃん、ほんとにちゃんと動くのかな？」などといった印象を与えてしまってはそれこそ末代までの名折れになるので、クローズドソースのコードに比べ、ソースコードに対する責任感が格段にあがります。
特に最近のソフトウェア開発においてはテストの重要性が高まっています。「テスト駆動開発」(TDD)という、「コードを書く前にテスト用のコードを書く」という開発スタイルが数年前から開発者の間で支持を受けていますが、最近のRailsコミュ二ティの間ではBDD(Behavior Driven Development)という、「そのソフトウェアが提供するであろう振る舞いをテストするコードを先に記述する」スタイルが人気を博してきています。
これはTDDのようにバグを減らす効果があるだけでなく、ドキュメンテーションとしての役割も担ってきます。
通常のドキュメンテーションだと仕様がかわるたびに、ドキュメントの記述内容が陳腐化している可能性が増えていきます。
テストの場合は、仕様がかわるとテストが壊れるので、テストを直すことで、常にテストの仕様を最新に保っている可能性が高まります。
事実私達がPanda開発に使用しているMerbというオープンソースWebフレームワークは、開発が活発に行われている分、仕様が頻繁にかわっており、Web上にある情報ですらほとんど使い物にならないほどです。そのため最近では、何かわからないことがあれば「スペックファイル」という仕様書兼テストコードを直接参考にしています。
ここまで強調したテスト（あるいはスペック）ですが、現在のPandaはお世辞にもテストが充実しているとはいえません。
Rcovというツールを使うと、どれだけのコードがテストコードによってカバーされているかわかるのですが、現在のカバー率は60%強。現在はテストカバレッジを高めるとともにリファクタリングをすることで、少しでもわかりやすいコードにするべく奮闘中です。
 |
| >Pandaのカバレッジ図 |
（続く）
