あなたが雇った開発者には、プロジェクトの公のフォーラムで一枚岩の企業の人間としてではなく、 個人として振る舞ってもらうようにしましょう。 これは企業が関わることでついてまわる否定的な意味合いがあるからではありません(まぁ多分あるのでしょうが、それはこの本では触れません)。 むしろ個人こそが、オープンソースプロジェクトが構造的に扱える唯一の存在だからです。 個人の貢献者は、議論に参加したり、パッチを提出したり、信頼を得たり、 投票するなどができますが、企業にはそれができません。

それ以上に、分散した個人として振る舞うことで、 反感が一ヶ所に集中するのを避けることができます。あなたが雇った開発者には、 メーリングリスト上でお互いが反目させるようにしてみましょう。 彼らにお互いのコードを頻繁に、公の場で、赤の他人としてレビューさせるようにしましょう。 そして、いつも徒党を組んで投票させないようにしましょう。なぜならそうしてしまうと、 他の人が「こいつらは徒党を組んでいる」と感じますし、道徳的な見地から、 彼らをチェックし続けるために組織的な努力がなされるべきだからです。

実際に個人として振る舞うことと、そうしようと単に努力することは違います。 状況によっては、雇った開発者達に一致した行動をとらせた方が便利なこともありますし、 必要なときは裏で協力する準備をすべきでしょう。 たとえば提案をするとき、合意が形成されつつあることを印象付けるために、 何人かに早い段階から同意の意志を示してもらうようにします。 他の人は、その提案に勢いがあると感じるでしょうし、仮に反対すれば、 その勢いを削いでしまうとも思うでしょう。 よって、理由がある場合だけ、人々は反対するようになります。 反対意見を真摯に受け止めている限り、賛成意見を組織化することは間違っていません。 賛成意見を公の場で明らかにすることは、 たとえそれが事前に協力していたとしても真摯である点は変わりませんし、 反対意見を封殺するのに使われない限り、害はありません。 彼らの目的は、単に体裁を保つためだけに反対したがる類の人を抑えることなのです。 そういう人については、6章コミュニケーション の 「簡単な議題ほど長引く」 を参照してください。