オープンソースプロジェクトでプログラマーを管理している場合、 技術的、政治的にうまくやっていくスキルを身につけるまで彼らをそこに留めるようにしましょう。 — それには最低でも2〜3年は必要です。 もちろん、オープンソースプロジェクトであれ、クローズドなプロジェクトであれ、 開発者を頻繁に入れ替えたりすると利益は得られません。 初心者が仕事のコツを覚えるのに必要なのは、どんな環境であってもそこに留まることです。 開発者を頻繁に入れ替えると、オープンソースプロジェクトではより不利になってしまいます。 なぜなら、出て行くプログラマーはコードに関する知識だけでなく、 そのコミュニティーで得た地位や人間関係も持って行ってしまうからです。

開発者がオープンソースプロジェクトで得た信頼は、人に伝えることができません。 一番わかりやすい例をあげましょう。新たに参加する開発者は、 プロジェクトから出て行く人からコミット権限を引き継ぐことは出来ません。 (この章の後の方にある 「カネで愛は買えない」 を参照してください) コミット権限がないので、新しい開発者はそれが得られるまでパッチを提出しなければいけません。 しかし、コミット権限だけが失われた信頼を測る唯一の要素ではありません。 長期に渡ってプロジェクトに関わった開発者は、 メーリングリストでの雑多な古い議論に関する知識もあります。 新しい開発者にはそうした知識がないので、古い議論を蒸し返そうとするかもしれません。 それによってプロジェクトでの信頼がなくなってしまうかもしれないのです。 つまり、「お前何も覚えてないのかよ？」と思われてしまうのです。 新しい開発者は、プロジェクトにいる個人が持つ政治的な力に関する感覚もないので、 長くプロジェクトにいた開発者ほど、 開発の方向性について、円滑に影響力を発揮することははできないでしょう。

新しい開発者については、計画に基づいて訓練するようにします。 彼には初日から開発コミュニティーと直接連絡をとらせ、 バグ修正やコードを掃除するタスクを始めさせるべきです。 それによってコードベースを学び、コミュニティーで信頼を得ることができます。 しかし、長い時間がかかる、複雑な設計の議論の火付け役にはならないようにします。 いつも新しい開発者の質問に答えてくれたり、 経験を積んだ開発者が普通は気に留めないようなスレッドでも、 彼のメーリングリストへの投稿を読んでくれている先輩の開発者がいるはずです。 こうすることで、新しい人が活躍する前から開発グループを潜在的に刺激することができます。 自分のコードを多くの人からピアレビューされることに開発者が慣れていない場合は、 裏で励ましたり、ポインタを示してあげたりすることも大いに役立つでしょう。

CollabNet が Subversion プロジェクトで働いてもらうために開発者を雇うときは、 一緒に話し合って保留中のバグをいくつか選んでもらい、経験を積んでもらいます。 バグを解決するための技術的な概要を話し合い、 新しい開発者が（公の場に）投稿する修正プログラムを（これも公の場で）レビューするために、 経験を積んだ開発者を少なくともひとり割り当てます。 メインの開発用メーリングリストで公になる前は、 私たちは彼のパッチを見ることさえしません。理由があれば見ることもできるわけですが。 重要なのは、新しい開発者が公の場で行われるレビューの過程を経験し、 全く知らない人から批判を受けることに慣れると同時に、コードベースを学ぶことです。 しかし私たちは、彼のパッチが投稿された後、 自分たちのレビューがすぐに行われるようにタイミングを調整しようとします。 こうして、メーリングリスト上での最初のレビューを自分たちが行うようにすると、 他の人のレビューの口調を抑えるのに役立ちます。 また、新しい人を真面目に扱おうという考え方を浸透させることができます。 適切なメーリングリストのアーカイブを参照したり、説明をすることで、 詳細なレビューに時間を割いているのを外部の人が見ると、 新しい開発者の訓練が行われていて、彼に対して長期に渡って投資を行うことがわかるのです。 こうすることで、開発者が少なくとも質問に答えたり、 パッチをレビューするのに時間を割こうという気にさせることができるのです。