連載
» 2009年09月18日 08時00分 UPDATE

オープンソースソフトウェアの育て方:カネと開発者とプロジェクトの不思議な関係 (1/3)

オープンソースソフトウェアの開発では、プロジェクトにカネを出している人もしくは企業が存在し、また、お金をもらって雇われている開発者も存在します。しかし、カネで買えるものと買えないものは確かに存在しています。ここでは、カネと開発者とプロジェクトに関するすべてを明らかにします。

[Karl Fogel, ]

開発者を長期に渡って雇用する

 オープンソースプロジェクトでプログラマーを管理している場合、技術的、政治的にうまくやっていくスキルを身につけるまで彼らをそこにとどめるようにしましょう――それには最低でも2〜3年は必要です。もちろん、オープンソースプロジェクトであれ、クローズドなプロジェクトであれ、開発者を頻繁に入れ替えたりすると利益は得られません。

 初心者が仕事のコツを覚えるのに必要なのは、どんな環境であってもそこにとどまることです。開発者を頻繁に入れ替えると、オープンソースプロジェクトではより不利になってしまいます。なぜなら、出て行くプログラマーはコードに関する知識だけでなく、そのコミュニティーで得た地位や人間関係も持って行ってしまうからです。

 開発者がオープンソースプロジェクトで得た信頼は、人に伝えることができません。一番分かりやすい例を挙げましょう。新たに参加する開発者は、プロジェクトから出て行く人からコミット権限を引き継ぐことはできません(この章の後の方にあるカネで愛は買えない項を参照してください)。コミット権限がないので、新しい開発者はそれが得られるまでパッチを提出しなければいけません。

 コミット権限だけが失われた信頼を測る唯一の要素ではありません。長期に渡ってプロジェクトにかかわった開発者は、メーリングリストでの雑多な古い議論に関する知識もあります。新しい開発者にはそうした知識がないので、古い議論を蒸し返そうとするかもしれません。それによってプロジェクトでの信頼がなくなってしまうかもしれないのです。つまり、「お前何も覚えてないのかよ?」と思われてしまうのです。新しい開発者は、プロジェクトにいる個人が持つ政治的な力に関する感覚もないので、長くプロジェクトにいた開発者ほど、開発の方向性について、円滑に影響力を発揮できないでしょう。

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

 CollabNetがSubversionプロジェクトで働いてもらうために開発者を雇うときは、一緒に話し合って保留中のバグを幾つか選んでもらい、経験を積んでもらいます。バグを解決するための技術的な概要を話し合い、新しい開発者が(公の場に)投稿する修正プログラムを(これも公の場で)レビューするために、経験を積んだ開発者を少なくとも1人割り当てます。メインの開発用メーリングリストで公になる前は、わたしたちは彼のパッチを見ることさえしません。理由があれば見ることもできるわけですが。重要なのは、新しい開発者が公の場で行われるレビューの過程を経験し、まったく知らない人から批判を受けることに慣れると同時に、コードベースを学ぶことです。

 しかしわたしたちは、彼のパッチが投稿された後、自分たちのレビューがすぐに行われるようにタイミングを調整しようとします。こうして、メーリングリスト上での最初のレビューを自分たちが行うようにすると、ほかの人のレビューの口調を抑えるのに役立ちます。また、新しい人を真面目に扱おうという考え方を浸透させることができます。適切なメーリングリストのアーカイブを参照したり、説明することで、詳細なレビューに時間を割いているのを外部の人が見ると、新しい開発者の訓練が行われていて、彼に対して長期に渡って投資を行うことが分かるのです。こうすることで、開発者が少なくとも質問に答えたり、パッチをレビューするのに時間を割こうという気にさせることができるのです。

企業の人間としてではなく、個人として振る舞う

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

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

 実際に個人として振る舞うことと、そうしようと単に努力することは違います。状況によっては、雇った開発者たちに一致した行動を取らせた方が便利なこともありますし、必要なときは裏で協力する準備をすべきでしょう。例えば提案をするとき、合意が形成されつつあることを印象付けるために、何人かに早い段階から同意の意思を示してもらうようにします。ほかの人は、その提案に勢いがあると感じるでしょうし、仮に反対すれば、その勢いを削いでしまうとも思うでしょう。よって、理由がある場合だけ、人々は反対するようになります。

 反対意見を誠実に受け止めている限り、賛成意見を組織化することは間違っていません。賛成意見を公の場で明らかにすることは、たとえそれが事前に協力していたとしても真摯である点は変わりませんし、反対意見を封殺するのに使われない限り、害はありません。彼らの目的は、単に体裁を保つためだけに反対したがる類の人を抑えることなのです。そういう人については、章6.コミュニケーション簡単な議題ほど長引く項を参照してください。

       1|2|3 次のページへ

content on this article is licensed under a Creative Commons License.

ピックアップコンテンツ

- PR -

注目のテーマ

マーケット解説

- PR -