ボランティアの管理
そのプロジェクトが目指すゴールに向かってみんなで協力してがんばっていくには、
ただ単に「メンバーがみんな仲良くやっており、
決定的な機能不全は起こしていない」というだけでは不十分です。
プロジェクトのメンバーを管理する役割の人が必要となります。
ボランティアを管理するという技術は、
コンピュータプログラミングの「技術」とは少々異なるかもしれません。
でも、学習と実践を通してうまく行えるようになるという点では、
ボランティアの管理も一種の「技術」であるといえるでしょう。
本章では、ボランティアの管理に関する手法を取り上げます。
これまでの章に比べて、より Subversion
プロジェクトでの実例を引き合いに出すことが多くなるでしょう。
というのも本書の執筆時には私はこのプロジェクトで作業しており、
Subversion プロジェクトの過去の資産については熟知しているからです。
また、ちょっと微妙な話題などでは身内のネタのほうが扱いやすいという面もあります。
もちろん、その他のプロジェクトについても調査をしました。
本章で扱う内容に従った (あるいは従わなかった) 結果、
そのプロジェクトはどうなったのか。
政治的な問題をクリアしたものについては、
他のプロジェクトの例も本章で取り上げます。
政治という言葉が出てきたついでに、
みなさんがあまりよく思っていないであろうこの言葉についてよく考えてみましょう。
技術者の多くは「政治的な話なんかうんざりだ。どこか別のところでしてくれよ」と考えがちです。
「僕は はただ、
このプロジェクトのために一番いいのはどの方法なのかを考えて意見を言っているだけなんだ。
なのに 彼女 はといえばいつも政治的な理由であれこれ文句をつけてくる。」
私が思うに、技術者という人種は政治 (あるいは彼らが政治であると思っているもの)
を嫌う傾向が特に強いようです。というのも技術者は、
「あるソリューションが他のものより優れているかどうかは客観的に判断できるはずだ」
という考えを持っているからです。
プロジェクトのメンバーが、あまり本質的でない問題に気をとられている
(たとえば自分の評価だけを気にする、他人の評判を落とそうとする、
あからさまな駆け引きを行う、他人に嫌われないことばかり考えるなど)
ようだと、他のメンバーはあまりいい気がしないでしょう。
もちろんほとんどの場合は、
他のメンバーも重大な関心事については同じように本質的でない振る舞いをしてしまいます。
もしあなたが「政治」という言葉を何か汚らしいものだと感じ、
自分のプロジェクトでは政治的な話を避けるようにしたいと思っておられるのなら、
そんな考えは即刻捨ててしまいましょう。
複数の人間が資源を共有して作業を進めていく以上、
政治的な話は避けることができないものです。
何かのアクションを起こしたときに、
そのプロジェクトにおける各メンバーの影響力がどのように変化するかを考慮する。
これはまったくもって合理的なことです。
結局のところ、もしあなたが多くのプログラマーと同様に
自分の判断とスキルに自信を持っているのなら、
何らかのアクションによって影響力が落ちたとしても、
それは単なる技術的な問題だと考えなければなりません。
同じことが、その他のいかにも「政治的」な振る舞いにだっていえるでしょう。
実際のところ、純粋に「政治」といえるようなものはありません。
人の行動というのは現実社会のさまざまな因果関係の中で行われるので、
人はまず最初に政治的なことを意識するようになります。
政治というのは、一言で言ってしまえば「すべての因果関係を考慮すること」
という合意にすぎません。
とある決定がメンバーの多くを技術的に満足させるものだったとしましょう。
ただ、それによってメンバー間の力関係に変化が生じ、
主要なメンバーが仲間はずれにされたと感じるようなことがあったとします。
この場合、主要なメンバーが感じる気持ちはかなり重要なものとなります。
それを無視してしまうのは、
気高いというよりはむしろ目先のことしか考えていないといえるでしょう。
さて、これ以降のアドバイスを読む際には、
そしてプロジェクトで活動をする際には、
政治のことだけを考えている人なんて どこにもいない
ということを心にとどめておきましょう。
政治をしているように見えるのは単なる戦略に過ぎず、
時には有効でしょうが決して現実の政治ではありません。
政治というのは、単に意見の相違が生じたときに起こるもので、
成功しているプロジェクトはそういう状況を建設的に解決するような
政治の仕組みを確立させています。
ボランティアを最大限に活用する
フリーソフトウェアプロジェクトでボランティアとして働くのは、なぜでしょう?
この疑問について詳しく調査したところ、興味深い結果がでました。
Karim Lakhani と Robert G. Wolf による論文
Why Hackers Do What They Do: Understanding
Motivation and Effort in Free/Open Source Software
Projects
にまとめられています。
をご覧ください。
「なぜ?」と聞かれたら、たいていの人は
「よりよいソフトウェアを作りたいから」とか
「個人的にバグの修正にかかわりたいから」などと答えることでしょう。
ただ、これだけがすべてだというわけではありません。
もし彼らに感謝の言葉を一言もかけなかったとしたら、
もし彼らの言うことに一切耳を傾けなかったとしたら、
それでも彼らはボランティアとして関わり続けてくれると思いますか?
もちろんそんなわけはありませんね。
人がわざわざ時間を割いてフリーソフトウェアに関わるのは、
よりよいコードを書きたいなんていう抽象的な重いだけからではありません。
彼らの真の動機を理解しておけば、ボランティアの人たちとうまくやっていくのに役立つでしょう。
「優れたソフトウェアを作り上げたい」とか
「難しい問題に挑戦してみたい」などという思いもその動機のひとつかもしれません。
しかし、人にはもともと「他の人たちと共同作業をしたい」
「他の人に尊敬されたい」といった願望もあります。
共同作業を進めていくにあたっては、
何らかの行動基準を定めた上で
目標に向かってともに進んでいけるようにしなければなりません。
そんな行動基準は、いつも自然に立ち上がるというわけではありません。
たとえば、プロジェクトによっては「頻繁に繰り返し発言する人がよりよい立場を得る」
ように見えるものもあります (オープンソース界で長年すごしてきた人なら、
おそらく「ああ、あれのことね」と頭に思い浮かぶものがあることでしょう)。
決して偶然そうなっているわけではありません。
複雑な議論を長々と続けていることに対する敬意のあらわれとして、
立場が上がってきているのです
(実際にその議論がプロジェクトにとって有用かどうかは関係ありません)。
名声を得るための行動が、同時に建設的な行為となるような空気を作り出す。
そのための方法を以下で説明していきます。
委任
「委任」は、単に負荷を分散させる方法というだけでなく
政治的・社会的な道具にもなります。
人に何か作業をたのむことにはどんな効果があるか、考えてみましょう。
いちばんわかりやすいのは、
「お願いを聞き入れてもらえたら、実際の作業は彼が行うことになってあなたは行わない」
ということです。しかし、それ以外の効果もあります。お願いをすることによって
「私はあの人に頼られているんだ」と彼に気づかせることができます。
さらに、もしそのお願いを公開の場でしたのなら、
「『私はあの人に頼られている』ということを、みんなも知っているんだ」
ということにも彼は気づくでしょう。
彼は「あの人の言うことだから、聞かなきゃ」というプレッシャーを感じるかもしれません。
したがって、人に何か頼みごとをするときには、
もし嫌なら気兼ねなく断れるように気配りしなければなりません。
彼に依頼する作業が、プロジェクト内の別の人との調整を要するようなものであった場合、
それは彼に「あなたは他の人とは違う。もう一段階すすんだ協力を頼みたい」
と言うのに等しいといえるでしょう。
そのプロジェクトのひとつのサブドメインを管理させるくらいのことになるかもしれません。
あまりやりすぎると威圧的に受け取られかねず、
彼はその責任の重大さから逃げ出してしまうかもしれません。
これらの効果を考慮すると、
人に何か作業をお願いするのは理にかなったことでしょう。
たとえそれを自分でやったほうが手際よくできることがわかりきっていたとしても。
もちろん、何らかの事情で人にお願いをせざるをえないということもあります。
あなたが自分でそれを行うのがコストに見合わない
(他にもっと重要な作業がある) 場合などです。
しかし、そんな差し迫った事情がない場合であっても、
人に作業をお願いすることがあるかもしれません。
将来的にその人にもっと深くプロジェクトに関わってほしいと考えている場合、
最初のうちは少々余分な時間を使ってしまってもかまわないでしょう。
また、逆も成り立ちます。誰か他の人の作業を手伝ってあげれば、
あなたに対する相手の印象はよくなるでしょうし、
相手から尊敬されるようになるでしょう。
委任したり代理をお願いしたりすることは、何も個々の作業だけのことではありません。
プロジェクトへのより深い関わりを持たせることにも関係します。
作業依頼と担当者の決定を明確に区別する
誰かがその作業を引き受けてくれるであろうことが、ほぼ見当がつくこともあります。
たとえば、誰かがコードにバグを仕込んでしまったとか、
誰かがコミットした内容がプロジェクトのガイドラインに明らかに反しているといった場合です。
そんな場合は、問題点を指摘した上でその当人に対応をお願いするだけで十分です。
彼はきっとその作業を引き受けてくれるでしょう。
しかし、時には相手がそのお願いを聞き入れてくれるかどうかが判断できないこともあります。
お願いを聞いてくれるかもしれないし、拒否されるかもしれない。
「○○をやってくれて当然でしょ」といった態度で頼まれると、
誰もあまりいい気はしません。
人に作業をお願いするときには、状況に応じた適切な方法を考えましょう。
相手がもっともいらつくであろうパターンは、
本人にはその気がないのに「これはあなたがやるのが当然でしょ」
といったことを匂わせてお願いすることです。
たとえば、バグ対応の担当者を決めるときに
このパターンがしばしば発生します。
プロジェクトのメンバー間では、誰がどの分野に詳しいかは
だいたいわかっています。何かバグ報告を受け取ったときに、
「これは彼にやってもらえばすぐに修正できるだろう」
と見当がつくこともよくあるでしょう。
しかし、だからといって、
何の前置きもなしにいきなりその人に対応をお願いしたりすると、
相手は気を悪くするかもしれません。
「私は期待されているんだ」と喜んでもらえるかもしれませんが、
それと同時に「私にこの技術があるばっかりに、
こんな作業を押し付けられるんだ」と感じることもあるかもしれません。
バグ対応というのは技術を身につけるためのよい作業でもあります。
こんな場合は、あえて誰か他の人に対応を任せるのもいいでしょう!
(バグ追跡システムの中には、バグ報告の内容に応じて
自動的に担当者を決める機能を持つものもあります。
このようなシステムを使用すれば、「押し付けられる」
という感覚はあまりなくなるでしょう。というのも、
これはあくまで機械的に割り当てられるものであり、
私情が挟まれていないことがわかっているからです)。
特定の人に負荷がかからないよう、
できるだけみんなに均等に作業を割り当てることは大切です。ただ、時には、
いちばんわかっている人に一刻も早く対応してもらいたいこともあるでしょう。
そんなときに毎回根回しをする (「このバグ、ちょっと見てくれないかな?」
「いいよ」「わかった。じゃあ担当者を君に設定するよ」「オーケー」)
時間が割けないのなら、できるだけ圧力を感じさせないように
淡々とお願いするようにしましょう。
ほぼすべてのバグ追跡システムには、
担当者を決めるときにコメントをつける機能が備わっています。
そのコメントで、次のように言うといいでしょう。
君にお願いするよ、jrandom。たぶん君がいちばんこのコードに詳しいだろうから。
もしその時間がなかったら、気兼ねせずにつき返してくれてもいいよ。
(で、もし今後こんな依頼を受けるのがいやだっていうのなら、
そう言ってほしいんだ)。
こうすれば、誰かに作業を 依頼
することと相手がそれを 受諾
するかどうかということを明確に区別することができます。
ここで、このやり取りは当事者間だけでなく全員が見ていることに注意しましょう。
その人に技術があるとみなされていること、
そしてその人に依頼を受諾するかどうかの決定権があることが全員に伝わるのです。
委任したあとのフォロー
誰かに何かの作業を依頼したら、
その後のフォローも忘れないようにしましょう。
これは通常、公開のフォーラムで行います。次のような形式になるでしょう。
"ところで、X についてはどうなっていますか? 教えてください。
別に無理ならそれでも気にしません。ただ単に気になっただけなので。"
返事があるかもしれませんし、あるいはないかもしれません。
あまり状況が芳しくないという返事があったら、
X について何か別の対応策を考える必要があります。
順調だよという返事があったら、しばらくはその作業の進捗を気にしないようにしましょう。
進捗状況について、簡単にコメントだけしておきます
(人はみな、自分の作業が他人に認められていることを知るとうれしいものです)。
数日待っても返事がなかった場合は、
もう一度聞いてみるか、あるいは
「返事がなかったんだけど、誰か他に X についての状況を知っている人はいますか?」
という投稿をすることになります。あるいは自分で調べることになるかもしれませんが、
その場合でも「最初の問いかけに対して返答がなかったので」
という投稿をしておくようにしましょう。
返事がなかったことをわざわざ投稿するのは、
決して その相手を非難するものではありません。
また、周りにそのように受け取られないように言い回しには注意しましょう。
目的は、単に「この前たずねたことをまだ気にかけていますよ。
何か反応があったらすぐ気づきますよ」という姿勢を示すことです。
そうしておけば、次に同じようなことがあったときに反応を得られやすくなります。
周りの人たちから、あなたはどんなちょっとしたことでも見逃さない人だ
ということを認識してもらえるからです。
みんなの好みを知る
自分が何に興味を持っているのかをわかってもらえていると、
人はうれしいものです。一般論として、
周りの人たちの性格をしっかり把握しておけば彼らはいい気分になるでしょう。
そして、あなたと一緒により多くの作業をしたいと思うようになることでしょう。
たとえば Subversion プロジェクトにおいては、
「まずは何とかしてバージョン 1.0 のリリースにこぎつけたい (現在はリリースされています)」
という人たちと
「新機能を追加したり興味深い問題を解決したりといったほうが先決だ。
バージョン 1.0 がいつリリースされるかなんて、そんなの関係ないよ」
という人たちとに明確に区別することができました。
どちらがいいとか悪いとかいうことではありません。
世の中には二種類の開発者がいるというだけのことです。
そしてどちらのタイプの開発者もプロジェクトに多大な貢献をしてくれています。
私たちにはすぐにわかりました。
「1.0 のリリースに向けてがんばろう!」
といった動機付けでみんなを一丸にできるなんて思わないほうがいいということを。
電子メディアは非常にあてにならないものです。
この気持ちはみんなで共有できていると感じていたとしても、
実際にそう思っているのは当事者だけで、
周りの人たちはまったく別の方向を見ていることもあるのです。
みんながそのプロジェクトに何を求めているのかに注意すればするほど、
周りに効率よく作業を依頼できるようになります。
実際に作業を依頼しなくても、
「あなたが何を求めているのかはわかっているよ」
ということを示すだけでも大事です。そうすれば、
自分がその他大勢のひとりではないということをみんなに気づかせることができます。
賞賛と批判
賞賛と批判は決して相反するものではありません。
多くの場合において、両者は非常に似通っています。
両者はともに、相手の気を引くことが主目的であり、
全体的なことを言うよりも特定のことに絞った方が効果的です。
また、どちらも具体的な目標を定めた上で行わなければなりません。
やり過ぎると、どちらの効果も薄れます。
必要以上にほめすぎたり、あまりにも頻繁にほめまくっていたりすると、
あなたのほめ言葉の価値が下がってしまうことでしょう。
批判だって同じです。ただ実際は、
批判のほうについては価値が下がる速度は多少遅くなるでしょう。
技術者の文化の中で重要なのは、詳細かつ冷静
(個人的な感情に左右されていない) 批判は、一種の賞賛とも受け取られるということです
(
の で説明しました)。なぜなら、
その作業はきちんと精査するだけの価値があるものだということが暗示されているからです。
しかし、あくまでも 詳細 かつ 冷静
というふたつの条件を満たしている場合のみであることに注意しましょう。
たとえば、誰かがコードにいい加減な変更を加えたとしましょう。
そんなときに単に「そんないい加減な変更はするな」とだけ言うのは無意味です
(というか、有害でさえあります)。いい加減なのは、
結局はその人の性格の問題であり、その作業成果とは関係ありません。
実際の作業成果に対してのみ反応するようにしましょう。
変更内容の中でまずいところを、淡々と指摘していくほうがずっと効果的です。
同じ人が何度も何度も同じようなケアレスミスを繰り返すようなら、
批判の最後に「同じことが繰り返されている」と指摘するのもいいでしょう。
ただし、その場合も、怒りを抑えることを忘れないようにしましょう。
批判を受けても相手が何も変わらなければ、
もう少しきつめな対応をすることになります。
この場合の対応としては、
できるだけ相手を傷つけないように彼の地位を奪うといったことがあります。
本章の後半の
で、この実例をご覧いただきます。
しかし、これは滅多に起こることではありません。
たいていの人は、具体的で詳細な批判を受け取れば
(口には出さずとも) 何らかの改善の姿勢を見せるものです。
ほめ言葉は誰も傷つけることはありません。
ただ、だからといって何も考えずにほめまくればいいというものでもありません。
賞賛は、一種の道具であるともいえます。
使う前には、なぜ そうするのかを検討するようにしましょう。
一般論として、人がふだんからごく普通に行っていることをほめるのはあまりいい考えではありません。
あるいは、そのグループに参加する上で当然のこととして期待されている作業に対しても、
特にほめることはないでしょう。
それをやり始めると、いつやめるかの判断が難しくなってしまいます。
当然のことをやっている人たち 全員
を個別に賞賛してまわりますか? どこかで線を引いてしまうと、
ほめられなかった人は「なぜ?」と思うでしょうね。
それよりも、いつもとは異なる働きをした人や
予期せぬ活躍をした人に対して
控えめに賞賛の言葉を贈るほうがずっと効果的です。
そして、「これからももっとがんばってね」と励ますわけです。
メンバー全体の生産性が一段階向上したと見なせるようになったら、
賞賛の言葉を贈る基準もそれにあわせて少し厳しめに変えましょう。
通常の行いに対して賞賛を繰り返すと、そのうちにそれは無意味になってしまいます。
みんなが高い生産性を発揮してくれているのは
もはや予想以上の働きでもなんでもなく期待通りのものであるわけで、
それをさらに上回る働きをした時点で改めて賞賛の対象となるわけです。
もちろんこれは、みんなの貢献を受け入れてはいけないという意味ではありません。
でも、知っておいてほしいのです。
プロジェクトがうまく機能していれば、みんなが何をやっているのかは
すでにわかるようになっているわけです。
そして、誰かがやった作業はメンバーみんなが知っている
(ということを、それをやった本人も気づいている) わけです。
直接賞賛の言葉を贈る以外にも、人の作業に対して何らかの意志を表明する方法はあります。
たとえば、何らかの議論をしているときに
「このへんについては彼女が多くの作業をしてくれているし、
彼女が詳しいだろう」と言ってみる。
あるいは、みんなに見える場所でコードの内容について彼女に尋ねてみる。
または、もっとも効率的な方法としては、
彼女の作業成果に基づいてさらなる作業を行うといったものもあります。
そうすれば、自分の作業が他人に認められているということを彼女も感じてくれるでしょう。
これらの行為は、別に計算の上で行わなければならないというものではありません。
プロジェクトに多大な貢献をし続けている人は、
何もしなくても自然にプロジェクト内での影響力を高めていくものです。
正当な評価を受けていないとあなたが感じた場合を除き、
それを後押しするために何らかの作業をする必要はありません。
縄張り意識の回避
プロジェクトの特定の分野において、
だれかが作業を独占しようとし始めたら要注意です。
誰かが始めようとした作業を積極的に引き継いだりといったことなどがそれにあたります。
そのような振る舞いは、最初のうちは健全なものに見えるかもしれません。
表面的には、その人がより多くの作業を引き受けてくれることで
その分野の作業を活発にさせてくれるように見えるかもしれません。
しかし、長い目で見た場合、これはあまりよい兆候ではありません。
周りの人が "あそこに立ち入っちゃいけない" と感じるようになると、
みんなそこにはかかわらなくなります。
その結果、どうなるか。その分野のレビューが機能しなくなり、
もろいものとなってしまいます。
一人の開発者がすべての責任を負ってしまい、
その人が欠ければそれでおしまいになってしまうからです。
さらに悪いことに、それは
プロジェクトの平等主義や協力体制を壊してしまうことになります。
理論上は、すべての開発者が
好きなときに好きな作業に参加できるようにしておくべきです。
もちろん、実際には多少異なることはあるでしょう。
その人によって得意な分野やそうでない分野があるでしょうし、
素人は達人の言うことに従うしかないという分野もあるでしょう。
しかし、重要なのは、これらはすべて自発的に参加する作業であるということです。
能力や実績にもとづいて非公式に権限を与えることもありますが、
決してそれを積極的に受け入れることがあってはなりません。
権力を欲している人が仮に有能な人であるとしても、
あくまでもその権威は非公式なものとすべきです。
つまりメンバー間の合意によるものということです。
また、その権威によって他のメンバーの介入を妨げることがあってはなりません。
誰かの作業内容を、技術的な理由で取り消したり編集したりするのは、
もちろん全然違う話です。
この場合、決定的な要素は作業の中身であり、
誰がその作業の責任を負っているかではありません。
たまたま特定の分野のレビューを行うのが特定の人に集中してしまうかもしれませんが、
その人が他人の介入を拒否しない限りは特に問題はありません。
縄張り主義が登場するのを防ぐために、
多くのプロジェクトではソースファイルから作者名や保守担当者名を取り除くようになっています。
私は心からこの習慣に賛同します。
Subversion プロジェクトでもこの方式を採用しており、
Apache Software Foundation
でもそれは事実上の公式方針となっています。
ASF のメンバーである Sander Striker は次のように述べています。
Apache Software foundation では、ソースコードに author
タグを使用しないことを推奨しています。
これには、法的な問題以外にさまざまな理由があります。
共同開発とは、みんなで一丸となって作業に取り組み、
みんなで一丸となってプロジェクトにかかわるということです。
クレジットを与えるのもいいでしょう。というか、むしろすべきでしょう。
でも、間違った情報を与えることになってしまってはいけません。
どんなときに author タグを追加するのか。
あるいはどんなときに削除するのか。
明確な基準などありません。
コメントを書き換えただけのときにあなたの名前を追加しますか?
たった 1 行だけ修正したときは?
コードをリファクタリングして、元のコードとは 95%
ほど違うものになったとしましょう。
こんな時に、元の作者の author タグを削除しますか?
すべてのファイルをちょっとずつ修正して、
自分の名前がすべてのファイルに登場するようにする人がいたとしましょう。
あなたはそれを見てどう思いますか?
クレジットを与えるよりもいい方法があります。
私たちとしてもそちらをおすすめします。
技術的な側面から見て、author タグは不要です。
特定のコードを誰が書いたのかを知りたければ、
バージョン管理システムを使用すればすぐにわかることです。
また、author タグは更新が遅れて現状を反映しなくなりがちです。
5 年前に書いたっきりで忘却の彼方にあったコードについて
個人的に問い合わせられたとして、あなたはどう思いますか?
ソフトウェアプロジェクトにおいて、
ソースコードファイルこそがその存在の証となります。
開発者コミュニティー全体でソースコードに責任を持つべきであり、
小さなグループに分けてしまってはいけません。
ソースコードで author タグや maintainer タグを使用したいと文句を言う人もいるでしょう。
そうすれば、誰がもっともがんばっているかが一目瞭然になるからというわけです。
しかし、この意見にはふたつの問題があります。
まず、「どの程度の作業をしたら名前を追加してもいいのか」
といったどうでもいい問題が必ず立ち上がってきます。
次に、クレジットを得ることがまるで権威を得ることであるかのような勘違いを起こしてしまいます。
過去にその部分の作業をしたからといって、コードのその部分が作業をした人のものになるわけではありません。
しかし、ソースファイルの先頭に個人の名前が並べられていたら、
そんな風に勘違いしてしまうことが避けられません。
いずれにせよ、クレジットは既に得られているわけです。
たとえばバージョン管理システムのログやメーリングリストのアーカイブなどでそれがわかります。
したがって、ソースファイルからクレジットを削除したところで
何も失われる情報はありません。
しかし、
の "having authors names in .py files" というスレッド、特に
William Stein の投稿は、その反論となるでしょう。
私が思うに、この場合のキーとなるのは、
作者の多くが「ソースに直接クレジットを書くのが当然であり、
それが高く評価される」という文化 (数学者のコミュニティー)
の出身であるということです。
このような場合はソースファイルに作者名を埋め込んでもいいでしょう。
そして個々の作者が具体的に何をしたのかを正確に記載しておきます。
そうすれば、今後新たに開発に加わる人たちにも
「そういうものなんだ」と認識させることができます。
あなたのプロジェクトで「ソースファイルには作者の名前を記載しない」
ことに決めたとしても、決してやり過ぎないようにしましょう。
たとえば、多くのプロジェクトには contrib/
という領域があって、細々したツールやヘルパースクリプト類をここで管理しています。
これらの中には、特定の人が作成したものであってプロジェクトとは関連のないものもあります。
そんな場合には作者の名前を含めてもかまわないでしょう。
だって実際のところ、そのファイルはプロジェクト全体で管理しているわけではないのですから。
一方、そのようなツールをプロジェクトの他のメンバーがハックするようになり、
本格的にプロジェクトに含めたくなることもあるかもしれません。
そのような場合は、原作者の承認を得た上で作者のクレジットを削除し、
プロジェクトで管理している他のリソースとあわせるようにします。
原作者がそれをいやがった場合、妥協案としては次のようなものが考えられます。
# indexclean.py: 古いデータを Scanley インデックスから削除する
#
# 原作者: K. Maru <kobayashi@yetanotheremailservice.com>
# 現在の保守担当者: The Scanley Project <http://www.scanley.org/>
# そして K. Maru.
#
# ...
しかし、できればこうした妥協は避けたいものです。
また、ほとんどの人は、言うことを聞いてくれることでしょう。
自分の作ったものがそのプロジェクトにより深く組み込まれていくというのはうれしいものです。
大事なのは、どんなプロジェクトであっても
その中心部と周囲はきっちりつながっているということです。
本体のソースコードファイルは明らかにプロジェクトの中心となるものであり、
コミュニティー全体で管理しなければなりません。
一方、周辺のツールやドキュメントの中には特定の個人が保守しているものもあるかもしれません。
たとえそれがプロジェクトに関連するものであったり
プロジェクトとともに配布されている場合であっても、
本質的にひとりで保守を担当していることになります。
すべてのファイルに対して画一的な規則で縛る必要はありません。
ただし、コミュニティー全体で管理しているリソースは
決して個人で囲い込んでしまってはいけないということを覚えておきましょう。
自動化の割合
機械にできることは、わざわざ人間にさせずに機械に任せてしまいましょう。
おおざっぱに言って、定型作業を自動化すれば少なくとも効率が 10 倍にはなるでしょう。
頻繁に行う作業であったり複雑な作業であったりした場合は、
20 倍以上になることも珍しくありません。
ここでは、あなたが単なる一人の開発者ではなく
"プロジェクトの管理者" になったつもりで考えてみましょう。
各開発者は、各個人がやっている枝葉の作業に精一杯で
プロジェクト全体の様子
(自動化できる作業をわざわざ手作業でやってしまっているなど)
が見えていないかもしれません。
それに気づいている人であっても、わざわざ時間を割いて問題を解決しようとは思わないでしょう。
実際のところ、各個人の作業自体は重荷となるほどのものではなく、
「何とかしなきゃ」と思うほどには困っていないのです。
たとえ個々の作業にかかる時間はわずかなものであったとしても、
各開発者がそれを行う回数だけ掛けるとどうなるでしょう。
さらにその結果を開発者の人数分だけ掛けたら?
……ということを考えだすと、自動化は無視できなくなります。
ここでいう "自動化" とは、広い意味の自動化を指しています。
いくつかのパラメータを指定して同じ動作を繰り返すというものだけでなく、
人間の作業を支援する技術的な仕組み一般を指して "自動化" といっています。
いまどきのプロジェクトの運営における最低限必要な自動化については
で説明しました。
しかし、これら以外にも各プロジェクトに固有の問題もあることでしょう。
たとえば、ドキュメント担当チームの場合は、
常に最新版のドキュメントが公開されているウェブサイトが必要かもしれません。
たいていの場合、ドキュメントは XML などのマークアップ言語で作成されるので、
コンパイルが必要となるかもしれません。
表示用とダウンロード用のドキュメントを作成するなど、
このコンパイル処理は複雑なものになることもあります。
コミットがあるたびに最新版をコンパイルしてウェブサイトに反映させるというのは、
複雑で時間のかかる処理です。
しかし、何日かかけてでもその仕組みを作成する価値はあります。
最新の状態を確認できるようにする仕組みがないとしても、
それで困るのはほんの一握りの人たちだけかもしれません。
それでも、その仕組みを作ることによる利益は計り知れないものがあります。
このように自動化すると、時間の浪費が解消されるだけでなく
人間が手動で作業したときの作業ミス (ミスは必ず発生します)
でいらいらすることもなくなります。
何段階にも及ぶ複雑な定型作業なんて、まさにコンピュータにやらせるべきものです。
そもそもコンピュータが発明されたのはそういう作業をやらせるためだったのですから。
そんな作業はコンピュータに任せ、
人間はもっと創造的な作業に時間を割くようにしましょう。
自動テスト
テストの自動化はどんなソフトウェアプロジェクトにとっても有用ですが、
オープンソースプロジェクトでは特に有用となります。
自動テスト (特に回帰テスト) を行うことで、
不慣れな分野のコードでも安心して変更できるようになります。
これは、開発の効率を大きく向上させます。
問題の原因を人間の目で検出するのは大変
(まず「このあたりに問題があるのではないか」と見当をつけ、
その部分に問題がないかどうかあらゆる手段で調べることになります)
なので、それを自動化すれば 大きな 時間の節約になります。
回帰テスト
回帰テスト (リグレッションテスト、Regression testing)
とは、修正済みのバグが再発していないかどうかを調べるテストのことです。
回帰テストを行う理由は、
コードを変更したことで予期せぬところでソフトウェアを破壊していないことを確認するためです。
ソフトウェアが大規模、複雑になっていくにつれて、
予期せぬ副作用があらわれる可能性も大きくなります。
きちんと設計していればその可能性を低くすることはできるでしょうが、
完全に問題を解消するのは不可能です。
ということもあり、多くのプロジェクトでは
テストスイート を用意しています。
これは、プロジェクトとは別に用意されたプログラムで、
過去に存在したバグが再現するような処理を実行します。
テストスイートを実行してこれらのバグが再現した状態を
リグレッション といいます。
これは、誰かの修正が過去に修正済みのバグを再発させてしまったことを意味します。
もご覧ください。
回帰テストは決して万能というわけではありません。
バッチ処理的なプログラムではうまく動作するでしょうが、
たとえばグラフィカルなインターフェイスで操作するプログラムに適用するのは難しいものです。
もうひとつの問題として、回帰テスト用のフレームワークが非常に複雑なものであるということが挙げられます。
まともに使いこなせるようになるまでにはかなりの時間がかかることでしょう。
この複雑さをなんとか軽減させることが大切です。
たとえ時間がかかったとしても、
その努力は必ず報われます。
新しいテストをテストスイートに追加しやすくすればするほど、
多くの開発者がテストを作成してくれるようになります。
その結果として、リリース後に見つかるバグも少なくなるでしょう。
テストを書きやすくするために費やした努力は、
将来にわたってそのプロジェクトに大きな効果を及ぼします。
多くのプロジェクトでは "Don't break the build!"
という決まりがあります。これは、コンパイルできなくなったり
実行できなくなったりするような変更はコミットするなという意味です。
そんなコミットをしてしまった人は、
かなり気まずい思いをすることになるでしょう。
回帰テストを採用しているプロジェクトの場合、この決まりはもっと明確になります。
つまり「テストが失敗するような変更はコミットするな」
ということになるのです。
テストスイート全体を毎晩自動実行するようにしておけば、
このようなコミットを検出することは容易です。
そして、テストの実行結果は開発者向けメーリングリスト
(あるいはテスト結果専用のメーリングリスト)
に送るようにすればいいのです。
ほら、ここにもまた自動化の例がひとつ登場しました。
わかりやすくて作業しやすいテストシステムがあれば、
たいていの開発者は喜んで回帰テストを作成してくれるでしょう。
変更をするときはテストも作成するというのは共通認識となっています。
この作業は、複数で協力して行うこともあります。
バグ修正作業を二人で分担し、一人が実際の修正を行って
もう一人がテストを書くといったようにです。
テストを書く側の担当者のほうが、作業量は多くなりがちです。
もともと実際のバグ修正にくらべてテストを書く作業はつまらないものなので、
テストを書くのが苦にならないようにする必要があります。
プロジェクトによっては、さらに厳しい規則を設けていることもあります。
バグ修正や機能追加を行う際は、必ず
新しいテストを追加しなければならないといったものです。
このような規則を設けることのよしあしは、多くの要素に依存します。
「そのソフトウェアがどんな類のものなのか」
「開発チームの構成はどのようなものなのか」
「新しいテストを書く難易度はどれくらいか」
などが考慮の対象になります。
CVS ()
プロジェクトでは、長年この厳しめの規則を採用しています。
理屈の上では、これはよい方針でしょう。
CVS はバージョン管理用のソフトウェアであり、
ユーザーのデータを壊して復旧できなくしてしまうようなことがあってはならないからです。
ただ、実際に運用していく上では問題がありました。
CVS の回帰テストスイートは、ひとつの巨大なシェルスクリプトでできています
(sanity.sh という変な名前がついています)。
これは非常に読みづらく、また修正したり拡張したりするのも大変なのです。
新しいテストを追加するのが大変であること、
そしてパッチが受け入れられるためには新しいテストが必須であること。
これらによって、CVS は事実上パッチの受け入れを拒否しているようなものだと言えます。
かつて私が CVS プロジェクトで作業をしていたころ、
「CVS のパッチを作成したんだけど、sanity.sh
にテストを追加しなきゃならないっていう話を聞いて結局あきらめた」
という人を散々見てきました。
バグの修正そのものより新たな回帰テストを書くほうが時間のかかるというのは
ごく普通のことです。ただ、CVS の場合はそれがちょっと極端すぎます。
数時間かけて自分用のテストを作ったとしても、まだそれが間違っているかもしれません。
35,000 行にもおよぶシェルスクリプトの中には、
思いもよらぬような込み入った仕組みが潜んでいるからです。
長年 CVS にかかわっている開発者でさえも、
新たなテストを追加するときには不満をもらすことがあります。
このようになってしまった原因は、
私たちが自動化の割合について考えていなかったことです。
自前で作るなり既存のものを使うなりして、
本物のテストフレームワークに移行しようという試みはありました。
既存のテストをすべて新しいフレームワークに移行させなければならないというわけではありません。
両者を共存させることもできるでしょう。
必要になったものだけを新しい形式に変換すればいいのです。
しかし、長年それを怠ってきたツケが今まわってきているというわけです。
この使いづらいテストスイートのせいで現在の CVS に取り込まれて いない
バグ修正や新機能って、いったいどれくらいになるんでしょう?
実際のところは知りようがありません。ただ、
新しいテストシステムを開発 (あるいは既存のシステムを採用)
する時間を確保するために減ってしまうバグ修正・機能追加の数よりはるかに多いことは確かです。
テストシステムを移行するのにかかる時間は有限のものですが、
何もせず現状のテストスイートを使い続けることによる被害は永遠に続くわけですから。
ここで言っているのは、「テストを書くよう厳しく要求するのはダメ」
ということではありません。また、
テストシステムをシェルスクリプトで書くのが必ずしも悪いというわけでもありません。
きちんと設計した上であれば、それが有用な場合もあるでしょう。
言いたかったのは、「もしテストシステムが開発の障害になっているのなら、
何か手を打たなければいけない」という単純なことです。
その他の定型作業も一緒です。
もしそれが障害やボトルネックになっているのなら、
何らかの対処が必要です。
すべてのユーザーの協力を得るために
ユーザーとのやり取りは、
そのプロジェクトに新たなメンバーを迎え入れるためのチャンスでもあります。
わざわざ時間を割いてプロジェクトのメーリングリストに投稿してくれたり
バグ報告をしてくれたりといった時点で、その人は
その他大勢 (の、そもそもそのプロジェクトのことなんか知らない人たち)
よりもより深くプロジェクトに興味を持ってくれていることがわかります。
そんな人たちをうまく釣り上げてしまいましょう。
バグ報告を受け取ったら、その人に感謝したうえで
「ところで、それを自分で修正してみる気はない?」
と聞いてみるといいでしょう。
FAQ に載せるべき質問が欠けているだとか
プログラムのドキュメントが不十分だとかいう指摘を受け取った場合は
(実際にそんな問題があったと仮定します)、
指摘をしっかり受け入れた上で
「ところで、それを自分で書いてみる気はない?」
と聞いてみましょう。
当然、たいていの場合は「いえ、そこまでは……」と断られるでしょう。
でも、聞いてみること自体にはそんなに手間はかかりません。
それに、毎回そのように返事をしていれば、
その他の参加者も「何か自分ができることで
プロジェクトに参加できるんだな」と気づくはずです。
目標は、単に新たな開発者やドキュメント作者を確保することだけではありません。
みんなによりよいバグ報告をしてもらえるように仕向けることは、
長い目でみれば十分に採算の取れることです。
ほんの少しの手間で彼らが将来多くのバグ報告をしてくれるようになればすばらしいと思いませんか?
そのためには、初めてバグを報告してくれた人に対して建設的な反応を返すことが大切です。
建設的な反応とは、単にバグを修正するということだけではありません
(もちろんそれが理想ではあります)。
たとえば、より詳細な情報を提供するよう相手に求めたり、
あるいはただそれがバグであるということを認めるだけでも建設的な反応といえます。
人は誰でも、自分の意見に耳を傾けてほしいものです。
また、バグを報告した人はそのバグが修正されることを望んでいます。
後者の望みはすぐにはかなえられないこともあるかもしれません。
しかし、あなた (というか、あなたのプロジェクト)
が前者の望みをかなえてあげることはできるはずです。
当然のことですが、
「何か言いたいのはわかるけれども具体的なことがさっぱりわからない」
ようなバグ報告にたいしても腹をたてたりしてはいけません。
個人的に、私はこのような態度は気に入りません。
さまざまなオープンソースのメーリングリスト上で、このような開発者が見られます。
そして、その害は明白です。
かわいそうな新入りさんが、次のような無意味な報告を送ってきたとしましょう。
Scanley が動かないんだけど。
起動しようとするとエラーが出るんだ。
他のみんなは大丈夫なのかな?
過去にこの類の報告を数限りなく見てきた開発者のなかには、
こんな答えを返す人がいます。
ちっ。そんな情報だけでいったいどうしろって言うんだよ。
もっと詳しい情報を教えてくれないと。
せめて Scanley のバージョンとか OS
の種類、あとエラーメッセージくらいは必要だ。
こんな答えを返す人は、ユーザーの目線で考えることができていないのでしょう。
そして、そんな反応が その他の
人たちにどんなふうに思われるかにも考えが及んでいないのでしょう。
プログラミングの経験がない人やバグ報告の経験のない人などは、
正しいバグ報告の方法なんて知らないかもしれません。
そんな人への対応はどうしたらいいのでしょう?
教育しちゃえばいいんです!
どうせするなら、よりよい返事をもらえるようにしてみましょう。
ご迷惑をおかけして申し訳ありません。
何が起こったのかを調べるためには
もう少し詳細な情報が必要です。
Scanley のバージョンと使用している OS、
そしてエラーの正確な内容を教えてくれませんか?
あと、実行したコマンドとその出力結果を正確に教えてもらえると助かります。
詳細は
http://www.scanley.org/how_to_report_a_bug.html
をご覧ください。
必要な情報をユーザーから引き出すには、
こういった感じの返答のほうがずっと効果的です。
なぜなら、この返答はユーザーの視点に立って書かれているからです。
まず 1 点目。この返答では「問題があったんですね。
お察しします。さぞ大変だったことでしょう」
と同情の意を表しています
(バグ報告に対して毎回このようにする必要はありません。
バグの深刻度、そしてユーザーがどの程度困っているのかに応じて使いわけます)。
次に 2 点目。バグ報告のお作法を知らないことをバカにするのではなく
「どうしたらいいのか、どんな情報がほしいのか」といったことを説明しています。
ごく一般的なユーザーは、「エラーの内容を教えて」と言われても、それが
「エラーメッセージを正確に教えてください。途中までで切ったり
変に省略したりしないこと」という意味であるとはわかりません。
そんなユーザーに対応する場合は、とくに事細かに説明しなければなりません。
最後に 3 点目。より詳しい、きちんとしたバグ報告をするための方法がわかるよう、
ポインタを示しています。うまく対応すれば、
きっとこの報告者はリンク先のドキュメントを読んでその内容を理解してくれるでしょう。
もちろん、事前にそのためのドキュメントを用意しておかなければなりません。
そのドキュメントでは、開発チームが
バグ報告の際にどんな情報を欲しているのかを明確に説明しておくようにします。
理想を言えば、プロジェクトにおけるユーザーのバグ報告の内容にあわせて
そのドキュメントを日々改良していくことが大切です。
Subversion プロジェクトにおけるバグ報告の説明は、まさにこの形式のよい例といえます
( をご覧ください)。
最後のほうに、バグを修正するためのパッチの提供を促している箇所があることに注目しましょう。
そうしたからといって、バグ報告におけるパッチの添付率が上がるわけではありません
(バグを修正できるくらいのレベルの人なら、
いちいち言われなくてもパッチが有用であることを知っているはずですから)。
真の目的は、すべての読者 (特にそのプロジェクトに初めて参加する人たち、
あるいはフリーソフトウェアの世界に初めて足を踏み入れる人たち)
に対して「このプロジェクトは多くのボランティアの貢献によって成り立っている」
ということを示すことです。プロジェクトの開発メンバーだからといって、
バグ修正に対する責任がバグの報告者より重いということはありません。
新入りさんにはあまりなじめない考え方でしょうが、これは重要です。
それをみんなに理解してもらえれば、
バグ修正のための手助けをより多く得られるようになるでしょう。
コードが書けない人であっても、バグの再現手順を詳細に説明したり
だれかのバグ修正の内容を検証したりといった支援は可能です。
最終的な目標は、みんなに「自分とプロジェクトのコアメンバーの間には
本質的な 違いはない」ということを理解してもらうことです。
失礼なユーザーに対しては、多少きつく対応しても許されるでしょう。
たまに、バグ報告や苦情を書く際に
状況を考えずにプロジェクトをバカにした態度をとる人がいます。
このような人は、バカにしたかと思えば急にこびへつらってきたり、
態度をコロコロ変えることがよくあります。かつて Subversion
のメーリングリストにこんな投稿をした人がいました。
6 日もたったのに、いまだに Windows 版のバイナリがないってどういうこと?!?
毎回こんなことが続くんで、もういらいらしっぱなしだよ。
そんなの自動化しちゃえばいいだけのことでしょ??
"RC" 版を出したってことはそれをみんなに使ってほしいんでしょ?
なのにこんな状態だと使うこともできないじゃないか。
試しようがないのなら、テスト期間なんて無駄じゃない??
この煽り気味の投稿に対する返信は、どれも驚くほど落ち着いたものでした。
このプロジェクトではバイナリ版をリリースしない方針になっていることを指摘し、
そんなにバイナリが大事なのなら自分でそれを作って提供するべきだと返信したのです。
驚くなかれ、彼の次の投稿はこんな一文から始まっていました。
まず最初に一言。Subversion は最高のツールだし、
プロジェクトのすべての参加者には本当に感謝してるんだよ。[...]
...といった舌の根も乾かぬうちに、また
バイナリを提供しないことに対するプロジェクトへの批判を続けたのです。
彼は自分では何もしようとしませんでした。それに対して、
50 人ほどが彼を批判する返信をしました。
私はそれを見ても、とくに気に病むことはありませんでした。
の で説明した、
失礼な人に対する「ゼロトレランス (情け容赦なく)」という考え方は、
そのプロジェクトに対して継続的にかかわり続ける人たちに対するものです。
しかし、相手がただ単に不満をぶちまけているだけなんだということがわかってしまえば、
彼に対して気配りをしても無意味です。
幸いなことに、こんな状況になることはほとんどありません。
初心者に対してもより建設的な対応を心がけているプロジェクトでは、
まずこのようなことはありえないでしょう。
Meeting In Person (Conferences, Hackfests, Code-a-Thons, Code Sprints, Retreats)
24 March 2013: If you're reading this note, then
you've encountered this section while it's undergoing substantial
revision; see producingoss.com/v2.html for details.
poss2 tbd
Some examples to use: Ubuntu community sprints, Adam
Hyde's flossmanuals doc sprints, and the Danese/Noel-style public
hackathons. Distinguish between purely dev events and
dev+user+funder+enterprise events — all are
useful, but don't confuse audiences.
技術的な作業だけでなく管理作業もみんなで
プロジェクトを運営していくにあたっては、
技術的な作業だけでなく管理作業も大切です。
プロジェクトが複雑になればなるほど、
メンバーや情報の流れの管理作業が多くなります。
管理作業だってみんなで協力してやるようにしましょう。
別にトップダウンの階層がなくたってそれは可能です。
実際のところ、行う作業というのは軍隊式の命令系統ではなく
ピアツーピアのネットワークトポロジーに近いものだからです。
「○○管理者」を正式に任命することもあれば、
その場のノリで決めてしまうこともあります。
Subversion プロジェクトには、「パッチマネージャー」
「翻訳マネージャー」「ドキュメントマネージャー」
「バグマネージャー (非公式ですが)」そして
「リリースマネージャー」がいます。
これらの中には意識して任命したものもあれば、
勝手に立候補してくれたものもあります。
プロジェクトが成長するにつれて、
さらにいろいろな役割が追加されることになるでしょう。
以下で、これらの役割 (に加えてさらにいくつかのもの)
についての詳細を説明します (リリースマネージャーについては省略します。
すでに 本章の前半の
や
で取り上げているからです)。
以下の説明を読むにあたっては、
これらの役割の担当範囲がが決してお互いに排他的なものではないことに注意しましょう。
たとえば問題マネージャーでなくても問題データベースを変更することがあるでしょうし、
FAQ の編集権を FAQ マネージャーに独占させてしまうこともありません。
これらの役割というのはあくまでも責任の範囲に関するものであり、
独占させるためのものではありません。
各マネージャーの仕事で重要なのは、
「誰かが自分の担当分野の作業をしていることに気づいたら、
その人がうまくやっていけるように自分の方針を伝える。
そして、みんなの作業が競合しないようにする」
ということです。マネージャーは、自分の担当分野の作業手順書を作成しなければなりません。
そうすれば、何らかの理由でマネージャーが作業をできなくなったとしても
誰かがすぐに後を引き継ぐことができます。
特定の役割を希望する人が複数あらわれることもあります。
このような場合にそれをうまく処理する方法には「これが正解!」というものはありません。
たとえば、希望者に所信表明を出してもらい、
それをもとにコミッターによる投票を行うという手もあります。
しかしこれは面倒ですし、後に尾を引いてしまう可能性があります。
それよりは、希望者たちがお互いに話し合って決めてもらうほうがいいでしょう。
そうすれば、結果がどうであれ、
他人に決められてしまうよりは満足のいくものになるはずです。
パッチマネージャー
パッチがたくさん送られてくるフリーソフトウェアプロジェクトでは、
「どんなパッチが投稿されたのか」「そのパッチをどう処理することにしたのか」
といった情報を追いかけるのは大変です。
中央管理体制でない場合などは特にそうでしょう。
大半のパッチはそのプロジェクトの開発者向けメーリングリストに投稿されます
(中にはバグ追跡システムに投稿したり
外部のウェブサイトで公開したりといったものもあります)。
そしてそのパッチをどのように処理するかについては何通りものパターンがあります。
時には、パッチをレビューした結果何か問題が見つかり、
元の投稿者に差し戻しとなることもあります。
このようなやり取りは、通常は何度か (メーリングリスト上で)
繰り返されることになります。元の投稿者がパッチを何度か書き直し、
レビューする側が何も文句のつけようがなくなるまでこれが続きます。
この繰り返しがいつ完了するのかがはっきりわかるとは限りません。
もしレビューした人がパッチをコミットすれば
「これで完了」とはっきりわかるのですが、そうでない場合はいろいろな理由が考えられます。
「コミットする時間がないだけ」「そもそもその人にコミット権がなく、
他の開発者にコミットを依頼できていない」などの理由があるでしょう。
パッチに対する反応としてよくあるもうひとつのパターンは、
そのパッチをネタにして議論が紛糾することです。
議論の内容はパッチそのものである必要はなく、
そのパッチの背景にある考え方のよしあしについてが話題になることもあります。
たとえば、ある特定のバグを修正するパッチが投稿されたとしましょう。
しかし、開発者側ではもっと別の修正方法のほうがよいと考えている
(問題をより一般化して、もっと広い範囲を修正することを考えているなど)
ということがあります。開発者側の考える修正方法は、
何も以前から頭にあったものであるとは限りません。
投稿されたパッチを見ることで、別の修正方法をひらめくということもあります。
たまに、投稿したパッチが完全にスルーされてしまうことがあります。
これは、たまたま
そのときにパッチをレビューする暇のある開発者がいなかっただけ
(みんな、誰か他の人がみてくれるだろうと思っていただけ)
ということが多いようです。「誰かが相手をするのを待つ」
のに時間の制限はありませんし、それ以外にも重要な作業はいくらでもあります。
かくしてそのパッチは誰の目にとまることもなくやみに葬り去られていきます。
せっかくの有用なパッチがこんなことで見過ごされてしまう可能性があるわけです。
それだけでなく、さらに悪い副作用もあります。せっかく時間を割いてくれた
パッチ作者のやる気をそいでしまうということです。
さらに「パッチのひとつでも書いてやろうか」
と考えているその他の人たちにとっても、
そのプロジェクトが魅力あるものには見えなくなるでしょう。
パッチマネージャーの役割は、この手の「闇に葬り去られてしまう」
パッチをなくすことです。そのために、
次のような手順ですべてのパッチを安定した状態にします。
パッチマネージャーはすべてのメーリングリストのスレッドを監視し、
パッチを含む投稿を拾い出します。
最終的にそのパッチがコミットされているのなら特に何もすることはありません。
レビューと修正を繰り返した結果、最終版のパッチがまだコミットされていないという場合は、
最終版のパッチ (とメーリングリストでの議論) を問題追跡システムに投稿します。
そうすれば、開発者が後でその記録を追うのが容易になります。
もしそのパッチが特定の問題を修正するためのものなら、
問題追跡システム上に登録されているその問題のコメントとしてパッチの情報を加えます。
この場合は、新たな問題として投稿することはありません。
パッチに対する反応が何もないまま数日が経過した場合は、
パッチマネージャーが「誰かレビューする人はいませんか?」とフォローします。
そうすれば、普通は何らかの反応があります。
「そのパッチは適用する価値があるとは思えない。なぜなら……」
とか「じゃあ私がレビューしましょうか?」などです。
反応があった場合は、先ほど説明したような手順で処理していきます。
それでも誰も反応しなかった場合は、
そのパッチを問題追跡システムに登録するかどうかは
パッチマネージャーの判断で決めます。しかし、
少なくともパッチの投稿者に対しては 何らかの
反応を返すようにしましょう。
パッチマネージャーを任命したおかげで、
Subversion の開発チームは時間と気力を大幅に節約することができました。
専任の担当者がいなければ、開発者みんなが
「今すぐには返事できそうにないけれど、誰か他の人が反応してくれるのかなあ?
それとも私が後で対応したほうがいいのかな?
でも、もし誰か他の人も同じように考えているのなら時間の無駄だなあ」
と常に心配するはめになっていたでしょう。
パッチマネージャーのおかげで、このような裏読みをすることはなくなりました。
各開発者は、パッチを見たときの状況に応じてどう処理するかを決めることができます。
もしそれをレビューしたいのならそうします。
マッチマネージャーが適切にフォローしてくれるでしょう。
もしそのパッチを完全に無視したいのならそれも結構。
あなたが見なかったとしても、
パッチマネージャーがそのパッチをきちんと扱ってくれます。
この仕組みがうまく動作するのは、
パッチマネージャーがきちんと処理してくれるとみんなが信頼できるときだけです。
つまり、この役割の担当者はノリで決めるのではなく正式な手続きを踏んで決める必要があります。
Subversion プロジェクトの場合は、まず開発者向けメーリングリストと
ユーザー向けメーリングリストで告知を行いました。
何人かが立候補してくれましたが、最初に返事をくれた人を担当者として任命しました。
後にその人が担当を降りたとき (本章の後半の
をご覧ください)
にも、同じ手順を繰り返しました。
同時に複数名を任命することは決してしませんでした。
なぜなら、そうすると担当者間のコミュニケーションの手間がかかるからです。
しかし、パッチの量があまりにも多い場合には
複数担当者制を敷くのもよいでしょう。
翻訳マネージャー
ソフトウェアプロジェクトにおける "翻訳"
には、ふたつの異なる意味合いがあります。
ソフトウェアのドキュメントを翻訳することと、ソフトウェアそのものを翻訳する
(エラー表示やヘルプメッセージをユーザーの好きな言語で表示できるようにする)
ことです。どちらも複雑な作業ですが、いったん仕組みを確立してしまえば
これは他の開発とは分けて行うことができます。
どちらの翻訳もやることはほぼ同じなので、(プロジェクトによっては)
両方の作業を一人の翻訳マネージャーが管理してもいいでしょう。
あるいはそれぞれ別の人に管理させてもいいでしょう。
Subversion プロジェクトでは、一人の翻訳マネージャーに両方を管理させています。
もちろん彼が実際に自分で翻訳を行うわけではありません。
ひとつやふたつの言語については作業できるかもしれませんが、
もしすべての翻訳を自分でしようとすると、現時点で彼は
10か国語 (方言も考慮すると12か国語) を操れなければなりません!
それは無理なので、彼はボランティアの翻訳者のチームを管理しています。
彼の仕事は翻訳者たちがお互いに協力し合えるように支援することであり、
翻訳チームがプロジェクトの他のメンバーとうまくやっていけるようにすることです。
翻訳マネージャーが必要となる理由のひとつに、
翻訳者たちは一般的な開発者とは少し異なるという点があります。
彼らの中にはバージョン管理システムの使用経験が浅い人もいるでしょうし、
ボランティアのチームの一員として働いたことのない人がいる可能性もあります。
しかし、それを別にすれば、彼らはボランティアとして最高の人たちであるともいえます。
特定の分野に関する知識を持っており、
それを生かしてプロジェクトに協力してくれているわけです。
彼らは、作業をするためならよろこんで勉強してくれるでしょう。
彼らに必要なのは、どうすればいいのかを教えてあげる人です。
翻訳マネージャーは、翻訳作業が通常の開発を不要に妨げないように注意します。
また、翻訳者全体の代表として働くこともあります。
翻訳作業に影響を与えるような変更を開発者が行った場合に、
それを翻訳者たちに伝えるのがその役目です。
したがって、翻訳マネージャーにとって一番大切なのは
技術的な能力ではなく外交力になります。
たとえば Subversion プロジェクトの場合、
各国語の翻訳は少なくとも 2 人以上で行うことという決まりを設けました。
そうしないと、翻訳をレビューすることができないからです。
たとえば、Subversion をマラガシ語に翻訳したいという人があらわれたとしましょう。
翻訳マネージャーは、6 か月前に同じことを申し出てきた別の人とペアを組ませて翻訳を任せるか、
あるいは「だれかもうひとりマラガシ語のわかる人を連れてきて、
ふたりで作業をしてほしい」とお願いしなければなりません。
人が集まったら、マネージャーは彼らに適切なコミット権を与え、
プロジェクト内の決まり事 (コミットメッセージの書き方など)
を説明したうえで彼らの作業を見守ります。
翻訳マネージャーと開発者とのやりとり、
あるいは翻訳マネージャーと各翻訳チームとのやりとりは、
通常はそのプロジェクトが元々使用している言語で行います。
つまり、翻訳の元となる言語ということです。
ほとんどのフリーソフトウェアプロジェクトでは、これは英語となるでしょう。
しかし、プロジェクトの事情によってそれ以外の言語となることがあってもかまいません
(とはいえ、そのプロジェクトを世界に広めたいのなら、
英語を使うのが一番よいでしょう)。
しかし、個々の翻訳チーム内でのやりとりは
彼らの言語で行うことになるでしょう。
翻訳マネージャーの仕事のひとつは、
個々の翻訳チーム用に専用のメーリングリストを用意することです。
そうすれば、翻訳に関する議論を
プロジェクト本体のメーリングリストのじゃまをせずに行うことができます。
本体のメーリングリストで翻訳の議論をしても、
ほとんどの人はその言語を理解できないでしょうから。
国際化 (Internationalization) と地域化 (Localization)
国際化
(I18N) と 地域化
(L10N) はどちらも、
元々の言語や文化以外の環境でプログラムを動作させるための手続きのことを指します。
これらの用語はよく混同されることがありますが、
正確には異なるものです。
によると、
その違いは次のようになります。
The distinction between them is subtle but important:
Internationalization is the adaptation of products
for potential use virtually everywhere, while
localization is the addition of special features for use in
a specific locale.
(これらの違いは、些細なことではありますが重要です。
国際化とは、その製品を事実上どの国でも使えるようにすることですが、
地域化とは特定の機能を 特定の
ロケールで使えるようにすることを意味します)。
たとえば、あなたのソフトウェアで
Unicode ()
テキストエンコーディングを扱えるようにすることは「国際化」にあたります。
これは特定の言語に関係するものではなく、
多国語のテキストを扱えるようにするものだからです。
一方「スロベニア語の環境で動かしたときは
すべてのエラーメッセージをスロベニア語で表示させるようにする」
という変更は「地域化」にあたります。
したがって、翻訳マネージャーの作業は主に地域化にかかわるものであり、
国際化に関するものではありません。
ドキュメントマネージャー
ソフトウェアのドキュメントを最新の状態に保つというのは、果てしなく続く作業です。
コードに新機能や拡張機能が追加されたら、
ドキュメントにもそれを反映させなければなりません。
また、そのプロジェクトのドキュメントがある一定のレベルに達したら、
コード自体へのパッチだけでなくドキュメントへのパッチも送られてくるようになるでしょう。
「コードのバグを修正することはできないけれど、
ドキュメントの間違いなら直せる」という人はたくさんいます。
ドキュメントはすべてのユーザーが読めますが、
実際にプログラムが書けるユーザーはその一部だけだからです。
ドキュメントへのパッチは、コードへのパッチに比べて
レビューして適用するのが容易です。
テストの必要はほとんどありませんし、
変更内容もざっと見ればわかります。
パッチの数は多いけれどそのレビューの手間は少ないということもあり、
管理作業と実際の生産的な作業の割合は
コードのパッチよりドキュメントのパッチのほうが高くなるでしょう。
さらに、もとの作者の書き方との一貫性を保つためには
ほとんどのパッチに対して多少の調整が必要となることでしょう。
多くの場合、ひとつのパッチが他のパッチに影響を及ぼしたり
他のパッチと内容が重複していたりします。
お互いのパッチの内容を尊重してそれらを調整してからコミットしなければなりません。
ドキュメントのパッチは緊急に処理しなければならないこと、
そしてドキュメントを最新に保つには
ソースコードの変更内容を逐次監視する必要があることなどを考えると、
ドキュメント専任の担当者を何名かおいたほうがいいでしょう。
彼らの作業は、ソフトウェアのどこがどう変わったのかを正確にドキュメントに反映させること。
そして彼らに必要なのは、大量のパッチを効率よくさばく能力です。
もちろん、そうしたからといってプロジェクトの他のメンバーが
ドキュメントのパッチを適用できなくなるというわけではありません。
ちょっとしたパッチなら、他のメンバーがその場でコミットしてしまってもかまわないでしょう。
パッチマネージャー (さきほどの
を参照ください)
はコードとドキュメントのパッチを把握しているので、
開発チームとドキュメントチームの両方に対して適切な情報を提供してくれます
(とはいえ、もしパッチの量が多くなりすぎて 1 人では管理しきれなくなっと場合などは、
まずはコードのパッチの担当者とドキュメントのパッチの担当者を分けることになるでしょう)。
ドキュメントチームのポイントは、各メンバーが
「ドキュメントをきちんとまとめて最新の状態に保ち、一貫性のあるものにする」
という役割を自覚することです。実際の作業としては、
ドキュメントの構成を熟知したうえでソースコードの変更点を追跡し、
また 別の人 によるドキュメントへのコミットや
ドキュメントに対するパッチをチェックして、しかるべき対応をすることなどがあります。
バグマネージャー
プロジェクトのバグ追跡システムに投稿される問題の数は、
そのソフトウェアを使う人の数に比例して増えていきます。
したがって、いくらバグを修正して安全なプログラムを公開するようにしても、
未対応の問題の数は際限なく増えていくことを覚悟しなければなりません。
同じ問題が何度も投稿されることも多くなるでしょうし、
何が言いたいのかさっぱりわからないバグ報告も増えてくるでしょう。
バグマネージャーの役割は、これらの問題を軽減するために
バグデータベースを常に監視し、定期的に整理整頓することです。
主な作業は、バグ報告の内容を補足することです。
バグ報告の中には、いくつかの項目が正しく埋められていないものもあれば
既存のバグと同じ内容を報告しているようなものもあるからです。
担当者がバグデータベースの内容に精通していればいるほど、
既存のバグと重複しているバグ報告を見つけやすくなります。
これが、バグ報告の対応に専任の担当者を割り当てる利点のひとつとなります。
全員が臨機応変に対応するより、そのほうが効率的だからです。
バグ対応を一元管理せずに分散管理しようとすると、
結局誰一人としてバグデータベースの内容に精通した人がいなくなってしまいます。
バグマネージャーは、個々のバグ報告に対して
個別の開発者を割り当てる作業も手伝います。
大量のバグ報告が飛び交うようになると、
中にはバグ報告の通知用メーリングリストをチェックするのが
おっくうになる開発者も出てくるでしょう。
開発チームの誰かがすべての報告にきちんと目を通しておくことにすれば、
そんな場合でも適切な担当者にきちんとバグ対応をお願いすることができるでしょう。
もちろん、この作業は開発の妨げにならないよう注意して行う必要があります。
対応をお願いする相手の状況を考慮することも大切です。
これらのことを考えると、
バグマネージャーは開発者チームの中から任命するとよいでしょう。
そのプロジェクトでバグ追跡システムをどのように利用するのかにもよりますが、
プロジェクト内の優先順位に応じて
バグデータベースを調整する役割もバグマネージャーにはあります。
たとえば Subversion プロジェクトでは、
各バグ報告に対して「将来のどのリリースで対応するか」を設定します。
そうすれば、誰かに「あのバグはいつ修正されるの？」と聞かれたときに
正確な日付がわからなくても「次の次のリリースで対応します」と答えることができます。
この「リリース」は、バグ追跡システム上では「ターゲットマイルストーン」
という項目で管理します。IssueZilla
IssueZilla は私たちが使用しているバグ追跡システムで、
BugZilla の後継にあたるものです。
にはこの項目が存在します。Subversion プロジェクトのルールとして、
各リリースにはひとつの大きな新機能追加といくつかのバグ修正を含めることにしています。
将来のリリースに向けた各バグ報告 (新機能も含みます。
新機能も同じデータベースで管理しています) に対して適切な
ターゲットマイルストーンを設定しておくことで、
それを見れば今後のリリースの予定がわかるようにしています。
しかし、一度設定したターゲットマイルストーンがずっとそのままでいることは
めったにありません。新しいバグが飛び込んでくると、
作業の優先順位が変わることもあるでしょう。
そんな場合は既存のバグのマイルストーンを移動させないと
リリース計画を管理できなくなります。
こういった作業をおこなうには、やはり特定の担当者を割り当てて
バグデータベース全体の状況と各報告の内容を把握させておくことが大切です。
バグマネージャーのもうひとつの役割は、
バグ報告の内容が現状に即していないものになった場合の対応です。
全然関係ない別の変更の結果、偶然にバグがなおってしまうこともあります。
あるいは、最初はバグとして対処しようとしていたけれど
結局それは仕様ということにしてしまうという場合もあります。
現状に即していないバグ報告を見つけるのは大変な手間のかかる作業です。
機械的にやるとするなら、データベース内のすべてのバグをチェックしなければなりません。
しかし、時を経て報告の量が増えてくればくるほど、
総チェックいうのは現実的ではなくなります。
ある程度の段階になると、データベースをまともな状態に保つ唯一の方法は
「分割して統治」ということになるでしょう。
バグ報告をカテゴリ分けし、それぞれを適切な開発者 (あるいはチーム)
に振り分けるのです。その後の対応はすべて振り分けられた側が責任を持つことにします。
これほどデータベースが巨大化すると、バグマネージャーは
どちらかというと全体の調整役として働くことが多くなります。
自分自身で個々のバグを処理するのではなく、
適切な人にそれを振り分ける役になるということです。
FAQ マネージャー
FAQ の保守という作業は、思いのほか難しいものです。
大半のドキュメントは、作者が事前に練り込んだ内容を記述するものです。
それとは異なり、FAQ は基本的に受け身のドキュメントとなります
( を参照ください)。
どれだけたくさんの量を書いたとしても、
次にどんな内容が追加されることになるかは決してわかりません。
そして、常に細切れの内容が追加され続けるので
ドキュメント全体としての一貫性やまとまりは簡単に崩れてしまいます。
ひどい場合は同じ内容が重複してしまったりすることもあるでしょう。
そんな問題がないように見えるものでも、
目立たないところで関連項目間の相互依存の問題が発生していることはよくあります。
たとえば本来はリンクするべきところができていないなどです。
お互いの項目が時期をずらして追加された場合などにこれが起こりえます。
FAQ マネージャーの役割は、ふたつあります。
まずは FAQ 全体の品質を保持すること。
そのためには、FAQ の中でどんな項目が取り上げられているのか
少なくとも質問だけでも把握しておく必要があります。
そうすれば、既存の項目に関連する内容や重複する内容が新たに追加されたときに
適切な処理をすることができます。
もうひとつは、プロジェクトのメーリングリストや掲示板をチェックして、
どんな問題が発生しているのかやどんな質問が行われているのかを確認することです。
それをもとにして、新しい FAQ を書き進めていきます。
後者の作業は非常に複雑なものになるかもしれません。
各スレッドを追いかけ、そこで行われている質問の内容を把握して
新たな FAQ エントリの追加を提案します。
そして他のメンバーのコメントなども考慮して
(FAQ マネージャーがすべての内容のエキスパートであるとは限りません)
エントリの内容をふくらませ、ある程度まとまった段階でそれを実際に追加することになります。
FAQ マネージャーは、FAQ 自体の書式についても責任を持ちます。
FAQ の体裁に関する注意点はさまざまなものがあります
( の
を参照ください)。
不特定多数が FAQ を編集するようになると、
これらの注意事項がおろそかになってしまうことがあります。
そんな場合でも FAQ マネージャーがきちんと注意してそれを修正していけば大丈夫です。
FAQ の管理を支援するためのフリーソフトウェアも数多く存在します。
FAQ の品質を低下させない範囲でそれらのソフトウェアを使うのはかまいませんが、
過度に自動化してしまわないように注意しましょう。
プロジェクトによっては、FAQ の保守を完全に自動化しようとしているところもあります。
wiki ( の
を参照ください) などを使用して、
誰でも自由に FAQ の項目を追加/編集できるようにするなどしています。
これは Faq-O-Matic
()
を使っているプロジェクトでよく見かけますが、
私の見る限りでは Faq-O-Matic
がもともと想定している範囲を超えた使い方だと感じます。
FAQ の管理を分散化することでたとえ全体の作業量を軽減できたとしても、
その結果できあがる FAQ はどうしても品質が劣ったものになってしまいます。
そこには FAQ 全体を把握している人もいなければ
更新を要する項目や時代遅れになってしまった項目を見つける人もいません。
さらに各項目間のつながりを管理できる人もいないでしょう。
そんな状態でできあがった FAQ は、
探したい情報が見つからないどころか
間違った情報を与えてしまうものになってしまう可能性があります。
プロジェクトの FAQ を管理するのにどんなツールを使うのも自由ですが、
ツールの便利さに惑わされて FAQ 自体の品質に妥協してしまわないようにしましょう。
Sean Michael Kerner が書いた The FAQs on
FAQs という記事が
で読めます。この記事では、オープンソースの
FAQ 管理ツールについての説明とその評価を行っています。
引き継ぎ
時には、何らかの役割 (パッチマネージャーや翻訳マネージャーなど)
を受け持っている人がその作業を全うすることができなくなる場合もあります。
理由としては「作業量が自分の見込みよりずっと多かった」
「子供が生まれた」「転職した」など、いろいろなものがあるでしょう。
担当者がこのような状態に陥った場合、
それをすぐに自覚できないこともあります。
それは徐々に起こることであり、「もはや自分の任務を果たせない」
とはっきりわかる瞬間がないからです。
プロジェクトの他のメンバーは
「そういえば最近あの人をあまり見かけないね」
と感じることになります。
そして、ある日突然彼がものすごい勢いで活動を再開します。
しばらく作業をしていなかったことに負い目を感じて
「徹夜してでもなんとか追いつこう」と感じているのでしょう。
その後、彼はまた (もっと長い) 沈黙期間に入ります。
しばらくしてまた突然復活するかもしれませんし、しないかもしれません。
正式に「この役割から退きます」という表明があることはほとんどありません。
彼らは自分の空き時間を使って作業をしているのです。
引退を表明するということは、
自分の空き時間が今後ずっと少なくなってしまうということを自覚することです。
人はそれはなかなか認めたがりません。
したがって、あなた (と他のプロジェクトのメンバー)
のすべきことは、現状がどうなっているのか (あるいはなにも起こっていないのか)
を把握して、彼に状況を確認することとなります。
相手を責めるのではなく、友好的に問い合わせなければなりません。
状況を知ることが大切で、
人を不快にさせることが目的なのではないからです。
一般に、この問い合わせはプロジェクトの他のメンバーにも見えるかたちで行います。
しかし、何らかの理由で個人的に問い合わせたほうがいいと判断した場合は
それでもかまいません。公開の場で問い合わせる主な理由は、
彼が「もう作業を続けることができない」という返事があった場合に
その 次の 投稿、
つまり新しい担当者の募集につなげやすいからです。
時には、自分で引き受けた作業をこなす能力がないにもかかわらず、
それを自覚できていないかあるいは認めようとしない人もいます。
もちろん、作業を始めたばかりのころは誰でもうまくいかないものです。
複雑な作業を与えられた場合などは特にそうでしょう。
しかし、他のメンバーができる限りの支援をしてやっても
なお彼が作業をこなせないとしたら、
彼にはお引き取り願ってだれか他の人に作業を任せるしかありません。
もし彼がそれに気づいていないのなら、だれかが教えてやる必要があります。
私が思うに、こんな場合の対応方法はひとつだけです。
ただ、その方法は何段階かに分かれるもので、
各段階がそれぞれ重要となります。
まずは、自分だけの思いこみではないということをはっきりさせましょう。
プロジェクトの他のメンバーと個人的に話し、
自分が持っている危機意識がみんなと同じくらいのものであることを確認します。
確認するまでもなく自明な状況であったとしても、他のメンバーと話すことで
「これからこういうことをしようとしている」
という気持ちを他のメンバーに伝えることができます。
通常は、この相談で相手に反対されることはないでしょう。
やっかいな仕事をあなたが引き受けてくれたということで、
むしろ感謝してもらえるかもしれません!
次に、問題となっている人に 個人的に
連絡を取ります。そして、やさしく (しかし要点をはぐらかすことなく)
あなたが感じている問題点を伝えます。
できるだけ、具体例を挙げて伝えるようにしましょう。
可能な限りの支援をしたこと、
それにもかかわらず問題は改善しなかったことをはっきりさせておきましょう。
このメールを書くのにはかなりの時間がかかることを覚悟しなければなりません。
この手のメッセージの場合、
もし自分が書いている内容にちょっとでも確信の持てない箇所があるのなら、
最初からそんなメッセージは書いてはいけません。
彼が引き受けた作業をだれか別の人に任せたいと思っていること、
プロジェクトに貢献するには他にもいろいろな作業があるということも説明しておきましょう。
この時点では、あなたが他のメンバーと相談したことは
まだ彼に言ってはいけません。
裏でこそこそ話が進められていたなんてことを知ったら
誰だって気を悪くするでしょう。
その後は、成り行きに応じていくつかの方法に分かれます。
たいていは、彼はあなたの提案に同意してくれるでしょう。
少なくとも否定はせず、進んで引き下がってくれることでしょう。
その場合は、引き下がることを彼自身で発表してもらうようにお願いします。
そして、あなたはその発表への返信で新たな候補者を募集します。
あるいは、問題があったことは認めるものの「もうちょっとだけチャンスがほしい
(リリースマネージャーのような役割なら『あと 1 回だけ』など)」
とお願いされるかもしれません。
あなたはここで審判としての働きをしなければならないわけですが、
どう判断するにしてもそこに私情を挟まないようにしましょう。
そこで猶予を与えてしまっても、
単に苦痛をひきのばすだけのことにしかなりません。
このお願いを拒否する理由としてはっきり言えるのは、
これまでに何度もチャンスがあったということ。
そしてそのチャンスを生かさなかったからこそ今の状態があるということです。
以下に示すのは私が送ったメールの例です。
これは、リリースマネージャーの役割を引き受けながら
その役割を果たせなかった人に対して送ったものです。
> もし私じゃダメだというのなら、喜んで別の人にこの役割を
> 譲ります。ただ、ひとつだけお願いがあります。決して無茶
> なお願いではないと思います。あと一回だけチャンスがほし
> いんです。次のリリースで私の能力を証明させてください。
言いたいことはよくわかります (できればそうしてあげたい) が、
今回については「あと一回だけ」というのはやるべきではないと
思います。
今回が初めてのリリースだったとかならともかく、もう既に６回
目か７回目くらいになるわけです。そしてその間ずっと、あなた
は期待通りの結果を出すことができませんでした (っていうこと
は以前お話しましたよね)。つまり、はっきり言えば「あと一回」
の段階は事実上終わっているわけです。結局のところ、この前の
[過去のリリース] がその「あと一回」だったんです。
最悪の場合は、相手が提案を拒否するかもしれません。
この場合は、ちょっと話がやっかいになることを覚悟しなければなりません。
ここにきて初めて、事前に他のメンバーとも話し合っていたことを明らかにします
(ただ、相手の許可を得るまでは「誰と」話したのかは言ってはいけません。
あくまでも私的な相談だったのですから)。
そしてこのままではプロジェクトにとってあまりよくないということも説明しましょう。
何度も何度も、しかし決して威圧的にならないように注意して。
覚えておいてほしいのは、大半の役割については
新しい担当者が作業を始めた時点で移行が完了する
(前任者が作業をやめた時点では ない)
ということです。たとえば、バグマネージャーの資質が問題になっているのなら、
あなた (やプロジェクト内の主要メンバー) は
いつでも新たなバグマネージャーを仕立て上げることができます。
前任者が新たなバグマネージャーの作業を邪魔したりしない限り、
前任者が作業をやめるかどうかは大きな問題ではありません。
ふとこんな考えが頭に浮かぶかもしれません。
「わざわざお引き取り願わなくたって、だれか補佐役をつけてやるだけでいいんじゃないの?」
「バグマネージャーにしたってパッチマネージャーにしたって、
別に 2 人いても何も問題はないんじゃないの?」
一見よさげに聞こえますが、一般的にこれはよい考えではありません。
マネージャーの役割がなぜうまく機能している
(役立っている) のかというと、それは中央集権型だからです。
もし分散管理してもうまくいくような作業なら、
きっとはじめからそのようにしていることでしょう。
ひとつの管理作業を 2 人に任せると、
その 2 人の間のコミュニケーションというオーバーヘッドが発生します。
そして、お互い責任をなすりつけあう
(「きみが救急箱を持ってくるんじゃなかったの?」
「まさか。ぼくは君が持ってくるものだとばかり思ってたよ!」)
という危険性もあるでしょう。
もちろん例外もあります。複数の人間がうまくかみ合って作業が進むこともあるでしょうし、
複数の人間で行うのに適した作業もあります。
しかし、もともとその作業に適していないと思われる人にとっては
あまり意味のないことでしょう。
彼が最初の時点で問題をきちんと把握していれば、
もっと早い段階で助けを求めてきたはずです。
いずれにせよ、作業がうまく進まないで
単なる時間の浪費になってしまっているのを見過ごすのはまずいことです。
だれかに手を引いてもらうようお願いするときに最も大切なのは、
プライバシーです。みんなに注目される中ではなく、
自分一人でどうするかを考える余地を残しておくようにしましょう。
私は、かつて間違いを犯しました。明白な間違いをです。
ある人に Subversion のリリースマネージャーを退いてもらい、
かわりに別の 2 人に任せようと考えたときに、
当事者 3 人に対して同時にメールを送ってしまったのです。
新たに任せる予定の 2 人には事前に個別に話を持ちかけており、
どちらもその気であることはわかっていました。
世間知らずで無神経な私は
「一通のメールを全員に送ってしまえば話は早いじゃないか。
こんな面倒なことはさっさと終わらせてしまおう」
と考えたのです。当時のリリースマネージャーもすでに事態を自覚しており、
きっとすんなり退いてくれるだろうと想定していました。
私は間違っていました。当時のリリースマネージャーは激高しました。
当然です。単に仕事を取り上げられたということだけでなく、
新しい担当者が 目の前に
いるところでそれを言われたのですから。
彼が怒っている理由を知って、私は謝りました。
彼は結局私たちの提案に同意してマネージャーを退いてくれました。
その後も別の形でプロジェクトに参加し続けてくれています。
しかし彼は傷ついたでしょう。言うまでもなく、
新たにマネージャーを引き受けることになった側にとってもやりにくかったはずです。
コミッター
あらゆるオープンソースプロジェクトにおいて唯一公式に識別可能なのは、
コミッターかそうでないかということです。
ここでは「コミッター」について注目してみましょう。
メンバーをできる限り平等に扱うことを心がけていたとしても、
コミッターだけは別に扱うということは避けられないでしょう。
「別に扱う」といっても、特に差別的な意味はありません。
コミッターの役割は欠かせないものであり、
それなしではプロジェクトがうまく回ることはないと考えます。
品質管理のためにはコントロールが必要です。
自分にはプログラムに変更を加える能力があると考える人は多くいますが、
実際に行うのはそのうちの一部の人となります。
プロジェクトは、各個人の自己判断に依存してはいけません。
何らかの基準を設け、それを満たした人にのみコミット権を与えるべきです
コミット権の考え方は、分散型のバージョン管理システムでは
多少異なることに注意しましょう。分散型のバージョン管理システムでは、
各個人がプロジェクトにリンクしたリポジトリを作成することができ、
作成したリポジトリに対するアクセス権を得ることができます。
それでもなお、コミット権という 考え方
自体は有効です。「コミット権」とは要するに
「そのグループが作成し、リリースするソフトウェアのコードに
変更を加える権限」ということです。中央管理型のバージョン管理システムでは、
これはリポジトリへの直接のコミット権を意味します。
分散型の場合は、自分の変更内容を配布ファイル本体に
pull できる権限のことを指します。
いずれにしても考え方は同じです。裏側の管理方式はそれほど重要ではありません。
。
一方、変更を直接コミットできる権限を持つ人たちのまわりには
そうでない人たちも多くいます。彼らにもさまざまな考えがあるでしょう。
それをうまく管理して、プロジェクトをうまく動かしていくことが必要です。
の
で、
新たなコミッターを決める方法については既に説明しました。
ここでは、新コミッター候補の能力を見極める方法や
大規模コミュニティーで同じ手続きを進める方法について考えてみましょう。
コミッターの選びかた
Subversion プロジェクトでは、コミッターを決める際には
ヒポクラテス主義 first, do no harm
(何よりもまず、患者に害を与えないこと) を重視しました。
技術的なスキルや Subversion のコードに関する知識よりも、
単によりよい判断ができるかどうかに重きを置いたのです。
「判断ができる」というのは、単に「すべきでないことは何か」
を知っているかどうかという意味です。
だれかがちょっとしたパッチを送ってきたとしましょう。
それは、コードの中のほんの些細な問題を修正するだけのものでした。
そのパッチはうまく適用することができてバグもなく、
プロジェクトのコーディング規約やログメッセージの規約も守っています。
そのようなパッチを数多く送ってきた人に対して、
既存のコミッターたちが「コミット権をあげたらどう?」と提案します。
少なくとも 3 人のコミッターが賛成し、
かつ反対する人が誰もいなければ、正式にコミット権を提供します。
もちろん、その人がコード全体を把握していて複雑な問題も解決できるという証拠なんてありません。
しかし、そんなことは関係ないのです。はっきりと言えることは、
彼は自分自身の能力をきちんと判断することができるということです。
技術的なことは、後からでも勉強できます (し、教えることもできます)
が、判断力についてはなかなかそうはいきません。
したがって、コミット権を与える際には判断力の有無を重視したほうがいいでしょう。
新たにコミッターを追加しようという提案が議論を呼ぶ場合、
その原因が技術的なものであることはあまりありません。
どちらかというと、メーリングリストや IRC
上でのその人のふるまいが問題になることが多いようです。
たまに、技術的には問題がなく
プロジェクトの公式指針にしたがって働くこともできるけれども、
掲示板ではやたらけんか腰だったり非協力的だったりする人がいます。
これはちょっと深刻な問題です。
何度か助言をした上でまだ彼がそのような態度をとり続けるようなら、
たとえ彼の技術が優れていたとしても私たちは彼をコミッターにはしないでしょう。
ボランティアの集まりにおいては、いわゆるソーシャルスキル、
つまり「集団の中でうまくやっていく能力」は技術力と同じくらい重要です。
すべてはバージョン管理されているわけなので、
仮にふさわしくない人をコミッターにしてしまったとしても
コードにはそれほど被害は及びません (何か問題があっても、
コードのレビューですぐに見つかることでしょう)。
しかし、そんな場合はすみやかにその人のコミット権を剥奪することになるでしょう。
これは決して気持ちのいいことではなく、ときには対立が起こることもあります。
多くのプロジェクトでは、重要なパッチを何回か提供することで
はじめてコミッター候補として認められるような仕組みになっています。
これは、単にその人が周りに害を与えないかどうかを見るだけではなく
その人がコードにどのように関わっていくかを見るという意味があります。
これはこれでいいのですが、コミット権を得るのがまるで
会員制の高級クラブに入会するかのようなことになってしまわないように注意しましょう。
ここで問うべきことは「コードにとってもっともよい結果をもたらすにはどうしたらいいのか?」
であり、決して
「こいつを仲間に入れるとコミッターたちの社会的な評判がおちるんじゃないか?」
といったものではありません。
コミット権を与えるのは個人の自尊心を高めるためではなく、
コードに変更を加える際の手間をできるだけ減らすためです。
100 人のコミッターのうち定期的に大規模な変更を行うのが 10 人だけで、
残りの 90 人は誤植やちょっとしたバグの修正を年に数度行うだけだったとしましょう。
それでもコミッターを 10 人だけにしておくよりもよっぽどましです。
コミット権の剥奪
コミット権の剥奪に関してまずひとこと。
そんなことをしなければならない羽目に陥らないように、
最初から十分注意するようにしましょう。
「誰の」アクセス権を「なぜ」剥奪するのか
といった議論は紛糾しやすいものです。
たとえ皆の意見が一致していたとしても、
そんな作業は全く生産的ではありません。
しかし、どうしてもそうしなければならない状況になったら、
まずはその人にコミット権を 与えた
ときのメンバーの間で非公開で議論しなければなりません。
問題となっている人自身はその議論に加えてはいけません。
通常は秘密主義は否定されるものです。その方針には反していますが、
この場合は非公開であることが必要なのです。
第一の理由として、そうでないと自由に意見を交換することができません。
もう一つの理由は、もしコミット権剥奪の試みが失敗したときに
「そういう考えがあった」ということを当事者に知られないようにするということです。
それを知られてしまうと、きっと「剥奪に賛成したのは誰?
私の味方になってくれたのは誰?」という疑問が頭に浮かぶことになるでしょう。
これは、もっともたちの悪い派閥争いの原因となってしまいます。
ごくまれに、コミット権を剥奪する (あるいはしようと考えている)
ことを警告として知らせたいという状況もあるかもしれません。
しかし、そのような場合は必ずグループ全体の同意をとってからにしなければなりません。
非公開で行った議論や投票の内容は、参加者全員が了解しない限り公開することはできません。
だれかのアクセス権を剥奪したら、その事実を公表しなければなりません
(この章の後半の
を参照ください)。
一般向けへの公表は、できるだけそつなく行うようにしましょう。
部分的なコミット権
プロジェクトによっては、コミット権に何段階かの区別をつけているところもあります。
たとえば、ドキュメントについては自由に変更できるけれども
コードそのものにはコミットできないといった権限を用意しているわけです。
このように「一部だけに限定」したコミット権を与える場面としてよくあるのは、
ドキュメント、翻訳、他のプログラミング言語とのバインディング、
パッケージ作成用の設定ファイル (RedHat の RPM スペックファイルなど)
などです。これらは、何か間違いがあったとしてもプロジェクトのコアには
あまり影響を及ぼさないところでもあります。
コミット権は、単にコミットすることだけでなく投票権
( の
を参照ください) にもからんできます。
部分的なコミット権を持つ人の扱いはどうしたらいいのでしょうか?
正解はひとつではありません。
そのプロジェクトでどのように部分コミット権を定義しているかによって変わります。
Subversion ではきわめてシンプルに考えています。
部分的なコミット権を持つコミッターは、
自分がからんでいる範囲の事項については投票できるが
それ以外の範囲についての投票権はないということです。
ただ、参考意見としての投票 (advisory vote) という仕組みは存在します
(要するに、投票用紙に単に "+1" と書くのではなく "+0"
あるいは "+1 (拘束力なし)" と書くようなものです)。
公式な効力がないからといって、彼らを完全に黙らせてしまう理由はありません。
フルコミッターは、あらゆることに関して投票権を持ちます。
ちょうど彼らがどの部分にでもコミットできるのと同じようなことです。
そして、フルコミッターのみが新規コミッターの追加に関する投票権を持ちます。
しかし現実的には、部分的なコミッターを追加する手続きについては権限を委譲することもよくあります。
フルコミッターが部分的なコミッターの "保証人" となり、
その分野だけのコミット権を持つコミッターについては彼らに選ばせるのです
(これは、特に翻訳作業などを円滑に進めるために便利です)。
作業の内容によっては、このような決まりを
あなたのプロジェクトでそのまま取り入れるわけにはいかないかもしれません。
しかし、
「すべてのコミッターは自分のコミット権の及ぶ範囲に関する決定への投票権を持ち、
コミット権の及ばない範囲に関しては投票できないということ」
「プロジェクトの進め方に関する投票は、基本的にフルコミッターのみが行うこと」
「ただし、もう少し投票できる人の範囲を広めるようにフルコミッターが決められるということ」
という大まかな考えかたはすべてのプロジェクトに適用できるでしょう。
部分的なコミット権の付与に関する注意:
部分的コミット権を与える機能を仮にバージョン管理システムが持っていたとしても、
できればそれは使わないようにしましょう。その理由については
の
をご覧ください。
休眠状態のコミッター
プロジェクトによっては、ある程度の期間 (たとえば一年間)
いちどもコミットがなかった人のコミット権を自動的に削除しているようなところもあります。
私はこれはあまりメリットがないと思っています。
というかむしろ逆効果でしょう。理由は次のふたつです。
まず、単にコミット権の有効期限切れを防ぐためだけの目的で、
あまり意味のない不要なコミットをする人が増えてくることになるでしょう。
次に、そんなことをしたところで何の意味もありません。
コミット権を与えるか否かを決める主要な条件は、
その人が正しい状況判断をできるかどうかです。
単にプロジェクトでの活動から一時離れていただけで
判断力が低下したと見なすことなんてできないでしょう?
仮に数年の間完全にプロジェクトから離れており、
その間コードも一切見ずに開発関連の議論にも目を通していなかったとしましょう。
それでも、プロジェクトに復帰した彼は
自分の状況をきちんと把握し、適切に振る舞ってくれることでしょう。
彼の判断力を信じたからこそコミット権を与えたはずです。
だったら最後まで信頼してあげましょうよ。
ハイスクールの卒業証書が期限切れになることがないのと同様に、
コミット権にだって有効期限なんかいらないはずです。
時には、コミッター自身から「私を削除してほしい」
「休眠状態であることをコミッター一覧
(この一覧についての詳細は 下の
をご覧ください)
に明示してほしい」とお願いされることもあります。
そんな場合は、当然そのお願いを受け入れなければなりません。
秘密主義を避ける
誰かを新しいコミッターとして認めるかどうかについての議論は内密に行う必要がありますが、
認める基準やその手続きについては特に隠す必要はありません。
というか、公表してしまったほうがずっといいでしょう。
そうすれば、まるで星室庁 (Star Chamber)
のような謎めいた組織だと見られることもなくなり、
よいパッチを投稿してコミュニティー内で認められさえすれば
コミッターになれるのだと理解してもらえます。
Subversion プロジェクトでは、
この情報を開発者むけガイドラインドキュメントに記載しています。
コミット権を取得したいと考える人のほとんどは、
コードを書いてプロジェクトに貢献したいと考えているであろうからです。
コミッターになる手順を公開するだけでなく、
現在のコミッターの一覧
も公開します。この情報を公開する場所として昔からよく使われているのは、
プロジェクトのソースコードツリーの最上位にある
MAINTAINERS あるいは
COMMITTERS という名前のファイルです。
このファイルには、まずフルコミット権を持つメンバーの一覧を記載します。
その後に、各分野別に部分コミット権を持つコミッターの一覧を続けます。
各メンバーについて名前とメールアドレスを記載しますが、
メールアドレスについてはメンバーの希望に応じてスパム対策のエンコードを施すこともあります
( の
をご覧ください)。
フルコミッターと部分コミッターは明確な基準で区別できるものなので、
一覧上でも区別しておくとよいでしょう。
ただ、プロジェクト内で必然的に発生する非公式な区別
(影響力の大きい人は誰かなど) までも一覧に反映させようとしてはいけません。
この一覧は公式な記録なのであり、覚え書きではありません。
コミッターの並び順は、単純にアルファベット順にするか
コミッターになった時期の順にします。
クレジット
クレジットある物事に対する貢献を明確にするため、貢献があった人物、
団体、企業等の名前を明示すること は、
フリーソフトウェアの世界における通貨のようなものです。
プロジェクトに参加する動機が何であれ、
匿名や他人の名前で仕事をして喜んでいる開発者を私は知りません。
これには明確な理由があります。
プロジェクトで尊敬されているかどうかは、そこで行使できる影響力をも左右します。
そして、オープンソースプロジェクトに参加していることを履歴書で評価する経営者もいるので、
そのことが直接ではないにしろ開発者の市場価値に反映されるかもしれないからです。
もっと明確で、説得力のある理由がもう一つあります。人は他人から評価されたいですし、
無意識のうちに他人が自分の仕事をわかってくれる証を求めるからです。
よって、クレジットはプロジェクトに対するもっとも強い動機付けのひとつになります。
小さな貢献をプロジェクトが認めてくれると、
認められた人はもっと大きな貢献をするために戻ってくるのです。
共同で開発するソフトウェア( を参照してください)
が持つ重要な特徴のひとつとして、誰がいつ、
何をしたかを正確に記録していることがあげられます。
可能ならいつも、この記録をクレジットを適切に記す目的に使うようにしましょう。
そして、行った貢献の種類を明確にしておきましょう。
"ありがとう、J. Random <jrandom@example.com>" のような書き方はせず、
"バグ報告と再現手順を教えてくれた J. Random <jrandom@example.com>、
ありがとう" と記すようにします。
Subversion プロジェクトでは、記録されているバグ報告や、
記録がなくてもコミットログに残っている報告者にクレジットを与えるやり方について、
非公式ですが一貫したポリシーがあります。
リビジョン 14525 までの Subversion のコミットログをざっと調査したところ、
10%のコミットに対して名前と電子メールアドレスを記録するクレジットを与えていました。
クレジットを与えられたのは、バグを報告したり、
そのコミットで修正されたバグを分析したりした人であるのが普通です。
クレジットを貰う人たちは、実際にコミットを行った開発者とは違いますし、
開発者の名前はいつも自動的にバージョン管理システムに記録されていることに注意してください。
Subversion プロジェクトでは、80数人のコミッターのうち55人が、
自身がコミッターになる前に(通常は複数回)コミットログでクレジットを貰っていました。
クレジットを貰うことが、
継続して開発に参加してくれることを保証してくれるわけではもちろんありません。
しかし少なくとも、
プロジェクトが貢献を認めることを期待できる雰囲気を作り出すことはできます。
貢献に対してお礼をいうことと、特別なお礼は区別することが重要です。
特定のコードや、コード以外の貢献を議論するときは、それらの仕事に対して
感謝の意を示すとよいでしょう。たとえば、"我々が機能Xを実装できるのは、
ダニエルさんが最近してくれたデルタコードに対する修正のおかげだ" というと、
彼の仕事のどの修正について話しているかが同時にわかるようになります。
一方で、ダニエルに単にお礼を言う電子メールを出すだけでは、実際すぐに役に立ちません。
単に電子メールでお礼を言うだけでは、情報がなにもわかりません。
なぜなら、バージョン管理システムなどの仕組みが、
変更を行った事実を既に記録しているからです。
何に対してもお礼を述べてしまうと、人々の興味が分散してしまい、
最終的には価値がなくなってしまいます。なぜなら、
お礼は普段している前向きなコメントより目立つほど効果が大きいものだからです。
もちろん、これはお礼を述べていけないということではありません。
与えるクレジットが多すぎて洪水を起こさないようにしましょう。
以下に示す基準が役に立つでしょう。
議論の場が短命であればあるほど、気軽にその場でお礼を述べるようにしましょう。
たとえば、IRC上の会話でバグ修正に対してお礼を言うのはよいことです。
また、他のトピックについて話している電子メールの中で、
余談としてお礼を言うのもよいでしょう。
しかし、本当にまれな功績がない限り、お礼を言うだけの電子メールを出してはいけません。
同様に、プロジェクトのウェブページのあちこちで感謝の言葉を述べてはいけません。
いったんそれをやり始めると、いつどこでやめたらいいのかわからなくなります。
そして、絶対に コードのコメントでお礼を言ってはいけません。
コードを読む人が理解の助けにする、というコメントの第一義を損なうだけだからです。
プロジェクトに参加する頻度が少ない人であればあるほど、
その人に対してお礼を言うのは適切です。
これは直感に反するかもしれませんが、
お礼は、自分が考えている以上のことをしてくれたときに言うものだ、
という考え方とよく合います。
よって、普段貢献してくれている人のいつもの仕事に対して頻繁にお礼を言ってしまうと、
彼らがしていることは期待されていないものだ、
ということを表現することになってしまいます。
どちらかというと、反対のことをあなたは言いたいはずですよね！
このルールにはときどき例外があります。
誰かが一時的に一生懸命努力しなければならない役割を全うしたときです。
良い例が、リリース時には本格的に作業しますが、
そうでないときは休眠状態 (リリースマネージャーとしては休眠していますが
— そのときは活発な開発者でもあるかもしれません。
ですが、これは別問題です) のリリースマネージャーです。
批判することやクレジットを与えることと同様、
感謝の意をあらわすのは特別であるべきです。たとえある人が偉大な人であっても、
ただそれだけでお礼を述べてはいけません。
普段以上の物事をやり遂げたことに対してお礼を言い、
それに付け加えて、それをなし遂げたのがなぜ素晴らしいかを述べるようにしましょう。
「プロジェクトが個別の貢献を認めること」と、
「個別の貢献を賞賛して積み重ねず、集団全体で努力すること」はいつも対立するのが普通です。
この対立関係を理解し、集団の中で試行錯誤するようにすれば、
収拾がつかなくなることはないでしょう。
プロジェクトの分裂
の
では、
プロジェクトが分裂する 可能性
がプロジェクトの管理体制に重大な影響を及ぼすことを取り上げました。
しかし、実際に分裂した場合はどうなるのでしょう?
どうやって処理するのでしょうか? それがどんな影響を及ぼすのでしょうか?
逆に、あなたのほうがそうしなければならないことはあるでしょうか?
その答えは、状況によって変わります。
プロジェクトの進む道に関して相容れない意見の相違が出てきたために
友好的にプロジェクトが分かれることもありますが、
おそらくそれよりもっと多いのは
技術的な意見の相違や人間関係の問題によって
プロジェクトが分裂することでしょう。
もちろん、これらを明確に区別できるとは限りません。
技術的な議論は往々にして個人的な議論の要素も含んでいるからです。
共通しているのは、ある開発者グループ
(あるいはひとりの開発者だけのこともあります)
にとってその他のメンバーとの共同作業のコストに見合う利益が
得られないと判断したということです。
プロジェクトが分裂したときの、どちらが「本家」だとかどちらが「元祖」
だとかいう問いへの明確な答えはありません。「プロジェクト P
から分裂した F」というように、あたかも P は何も変わらないままで
F がそこから新たに分岐したと話す人もいます。
しかし、実際のところこれは「その人がどのように感じているか」
を言っているにすぎません。
これは基本的に認知度の問題です。周囲の大多数が同意すれば、
その主張が真実だということになります。
客観的にみた真実が最初からあるというわけではありません。
不十分ながらも「なんとなくこうじゃないかな」と考えることしかできません。
そして、まわりの認知度こそがむしろ客観的な真実と言えます。
結局のところ本家 (あるいは分家) の区別
というものは人の心の中にのみ存在するものだからです。
もしプロジェクトを分裂させようと考えた人が
メインプロジェクトから離れて新たなブランチを立ち上げたのなら、
認知度に関する問題はすぐに解決するでしょう。
開発者もユーザーも、
新たに登場した競合プロジェクトが新しいプロジェクトであることを認め、
新しい名前 (元の名前に由来するものかもしれませんが、
容易に区別できるもの) や新しいウェブサイト、
新しい目標を持つものであることを認めることでしょう。
しかし、両方の陣営が「自分のほうこそがこのプロジェクトの本流であり、
名前を使い続ける権利がある」と考えている場合は話がややこしくなります。
もしそのプロジェクト名の商標権やドメイン、ウェブページなどを
何らかの組織で管理している場合は、通常はその組織の考えで問題を解決されます。
どちらが本家でどちらが分家なのかをその組織が決めることになるわけです。
というのも、広報合戦になればその組織にはかないっこないからです。
当然、そんな事態になることはめったにありません。
力関係についてはみんなよくわかっており、
結果のわかっているケンカなどしないでしょうから。
幸いなことに、たいていの場合は「どっちが本流でどっちが傍流か」
といった争いは起こりません。というのも、
実際に分裂してしまうかどうかは、
その動きに対する信任投票のような力学で決まるからです。
もし開発者の過半数がプロジェクトを分裂させる動きに賛同したのなら、
通常はもはやそうする必要はありません。
強情な独裁者がプロジェクトを仕切っているのでもない限り、
わざわざ分裂させなくてもそのプロジェクトの中で動きを進めていけばいいのです。
一方、もし分裂させようと考えているのが全体の半数より少ないのなら、
それは明らかに少数派の反乱です。礼儀的な意味でも、
また常識で考えても彼らが本流となることはないでしょう。
本流から分岐した別のものと考えるべきです。
分裂の動きをうまく処理する
プロジェクト内で誰かが新しい競合プロジェクトを立ち上げる動きを見せ始めたら、
まずは落ち着いてあなたの長期目標を思い出しましょう。
分裂すること自体はプロジェクトにとって害ではありません。
むしろそれによって開発者やユーザーを失うことが問題なのです。
つまり、あなたのやるべきことはそうした動きの芽を摘むことではなく
その被害を最小限に抑えることなのです。
腹が立つかもしれません。
そんな動きは不当なものであり、
また不要なものであると感じるかもしれません。
でも、そんな感情を表に出したところで、
態度を決めかねている開発者をあなたから遠ざけることにしかなりません。
開発者たちに、態度を明確にするよう要求してはいけません。
そして、新しくプロジェクトを立ち上げる人たちともできるだけ協力的に接するようにしましょう。
まず第一に、誰かが新しいプロジェクト側で作業をすることになったからといって、
その人のコミット権を剥奪するようなことはやめましょう。
新しいプロジェクトの側で作業をすることになったからといって、
元のプロジェクトにおけるその人の権限が即刻失われるというわけではありません。
これまでコミッターであった人は、これからもコミッターであり続けるべきです。
さらに、新しいプロジェクト側とはできるだけ仲良くやっていきたいという意志を示すことも大切です。
必要に応じて、お互いのプロジェクトの変更内容を相手側にも反映させられるような関係を保ちましょう。
もしあなたがプロジェクトのサーバの管理権限を持っているのなら、
プロジェクトを始めるにあたってのインフラの支援を提案しましょう。
たとえば、そのプロジェクトの過去のバージョン管理リポジトリのデータのコピーを提供すれば、
彼らが過去のデータを使えるようになります
(使用するバージョン管理システムによっては、
わざわざそうしなくても過去のデータを利用できるものもあります)。
何か必要なものがないかどうかを彼らに聞き、
可能な限り支援するようにしましょう。
あなたが邪魔をするつもりがないこと、
そして (他の要因ではなく)
あくまでも実力次第で新しいプロジェクトの成功か失敗が決まるような状態にすることを態度で示すことが大切です。
これらすべてを (公式に) 行う理由は、
新しくプロジェクトを立ち上げる人たちを助けるためではありません。
「こっち側にいたほうが何かと安全ですよ」
ということを、できるだけ押しつけがましくない方法で開発者たちに伝えるためです。
戦争においては、どちらの陣営に属するのかを明確にさせることにはそれなりの意味もあります
(戦略的な意味、あるいは人間的な意味において)。
しかし、フリーソフトウェアの世界においてはこれはまったく無意味です。
実際、プロジェクトを立ち上げた後でも両方のプロジェクトでおおっぴらに活動する開発者も中にはいます。
両者の互換性を保つために力を注いでいたりするわけです。
彼らのおかげで、分裂した後でも両方のプロジェクトの間の交流ができるようになります。
彼らは、新しいプロジェクトの側で追加したすてきな新機能をあなたのプロジェクトにもたらしてくれるかもしれません
(そう、あなたの望むものをあちら側で作っている可能性もあるでしょう)。
そして、将来ふたたび両者が合流するという望みも残してくれます。
時には新しいプロジェクトのほうが大成功を収めることもあります。
最初に分裂させた当事者でさえ自分たちのほうが分家だと認めているにもかかわらず、
みんながそちらのバージョンのほうをずっと好むようになり、
結局本家に取って代わるようになるといったものです。
有名なのは GCC/EGCS の例です。
GNU Compiler Collection
(GCC、これは以前は GNU C
Compiler という名前でした)
は、オープンソースのネイティブコードコンパイラとしてもっともよく知られているもので、
またもっとも多くの環境に移植されているコンパイラでもあります。
GCC の公式メンテナーと Cygnus Software
現在は RedHat ()
に吸収されました。
との間の意見の相違が原因で、GCC のもっとも活発な開発者グループのひとつであった
Cygnus は GCC を離れて EGCS
という新しいプロジェクトを立ち上げました。
EGCS 側は、意図的にオリジナルと敵対することを避けました。
EGCS の開発者は、決して自分たちのバージョンを公式な GCC にしようとは思わなかったのです。
そうではなく、EGCS をよりよいものにすることだけに注力し、
パッチを受け入れる頻度も公式の GCC メンテナーより多くしました。
EGCS の人気は増し、大手の OS ディストリビュータの中にも
デフォルトのコンパイラとして GCC ではなく EGCS を採用するところが出てきました。
ここにきて、さすがに "GCC" の名前を持っている本家 GCC のメンテナーたちもわかってきました。
みんなが EGCS に移行するときにわざわざ名前を変更しなければならないのは面倒だということ、
そしてもはや GCC の名前を引き渡さざるをえないということを。
そこで、GCC は EGCS のコードを受け入れることにしました。
GCC は再び統一されたのです。
オリジナルから分かれて、新たにプロジェクトを立ち上げたおかげで、
中身はとても改良されたものになっています。
この例ひとつとっても、
プロジェクトの分裂を単純に悪とみなすべきではないことがよくわかります。
実際に起こったときは苦痛を感じてあまり歓迎されないかもしれませんが、
それが成功するかどうかなんてそのときには知ることはできません。
したがって、あなたを含むプロジェクトのメンバーができることといえば、
彼らを見守り続けて新機能やコードを取り込めるように準備しておくことくらいです。
もしそのほうがプロジェクト全体の利益になると皆が同意したら、
究極の選択として彼らに合流することも考えるべきでしょう。
もちろん、それ加わるメンバーをみれば
それが成功するか失敗するかをある程度予測できることも多いでしょう。
たとえば、プロジェクト内で文句ばかり言っていた人が
一握りの不満分子 (彼らもプロジェクト内では建設的な振る舞いをしていませんでした)
を引き連れて新たな競合プロジェクトを立ち上げたとしましょう。
こんな場合は、むしろそうしてくれたほうがありがたかったでしょうね。
彼らが本家に取って代わることを心配する必要もないでしょう。
しかし、もし皆に尊敬されている実力者が新しいプロジェクトに参加しているというのなら、
なぜそんなことになったのか自分に問い返してみましょう。
おそらく、あなたのプロジェクトには制約が多すぎ、
やりたいことの一部 (あるいはすべて)
を実現するにはプロジェクトのコピーを使って競合プロジェクトを立ち上げるしかなかったのでしょう。
要するに、自らが行動することで他の分裂の動きを避けるということです。
新しいプロジェクトを立ち上げる
ここでのアドバイスは、最後の手段としてオリジナルのコピーを使い、
競合プロジェクトを立ち上げざるを得なくなった人たちに向けたものです。
立ち上げを始める前に、まず他の可能性を徹底的に試すようにしましょう。
実際に競合プロジェクトを立ち上げると、
ほとんどの場合は開発者を失うことになります。
仮に後で新しい開発者が増えるとしても、そうなる確証はありません。
また、競合プロジェクトを立ち上げるということは、
ユーザーの気を引くための競争が始まるということを意味します。
そのソフトウェアをダウンロードしようとした人たちはみんな悩むことでしょう。
"で、いったい私はどっちをダウンロードすりゃいいの?"
あなたがどちらのプロジェクトにいたとしても、状況は混沌としています。
そんな質問は、プロジェクトが分裂する前には出なかったわけですから。
中には、プロジェクトが分裂することはソフトウェアの生態系上ごく自然なことだという人もいます。
自然淘汰の結果、一番環境に適合したものが生き残る。
つまり、結局はみんながよりよいソフトウェアを使えるようになるというわけです。
生態系という意味ではそれが真実かもしれませんが、
個々のプロジェクトにおいては決して真実であるとはいえません。
プロジェクトが分裂しても、
新たに立ち上がったプロジェクトが成功することはほとんどありません。
また、ほとんどのプロジェクトは分裂してもよい結果を生みません。
結論としては、議論のネタとしてプロジェクトが分裂することを持ち出してはいけないということです。
—"俺の言うとおりにしてくれなきゃプロジェクトが分裂しちゃうよ!"— といった具合に。
なぜなら、みんな知っているからです。
プロジェクトを分裂させたとしても、
開発者の興味をひくことができなかったら、
新しい競合プロジェクトの行く末は長くないことが多いということを。
すべての関係者 (開発者だけではなくユーザーや各 OS 向けのパッケージ作成担当者なども)
がどちら側を選ぶのかの判断を迫られることになります。
したがって、あくまでもそれ以外のやり方がないことが確実に主張できる状況にならない限り
プロジェクトを分裂させるのは避けるようにしましょう。
プロジェクトを分裂させることで生まれる、
新しいプロジェクトが成功するかどうかの可能性を評価するにあたっては、
すべての 要素を考慮にいれることを忘れないようにしましょう。
たとえば、
プロジェクトの開発者の多くが同じ雇い主のもとで働いているとしましょう。
たとえ彼らが不満を抱いて個人的に新しいプロジェクトの立ち上げを考えたとしても、
雇い主がそれに反対していると知れば
声を大にしてそれを言うことはないでしょう。
フリーソフトウェアプログラマーの多くは、
コードにフリーなライセンスが適用されていたら
特定の企業に開発が左右されることはないと考えがちです。
究極の意味では、ライセンスが自由を保証しているというのは事実です。
だれかが本当に元のプロジェクトから分かれて、
新しい競合プロジェクトの立ち上げを望み
それだけのリソースがあるのなら、できないことはないでしょう。
しかし実際のところは、いくつかのプロジェクトの開発チームは
ほぼ特定の団体が資金源になっていることが多く、
それを隠そうとしても無意味です。
その団体がそうした動きに反対しているようなら、
たとえ開発者が参加する気があったとしても
実際には参加することがないでしょう。
それでもまだ「今のプロジェクトから分かれて、
新しいプロジェクトを立ち上げる以外ない」と思っているなら、
まずは個人的に賛同してくれる仲間を集めましょう。
それから、そうすることを (けんか腰ではなく) おだやかに宣言します。
たとえ現在のメンテナーにたいして怒りや失望の気持ちがあったとしても、
それを実際に言ってはいけません。
あなたが決心したきっかけは何なのかということ、
そして現在のプロジェクトに対して悪意はまったくないということを冷静に説明します。
プロジェクトを分裂させるつもり (元のプロジェクトを緊急待避させるのではなく)
であるなら、あくまでもコードを派生させるのであってオリジナルと同じ名前を使うのではないということを強調し、
元のプロジェクトの名前と衝突することのない名前を選びます。
元のプロジェクトときちんと区別できるような名前であれば、
その一部に元のプロジェクトの名前を含めることもできます。
もちろん、新しいプロジェクトのホームページで
「これは元のプログラムから分離したものであり、元のプログラムを置き換えることを目指している」
と説明するのはかまいません。
区別しにくいような状況にユーザーを陥れてしまうことは避けましょう。
最後に、よいスタートを切るためのひとつの方法として、
元のプロジェクトのコミッター全員に対して (たとえ明示的に新しいプロジェクト立ち上げに反対していたとしても)
新しいプロジェクトのコミット権を与えてしまうというものもあります。
たとえ彼らがそのアクセス権を一切使用しなかったとしても、
あなたからの
「意見の不一致はあったけれども、敵になったというわけではない。
よいコードならどなたからのものでも歓迎します」というメッセージは伝わります。