Software Release Practice HOWTO Eric S. Raymond v2.0, 18 September 1999 福島於修 v2.0j1, 08 October 1999 この HOWTO では Linux でのオープンソース・プロジェクトの公開にかかわる 望ましい慣例について解説します。これらの慣例を踏襲することによって、ユ ーザがソースコードからビルドして使用することが大変容易になりますし、他 の開発者はコードの内容を理解し、改良に協力することができます。この文書 は開発の初心者にとっては必読のものです。経験をつんだ開発者にとっても、 新しいプロジェクトをリリースする前に再確認すべき点を含んでいます。この 文書は、標準的な望ましい慣例の実情を反映して、定期的に改訂する予定で す。 ______________________________________________________________________ 目次 1. はじめに 1.1 この文書が書かれた背景 1.2 この文書の最新の版 1.2.1 翻訳文に関して 2. 正しいプロジェクトとアーカイヴの命名規則についての提案 2.1 基本名称 + major.minor.patch 番号という GNU スタイルを使いましょう 2.2 それでも「郷に入っては郷に従いましょう」 2.3 プロジェクトには特徴ある、入力しやすい基本名称を選びましょう 3. 正しいライセンスと著作権に関する提案: 基礎篇 3.1 オープン・ソースと著作権 3.2 オープン・ソースである条件 4. 正しいライセンスと著作権に関する提案: 実践篇 4.1 自分自身、または FSF を著作権保持者にしましょう 4.2 Open Source Definition に準じたライセンスを設定しましょう 4.3 無効になるようなライセンスを自分自身で書かないようにしましょう 5. 正しい開発作業についての提案 5.1 純粋な ANSI C もしくは可搬性の高いスクリプト言語を使いましょう 5.2 正しい C 言語の互換性に留意しましょう 5.3 autoconf/automake/autoheader を使いましょう 5.4 リリースの前にコードの正当性をチェックしましょう 6. 正しい配布形態についての提案 6.1 tarball からは常に単一の新しいディレクトリに展開されることを確認しましょう 6.2 README を用意しましょう 6.3 標準的なファイル命名規則を重んじてそれに従いましょう 6.4 RPM バイナリパッケージを提供しましょう 7. 正しいコミュニケーションについての提案 7.1 c.o.l.a でアナウンスしましょう 7.2 関連する Newsgroup にアナウンスしましょう 7.3 Web サイトを用意しましょう 7.4 プロジェクトのメーリングリストを用意しましょう 7.5 主要なアーカイブサイトに置きましょう 8. 正しいプロジェクト運営に関する提案 ______________________________________________________________________ 1. はじめに 1.1. この文書が書かれた背景 オープンソースのコードをめぐっては、誰かがそれを移植し、使用し、開発に 協力することを妨げることのないよう、数多くの伝統ある良き慣習が存在して います。それらの慣例のいくつかは Unix および Linux の世界で伝統的に受 け継がれてきたものです。その他の慣例は、 World Wide Web のような特徴あ る新しい技術やツールに関連して、最近になって生み出されたものです。 この文書は正しい慣習について知るための一助となるでしょう。各章の見出し には、それぞれがチェックリストの項目となるように要旨をまとめました。あ なたの配布物が旅に出る前の点検項目とお考え下さい。 1.2. この文書の最新の版 この文書は毎月 comp.os.linux.answers に投稿されます。また metalab.unc.edu の pub/Linux/docs/HOWTO を含め、数多くの Linux FTP サ イトに保管されています。 また、この HOWTO の最新の版を World Wide Web では で読むことができます。 この HOWTO に関する質問や意見は Eric S. Raymond, esr@snark.thyrsus.com 宛にお気軽にお寄せ下さい。 1.2.1. 翻訳文に関して この HOWTO の日本語版は で最新のものを読むことができます。訳文に 関する質問や意見は 宛にお寄せ下さい。 なお、翻訳文には JF Project の以下の方々の意見・校正が反映されていま す。 o 武井伸光さん 2. 正しいプロジェクトとアーカイヴの命名規則についての提案 Metalab や PSA そして CPAN のようなアーカイヴサイトの管理者にかかる負 担が増えるにつれて、登録作業の一部あるいは全てをプログラムによって処理 するという傾向になってきています (つまり、人間によって行われるのではな いということです)。 これによってプロジェクトとアーカイヴファイルの名称が、計算機のプログラ ムによって解析し理解されるよう、正しい形式で名前付けされていることの重 要性が増しました。 2.1. 基本名称 + major.minor.patch 番号という GNU スタイルを使いましょ う もし全てのアーカイヴのファイルに GNU のような名前付け -- つまり小文字 のアルファベットから成る基本名称を頭に付けて、ダッシュ (-) を付加し、 続けてバージョン数字列、拡張子、その他の識別子を付けるやり方 -- がされ ていたら、これは誰の目にもわかりやすいものになります。 仮に `foobar' という名前で呼ばれているプロジェクトの、バージョン 1、リ リース 1、パッチレベル 3 があるとしましょう。もしそれが単一のアーカイ ヴとして成立しているなら (おそらくはソースコードでしょう)、以下のよう な名前付けがいいでしょう: foobar-1.2.3.tar.gz ソースアーカイヴ foobar.lsm LSM ファイル (Metalab に登録する場合). 次のようなのは ダメ です: foobar123.tar.gz これは多くのプログラムに `foobar123' という名のプロジェクトのバ ージョン番号のないアーカイヴと見なされてしまいます。 foobar1.2.3.tar.gz これは多くのプログラムに `foobar1' という名のプロジェクトのバー ジョン 2.3 のアーカイヴと見なされてしまいます。 foobar-v1.2.3.tar.gz 多くのプログラムはこいつを `foobar-v1' という名のプロジェクトだ と解釈されてしまいます。 foo_bar-1.2.3.tar.gz アンダースコアは人間が喋りにくいし、入力しづらいし、覚えにくいで す。 FooBar-1.2.3.tar.gz 小賢しい利己主義者と思われても構わないならば。 おまけにこれは喋 りにくいし、入力しづらいし、覚えにくいです。 ファイル名によってソースとバイナリアーカイヴや、異なる種類のバイナリを 区別したり、ビルドの時のオプションのたぐいを表現する必要があるなら、そ れらはバージョン番号の後に付加するファイル識別子として取り扱うようにし てください。つまり、以下のような方法です: foobar-1.2.3.src.tar.gz ソースコード foobar-1.2.3.bin.tar.gz バイナリ (タイプは不明) foobar-1.2.3.bin.ELF.tar.gz ELF バイナリ foobar-1.2.3.bin.ELF.static.tar.gz 静的にリンクされた ELF バイナリ foobar-1.2.3.bin.SPARC.tar.gz SPARC 向けバイナリ `foobar-ELF-1.2.3.tar.gz' みたいなのはやめましょう。これはプログラムが 基本名称から内部識別子 (`-ELF' のような部分) を導き出しにくくなるから です。 よい名前の一般的形式は、以下のような部分から順番に成り立っています: 1. プロジェクトの基本名称 2. ダッシュ (-) 3. バージョン番号 4. ドット (.) 5. "src" または "bin" (任意) 6. ドットまたはダッシュ (ドットが望ましい) 7. バイナリタイプと付記事項 (任意) 8. アーカイヴと圧縮手段の識別子 2.2. それでも「郷に入っては郷に従いましょう」 プロジェクトやコミュニティによっては、名前付けとバージョン番号について 明確に定義された慣習があり、その場合は上記のアドバイスにならう必要はあ りません。たとえば Apache のモジュールには mod_foo のような名前が一般 的に使われており、それ自身のバージョン番号とそれが動作する Apache のバ ージョン番号の両方が付加されています。同様に Perl のモジュールには浮動 小数点として取り扱い可能なバージョン番号が付けられていて (たとえば 1.3.3 のような形式よりも 1.303 のような形式を見ることが多いでしょ う)、Foo::Bar というモジュールのバージョン 1.303 の配布物には、Foo- Bar-1.303.tar.gz という名称が付けられることが一般的です。 コミュニティと開発集団に独自の慣習を調べ、それを大切にしてください。 2.3. プロジェクトには特徴ある、入力しやすい基本名称を選びましょう 基本名称はプロジェクトのファイル全体を通して共通のものとし、それは読み やすく、入力しやすく、そして覚えやすいものにするべきです。アンダースコ ア(_)を使うのはやめましょう。それと、格段の理由のない限り、全体あるい は一部にでも大文字を使うのはやめましょう。人間の目視による自然な検索順 序を困惑させることになりますし、まるで小賢しく立ち振舞おうとする下衆な 利己主義者みたいじゃないですか。 ふたつの異なるプロジェクトが同じ基本名称を持つと、みんなが混乱します。 はじめてのリリースの前には名前が衝突してないかをチェックしましょう。こ のチェックには index file of Metalab が便利です。 3. 正しいライセンスと著作権に関する提案: 基礎篇 あなたの選択するライセンスには、共同開発者たちとユーザの間で合意したい 社会的な契約事項が定義されることになります。また、ソフトウェアに授けた 著作権は、ソフトウェアとそこからの派生物に関するライセンス事項におい て、主としてあなたの権利を法的に主張するものとして機能します。 3.1. オープン・ソースと著作権 パブリック・ドメインでないかぎり、全ての著作物には、ひとつないしは複数 の著作権が存在しています。ベルヌ条約 (1978 年からアメリカ合衆国でも有 効な法律) の元では、著作権は必ずしも明示されなくてもよいことになってい ます。したがって、仮に著作権が明示されていなくても、著作者は著作権を保 持していることになります。 誰を著作者としてカウントするか、ということは、特に多数の人の手が加わっ たソフトウェアの場合、大変な難問となり得ます。ライセンス条項が重要であ る理由がここにあります。協定の内容によっては、それを設定することによっ て、著作権の保持者による独断的な行動から自身を守る権利を、ユーザたちに も認めることができるようになります。 独占状態にあるソフトウェアでは、ライセンス条項は専ら著作権を保護するも のとして設計されています。所有者 (著作権保持者) には法的分野における幅 広い権利を認める一方で、ユーザにはほんのわずかな権利しか認めない、とい うやり方です。著作権保持者こそが一番重要であり、またライセンスの論理に おける制限があまりに厳しいために、ライセンス条項そのものの厳密な特記事 項は大抵の場合あまり重要でなかったりします。 オープン・ソース・ソフトウェアにおいては、状況はまったく正反対です。著 作権はライセンスを保護するために存在しています。著作権保持者が常に維持 できる唯一の権利は、ライセンスを強く主張することだけです。その一方で、 ほんのわずかな権利を除く、ほとんど全ての選択権はユーザにあります。とり わけ、著作権保持者はすでに人手に渡ったコピーに関する条項は変更できませ ん。それゆえ、オープン・ソース・ソフトウェアにおいては、著作権保持者は ほとんど無力です。しかし、ライセンス条項はとても重要な意味を持っていま す。 通常、プロジェクトの著作権保持者はその時点でのプロジェクトリーダーか、 プロジェクトを援助している組織です。プロジェクトを新しいリーダーに引き 継ぐことが、著作権保持者が変わることによって示されることもよくありま す。しかしながら、これは絶対的に堅固なルールというわけではありません。 たとえば多くのオープン・ソース・プロジェクトには複数の著作権保持者が存 在していますが、このことが法的な問題を引き起こしたという実例は過去にあ りません。 いくつかのプロジェクトは著作権を Free Software Foundation に譲渡するこ とを選択しています。この組織はオープン・ソースを防御することに関心があ り、そのために法律家の力も借りることができる、という考えに基づくもので す。 3.2. オープン・ソースである条件 実際のライセンス供与にあたり、そのライセンスが誘引するいくつかの異なっ た種類の権利について、区別して考えることができます。複製・再配布する権 利、使用する権利、個人的な用途にあわせて改変する権利、そして改変したも のの複製物を再配布する権利です。どの権利においてもライセンスによって制 限が加えられる可能性があります。 あるソフトウェアを ``オープン・ソース'' あるいは ``フリー'' (古くから の用語) と定義づける条件について、深く掘り下げて考察した結果が Open Source Initiative にまとめられています。こ こではライセンスに関して以下のような制限事項が要求されています : 1. 複製に関しては無制限の権利が認められていること 2. 使用に関しては無制限の権利が認められていること 3. 個人的使用を目的とした改変に関しては無制限の権利が認められているこ と このガイドラインでは改変をほどこしたバイナリの再配布に関する制限も禁止 されています。これは、余計な負担を強いられることなく、自分たちの作業し たコードを提供したいというソフトウェア・ディストビュータのニーズに合わ せた結果です。一方で改変したソース・コードは改変前のソース・コードとそ れに対するパッチの組合わせで再配布されるよう、作者が要求することを認め ています。これによって当初の作者の意図と、第三者による改変の様子を ``追跡調査'' する仕組みが確立できることになります。 OSD は `OSI Certified Open Source (OSI 公認オープン・ソース)' 認定マー クの法的な定義であり、どんな人でも歩み寄れるように ``フリー・ソフト ウェア'' をより良く定義したものです。全ての標準的なライセンス (MIT, BSD, Artistic, そして GPL/LGPL) がこれに合致します (ただし、GPL のよう ないくつかのライセンスには、それを選択する前に理解しなければならない別 の制限事項も存在しています)。 非商用に限定して使用を許可するライセンスは、たとえ ``GPL'' あるいはそ の他の標準ライセンスによる装飾がされていたとしても、オープン・ソースの ライセンス形態は満たしていない ことに注意してください。それは特定の職 業、人間、集団を差別するものなのです。そして、CD-ROM 配布業者やオープ ン・ソース・ソフトウェアを商業的に普及させようとする人々にとっては、非 常に悩ましい頭痛の種となるのです。 4. 正しいライセンスと著作権に関する提案: 実践篇 これまでに説明してきた一般法則を実践に移す方法について説明します。 4.1. 自分自身、または FSF を著作権保持者にしましょう 法律家を擁するスポンサー団体による支援がある場合、その団体に著作権を渡 したい、というケースもあるでしょう。 4.2. Open Source Definition に準じたライセンスを設定しましょう Open Source Definition は、この世界におけるライセンスの確固たる標準で す。 OSD そのものはライセンス条項ではなく、あるライセンス条項がオープ ン・ソース・ライセンスとして機能することを保証するための、必要最小限の 権利関係を定義づけるものといえます。 OSD とそれを補足するものは Open Source Initiative のウェブ・サイトから入手 できます。 4.3. 無効になるようなライセンスを自分自身で書かないようにしましょう すでに普及している OSD 準拠のライセンスには、大変よく確立された伝統あ る解釈が盛り込まれています。開発者は (その気さえあれば、ユーザも) それ らが意図するものを理解しており、納得できるならリスクを引き受け、そして 自らの関与したものを交換取引するのです。ですから、可能な限り OSI のサ イトにある標準的なライセンスのどれかを利用するようにしましょう。 もし自分自身でライセンス条項を書かなければならないなら、 OSI によって 認定を受けるようにしましょう。これによって際限のない論争と無駄を回避す ることができるでしょう。ライセンスについての議論の応酬がいかに始末に負 えないものになるか、あなたがそれを経験していないなら想像もつかないで しょうが、ライセンスはオープン・ソース社会の真核部分に触れるほとんど宗 教がかった誓約に関するものなので、人々はつい激情に駆られやすくなってし まうのです。 さらにいえば、もしあなたのライセンス条項が法廷で審判を受けることになれ ば、すでに確立された解釈体系の存在がいかに重要であるか、証明されること になるでしょう。これを書いている時点 (1999 年後半) では、どのオープ ン・ソース・ライセンスに関しても、有効・無効のどちらの判例もありませ ん。しかしながら、これは起源となった共同体においては当然予期され、また 妥当な慣習に基づいたライセンス条項および契約事項であると法廷で解釈され るはずの、法律的に有効な主張です (少なくともアメリカ合衆国では。そして おそらくイングランドとそれ以外のブリテン諸国など、他の慣習法に則った国 々でも)。 5. 正しい開発作業についての提案 ここで触れる話題のほとんどは、Linux 圏のみならず、他の Unix も含めた移 植性の確保に関係するものです。他の Unix へ移植可能であるということは、 プロフェッショナリズムとハッカー主義の美徳であるだけでなく、将来におい て Linux 自体に変化が起きた場合にそなえた貴重な保険ということもできま す。 結論から言えば、誰かがあなたのコードを Linux 以外のシステムにおいてビ ルドしようとするのは明らかです。移植性を高めておけば、あなたが受け取る 煩わしくて面倒な email の数を減らすことができるでしょう。 5.1. 純粋な ANSI C もしくは可搬性の高いスクリプト言語を使いましょう 移植性と安定性のために、ANSI C もしくは可搬性の保証されているスクリプ ト言語を使いましょう。プラットフォームを越えて単一の実装が存在している からです。 これに適合するスクリプト言語としては、 Python, Perl, Tcl, そして Emacs Lisp などがあります。プレインな古い shell は不合格です。微妙な違いのあ る、たくさんの異なる実装が存在していますし、エイリアスのようなユーザカ スタマイズによって、 shell の実行環境がごちゃごちゃになっていることも 想定されるからです。 Java は可搬性の高い言語であることを約束していますが、今のところ Linux で利用できる実装は完全ではなく、 Linux との親和性も貧弱です。 Java は 成熟するに連れてさらに人気を増していくように見えますが、現時点ではまだ 薄氷を踏むような選択と言えます。 5.2. 正しい C 言語の互換性に留意しましょう C 言語で開発しているなら、ANSI で用意されたすべての機能を好きなように 使ってください。モジュール間の矛盾を洗い出すために便利なファンクショ ン・プロトタイプもこれに含まれます。旧式の K&R コンパイラはすでに歴史 の遺物です。 その一方で、たとえば `-pipe' オプションやネストされた関数構造など、 GCC 固有の機能が使えると仮定してはいけません。誰かが Linux 以外、GCC 以外のシステムに移植する際に、この問題が付きまとい、困らせることになり ます。 5.3. autoconf/automake/autoheader を使いましょう C 言語で開発しているなら、システムの環境設定を探査したり、 makefile を 仕立てたりといった、可搬性にまつわる事柄を操作するために、 autoconf/automake/autoheader ユーティリティーを使いましょう。今日で は、ソースからビルドする際に、 "configure; make" とタイプして、きれい に、そして正しく作り上げられることを人々は期待しているのです。 5.4. リリースの前にコードの正当性をチェックしましょう C 言語で開発している場合は、リリースの前に少なくとも一回は -Wall オプ ションを付けてテストコンパイルを行い、エラーが出ないことを確認しましょ う。これは非常に多くのエラーを検出します。究極を目指すなら、-pedantic オプションを付けてコンパイルしてみましょう。 Perl で書いている場合は、コードに -c (場合によっては -T) オプションを 付けてチェックしてみましょう。信心深く行うなら perl -w と `use strict' ですね (これについては Perl のドキュメントを参照してください)。 6. 正しい配布形態についての提案 これから述べるガイドラインでは、誰かが配布物をダウンロードし、中身を取 り出して展開した際に、配布物はどのように現れるべきか、という事を説明し ます。 6.1. tarball からは常に単一の新しいディレクトリに展開されることを確認 しましょう 開発の初心者が冒しやすい誤りの中で、もっともわずらわしいものは、配布物 中のファイルとディレクトリをカレントディレクトリにぶちまけ、すでにそこ にあるファイル群を上書きする可能性のある tarball を作ってしまう、とい うものです。こうしては絶対にいけません！ これを避けるには、アーカイヴされたファイルを全てプロジェクト名で始まる 専用のディレクトリに入れれば、現在のディレクトリの直下にある、単一の トップ・ディレクトリの中に展開されるでしょう。 これを完璧に行うための makefile の裏技があります。配布物のディレクトリ が `foobar' という名前で、 SRC という変数には配布ファイルのリストが 入っているとします。これには GNU tar 1.13 が必要です。 VERS=1.0 foobar-$(VERS).tar.gz: tar --name-prefix='foobar-$(VERS)/' -czf foobar-$(VERS).tar.gz $(SRC) もし古い tar を使っている場合は、以下のようにします。 foobar-$(VERS).tar.gz: @ls $(SRC) | sed s:^:foobar-$(VERS)/: >MANIFEST @(cd ..; ln -s foobar foobar-$(VERS)) (cd ..; tar -czvf foobar/foobar-$(VERS).tar.gz `cat foobar/MANIFEST`) @(cd ..; rm foobar-$(VERS)) 6.2. README を用意しましょう ソース配布物のロードマップとなる README もしくは READ.ME というファイ ルを用意しましょう。古来の言い伝えでは、これはソースを展開した勇敢なる 探検者たちが最初に目にして読むはずの書、ということになっています。 README の中に書いておきたい項目は: o プロジェクトの概要説明. o プロジェクトの Web サイトへのポインタ(もしあるなら). o 開発者のビルド環境と可搬性についての説明. o 重要なファイルとサブディレクトリについて説明したロードマップ. o ビルドとインストールの手引き、または同じ内容を含んだファイルへのポ インタ. (大抵は INSTALL というファイル) o 管理者/関係者のリスト、または同じ内容を含んだファイルへのポインタ. (大抵は CREDITS というファイル) o プロジェクトに関する最近のニュース、あるいは同じ内容を含んだファイ ルへのポインタ. (大抵は NEWS というファイル) 6.3. 標準的なファイル命名規則を重んじてそれに従いましょう README ファイルを読むより先に、勇敢なる探検者たちは展開した配布物の トップディレクトリのファイル名を探索するでしょう。ファイルの名称は、そ れ自体が情報を含んでいます。標準的な名前付けの慣例を踏襲することによっ て、次に何を見るべきなのかという重要な手がかりを、探検者たちに示すこと ができます。 標準的なトップレベルのファイル名とそれが意味するものについて説明しま しょう。配布物にこれら全部が必要ではありません。 README または READ.ME 最初に読む案内書 INSTALL 設定・ビルド・インストール方法の解説 CREDITS プロジェクトに対する貢献者のリスト NEWS プロジェクトに関する最近のニュース HISTORY プロジェクトの履歴 COPYING プロジェクトのライセンス (GNU 流の慣習) LICENSE プロジェクトのライセンス MANIFEST 配布物に含まれるファイルの一覧 FAQ プロジェクトに関して、よく尋ねられる質問とその回答を記したプレイ ンテキストのドキュメント TAGS Emacs や vi で利用するタグファイル これらのファイル名が全て大文字で構成されているという慣習は、それらがビ ルドの部品として使われるのではなく、パッケージに関する一般的情報を含ん だ人間が読むべきものだと暗示していることに注意してください。 6.4. RPM バイナリパッケージを提供しましょう インストールに使われるバイナリパッケージの事実上の標準フォーマットは、 Red Hat Package Manager, RPM です。これはもっとも人気のある Linux ディ ストリビューションの特長となっており、事実上他の Linux ディストリビュ ーションでもサポートされています (Debian と Slackware は除きます。ただ し Debian では RPM からインストールすることも可能です)。 したがって、ソースコードの tarball と同様に、インストール可能な RPM 形 式のファイルをプロジェクトのサイトで提供するのは良い考えです。 また、ソース・コードの tarball の中には RPM の spec ファイルを含め、 Makefile の中ではそこから RPM を生成する仕組みを提供するのも良い考えで しょう。 spec ファイルには rpm の -t オプションで tarball から見つけら れるように、 `.spec' という拡張子を与えておきましょう。 形式に関して点数を稼ぎたいなら、 Makefile あるいは version.h を読み込 んで正しいバージョン番号を自動的に返すような Shell スクリプトを利用 し、spec ファイルを生成するようにしましょう。 7. 正しいコミュニケーションについての提案 あなたのソフトウェアは、その存在を知られない限り世界に貢献することはで きません。また、プロジェクトの存在をインターネット上で明らかにすること は、ユーザを増やしたり共同開発者を募るのに役立つでしょう。これについて の標準的な手法に関して解説します。 7.1. c.o.l.a でアナウンスしましょう comp.os.linux.announce で新たなリリース のお知らせをしましょう。 それ自体がよく購読されている Newsgroup である上に、 Freshmeat のような Web ベースで新着情報を扱うサイトへ も転送されています。 7.2. 関連する Newsgroup にアナウンスしましょう あなたのアプリケーションに直接関連する USENET の Newsgroup を見つけ て、そこでもアナウンスしましょう。慎みを持って、ソフトウェアとしての機 能が関係する Newsgroup にのみ投稿してください。 例えば IMAP サーバに問い合わせを行う Perl で書かれたプログラムをリリー スしようとしているなら、間違いなく comp.mail.imap には投稿するべきで しょう。しかしプログラムが Perl の先鋭的テクニックのお手本にもなるもの でなければ、おそらく comp.lang.perl には投稿しない方がよいでしょう。 アナウンスにはプロジェクトの Web サイトの URL も示しておきましょう。 (訳注: 日本語の Newsgroup では fj.sources でソフト ウェア公開のアナウンスがされています。本来テキストエンコードされたソー スコードのアーカイブを、直接投稿する Newsgroup でしたが、最近はアナウ ンスのみを投稿することの方が増えています。投稿する記事には Followup- To: ヘッダで fj.sources.d を指定することがマナーと なっています。) 7.3. Web サイトを用意しましょう プロジェクトのユーザあるいは開発者のコミュニティをしっかりと築くことを 目指すならば、 Web サイトを用意した方がよいでしょう。 Web サイトに用意 する標準的な内容は以下のようなものです: o プロジェクトの目的 (存在の意義、対象となる読者、等々). o プロジェクトのソースをダウンロードできるリンク. o プロジェクトのメーリングリストへの加入方法. o FAQ リスト (よくある質問と回答集). o プロジェクトのドキュメントを HTML 化したもの. o 関連する、あるいは競合するプロジェクトへのリンク集. プロジェクトのサイトによっては、一次ソースツリーへの匿名アクセスが可能 な URL を用意することもあります。 7.4. プロジェクトのメーリングリストを用意しましょう 開発の協力者が交流を行い、パッチを交換できるような非公開のメーリングリ ストを用意することが一般によく行われています。プロジェクトの進歩状況を 知らせて欲しい人々を対象とした、アナウンスのためのメーリングリストが あってもよいでしょう。 7.5. 主要なアーカイブサイトに置きましょう ここ数年の間、 Metalab archive は Linux のソフトウェアのための重要な拠点となってきました。 それ以外に以下のような重要なサイトがあります: o the Python Software Activity site (Python で書かれたソフトウェア用). o the CPAN , the Comprehensive Perl Archive Network. (Perl で書かれたソフトウェア用). 8. 正しいプロジェクト運営に関する提案 関係者がみなボランティアである場合、プロジェクトを上手に運用するという ことは、それ自体が特殊な課題となります。このことは、この HOWTO で取り 上げるには大きすぎる題材です。幸いなことに、これに関する要点を理解する ための助けとなる、幾つかの文書が存在しています。 基礎となる開発集団と、 The Cathedral and the Bazaar (伽藍とバザール) を参照してくだ さい。 動機付けに関する考察、共同体の風習、衝突の解決といった話題については、 Homesteading the Noosphere (ノウアスフィアの開墾) をご覧下さい。 経済的側面と適切なビジネス・モデルに関しては、 The Magic Cauldron (魔 法のおなべ) . を 参照してください。 これらの文書はオープン・ソース開発に関する決定版というわけではありませ ん。しかし、もっとも早くに書かれた意義深い分析であり、これに代わる文書 は未だに出てきていません。 (訳注: この節で取り上げた文書の翻訳が以下で参照できます。 o http://www.post1.com/home/hiyori13/freeware/cathedral.html The Cathedral and the Bazaar (伽藍とバザール), Eric S. Raymond 著, 山形 浩生 訳 o http://www.post1.com/home/hiyori13/freeware/noosphere.html Homesteading the Noosphere (ノウアスフィアの開墾), Eric S. Raymond 著, 山形浩生 訳 o http://www.post1.com/home/hiyori13/freeware/magicpot.html The Magic Cauldron (魔法のおなべ), Eric S. Raymond 著, 山形浩生 + 田宮まや 訳 )