独占的なソフトウェアの開発では、バグ探しやパフォーマンス、 スケーラビリティのテスト、インターフェイスやドキュメントの確認、 などの品質保証専門チームを置くことが普通です。 フリーソフトウェアプロジェクトのボランティアなコミュニティーでは、 品質保証に関する活動は積極的に行われないのが一般的です。 これはテストのような地味な仕事をやってくれるボランティアの人はなかなか見つかりませんし、 ユーザー数が多いプロジェクトのコミュニティーでは、 テストの網羅率が高くなると人々が考えるということもあります。 また、パフォーマンスやスケーラビリティのテストの場合は、 ボランティアは必要なハードウェアリソースを得られないから、 ということもあります。

多くのユーザーを抱えているプロダクトには多くのテスターがいる、 という考えは全く根拠がないものではありません。一般的な環境で、 基礎的な機能にテスターを割り当てるのはあまり意味がないのは確かです。 なぜなら、そういう状況ではバグがすぐに見つかるのが自然の流れだからです。 しかし、ユーザーはただ仕事をこなそうとするだけなので、 プログラムの動作の限界を意図的に探そうとはしません。 よってある程度のバグが残る可能性があります。 さらに、容易に回避する方法があるバグの場合、 ユーザーはバグを報告せずに黙ってその回避策を使ってしまうことが多いです。 もっとも油断ならないのは、あなたの顧客 (あなたが 関心がある人たちです) のソフトウェアの使い方が、 そこら辺にいる平均的なユーザーの使い方と違う場合があることです。

テスト専門のチームは、 こうした手合いのバグをフリーソフトウェアでも発見してくれます。 難しいのは、テストチームが行った作業の結果を、 わかりやすい方法で皆に伝えることです。 組織内のテスト専門部署は、 テスト結果を報告する独自のやり方をそれぞれ持っています。 たとえば企業独自の方言や、 特定の顧客や彼ら向けのデータに関する特定の知識などです。 こういった独自の情報は、書式や秘密保持の観点から、 公開されているバグ追跡システムに載せるのは不適切です。 たとえあなたの企業で使っているバグ追跡システムが、 フリーソフトウェアプロジェクトのそれと同じだったとしても、 特定の企業向けのコメントやバグに関するメタデータ (たとえば、バグに対する内部的な優先度や、 特定の顧客向けに解決するスケジュール) を作る必要があるでしょう。 こうした情報は外部には漏らさないのが普通です— 場合によっては、顧客にすらみせてはいけないものです。 しかし、たとえ秘密でなくても、 それらはフリーソフトウェアプロジェクトにとっては関心がないものです。 よって、そうした情報に気を取られてはいけません。

しかしながら、バグ報告そのもの はフリーソフトウェアプロジェクトにとって重要なものです。 実際、テスト専門のチームからあがってきたバグ報告は、 多くのユーザーから受け取るそれよりもある意味価値があるものです。 なぜなら、彼らはユーザーが調べてくれないことを調べてくれるからです。 テストチームからしかあがってこないバグ報告がある場合、 確実に保存してフリーソフトウェアプロジェクトが利用できるようにしておきます。

確実に保存するには、彼らが直接バグ追跡システムに問題を登録するか、 彼らとの仲介役 (通常は開発者のひとり) が、 内部向けのバグ報告を新しいものに「翻訳」してバグ追跡システムに登録するようにします。 ここでいう「翻訳」とは、単に顧客特有のデータ (バグの再現手順には、 勿論顧客の同意を得た上で顧客のデータを使う場合があります) を参照せずにバグについて説明することです。

テストチームが直接問題を登録する方がどちらかといえば望ましいです。 こうすることで、あなたの企業がプロジェクトに直接貢献していることをアピールできるからです。 役に立つバグ報告をすると、 技術的な貢献をすることと同じくらいあなたの組織への信頼は高まります。 これは開発者にとっては、 テストチームと直接話をする機会に繋がります。 たとえば、テストチームがプロジェクトのバグ報告システムを見張ってくれている場合、 開発者はスケーラビリティに関するバグ (これをテストするリソースを彼らは持たない場合があります) を修正する作業に注力でき、 その修正が望ましい結果を出しているか検証するよう、 バグ追跡システム上にコメントすることでテストチームに頼むことができます。 開発者から多少の抵抗があることは覚悟しておいてください。 プログラマーは、テストをせいぜい必要悪くらいにしか思わない傾向があるからです。 テストチームが重要なバグを発見し、 理解しやすいバグ報告を行えば、こうした抵抗を振り払うのは簡単です。 一方、彼らのバグ報告の質がユーザーからあがってくるそれと大差ない場合は、 開発者と彼らが直接話をする意味はありません。

どちらにせよ、組織内部のバグ報告が、 外部のバグ追跡システムにいったん登録されたら、 組織内部の情報は、そのバグ追跡システムのものを参照させるべきです。 組織の管理者や雇われている開発者は、 必要に応じて顧客に特有の情報について注釈を付けても構いませんが、 みんなが使えるようにするために、外部の情報を利用するようにしましょう。

こうした作業の過程で、あなたには余計な負担が掛かるはずです。 ひとつしかバグがないのに二重にバグ報告を管理するのは、 ひとつを管理するのに比べて仕事が多くなるのは当然です。 ただ、こうすることで多くのプログラマーがバグ報告の情報を利用でき、 問題の解決に貢献できるようになるのです。

