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

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

機能一覧・要件一覧

 そのソフトウェアのちょっとした機能一覧(まだ完成していない機能を一覧に含めてもかまいません。しかしその場合は“予定”とか“開発中”などとはっきり示しておくようにしましょう)、そしてそれを動かすために必要な要件についての説明が必要です。機能一覧/要件一覧は、そのプロジェクトについて誰かに聞かれたときに答えるためにまとめたものと考えるといいでしょう。これは、単にミッションステートメントの内容をより深く掘り下げたものと考えても構いません。例えば、ミッションステートメントで次のように説明したとすると、

豊富なAPIを備えた全文インデクサー・サーチエンジンを作成します。大量のテキストファイルに対する検索サービスを準備するプログラマーの利用を想定しています。

 機能一覧、要件一覧でその詳細を説明することでミッションステートメントの範囲を明確にします。

機能

  • プレーンテキスト、HTMLおよびXMLの検索
  • 単語あるいはフレーズによる検索
  • (予定)あいまい検索
  • (予定)インデックスの差分更新
  • (予定)リモートのWebサイトのインデックス化

要件

  • Python 2.2以降
  • インデックス作成用のディスク領域(元のデータの約2倍の大きさ)

 これらの情報によって、訪問者はそのソフトウェアが自分の希望を満たすものかどうかを判断します。また場合によっては開発者としてプロジェクトに参加することを検討してくれるかもしれません。

開発の進ちょく状況

 そのプロジェクトがいったい何をやっているのか、訪問者たちはきっと気になることでしょう。特に新しいプロジェクトの場合は、そのプロジェクトが掲げている目標のうち現在どれくらいが達成されているのかが気になるところです。十分に成熟したプロジェクトの場合に気になるのは、「そのプロジェクトが現在活発に保守されているのか」「どれくらいの頻度で新しいバージョンがリリースされているのか」「バグリポートに対する反応の速さはどれくらいか」などとなります。

 これらの質問に答えるために、開発状況を示すページを作らなければなりません。ここには、直近の目標とそれを達成するために必要なもの(例えば『ある特定の分野に強い開発者を募集しています』など)を表示します。また、過去のリリース履歴や機能一覧などもここに掲載するとよいでしょう。そうすることで、そのプロジェクトが「進ちょく」というものをどう定義し、その定義に従ってどのくらい速く前進しているのか、ということが訪問者に分かるようにしておきます。

 まだできあがっていないことを恐れる必要はありません。できあがってもいないことを変にごまかすこともやめましょう。ソフトウェアの開発には幾つかの段階があることを、みんな知っています。“このソフトウェアはα版です。既知のバグが存在します。取りあえずは動作するでしょう。しかし、自己責任の下で使用するようにしてください”といったところで、何も恥ずかしいことはありません。そのような段階でプロジェクトが必要としている開発者は、「α版」という説明なんかではおびえたりしません。対エンドユーザーという面では、まだできあがってもいないソフトウェアにユーザーが群がってしまうほどまずいことはありません。いったん「不安定」だとか「バグだらけだ」だとかいう評判が出てしまうと、それを払しょくするのは大変な話になります。結局のところ、多少保守的な方がうまくいきます。そのソフトウェアが「ユーザーが期待しているよりも安定していた」方が、期待はずれだった場合よりもずっといいでしょう。そしてその方が、口コミによる広がりが期待できます。

α版/β版

 α版とは、通常は一番最初のリリースのことを指します。取りあえずは動かすことができ、ひととおりの機能はそろっていますが、まだバグが残っている状態です。α版の主な目的は、利用者からのフィードバックを得ることです。それによって開発者は、何に取り組むべきかを知ることができます。その次の段階となるのがβ版です。これは、致命的なバグはすべて修正済みとなっていますが、まだリリースに向けての十分なテストが行われていない状態です。β版の目的には2種類あります。1つには、バグが見つからない場合にそれをそのまま公式リリースとすることです。もう1つには、公式リリースを早く行うため、開発者が詳細なフィードバックを受け取れるようにすることです。α版とβ版の差をどこにおくかは、あなた次第です。


ダウンロード

 標準的な形式で、ソフトウェアのソースコードをダウンロードできるようにする必要があります。プロジェクトを立ち上げた最初のうちは、バイナリ(実行可能)パッケージはなくても構わないでしょう。ただし、ビルド手順が面倒だったり依存性が複雑だったりして、ただ動かせるようにするだけでも多くの人にとって骨が折れるような場合は、バイナリ版も必要です(でも、そんなプロジェクトは開発者にとってはあまり魅力的ではありません)。

 配布形態は、できるだけ便利で標準的かつ余計な負担の少ないものを選びましょう。あなたがある病気の撲滅を狙っているなら、薬を配る際に独自の注射器が必要となるような面倒な手段は取らないでしょう。同様に、ソフトウェアについても標準的な手順でビルド/インストールできるようにしておきましょう。標準から外れれば外れるほど、ユーザー候補や開発者候補はうろたえ、そのプロジェクトから離れてしまいます。

 当然のことだと思われるかもしれません。しかし、多くのプロジェクトは本当に切羽詰まるまでインストール手順を標準化しないものです。“ま、リリースに近づいたらそのときにやろうよ。そんなことはいつでもできるんだから”といった言い訳をしてしまいがちです。彼らは分かっていないのですが、そういった作業を後回しにしてしまうと、結果的にリリースに近づくまで余計に時間が掛かってしまうのです。なぜならば、さもなくばコードを貢献してくれたかもしれない開発者たちの意欲を削いでしまうからです。最も悪いことに、彼らはそのような開発者を失いつつあることに気づきません。なぜならば、この過程は「誰かがWebサイトを訪れた→ソフトウェアをダウンロードした→ビルドしようとした→失敗した→あきらめた」という、イベントが発生しなかったことの積み重ねだからです。あきらめた本人以外には、そんなことがあったことは分かりません。もともとあなたのプロジェクトに興味を持っていてくれたはずの人が黙って立ち去ってしまった、そしてそれをプロジェクトのメンバーは誰も気づかないのです。

 面倒だが見返りの大きい作業は、できるだけ早めに済ませましょう。パッケージをきちんと作成すると、プロジェクトへの参加障壁を劇的に下げることができ、結果として大きな見返りを得ることになります。

 ダウンロード用のパッケージをリリースするときは、それに対して一意なバージョン番号を与えることが大切です。それによって人は、2つのリリースのうちどちらが新しいのかを知ることになるのです。バージョン番号のつけ方については章7.パッケージの作成、リリース、日々の開発リリースに番号をつける項で、そしてビルド手順やインストール手順の標準化については同じ章のパッケージング項でそれぞれ詳しく説明します。

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

注目のテーマ