新しいフリーソフトウェアプロジェクトをスタートさせる方法――各論オープンソースソフトウェアの育て方(3/5 ページ)

» 2009年08月18日 14時25分 公開
[Karl Fogel, ]

バージョン管理システムやバグ追跡システムへのアクセス

 単にそのソフトウェアをインストールして使いたいだけという人にとっては、ソースパッケージで十分でしょう。しかし、デバッグをしたり機能追加をしたりしたい人たちにとってはそれだけでは不十分です。毎晩最新ソースのスナップショットを作成する手もありますが、開発が活発に行われているコミュニティーではまだこれでも完ぺきだとはいえません。

 常にその時点の最新のソースにアクセスしたいという人たちにその手段を提供するのが、バージョン管理システムです。バージョン管理システム上のソースに匿名でアクセスできるようにしておくと、「このプロジェクトは、新しいメンバーの参加を歓迎しています」というメッセージをユーザーと開発者の両方に送ることになります。もし今すぐにバージョン管理システムを用意できない場合は、近々公開予定であるというメッセージを書いておくようにしましょう。バージョン管理システムについては章3.技術的な問題バージョン管理項で詳しく説明します。

 バグ追跡システムについても同じです。バグ追跡システムの意義は、開発者に対する有用性だけでなく、それがプロジェクトの観察者に対して発している暗黙のメッセージにも存在します。多くの人は、バグデータベースが公開されていると「熱心に開発が進められているようだ」と感じます。さらに、バグデータベースにたくさんのバグが登録されていればいるほど、そのプロジェクトの見栄えはよくなります。少し直感に反しているように思われるかもしれません。でも考えてもみてください。バグデータベースに登録されたバグの数が実際何に依存しているかというと、それは次の3つです。

 まず、そのソフトウェアに存在するバグの絶対数。次に、そのソフトウェアを使用しているユーザー数。そして最後に、ユーザーが新規のバグを登録できるための利便性です。このうち最初の1つよりも後ろの2つの方が重要な要素になります。ある程度の規模と複雑さを持つソフトウェアには、基本的にバグが含まれているものです。本当の問題は、それらのバグをいかにして見つけ、どのように優先順位を設定するかという点にあります。従って、よく整備された(バグに対する対応が素早く、重複したバグ報告はきちんと統一されているなど)大規模なバグデータベースがあると、バグデータベースがなかったりほとんど機能していなかったりするプロジェクトよりずっと印象がよくなります。

 もちろん、そのプロジェクトが本当に始まったばかりなのならバグデータベースに登録される内容はほんのちょっとだけになるでしょう。それについてはどうにもしようがありません。しかし、プロジェクトが始まったばかりであることがどこかにきちんと書いてあり、かつデータベースに登録されているのが最近登録されたバグばかりであったとすると、プロジェクトのバグ登録が健全な比率を保っている、ということを読み取ることができます。彼らはバグ登録の絶対数が小さいことを不当に警戒することはないでしょう。

 バグ追跡システムに登録されるのはソフトウェアのバグだけではありません。機能追加の要望やドキュメントの変更、取りあえず保留になっている作業などが登録されることも多々あります。バグ追跡システムの運用方法については章3.技術的な問題バグ追跡システム項で詳しく説明するので、ここでは深く立ち入りません。プロジェクトの見栄えという観点から見て大切なのは、まずバグ追跡システムが存在するということ。そしてそれがプロジェクトのトップページからたどれる場所にあるということです。

連絡手段

 プロジェクトの関係者の連絡先を知りたいという人も現れることでしょう。関係者と連絡を取れるように、メーリングリストのアドレスやチャットルーム、IRCチャンネル、掲示板などの場所を示しておきましょう。あなた、あるいはそのほかのプロジェクト関係者がこのメーリングリストに参加していることも明記しておきましょう。そうすることで、「そこに行けば開発者と話すことができる」ことが伝わります。あなたがメーリングリストに参加しているからといって、すべての質問に答えなければならないとか、すべての要望に答えなければならないとかいった義務が発生するわけではありません。長い目で見れば、ユーザーのほとんどはこのようなメーリングリストや掲示板には参加しません。とはいえ、必要ならいつでも参加できるということを示すだけで、安心感を与えることができます。

 プロジェクトを立ち上げたばかりのころは、エンドユーザー向けと開発者向けにフォーラムを分ける必要はありません。それよりも、プロジェクトにかかわる人たちが1つの「部屋」に集まってわいわいがやがや話をする方がずっといいでしょう。アーリーアダプター層においては、開発者とユーザーの区別はあいまいです。あえて分類するとしても、プロジェクトの初期には開発者の比率がかなり高くなります。アーリーアダプターのすべてがそのソフトウェアをハックしたいと思っているとは限りません。しかし、少なくともそのプロジェクトの今後の方向性に関する議論には興味を持っていることでしょう。

 本章では「プロジェクトをどのように立ち上げるか」についてのみを扱っています。この段階では「取りあえずコミュニケーション用の場所が必要だ」というくらいで十分でしょう。後で、章6.コミュニケーション巨大化への対応項でさらに詳しく説明します。ここでは、掲示板の設置や管理の方法について扱います。また、いつかユーザー向け会議室と開発者向け会議室を分割することになったときに、両者の間に溝を生じさせないための方法も説明します。

content on this article is licensed under a Creative Commons License.

注目のテーマ