営利企業であれ、非営利な組織であれ、 法人はフリーソフトウェアに潜む複雑な法律問題に注意を払う機会があるほぼ唯一の組織です。 開発者個人は、オープンソースライセンスの微妙な違いを理解している人もいますが、 著作権、商標、そして特許に関する法律の詳細を理解するためのリソースも時間もないのが普通です。 あなたの組織に法務部がある場合、 プログラムについている著作権の状態を調査したり、 実際に起こりうる特許や商標の問題について開発者に具体的に助言することができます。 こうした点で開発者を助ける正しいやり方は、 10章ライセンス、著作権、特許 で議論しています。 もっとも重要なのは、法務部と開発者コミュニティーがコミュニケーションを取る必要がある場合、 それぞれが全く違う世界にいることを認識した上で話をすることです。 お互いが過去に話したことがある場合もあれば、 一方が全く知らない専門領域に関する知識を持っているものとめいめいが思い込んでいる場合もあります。 一番よいのは、仲介役となる人 (開発者か、技術的な専門知識をもった弁護士) を必要な限り間に置くことです。

ドキュメントとユーザビリティは、両方ともオープンソースプロジェクトの弱点として有名ですが、 私は少なくともドキュメントについては、独占的なソフトウェアとの違いが誇張されていると思っています。 とは言っても経験上は、素晴らしいドキュメントやユーザビリティ調査が多くのオープンソースプロジェクトに欠けているのは事実です。

あなたの組織がプロジェクトにあるこれらの穴を埋めたいのなら、 プロジェクトの開発者ではなく、 彼らと建設的に話ができる人を雇うとよいでしょう。 プロジェクトの開発者を雇わない方がよい理由はふたつあります。 ひとつは、プロジェクトから離れてしまうと開発する時間がとれなくなること。 もうひとつは、対象となるソフトウェアにあまりにも距離が近い人は、 第3者の視点からそれを眺めるのが難しいために、 ドキュメントを書いたりユーザビリティを調べるのに普通向いていないからです。

しかしながら、開発者と話をしながらこれらの問題に取り組んでくれる人は必要です。 彼らと話せるだけの技術スキルがあるものの、対象となるソフトウェアに精通しておらず、 普通のユーザーに感情移入できる人を探しましょう。

中級者レベルのユーザーが、ドキュメントを書くのに多分向いているでしょう。 実際、この本の第1版が世に出たあと、 私は Dirk Reiner というオープンソースソフトウェアの開発者から次のようなメールを受け取っています。

    「5.カネに関する問題」の「ドキュメントやユーザビリティの改善」についてひと言。
    もし人に支払えるだけのお金があって、もっとも必要となっているのが初心者向けの
    チュートリアルだという話になったとき、私が実際に雇ったのは中級者レベルのユー
    ザーでした。彼はシステムに関する研修を最近受けていたので、何が問題になるのか
    を覚えていましたし、問題を乗り越えてきていたので、どう人に説明すればいいかを
    分かっていました。このため、彼が書いたドキュメントは、彼自身が理解できなかっ
    た部分については、開発者がちょっと修正すればすみましたし、開発者が「自明な」
    ものとして見逃していた部分も網羅できていたのです。
 
    もっとも、彼の仕事は多くの人(生徒)にシステムを紹介することでした。よって彼は
    自分が教えた人達の経験、つまりほとんどの人が理解できなかったことや、たまたま
    うまくできたこと、をうまく組み合わせることができました。
    よって、彼が書いたドキュメントはさらに素晴らしいものになっていたのです。

一通りのツールが揃ったホスティングサイト ( 3章技術的な問題 の 「ツールが一通り揃ったホスティングサイト」 を参照してください) を使っていないプロジェクトに対して、 サーバやネットワーク接続を提供— もっとも重要なのはシステム管理を手助けすることですが—すると、 プロジェクトが大いに助かる可能性があります。 たとえそれがあなたの組織ができる全てであったとしても、 世間的に良い評価を得るためにそれなりの手段になることでしょう。 但し、プロジェクト全体の方向性に影響を与えることはできません。

ホスティングサイトを提供していることに感謝の意を表すために、 プロジェクトのホームページにお礼の言葉を載せてもらったり、 バナー広告を貼らせてもらえることが期待できます。 ホスティングの設定にあたって、プロジェクトのURLをあなたの企業のドメイン内に設定した場合、 URLだけでプロジェクトとあなたの企業が関係があることを理解してもらえるでしょう。 これによって、あなたの企業が開発に全く貢献していなくても、 ほとんどのユーザーが 何かしらの 関係があると看做すようになります。 問題は、ユーザーがそう考えることに開発者も気づくため、 ホスティングサイトやネットワーク回線以外の開発リソースを提供しなければ、 あなたのドメイン内にプロジェクトを置くことにあまりいい感情を持たない可能性があることです。 何だかんだ言っても、最近はたくさんのホスティングサイトがあります。 コミュニティーは結局、実態に見合わないクレジットを与えるのは、 ホスティングを提供してもらう利点に見合わないと感じて、 プロジェクトを他に移してしまうでしょう。 よって、あなたがホスティングサイトを提供したいなら、そうすると良いでしょう— 但し、すぐにもっと積極的にプロジェクトに関わるプランを示すか、 自分の主張がどれくらいプロジェクトに影響を与えられるかについて、 よく考える必要があります。