<!-- <para>There are a few sites that provide free hosting and @@ -2167,7 +2181,7 @@ これらのサイトのいずれかを使用すると、無料で多くのものを手に入れることができます。 ただ、ユーザーへの見せ方をきめ細かく調整するといったことはあきらめなければなりません。 そのサイトでどんなソフトウェアを用いるのかを決めるのはホスティング業者であり、 - プロジェクトの見た目はその業者が選んだソフトウェアに左右されることになります。 + プロジェクトのウェブページの見た目はその業者に多少なりとも左右されることになります。 </para>
[patch] (スコア:1)
ていただければ幸いです。
「カネで愛は買えない」のセクションにもいくつか気になる部分がありますが、
それはまた後ほど書きます。
--- ch04.xml.orig 2009-03-13 13:41:53.000000000 +0900
+++ ch04.xml 2009-03-13 17:24:30.000000000 +0900
@@ -1230,11 +1230,11 @@
メーリングリストでの議論や既に有効になっている合意をベースにしていることを明示するようにしましょう。
実際に記録するときは、
[patch] ch02 (1/2) (スコア:1)
--- ch02.xml.orig 2009-03-13 13:41:53.000000000 +0900
+++ ch02.xml 2009-03-24 16:01:16.000000000 +0900
@@ -101,9 +101,8 @@
-->
<para>
しかし、Raymond の指摘は今でも洞察に満ちています。
- ソフトウェアの作者自身がそのソフトウェアに興味を持っているというのは、
- 成功するために必要不可欠なことです。なぜなら、
- 彼らは自分自身でそれを使うことになるからです。
+ ソフトウェアの作者自身がその成功に直接的な興味を持っている、
+ なぜなら彼らは自分自身でそれを使うことになるから、というのが本質的な条件です。
もしそのソフトウェアが期待通りに動かなければ、
日々それを使用している作者は不満に思うことになるでしょう。
たとえば OpenAdapter プロジェクト (<ulink url="http://www.openadapter.org/"/>)
@@ -112,13 +111,13 @@
さまざまな金融情報システムを統合するためのものです。
どう考えても、これは「開発者の個人的な悩み解決」
のために作られたものとはいえないでしょう。
- どちらかというと「制度上の問題を解決」するためのものです。
- しかし、この問題はその機関とパートナーの経験から直接くるものです。
- したがって、もしこのプロジェクトがうまくいかなければ、それが直接影響することになるでしょう。
+ これは「機関の悩み解決」をするためのものです。
+ しかし、この悩みはその機関とパートナーの経験から直接くるものです。
+ したがって、もしこのプロジェクトがうまくいっていなければ、それと気づくことができるでしょう。
このようなプロジェクトは、よりよいソフトウェアを産み出すでしょう。
- なぜなら、あるべき方向に導こうとみんながフィードバックを行うからです。
- プログラムというのは、見知らぬ誰かが彼ら自身の問題を解決できるように書くものではありません。
- 最初は自分たち自身の問題を解決するために書かれます。
+ なぜなら、フィードバックループが正しい方向に流れるからです。
+ そのプログラムは、見知らぬ誰かに売りつけて、<emphasis>彼らの</emphasis>問題を解決できるよう書かれるのではありません。
+ 最初は自分たち<emphasis>自身の</emphasis>問題を解決するために書かれます。
そしてそれがみんなと共有されるようになります。
「問題」を病気にたとえると、ソフトウェアは薬のようなものです。
流行病を完全に根絶するために薬をばらまくのと同じように、ソフトウェアを配布するようになります。
@@ -137,7 +136,7 @@
<para>
本章では、新しいフリーソフトウェアプロジェクトをスタートさせる方法を扱います。
しかし、本章にかかれている内容の多くは、
- 保険所が薬を配布するときの方法と似ていることでしょう。
+ 保健機関が薬を配布するときの方法と似ていることでしょう。
両者の目標はよく似ています。薬の効能ははっきり示さないといけないでしょうし、
それを本当に必要とする人に手渡さないといけないでしょうし、
またそれを受け取った人は薬の扱い方を知っていなければなりません。
@@ -159,18 +158,18 @@
investing effort.</para>
-->
<para>
- フリーソフトウェアの配布作業は、通常の2倍の作業量となります。
+ フリーソフトウェアの配布作業は、2つの側面を有しています。
ソフトウェアのユーザーを獲得すると同時に、開発者も獲得しなければならないからです。
- これら2つは決して競合するものではありません。
- しかし、プロジェクトをどのように見せるかという点において、これは少々複雑な話になります。
+ これら2つは必ずしも競合するものではありません。
+ しかし、プロジェクトを初めにどのように見せるかを考えると、これは少々複雑な話になります。
ユーザーと開発者の両方に対して有用な情報もあれば、
そのどちらか一方にしか役立たない情報もあります。
- これら2種類の情報の割合には気をつける必要があります。つまり、
+ どちらの情報もスケールするプレゼンテーション (scaled presentation) の原則にしたがっていなければなりません。すなわち、
読み手が時間をかけて熱心に読めば読むほど、
それにあわせた詳細な情報が得られるようになっていなければなりません。
努力すればするほど、それに対する見返りが得られるべきです。
- ユーザー向けと開発者向けの情報がうまく関連していなければ、
- 人はそこに参加する意欲を失ってしまうでしょう。
+ 両者<!-- 努力と見返り -->がきちんと相関していなければ、
+ 人はすぐ信頼する心を失い、努力を注ぎ込むのをやめてしまうでしょう。
</para>
<!--
@@ -183,12 +182,12 @@
come up with on their own.</para>
-->
<para>
- ここで登場するのが、<emphasis>見栄えよくするという問題 (appearances matter)</emphasis> です。
- プログラマーという人種は、これをあまり好まないようです。
- 見栄えなんかよりもその本質にこだわるという、プロとしてのプライドがあるからです。
+ この系として言えるのが、<emphasis>見栄えは重要である</emphasis> ということです。
+ とりわけプログラマーという人種は、これを信じようとしません。
+ 形式を差し置いた本質に対する彼らのこだわりは、ほとんど職人的プライドの域に達しています。
多くのプログラマーはマーケティングや広報活動を毛嫌いしているようだし、
プロのグラフィックデザイナも「プログラマーって人たちはいったい何を考えているのか」
- と恐れているようです。
+ と恐れているようですが、これは全く不思議なことではありません。
</para>
<!--
@@ -209,20 +208,20 @@
association.</para>
-->
<para>
- これは残念な話です。見栄えのよさもその本質の一部であり、
- プロジェクトをどのように見せるかも本質の一部であるからです。
+ これは残念な話です。状況によっては形式こそが本質であり、
+ プロジェクトの見栄えの問題はその状況の1つだからです。
たとえば、あるプロジェクトの存在を知った人が最初に目にするのは、
そのプロジェクトのウェブサイトの見た目です。
実際に何が書かれているかとかどこにリンクされているとかよりも前に、
まずそのウェブサイトがどんな感じかということが目に入るわけです。
おかしな話だと思われるかもしれませんが、
- 第一印象っていうのは結構重要なものなのです。
- 見た目に気を使って作ったか否かにかかわらず、そのサイトの見た目は人に何らかの影響を与えます。
- 見た目に気を使って作っているかどうかは、意外と簡単に見抜かれてしまうものです。
+ 人は第一印象の形成を抑制することができないものなのです。
+ サイトの見た目は、そのプロジェクトの見栄えの構成に配慮が払われたか否かという情報を発信します。
+ そして人間は、配慮の投資を検知するためのおそろしく感度のよいアンテナを備えているのです。
たいていの人は、そのサイトが片手間に作られたものか
よく練りこまれているものかを一目見て判断することができます。
そのプロジェクトを世に出すにあたって最初に見てもらうところがウェブサイトなのですから、
- そのできばえはプロジェクト全体に大きくかかわってきます。
+ その印象は連想によってプロジェクト全体に持ち越されるのです。
</para>
<!--
@@ -249,24 +248,25 @@
what people need to hear.</para>
-->
<para>
- したがって、本章で「プロジェクトのはじめ方」
- として書かれている内容の多くは、見栄えの問題も含めたものであることを念頭においておきましょう。
+ したがって、一方で本章では主にプロジェクトを開始するにあたり用意しておくべき内容について取り扱っているのですが、
+ その見栄えも重要であるということは忘れないでください。
プロジェクトのウェブサイトは (エンドユーザーと開発者の) 2種類の人たちが利用するものなので、
どちらを対象としたものなのかをはっきりさせる必要があります。
本書はウェブデザインの専門書ではありませんが、
ひとつだけ重要な法則を示しておきます。
このようにさまざまな相手 (部分的に重複することもあるでしょう)
を対象とするときは特に重要なことです。
- リンク先に何があるのかが、リンクをクリックしなくても大まかにわかるようにしておきましょう。
+ それは、リンク先に何があるのかが、リンクをクリックしなくても大まかにわかるようにしておく、ということです。
たとえば、ユーザー向けのドキュメントなのか開発者向けのドキュメントなのかが、
<emphasis>リンク先ではなくリンクそのものを見ただけで</emphasis>
- 判断できるようにしておくべきです。情報を提供することは、
- プロジェクト運営のひとつの側面になります。そして、それは同時に安心感を提供することにもなります。
- あるべき場所に普通に情報が提供されているというだけで、
- そのプロジェクトに興味を持っているユーザーや開発者は非常に安心します。
+ 判断できるようにしておくべきです。
+ プロジェクト運営には、情報を提供するという側面が一部にはあります。
+ しかしまた、安心感を提供するという側面もあるのです。
+ 期待した場所に決まりきったものが提供されているというだけで、
+ そのプロジェクトに関わるか否か決めようとしているユーザーや開発者は安心します。
「このプロジェクトはやるべきことを行い、想定される質問に対応し、
その質問に対する答えをできるだけ簡単に得られるようにしている」という努力が見えるからです。
- このような気合を見せることで「このプロジェクトは決してあなたの期待を裏切らない」
+ このような気合を見せることで「このプロジェクトに関わってもあなたの時間は無駄にならない」
というメッセージを送ることができます。それこそが皆が聞きたいメッセージです。
</para>
@@ -307,9 +307,9 @@
<para>
まずは周りを見渡して、同じようなプロジェクトが既に存在しないかどうかを確認しましょう。
あなたが今まさに解決しようと思っている問題を、
- 別の誰かがもっと前に解決しているという可能性は大いにあります。
- 別の誰かが同じことをやっていてそれをすでにフリーなライセンスで公開しているのなら、
- あえて車輪の再発明をする必然性はありません。
+ あなたよりも前に別の誰かが解決しようと思っていた可能性は大いにあります。
+ そして彼らが実際にその問題を解決し、コードをフリーなライセンスで公開しているのなら、
+ あなたがこれから車輪の再発明をする理由はありません。
もちろん、例外もあります。自分の勉強のためにプロジェクトを開始するのなら、
既存のコードは助けにならないでしょう。あるいは
これからはじめようとしているプロジェクトがあまりにも特定の分野に特化したものであり、
@@ -384,19 +384,20 @@
個人的なビジョンをみんなにわかる形に置き換えることです。
あなた (あるいはあなたの属する組織) にとっては何がやりたいのかは明白でしょう。
しかし、そのプロジェクトの目標が何なのかを一般にもわかるように表明することは、
- それなりに大変な作業です。しかし、これは基本的なことなので、
- 時間を割いてでもやる必要があります。
+ それなりに大変な作業です。しかし、
+ かならず時間を割いてそれをやらなければなりません。
あなた (そして共同でプロジェクトを立ち上げた他のメンバー)
- は、まず「そのプロジェクトがどんなものなのか」「何をやりたいのか」
- 「何を<emphasis>やらない</emphasis>のか」といったことをきちんと把握し、
- それを表明する必要があります。
+ は、まず「プロジェクトが実際何なのか」、すなわち、
+ 「何をやるのか」と同時に
+ 「何を<emphasis>やらない</emphasis>のか」という限界を決定し、
+ ミッションステートメントを書き上げなければなりません。
普通は、これはそれほど困難なことではありません。
- しかし、この作業によって、暗黙の了解であったことや意見の相違が浮かび上がってくるかもしれません。
+ しかし、この作業によって、プロジェクトの本質に関する暗黙の了解やさらには意見の相違まで浮かび上がってくるかもしれません。
それでいいんです。後になってからそれが判明するよりも、
早いうちに見つけてしまったほうが解決しやすくなります。
この作業が終われば、次にすることは
一般公開用のパッケージを作成することです。
- これは、ぶっちゃけて言うと単純でつまらない骨折り仕事です。
+ これは、ぶっちゃけて言うと単純でつまらない純然たる骨折り仕事です。
</para>
<!--
@@ -451,8 +452,8 @@
設計文書や完全なユーザーマニュアル (今後実装予定の機能についての説明も含む)、
複数プラットフォームで動作するきれいにパッケージされたコードなどがそろっているといいのでしょう。
しかし現実的には、これらをばっちりそろえることは手間がかかりすぎます。
- とにかく一度プロジェクトを始めてしまい、
- プロジェクトが動き出してから協力者を探すという手もあるでしょう。
+ それになにより、ひとたびプロジェクトが動き出せば、
+ これらの作業に対するボランティアの協力を正当に期待できるのです。
</para>
<!--
@@ -468,10 +469,11 @@
to get involved.</para>
-->
<para>
- しかし、必要なのは<emphasis>何なのか</emphasis>といえば、
- 見栄えの調整に十分に力をいれ、新入りさんがプロジェクトになじみやすくすることです。
- ちょっと面倒な作業ですが、これを
- 新規プロジェクトを立ち上げる際に最低限必要な動力と考えてみましょう。
+ しかし、何が<emphasis>本当に</emphasis>必要なのかといえば、
+ 見栄えの調整に十分に力をいれ、
+ 新入りさんが不慣れという名の最初の障壁を乗り越えられるようにすることです。
+ この作業をブートストラップ過程の第一段階、
+ プロジェクトをいわば活性化エネルギー最小の状態に持っていくことだと考えてください。
新入りさんが「このプロジェクトに対して何らかのかかわりと持とう」
と考えるために必要なエネルギーの閾値のことを、どこかの誰かが
<firstterm>ハクティベーション (hacktivation)
@@ -504,7 +506,9 @@
そのプロジェクトをはじめて知った人が遭遇するであろう順に並べていますが、
もちろんこのとおりの順で作成しなければならないというわけではありません。
これらの項目を、チェックリストとして用いるといいでしょう。
- プロジェクトをはじめる際にはこれらの各項目が網羅されていることを確認しましょう。
+ プロジェクトをはじめる際にはこれらの各項目が網羅されていることを確認するか、
+ あるいはもし省略した項目がある場合は、
+ せめて予想される結果が満足のいくものであることを確認しましょう。
</para>
<!-- ======================== subsection ============================== -->
@@ -544,9 +548,9 @@
マズい名前をつけてしまったら悪影響があるかもしれません。
しかし、わざわざプロジェクトを失敗に持っていくようなことはしないだろう
という前提の下で話を進めます。
- ただ、(あまりにも不真面目だったり覚えにくかったりといった)
- 変な名前をつけてしまうと、そのプロジェクトの利用に踏み切るまでに
- 時間がかかってしまうかもしれません。
+ ただ、変な名前をつけてしまうと、
+ 真剣に受け止めてもらえなかったり覚えてもらいにくかったりして、
+ そのプロジェクトの利用が低下してしまうかもしれません。
</para>
<!--
@@ -564,10 +568,10 @@
-->
<listitem>
<para>
- そのプロジェクトが何をするものなのか、
- あるいは少なくとも何に関するものなのかがはっきりわかること。
- そうすると、名前を聞いただけで何をするものなのかが判断でき、
- 名前を覚えてもらいやすくなります。
+ そのプロジェクトのやることが多少なりとも分かること、
+ あるいは少なくとも明らかな形でそれと関連があること。
+ そうすることで、名前とやることを知ってもらったあと、
+ その名前をすぐ思い出してもらえるようにするのです。
</para>
</listitem>
<!--
@@ -620,8 +624,8 @@
そして商標権を侵害しないものであること。
これは、礼儀の問題であると同時に法的にもよい考えです。
別のプロジェクトと混同されてしまうようなことは望ましくないでしょう。
- ネット上ですでにさまざまな情報が流れているものと同じ名前にしてしまうと、
- そのプロジェクトの情報を追いかけにくくなります。
+ 別々のものが同じ名前を持っていなかったとしても、
+ ネットで手に入るものすべてを追跡するのは既に十分困難なことなのです。
</para>
<para>
@@ -653,11 +657,11 @@
できれば、<systemitem>.com</systemitem> や
<systemitem>.net</systemitem>、<systemitem>.org</systemitem>
のようなトップレベルドメインが利用できる名前を選びましょう。
- この中のいずれか (おそらく <systemitem>.org</systemitem>
- でしょう) を利用すると、プロジェクトのウェブサイトを簡単に広めることができます。
+ この中のいずれか1つ (おそらく <systemitem>.org</systemitem>
+ でしょう) を選び、プロジェクトの公式サイトとして宣伝します。
他の2つのトップレベルドメインについては単純に
プロジェクトのサイトに転送させるだけにしておきます。
- これにより、第三者にそのドメインを悪用される心配をなくします。
+ こうすることで、プロジェクト名にまつわる同一性の混乱を第三者が発生させる心配をなくします。
仮にそのプロジェクトのサイトを別の場所
(<xref linkend="starting-with-canned-hosting"/> を参照してください)
におくとしても、プロジェクト名のドメインは取得しておくべきです。
@@ -744,9 +748,10 @@
the mission statement concise.</para>
-->
<para>
- たったこれだけの文章ですが、訪問者に予備知識を与えるという意味ではこれで十分です。
+ たったこれだけの文章ですが、主に訪問者の予備知識を利用することにより、
+ 重要なところはすべてヒットしています。
"<emphasis>コミュニティーとして (as a community)</emphasis>" と明記することにより、
- どこかの企業が開発するものではないことを表しています。また
+ どこか1つの企業が開発を支配するものではないことを表しています。また
"<emphasis>国際的な (international)</emphasis>" という言葉によって、
このソフトウェアが複数の言語や地域で動作することを示しています。
そして "<emphasis>すべての主要なプラットフォーム (all major platforms)</emphasis>"
@@ -755,13 +760,14 @@
ファイルのフォーマットが一般的なものであることなどがわかるでしょう。
彼らが Microsoft Office の代わりとなるフリーソフトウェアを作ろうとしているとはどこにも書かれていません。
しかし、たいていの人は行間からその気持ちを読み取ることができるでしょう。
- この声明はかなり大風呂敷を広げているように見えますが、
- 事実上これらは密接に絡み合っています。
+ この声明は一見したところ大雑把なようですが、
+ 実際にはきわめて絞り込まれたものです。
また "<emphasis>オフィススイート (office suite)</emphasis>"
という言葉を使用することで、その手のソフトウェアになじみがある人たちにとって
- かなり具体的な印象を与えることができます。つまり、
+ かなり具体的な印象を与えることができます。
+ ここでも声明を簡潔なものとするため、
訪問者が持っているであろうと思われる前提知識 (この場合は MS Office に関するもの)
- を利用して、この声明を簡潔にまとめているのです。
+ を利用しているのです。
</para>
<!--
@@ -788,9 +794,8 @@
現在も同社が主なスポンサーとなっているからです。
あえてこの文言を含めることで Sun は「開発プロセスを
支配するようなつもりはない」ということを示しているわけです。
- このように「そのような懸念があることを認識している」
- ということを示すだけでも、あとで問題が発生する
- <emphasis>可能性</emphasis>を減らすことができます。
+ このように「問題が起こる<emphasis>可能性</emphasis>を認識している」
+ ということを示すだけでも、問題の発生を回避するのに大いに効果があるのです。
一方、特定の企業の支援を受けているわけではないプロジェクトについては
このような文言は不要でしょう。結局のところ、
普通はコミュニティーベースの開発になるわけですから、
@@ -814,7 +819,7 @@
-->
<para>
プロジェクトの目標についての説明 (ミッションステートメント)
- を読んで興味を持ったひとたちは、もっと詳細な情報を知りたくなることでしょう。
+ を読んで興味が残っているひとたちは、もっと詳細な情報を知りたくなることでしょう。
たとえばユーザー向けドキュメントや開発者向けドキュメントなど。
そして、何かをダウンロードしたくなるでしょうね。
でもその前に、まずはそれがオープンソースなのかどうかを知る必要があります。
@@ -923,10 +928,8 @@
services for large collections of text files.</emphasis></para>
-->
<para><emphasis>
- 全文検索用のインデックスを作成し、
- 高機能な API つきのサーチエンジンを用意します。
- これらを使用することで、
- 大量のテキストファイルに対する検索処理をプログラマーが行えるようにします。
+ 豊富な API を備えた全文インデクサー・サーチエンジンを作成します。
+ 大量のテキストファイルに対する検索サービスを準備するプログラマーの利用を想定しています。
</emphasis></para>
</blockquote>
@@ -1054,7 +1057,9 @@
ここには、直近の目標とそれを達成するために必要なもの
(たとえば「ある特定の分野に強い開発者を募集しています」など)
を表示します。また、過去のリリース履歴や機能一覧などもここに掲載するといいでしょう。
- そうすることで、そのプロジェクトの「進捗状況」がわかりやすくなります。
+ そうすることで、そのプロジェクトが「進捗」というものをどのように定義し、
+ その定義にしたがってどのくらい速く前進しているのか、
+ ということが訪問者にわかるようにしておきます。
</para>
<!--
@@ -1075,7 +1080,7 @@
まだできあがっていないことを恐れる必要はありません。
できあがってもいないことを変にごまかすこともやめましょう。
ソフトウェアの開発にはいくつかの段階があることを、みんな知っています。
- "このソフトウェアはアルファ版です。まだバグが存在します。
+ "このソフトウェアはアルファ版です。既知のバグが存在します。
とりあえずは動作するでしょう。しかし、自己責任のもとで使用するようにしてください"
と言ったところで、何も恥ずかしいことはありません。
そのような段階でプロジェクトが必要としている開発者は、
@@ -1112,14 +1117,14 @@
とりあえずは動かすことができ、ひととおりの機能はそろっていますが、
まだバグが残っている状態です。アルファ版の主な目的は、
利用者からのフィードバックを得ることです。それによって開発者は、
- そのソフトウェアがどのように動いているのかをよく知ることができるようになります。
+ 何に取り組むべきかを知ることができます。
その次の段階となるのが<firstterm>ベータ版</firstterm>です。
これは、致命的なバグはすべて修正済みとなっていますが、
まだリリースに向けての十分なテストが行われていない状態です。
- ベータ版の主な目的は、バグが見つからないことを確認して
- 公式リリースに向けての準備を行うことです。また、
- 開発者からの具体的なフィードバックを受け取ることで
- 公式リリースをより早く行うという意味もあります。
+ ベータ版の目的には2種類あります。
+ 1つには、バグが見つからない場合にそれをそのまま公式リリースとすることです。
+ もう1つには、公式リリースを早く行うため、
+ 開発者が詳細なフィードバックを受け取れるようにすることです。
アルファ版とベータ版の差をどこにおくかは、あなたしだいです。
</para>
</sidebar>
@@ -1145,7 +1150,8 @@
<para>
標準的な形式で、ソフトウェアのソースコードをダウンロードできるようにする必要があります。
プロジェクトを立ち上げた最初のうちは、バイナリ (実行可能) パッケージはなくてもかまわないでしょう。
- ただし、ビルド手順が面倒だったり依存性が複雑だったりする場合は
+ ただし、ビルド手順が面倒だったり依存性が複雑だったりして、
+ ただ動かせるようにするだけでも多くの人にとって骨が折れるような場合は、
バイナリ版も必要です (でも、
そんなプロジェクトは開発者にとってはあまり魅力的ではありません)。
</para>
@@ -1160,14 +1166,13 @@
developers will give up and go away confused.</para>
-->
<para>
- 配布形態は、便利で標準的なものにしましょう。
- また、できるだけ利用者の負担を減らすべきです。
+ 配布形態は、できるだけ便利で標準的かつ余計な負担の少ないものを選びましょう。
あなたがある病気の撲滅を狙っているなら、
薬を配る際に独自の注射器が必要となるような面倒な手段はとらないでしょう。
同様に、ソフトウェアについても標準的な手順で
ビルド・インストールできるようにしておきましょう。
標準から外れれば外れるほど、
- ユーザー候補や開発者候補はそのプロジェクトから離れてしまいます。
+ ユーザー候補や開発者候補は狼狽してそのプロジェクトから離れてしまいます。
</para>
<!--
@@ -1191,15 +1196,17 @@
当然のことだと思われるかもしれません。
しかし、多くのプロジェクトは本当に切羽詰るまで
インストール手順を標準化しようとはしないものです。
- <emphasis>"ま、リリース予定日が迫ってきたら、
+ <emphasis>"ま、リリースに近づいたら
そのときにやろうよ。そんなことはいつでもできるんだから。"</emphasis>
といった言い訳をしてしまいがちです。
- 彼らはわかっていないのです。そういった作業を後回しにしてしまうと、
- 結果的に余計に時間がかかってしまうということを。
- また、それによって多くの開発者を失っていることにも気づいていないでしょう。
+ 彼らはわかっていないのですが、そういった作業を後回しにしてしまうと、
+ 結果的にリリースに近づくまで余計に時間がかかってしまうのです。
+ なぜならば、さもなくばコードを貢献してくれたかもしれない開発者たちの意欲を削いでしまうからです。
+ もっとも悪いことに、彼らはそのような開発者を失いつつあることに気づきません。
+ なぜならば、この過程は
「誰かがウェブサイトを訪れた→ソフトウェアをダウンロードした
→ビルドしようとした→失敗した→あきらめた」
- ということがあちこちで積み重なっているはずです。
+ という、イベントが発生しなかったことの積み重ねだからです。
あきらめた本人以外には、そんなことがあったということはわかりません。
もともとあなたのプロジェクトに興味を持っていてくれたはずの人が黙って立ち去ってしまった、
そしてそれをプロジェクトのメンバーは誰も気づかないのです。
@@ -1228,7 +1235,7 @@
in <xref linkend="development-cycle"/></phrase>.</para>
-->
<para>
- ダウンロード用のパッケージを作成したら、それに対して
+ ダウンロード用のパッケージをリリースするときは、それに対して
一意なバージョン番号を与えることが大切です。
それによって人は、2つのリリースのうちどちらが新しいのかを知ることになるのです。
バージョン番号のつけかたについては
@@ -1303,18 +1310,18 @@
-->
<para>
バグ追跡システムについても同じです。
- バグ追跡システムは、単に開発者たちにとって便利であるだけではなく、
- 周りでそのプロジェクトの進み具合を見守っている人たちにとっても便利なものなのです。
+ バグ追跡システムの意義は、開発者に対する有用性だけでなく、
+ それがプロジェクトの観察者に対して発している暗黙のメッセージにも存在します。
多くの人は、バグデータベースが公開されていると
「熱心に開発が進められているようだ」と感じます。
さらに、バグデータベースにたくさんのバグが登録されていればいるほど、
そのプロジェクトの見栄えはよくなります。
ちょっと直感に反しているように思われるかもしれません。でも考えてもみてください。
- バグデータベースにたくさんのバグが報告されているということからわかるのは、
- 次の3つの事実です。まず、そのソフトウェアにたくさんのバグが存在すること。
- 次に、多くのユーザーがそのソフトウェアを使用しているということ。
- そして最後に、ユーザーが気軽にバグを登録できるということ。
- 最初の1つはともかく、残りの2つは特に重要です。
+ バグデータベースに登録されたバグの数が実際何に依存しているかというと、
+ それは次の3つです。まず、そのソフトウェアに存在するバグの絶対数。
+ 次に、そのソフトウェアを使用しているユーザー数。
+ そして最後に、ユーザーが新規のバグを登録できるための利便性です。
+ このうち最初の1つよりも後ろの2つの方が重要な要素になります。
ある程度の規模と複雑さを持つソフトウェアには、
基本的にバグが含まれているものです。本当の問題は、
それらのバグをいかにして見つけ、どのように優先順位を設定するかというところにあります。
@@ -1340,8 +1347,10 @@
それについてはどうにもしようがありません。
しかし、プロジェクトが始まったばかりであることがどこかにきちんと書いてあり、
かつデータベースに登録されているのが最近登録されたバグばかりであったとすると、
- 訪問者はそのプロジェクトがちゃんと運営されていることを読み取ってくれるでしょう。
- バグの登録数があまりにも少ないからといって、心配されることはありません。
+ 訪問者はその事実から外挿して、
+ プロジェクトのバグ登録が健全な<emphasis>比率</emphasis>を保っている、
+ ということを読み取ることができます。
+ 彼らはバグ登録の絶対数が小さいことを不当に警戒することはないでしょう。
</para>
<!--
@@ -1588,14 +1597,14 @@
-->
<para>
ドキュメントは必要不可欠です。
- 人はみな、<emphasis>何か</emphasis>を読みたいものです。
+ <emphasis>何か</emphasis>読んでもらうものが必要です。
たとえそれがごく簡単な未完成のものであってもかまいません。
- これは、最初のうちは非常に "たいへんな" 作業でしょう。
- 新しいオープンソースプロジェクトがつまづく原因として最も多いのもこの分野です。
- これまでに考えてきたミッションステートメントや機能一覧、
- ライセンス、開発状況のまとめなどは、どれも比較的小規模な作業でした。
+ この作業はまさに、先ほど言及した「骨折り仕事」の範疇に属するものです。
+ 新しいオープンソースプロジェクトがしばしば最初につまづくのがこの分野です。
+ ミッションステートメントや機能一覧を作成するとか、
+ ライセンスを選択するとか、開発状況をまとめるとかいったことはどれも比較的小規模な作業です。
しかも「ここまでできたら完了」という点がはっきりしており、
- 通常は一度作成すればそれ以降は手を加える必要のないものでした。
+ 通常は一度作成すればそれ以降は手を加える必要のないものです。
ドキュメント作成はこれらとは異なり、
決して終わることのない作業です。
みんながドキュメント作成を嫌がるひとつの理由がここにあります。
@@ -1620,11 +1629,11 @@
はじめて使用するユーザーにとって必要なドキュメントは、
基本をまとめたものです。ソフトウェアを手っ取り早くセットアップする方法や
動作の概要、そして一般的な作業をするための手引きなどが必要でしょう。
- しかし、これらの内容は、ドキュメントの<emphasis>書き手</emphasis>
- にとってはどれも既知のことばかりです。つまり、これらの内容を
- 利用者側の視点で説明することはかなり難しくなるのです。
- (ドキュメントの書き手にとっては) 明らかなことを、
- 順を追って説明しなければならないのは大変でしょう。
+ しかし、これらの内容はまさに、ドキュメントの<emphasis>書き手</emphasis>
+ があまりにもよく知りすぎていることです。
+ そのためかえって、物事を読者の視点から眺めたり、また、
+ (ドキュメントの書き手にとっては) 言及に値しないほど明白な手順を、
+ 骨を折って詳細に説明するのが困難になる可能性があります。
</para>
<!--
@@ -1642,10 +1651,10 @@
この問題を解決するためのマル秘手段は存在しません。
誰かが腰を落ち着けてそれを書かなければならないのです。
そして、初心者にそれを見せて内容をチェックしてもらわなければなりません。
- ドキュメントの書式は、シンプルで編集しやすいものにしましょう。
- たとえば HTML やプレーンテキスト、Texinfo あるいは各種 XML などがいいでしょう。
- これらの書式はどれも便利で軽量であり、
- とりあえずどんどんドキュメントを書き進めるには最適です。
+ ドキュメントの書式は、
+ たとえば HTML やプレーンテキスト、Texinfo あるいは各種 XML といったような、
+ シンプルで編集しやすいものにしましょう。
+ すなわち、ふと思ったときお手軽かつ迅速に更新するのに適した書式です。
これらを使用すると、ドキュメントの作成者があとからそれを更新する際の手間も少なくなります。
また、後からプロジェクトに合流した人にとっても、作業に参加しやすくなるでしょう。
</para>
@@ -1661,7 +1670,7 @@
ドキュメントで網羅する範囲を事前に限定してしまうというものがあります。
このようにしてしまうと、少なくともドキュメントの作成が
果てしない作業に思えてしまうことはなくなるでしょう。
- おおざっぱに言うと、最低限として次の内容を満たしていればいいということにしましょう。
+ 実際的な目安としては、以下に挙げる最低限の基準は満たすようにすべきです。
</para>
<itemizedlist>
@@ -1672,7 +1681,7 @@
-->
<listitem>
<para>
- 読者に対して、そのドキュメントを読むために必要となる
+ 読者に対して、ソフトウェアを使用するために必要となる
技術的な前提知識を明確に示す。
</para>
</listitem>
@@ -1701,9 +1710,10 @@
セットアップが正常に完了したのかを確認できるようにする。
導入に関するドキュメントは、
ある意味実際の使用法のドキュメントよりも重要です。
- より多くの人がインストールしてくれればくれるほど、
- ドキュメント化されていない高度な機能を発見してもらえる可能性も高くなります。
- ユーザーがつまづくとしたら、それは初期であることが多くなります。
+ ソフトウェアをインストールして起動するためにより多くの努力を注ぎ込んでいればいるほど、
+ そのユーザーはより粘り強く、
+ ドキュメントが不十分な高度な機能を理解しようとするのです。
+ ユーザーが諦めるとしたら、それは初期であることが多くなります。
つまり、最も初期の段階であるインストール時にこそ最大のサポートが必要となるわけです。
</para>
</listitem>
@@ -1747,12 +1757,15 @@
<listitem>
<para>
ドキュメントがまだ出来上がっていないところについては、
- それを示しておくこと。このように結果を認めることによって、
- あなたは読者と同じ視点に立つことができるようになります。
- また、これによって読者は、
- そのプロジェクトにとって重要なことを理解できるようになります。
+ それを示しておくこと。
+ 読者に対し、足りていない部分があることを認識していますよ、
+ ということを示すことにより、
+ あなたは読者の視線に合わせることになります。
+ 読者に共感を示すことにより、読者に対し、
+ 重要なことをプロジェクトに納得してもらうための苦闘に直面することはない、
+ ということを再保証することになるのです。
別に「いつまでにこのドキュメントを仕上げる」と表明する必要はありません。
- これを示すのは、だれかの助けを必要としていることを示すのと同じことになります。
+ ボランティアの助けを広く求めるものとして取り扱うのも同程度に正当なことです。
</para>
</listitem>
</itemizedlist>
@@ -1774,16 +1787,16 @@
doing.</para>
-->
<para>
- 最後に、より広い意味で重要なことを述べて起きます。
- これは、単にドキュメントだけに限らずプロジェクト全体にあてはまることですが、
- 足りていない部分をちゃんと認めるということは、
+ この最後に述べた点は、実のところ、より広範囲の重要性があり、
+ 単にドキュメントだけに限らずプロジェクト全体にあてはまることです。
+ 既知の足りていない部分を正確に会計することは、
オープンソースの世界においては当たり前のことだということです。
そのプロジェクトの欠点を必要以上に誇張する必要はありません。
- 単に、きちんと公平に適切な場所
- (ドキュメントやバグトラッキングデータベース、あるいはメーリングリストなど)
- でそれを認めればいいだけのことです。
+ 単に、事情がそれを要求する場合
+ (ドキュメントやバグ追跡データベース、あるいはメーリングリストにおける議論など)
+ に、それを厳正かつ私情を交えずに明らかにするだけのことです。
それを負け犬根性だという人はいないでしょうし、
- 明示的に示さない限りは「いつまでにこれを解決する」という期限を問われることもありません。
+ 明示的に示さない限りは「いつまでにこれを解決する」という公約だと受け取る人もいないでしょう。
ソフトウェアを使用していると、だれでもそのソフトウェアの欠陥を発見してしまうものです。
彼らが心の準備をできるようにしておいてあげましょう。
すると、そのプロジェクトは自分たちのことがよくわかっているとみなされるようになります。
@@ -1809,12 +1822,12 @@
-->
<para>
<firstterm>FAQ</firstterm> ("Frequently Asked Questions"、
- つまり "よくある質問集") は、時間をかけて作成するだけの価値があるものです。
- FAQ には、ユーザーや開発者が実際に質問した内容
- —彼らが <emphasis>質問するであろう</emphasis>
- と予測した内容ではありません—をまとめます。
+ つまり "よくある質問集") は、教育という観点において投資効果の最も高いものの1つです。
+ FAQ は、ユーザーや開発者が実際に質問する内容
+ —彼らが質問することをあなたが <emphasis>期待した</emphasis>
+ 内容ではありません—にチューニングされています。
その結果、よくメンテナンスされている FAQ
- を見ればたいていの質問に対する答えが見つかるようになります。
+ を探した人はたいてい、まさに欲しかった回答が見つけられるようになります。
ユーザーは、何か問題に出くわすとまず FAQ を調べます。
公式マニュアルよりも FAQ のほうを先に見ることも多いでしょう。
そして、他のサイトから最も多くリンクされることになるのも
@@ -1833,9 +1846,10 @@
残念なことに、プロジェクトが始まったばかりのころは
FAQ を用意することはできません。FAQ は誰かが書くものではなく、
徐々に成長していくものだからです。FAQ は、
- 多くの人が日々ソフトウェアを使っていく過程でできあがっていくドキュメントです。
+ その名前からして反応的なドキュメントであり、
+ 多くの人が日々ソフトウェアを使っていくにしたがって成長するものです。
これから受けることになるであろう質問を正確に予測することなど不可能なので、
- 有用な FAQ をゼロから書き上げることなどできないのです。
+ 有用な FAQ を腰を据えてゼロから書き上げることなどできないのです。
</para>
<!--
@@ -1850,7 +1864,7 @@
<xref linkend="managing-volunteers"/></phrase>.)</para>
-->
<para>
- したがって、FAQ の作成にあまり時間をとられないようにしてください。
+ したがって、FAQ を書こうとして時間を浪費することは避けましょう。
しかし、ほとんど空っぽの FAQ のテンプレートを用意しておくことは良い考えかもしれません。
そうすることによって、プロジェクトが動き始めた後に
ユーザーが質問と回答を投稿してくれるかもしれません。
@@ -1893,9 +1907,9 @@
ドキュメントを読むことが多いからです。
ダウンロードに値するかどうかを、ドキュメントの内容で判断するわけです。
しかし、それだけでなくソフトウェアにも同梱しておく必要があります。
- というわけで、ダウンロード版をサポートする理由は、
- そのパッケージを使用するすべての人が
- ドキュメントにローカルからアクセスできる必要があるからです。
+ これは、ダウンロードすることでそのパッケージを使用するために必要なものがすべて手に入る
+ (すなわち、ローカルにアクセス可能になる) ようにすべきである、
+ という原則に従ったものです。
</para>
<!--
@@ -1931,7 +1945,7 @@
単に、それが第何章にあるのかが思い出せないだけなのです。
そんな人たちにとっては、あるページには目次だけ、次のページには導入だけ、
その次のページにはインストール方法だけ、……
- といったドキュメントだとちょっと困り者です。
+ といったドキュメントほどストレスが溜まるものはありません。
こんな形式のページ構成だと、ブラウザの検索機能が無意味になってしまいます。
個別に分割した形式が便利なのは、必要な内容が第何章にあるのかが事前にわかっている場合です。
あるいは、ドキュメント全体を頭から最後まで順に読んでいきたい人にとっても便利でしょう。
@@ -2017,7 +2031,7 @@
them.</para>
-->
<para>
- そう。そんなドキュメントを書く時間があるのなら、
+ なので、もしどちらか一方に向けたドキュメントしか書く時間がないのであれば、
まずユーザー向けのドキュメントを作成しましょう。
ユーザー向けのドキュメントは、事実上
開発者向けのドキュメントでもあります。
@@ -2073,13 +2087,13 @@
run.</para>
-->
<para>
- そのプロジェクトがグラフィカルなユーザーインターフェイスを持っていたり
- グラフィカルな出力を行ったりする場合は、
+ そのプロジェクトがグラフィカルなユーザーインターフェイスを持っていたり、
+ グラフィカルあるいはそうでない特徴的な出力を行ったりする場合は、
そのサンプルをプロジェクトのウェブサイトに公開しておきましょう。
インターフェイスの場合は、スクリーンショットがこれにあたります。
出力の場合は、同じくスクリーンショットか、
あるいは実際の出力ファイルとなります。
- これはどちらも、ユーザーの要望に応えるために必要となります。
+ これはどちらも、即座の満足感に対するユーザーの欲求を満たすものです。
長々とした説明やメーリングリストでのやりとりよりも、
ほんの一枚のスクリーンショットのほうが説得力を持つこともあります。
なぜなら、スクリーンショットはまさにそのソフトウェアが
@@ -2139,14 +2153,14 @@
サイト内検索の機能、寄付の受付などです。
もし時間が許したり何か特別な理由があるのなら、これらを作成してもよいでしょうが、
プロジェクトの立ち上げ時には通常はどれも不要です。
- しかし、将来はこれらも考慮する必要が出てくることを覚えておきましょう。
+ しかし、将来のために心に留めておきましょう。
</para>
<sect2 id="starting-with-canned-hosting">
<!--
<title>Canned Hosting</title>
-->
-<title>公開場所</title>
+<title>出来合いのホスティングサイト</title>
<!--
<para>There are a few sites that provide free hosting and
@@ -2167,7 +2181,7 @@
これらのサイトのいずれかを使用すると、無料で多くのものを手に入れることができます。
ただ、ユーザーへの見せ方をきめ細かく調整するといったことはあきらめなければなりません。
そのサイトでどんなソフトウェアを用いるのかを決めるのはホスティング業者であり、
- プロジェクトの見た目はその業者が選んだソフトウェアに左右されることになります。
+ プロジェクトのウェブページの見た目はその業者に多少なりとも左右されることになります。
</para>
<!--
Re:[patch] ch02 (1/2) (スコア:1)
TAKAGI Masahiro a.k.a. m-takagi
Re:[patch] ch02 (1/2) (スコア:1)
TAKAGI Masahiro a.k.a. m-takagi