ボランティアの開発者コミュニティーをあなたの味方に付けるには、 はっきりしていない事柄は喋らないことが とても 重要です。 すべての主張を公にする前に注意深く調べ、その主張自体をチェックする手段も公にしておきます。 独自に事実を検証できるのは、オープンソースの重要な部分です。 それはコード以外の部分にも当てはまります。

当然のことながら、検証できない主張をするなと企業にアドバイスする人などいません。 しかし、ことオープンソースの活動においては、 主張を検証する経験に長けた人が非常に多くいます— なぜなら、広い帯域のインターネット接続回線を持ち、 物事を中傷するために社会的接触を持つ可能性がある人が大勢いるからです。 化学工業の巨大企業が川を汚染している場合、それは検証可能ですが、 検証できるのは訓練を受けた科学者のみです。 彼らは巨大企業の科学者から反論され、 頭をかきむしってどう考えたらよいのか困惑するかもしれません。 一方で、オープンソースの世界であなたがすることは、 目に見える形で記録されるだけではありません。多くの人が独立してチェックし、 独自の結論を下し、それらを口コミで広めていくのです。 この口コミのネットワークは既に定着しているものです。つまり、 オープンソースがどのように影響するかを決める要素であり、 あらゆる種類の情報を伝えるのに使われます。反論は不可能ではないにしても、 特に人々が言っていることが事実である場合は、普通難しいものです。

たとえば、"プロジェクトXを作った" とあなたの組織が言うのは、 実際にそうしたのであれば問題ありません。しかし、 実際にコードを書いたのが外部の人間である場合、 "Xというソフトウェアを作った" と言ってはいけません。 逆に、誰かがリポジトリの中身を覗いてみて、 あなたの組織以外の人が変更を加えた跡が殆どまたは全くない場合は、 ボランティアの開発者コミュニティーが深く関与していると主張してはいけません。

それほど昔のことではありませんが、 とてもよく知られているコンピューター会社が、 重要なソフトウェアパッケージをオープンソースライセンスの下で公開した、 というアナウンスを見ました。はじめのアナウンスが出た後、 私は公開されているバージョン管理システムのリポジトリを見てみましたが、 そこには3つのリビジョンしか存在していませんでした。 言い換えれば、彼らはソースコードのインポートを終えたこと以外は何もしていなかったのです。 それ自体は変な事ではありませんでした。— だって結局彼らはアナウンスしただけですから。 しかし、すぐに活発な開発が行われると期待する理由は何もなかったのです。

しばらくたってから、別のアナウンスがありました。以下にそれを示しますが、 リリースナンバーとソフトウェアの名前は別のものに置き換えてあります。

"厳密なテスト" によってコミュニティーが明らかにしたことを知りたいと思い、 私はリポジトリを再度見に行って最近の変更履歴を覗いてみました。 プロジェクト自体のリビジョンは3のままでした。明らかに、 コミュニティーはリリース前に修正すべきバグを ひとつも 見つけていなかったのです！ コミュニティーによるテスト結果がどこかに記録されているはずだと考えて、 私は次にバグ追跡システムを調べてみました。そこには確かに6つの問題が記録されていましたが、 そのうちの4つは数ヶ月の間保留状態のままだったのです。

これは勿論信じがたいことです。 テスターが巨大かつ複雑なソフトウェアをそれなりの時間使えば、 彼らはバグを見つけるものです。 たとえそうしたバグが次回のリリースに取り込まれなかったとしても、 テストの結果としてバージョン管理システム上での活動か、 新しい問題がバグ追跡システムに登録されていると期待されるはずです。 しかしながら、どこを見ても、はじめのアナウンスと、 その次のアナウンスとの間に活動の跡はみられなかったのです。

問題は、コミュニティーがテストしたことについて、企業が嘘をついたことではありません。 コミュニティーがテストしたかどうかは私には分からないからです。 しかし、彼らが言っていることがどれくらい嘘っぽいかは明らかでした。 バージョン管理システムだけでなく、バグ追跡システムにも、 厳密なテストが行われたことを示す痕跡はなかったので、 企業はコミュニティーがテストしたという主張をしないか、 目に見える形のテスト結果へのリンク ("278個のバグが発見されました。 詳細はここをクリックしてください") を提供すべきでした。 後者は誰でもコミュニティーの活動レベルを素早く把握できるようにするものです。 実際は、コミュニティーがテストしたことを探すのに2、3分しかかかりませんでしたし、 普通なら記録される場所に、テストの痕跡が全く残っていなかったのです。 検証するのに大した手間はかかりませんでしたが、 手間をかけたのは私だけではないはずです。

透明性と検証可能性は、正確なクレジットを与えるときも勿論重要です。 詳しくは、8章ボランティアの管理 の 「クレジット」 を参照してください。

競合するオープンソースプロジェクトについて、否定的な意見を述べるのはやめましょう。 否定的な 事実 については一向に構いません。 — 容易に裏が取れる主張は、比較の要素としてよく見られるものだからです。 しかし、あいまいな事柄に対して否定的な評価を行うことは避けた方が良いでしょう。 理由はふたつあります。 まず、それがきっかけで建設的でないフレームウォーが起こりがちだからです。 ふたつめは、もっと重要なことですが、 あなたの プロジェクトにいるボランティアの開発者の中からも、 競合プロジェクトで働く人が出る可能性があるからです。 前者より、後者の方が多く発生する可能性が高いです。 なぜなら、それぞれのプロジェクトは既に同じ専門領域に属していて(それゆえに競合関係にあります)、 その領域で専門知識を持っている開発者は、 それを生かせる場所であればどのプロジェクトでも貢献してよいからです。 直接的には開発者が重複していない状況でも、あなたのプロジェクトにいる開発者が、 関連するプロジェクトの開発者を知っている可能性があります。 彼らの建設的な人間関係を維持する能力が、 否定的なマーケティングのメッセージによって全て壊れてしまう可能性だってあるのです。

ソースコードが公開されていない競合プロジェクトを攻撃することは、 特にその製品がマイクロソフト製である場合は、 オープンソースの世界では広く受け入れられています。 個人的には、この傾向は (単刀直入に事実を比較するのであれば一向に構わないのですが) 残念に思っています。 なぜなら、これは相手に失礼であるからというだけでなく、 プロジェクトが自ら作っているものの誇大広告を信じ、 それゆえに競合相手が実際に優れている点を無視し始めるのが危険でもあるからです。 一般的には、マーケティングのメッセージが、 自分たちの開発コミュニティーにも影響を与えるものかどうかを注意しておくとよいでしょう。 マーケティングにお金が使われると、 開発者は自分達のソフトウェアが持っている本当の強みや弱点を、 客観的な眼で見なくなってしまいます。 このため、企業の開発者はマーケティング上のメッセージに対して、 公のフォーラム上でさえある種無関心な態度を示すのが普通ですし、 むしろそれが期待されています。 はっきりしているのは、企業の開発者はマーケティングによるメッセージに対して、 公の場で矛盾した態度を直接示してはいけない (但し、 それが実際に間違っているというのなら別ですが、 その手の事実は早い段階からわかることでしょう) ということです。 企業の開発者はそうしたメッセージをネタとして扱い、 コミュニティーをマーケティングのメッセージから現実に引き戻す手段にしているのです。