新しいフリーソフトウェアプロジェクトをスタートさせる方法は、保健機関が薬を配布するときの方法と似ています。フリーソフトウェアプロジェクトの立ち上げ時の注意点を解説します。
以下の各項では、新しいプロジェクトをはじめるに当たって重要となる内容について個別に説明します。そのプロジェクトをはじめて知った人が遭遇するであろう順に並べていますが、もちろんこのとおりの順で作成しなくても構いません。これらの項目を、チェックリストとして用いるといいでしょう。プロジェクトをはじめる際にはこれらの各項目が網羅されていることを確認するか、あるいはもし省略した項目がある場合は、せめて予想される結果が満足のいくものであることを確認しましょう。
どこかの誰かがあなたのプロジェクトのことを聞きつけたとしましょう。おそらく、何かの問題を解決するためのソフトウェアを検索しているときに見つけたのでしょう。彼らが真っ先に目にするのは、そのプロジェクトの名前です。
素晴らしい名前をつけたからといって、そのプロジェクトの成功が約束されるわけではありません。また、変な名前をつけたからといってそれだけの理由でプロジェクトが失敗するというわけでもありません――もちろん、あまりにもマズい名前をつけてしまったら悪影響があるかもしれません。しかし、わざわざプロジェクトを失敗に持っていくようなことはしないだろうという前提の下で話を進めます。ただ、変な名前をつけてしまうと、真剣に受け止めてもらえなかったり覚えてもらいにくかったりして、そのプロジェクトの利用が低下してしまうかもしれません。
よい名前とは、次のような条件を満たすものです。
プロジェクトのWebサイトを訪れた人たちが次に見るものは、そのプロジェクトについての簡単な説明や目標などのメッセージです。それらを見て(たいていは30秒程度で)、人はそこから先に進むか引き返すかを決断します。このメッセージは、トップページの目立つ場所に配置しなければなりません。プロジェクト名のすぐ下に置くといいでしょう。 この声明は、具体的で内容を絞り込み、そしてなによりも簡潔でなければなりません。例えば、以下に引用したOpenOffice.orgの記述などがよい例です。
To create, as a community, the leading international office suite that will run on all major platforms and provide access to all functionality and data through open-component based APIs and an XML-based file format.(コミュニティーとして、国際的な最先端のオフィススイートを作成します。すべての主要なプラットフォーム上で動作し、そのすべての機能やデータに対してオープンコンポーネントベースのAPIとXMLベースのファイルフォーマットでのアクセス機能を提供します)
たったこれだけの文章ですが、主に訪問者の予備知識を利用することで、重要なところはすべてヒットしています。“コミュニティーとして(as a community)”と明記することで、どこか1つの企業が開発を支配するものではないことを表しています。また“国際的な(international)”という言葉によって、このソフトウェアが複数の言語や地域で動作することを示しています。そして“すべての主要なプラットフォーム(all major platforms)”とあることから、おそらくUNIX、MacintoshそしてWindowsで動作するであろうことが読み取れます。そのほかの個所からは、インタフェースが公開されていることやファイルのフォーマットが一般的なものであることなどが分かるでしょう。
彼らがMicrosoft Officeの代わりとなるフリーソフトウェアを作ろうとしているとはどこにも書かれていません。しかし、たいていの人は行間からその気持ちを読み取ることができるでしょう。この声明は一見したところ大ざっぱなようですが、実際にはきわめて絞り込まれたものです。また“オフィススイート(office suite)”という言葉を使用することで、その手のソフトウェアになじみがある人たちにとってかなり具体的な印象を与えることができます。ここでも声明を簡潔なものとするため、訪問者が持っているであろうと思われる前提知識(この場合はMicrosoft Officeにかんするもの)を利用しているのです。
この声明の本質は、それが対象としているソフトウェアだけではなく「だれがそれを書いたか」にも依存します。例えば、OpenOffice.orgがあえて“コミュニティーとして(as a community)”と書いているのがいい例です。このプロジェクトはもともとSun Microsystemsが始めたものであり、現在も同社が主なスポンサーとなっているからです。あえてこの文言を含めることでSunは「開発プロセスを支配するようなつもりはない」ということを示しているわけです。このように「問題が起こる可能性を認識している」ということを示すだけでも、問題の発生を回避するのに大いに効果があるのです。一方、特定の企業の支援を受けているわけではないプロジェクトについてはこのような文言は不要でしょう。結局のところ、普通はコミュニティーベースの開発になるわけですから、それをわざわざ示す必要はないわけです。
プロジェクトの目標についての説明(ミッションステートメント)を読んで興味が残っている人たちは、もっと詳細な情報を知りたくなることでしょう。例えばユーザー向けドキュメントや開発者向けドキュメントなど。そして、何かをダウンロードしたくなるでしょうね。でもその前に、まずはそれがオープンソースなのかどうかを知る必要があります。
プロジェクトのトップページで、それがオープンソースであることを明記しておかなければなりません。当然のことだとお考えかもしれません。しかし、世の中にはそれができていないオープンソースプロジェクトが山ほどあります。わたしがかつて目にしたフリーソフトウェアプロジェクトのWebサイトのトップページでは、そのソフトウェアの配布時にどのライセンスを適用するかが示されておらず、さらにそのソフトウェアがフリーなのかどうかさえ書かれていませんでした。また、このような重要な情報がダウンロードページや開発者向けページなどにしか存在しないというページもよくあります。このような場合は、重要な情報を得るためにさらにマウスクリックが必要となってしまいます。最もひどかった例では、Webサイト上のどこにもライセンスが示されていなかったものもありました。ソフトウェアをダウンロードしてその中身を見ない限り、ライセンスの内容が分からなかったのです。
同じようなミスはしないでください。そんなことをすると、せっかくの開発者候補やユーザー候補の多くを失うことになります。トップページのミッションステートメント部の次に、そのプロジェクトが「フリーソフトウェア」あるいは「オープンソース」であることを示し、さらに具体的なライセンスについても記しておきましょう。どのライセンスを適用すればいいかについてはライセンスの選択と適用項で説明します。また、ライセンスに関するさまざまな問題については章9.ライセンス、著作権、特許で詳しく説明します。
ここまでの情報を見るのに、訪問者が要する時間は1分かそれ以下でしょう。これらの内容を基に、彼/彼女らがさらに次を読み進めるかどうかを決断するわけです。次のセクションでは、最初の5分間で訪問者が見るであろう内容について扱います。
content on this article is licensed under a Creative Commons License.