OSS開発、“はじめの一歩”で抑えておくべきポイント：オープンソースソフトウェアの育て方（5/5 ページ）

[Karl Fogel， ]

もともと非公開だったプロジェクトをオープンにするときには、変化の大きさに気をつけよう

　既存のプロジェクトをオープンにする場合は、クローズド環境での開発に慣れきった既存の開発者がいることに注意しましょう。環境が大きく変わることを彼らに理解してもらうこと、また、彼ら側の視点で考えた場合に何がどのように変わるのかをあなた自身が理解することが大切です。

　彼らにとってその状況がどのようなものかを想像してください。これまでは、どのような設計でどのようなコードを書くのかを決めるのは特定のプログラマーの集団でした。また、彼らは同じ管理者の下で働き、同じような重圧を受けていました。そしてお互いのスキルや弱点もよく分かっていました。今やそうではありません。自分の書いたコードをチェックしてもらうためにどこの誰とも分からない人に向かって公開しなければならないのです。

　彼らは純粋にコードの内容だけを基にして判断を下します。それ以外のビジネス上の問題などは考慮しません。自分のコードについて、見知らぬ人からさまざまな質問が寄せられることになります。あんなに苦労して作ったドキュメントが、まだ不十分であることが判明して（お決まりのパターンです）衝撃を受ける瞬間です。新入りさんは、みんな誰も知らないえたいの知れない人たちばかりです。もし既存の開発者の中に自分のスキルに不安のある人がいたとしましょう。新入りさんが何も考えずに彼のコードの問題を指摘したら、彼にどのような悪影響を及ぼすでしょうか。特に、彼の同僚の目の前でそのようなことが起こったら、さらに状況は悪くなります。完全無欠のプログラマーが集まったチームでもない限り、このような問題が起こることは避けられません。実際、すべてのメンバーが一度はこのような経験をすることになるでしょう。これは、決して彼らがプログラマーとして劣っているからではありません。

　ある程度以上のサイズのプログラムには、必ずバグが含まれるものです。そして、コードのレビューによってそれが見つかることになります（本章の前半にあるきちんとしたコードレビューの習慣項をご覧ください）。と同時に、新入りさん自身は最初のうちは自分のコードをレビューされることはないでしょう。というのも、そのプロジェクトにある程度なじむまではコードを書くことができないからです。既存の開発者にとっては「奴らからさんざん批判されるだけで、こちらからは言い返すことができない」状況になるわけです。そのため、古株の開発者たちに対する総攻撃状態になる危険性があります。

　これを避ける最良の方法は、これから何が起こるのかを彼らに説明することです。最初のうちは不快に感じるかもしれないがそれは当然の心理であること、そしていつかはうまくいくようになることを説明しましょう。これらの警告は、プロジェクトをオープンにする前に閉じた場所で行わなければなりません。また、公開されたメーリングリスト上で「プロジェクトの開発方式が新しくなった」「慣れるには少々時間が掛かる」ことを知らせるのも効果的です。

　一番いいのは、何か例を示すことです。既存の開発者たちがあまり初心者の質問に答えていないようなら、彼らに「もっと返事を書いてあげてよ」といってもあまり意味がありません。彼らは単に、どう答えればいいのかが分からないだけかもしれません。あるいは、他人の質問に答えるよりも実際にコードを書く方が大切だと思っているのかもしれません。彼らを質問に答えさせるようにするには、まずあなた自身がお手本を見せましょう。公開されているメーリングリスト上で、誰かの質問に対して答えてみましょう。その質問をうまくさばくだけの専門知識がない場合は、それに対応できる開発者に明示的に対応を依頼するようにしましょう。

　そして、彼が確かに答えを返すこと、あるいは少なくとも何らかの返事をすることを確認しましょう。長年プロジェクトにかかわってきた開発者にとってはどうしても閉じた場での議論の方がやりやすく感じられることでしょう。これまではずっとそうしてきたのですから。そんなことが起こらないように内輪のメーリングリストの動きもチェックし、必要な議論は公開の場で行うように彼らを誘導しましょう。

　これまでは閉じた環境にあったプロジェクトをオープンにするに当たっては、これら以外にも長期的な懸案事項があります。章5.カネに関する問題では、給料をもらって開発に参加している人たちと無償で開発に参加している人たちとをうまく共存させる方法を考えます。また章9.ライセンス、著作権、特許では、法的な努力の必要性について考えます。ほかの団体が書いた、あるいは"所有している"コードを含むかもしれないソフトウェアを公開する場合は、それなりの注意が必要となります。

著者：Fogel Karl

翻訳者：高木 正弘

翻訳者：Takaoka Yoshinari(a.k.a mumumu)

製作著作 © 2005, 2006, 2007, 2008, 2009 Karl Fogel, 高木正弘, Yoshinari Takaoka(a.k.a mumumu), under a CreativeCommons Attribution-ShareAlike (表示・継承) license (3.0, 2.1-jp)

よいフリーソフトウェアを作ることは本質的に価値のある目標です。その方法を模索している読者の皆さんが、本連載「オープンソースソフトウェアの育て方」で何かのヒントを得てくだされば幸いです。

原文へのリンク