オープンソースコミュニティ運営方法

Google Videoに「 How Open Source Projects Survive Poisonous People (And You Can Too)」という54分のビデオがありました。 Subversionの開発者達が、オープンソースプロジェクトを運営上の注意点を解説していました。 面白かったです。

ボランティア開発者の集合体によって実現しているオープンソースプロジェクトを運営する方法を解説するという題目ですが、 最後のオチでは、「これはオープンソースに限らない」と言っていました。 確かに、一般的な開発でも参考になる部分は多いと思いました。 また、掲示板やブログのコメント欄でも一部は適用できそうなノウハウであると思いました。

要約してみましたが、結構いい加減で間違いなどがあると思うので詳細はビデオをご覧下さい。 「Poisonous People」は「有害な人」と訳してみました。

概要

最初に、これは唯一の方法ではなく、私達の方法です。

プロジェクトを有害な人から守る４つのステップ

comprehension : 有害なのは誰か、どんな人か、守るものは何か

fortification : 有害な人は引き付けない

identification : 誰がそうか

disinfection : どうやって追い出すか

comprehension

大事なのはリソース。時間など。

コミュニティが大事 それを守りたい 感情的になってコミュニティのやる気を削ぐ人 無駄な争いを起こす人 何かをしようとしても、足をひっぱったり、間違った方向に導こうとする

狙ってこれをする人もいれば、うっかりやってしまうひともいる。

自分では気が付かずにやっている人がいる。 むしろそのほうが多い。 あまりにそのプロジェクトが大好きで良くしたい でも、結局は痛めつけているだけになる 完璧にやりたいと思っている

「完璧が良品の敵になるべきではない(The perfect must not be the enemy of the good)。 subversion projectではそれが標語になっている デザインドキュメントに完璧を求めすぎる人がいて、コードを書き始められなかった

昔、BSDのコミュニティで sleep は second か microsecondか？の討論があった 全体から見るとあまりに細かすぎる事に時間をかけ過ぎてしまった 細かすぎる議論で全体を見失ってはいけない

fortifying against the threat

open source communityをどうやってまもるか

healty open source projectの４大要素。open source projectでこれがないと失敗する。

礼儀正さ (politeness)

敬意 (respect)

信頼 (trust)

謙虚さ (humility)

mission, directionを持て

何を目指しているかと、スコープを区切って明確にする事が大事

subversionの場合は、「To create a compelling replacement for CVS」

6年やった あれもこれもやりたいという人がいた 何をしたいか、CVSの問題点は何かをまず列挙した ToDo Listを作った 新しい提案が出てきても、リストを眺めて、ToDoになければ、「1.0以降にもう一度来てください」と言った

新しくやって来る開発者と常にコミュニケーションをとらないといけない。 その開発者と方向性があうなら最高だ、でも、あわなそうならばお互いの時間を節約しよう(バイバイ)。

google web toolkitの場合は、scope を最初に明確にしようといった。 ボランティアの開発者達を「work with you but not against you」な状態にしないといけない。 google web toolkitのscopeは「no compermise AJAX development environment in JAVA in a modern browser」にした。 やること、やりたくないことの範囲を明確にすることが大事。

IRCとかIMがあるけど、ほとんどの議論はメーリングリストで行われる。 途中から来た人がメールアーカイブを読んでいないと意味が無い。 途中から来た人が、前提を読まないとみんなの時間を浪費してしまう。 それは途中から来た人が前からいる皆に対するdisrespectなので、それを発生させてはいけない。

議論をしていると、自分に反対する全てのメールに全て個別にリプライする人が出てくる。 ５０個ぐらいのメールの半分が特定の個人という事もある。 馬鹿馬鹿しい。 自分で出すresponseは一つにまとめろと言うことにしている。 ざっと読んでいると、反対する人が多いなぁという印象を持つかも知れないが、実は一人だったりする。

ドキュメンテーションは重要だ

全体の方向性 何をしているか、何をしようとしているか design disision bug fixes issue tracks 失敗もドキュメントとして残すべき 失敗を書かないと、もう一度議論を始める人が出る 全員がずっとプロジェクトに存在し続けるわけではない 今までの経過を書いて残すことになる

ドキュメンテーションをしないと。。。 同じ事を、何度も何度も何度も何度も何度も何度も何度も何度も何度も、繰り返すことになる

code collaboration

commit e-mailはbest way to realize what others are doing code reviewをメンバーがするきっかけになる commit e-mailは重要

開発者が人知れず３ヶ月ぐらいこっそりと巨大な機能を作りこんで、ある日突然commitするような事を許してはいけない あまりに巨大すぎると誰もレビューできない 皆がやるきをなくしてしまう 一人しかわからなくなってしまう branchを恐れてはいけない

開発者がいきなりいなくなることがある コメントがコード中に十分に書かれている事を確認するようにしている 一人で書いているときには、一緒に書いて手伝ってくれる人を募った 開発者に子供が生まれるかもしれない 開発者が転職するかも知れない 人生で色々転機がくるかもしれない ボランティアなので、些細なことでも開発者が離れてしまう可能性がある

誰か、特定の人がコードの特定の場所を「所有」してしまわないようにする 特定の事柄のエキスパートになるのは良い でも、企業やオープンソースプロジェクトでよくあるのが、段々と特定の個人がテリトリーを主張しだしてしまうこと この部分はおれの守備範囲だ！ ファイルの先頭に名前を書かせない コントリビュータリストなど他に書くところがある change logに書いてある、anotateすれば出てくる ファイルに名前が書いてあると、遠慮してしまうことがある。全てがanonymousだったら直してみようかなという気になる 名前が入っていると、どれぐらいやったらファイルに名前が入るのかという問題も発生する ２行書いたら入るのかとか、改行を修正したら入るのかとか

date parser engineerの事例 date parserを書いた人がいた 元々使っていたのは CVS から持ってきたdate parserでコードが汚かった 全部綺麗に書き直した人がいた 名前をファイルの先頭に書いた 名前をファイルに入れられないと言った 何で俺の名前が入らないんだ！ 入れられないので、書いて頂いたdate parserはいりません、さようならと言った 綺麗なコードやbug の修正よりもコミュニティ全体が重要だと判断している 目先のことよりも、long termで考えている 結局、他のエンジニアがやってきて書いてくれた ちょっと時間がかかっただけだった

well defined processes

release branch release processが無いプロジェクトがある

エンジニアをコミュニティにどうやって引き入れるか パッチを送ってくれる人をどうやって引き入れるか 忙しいとパッチを無視してしまうことがある 何らかのリストに入れるなど、正しくケアすることが大事

コミュニティの一員であるということの意味 技術的にはcommitできること それ以外にも、文化的には、仲間になること パッチを送ってくれる人からcommitできる人になるというプロセスがある 誰かがいきなり狂ったらどうなるか 事例としては、founderがほとんど全部書いたオープンソースプロジェクトがあった founderが全部書き直したくなったときコミュニティ全体とは違う方向性がでてきた コミュニティとしては、それを説明したが、founderは全部消すぞと脅しだした founderがコミュニティと方向性が違うなら、founderを捨ててしまえという発想 有害な人はある日突然内部から発生する場合があるという例 外部からだけとは限らない

多数決は最後の手段

健全なコミュニティでは多数決は行われない しょっちゅう多数決をとっているようなコミュニティは何かがおかしい 我々が今までに行った多数決は一つ コードのフォーマットについて カッコの前に空白を入れるかどうかだけ この議論は非常に白熱した

identifying poisonous people

bozo filter入りにするかどうか。 ただ、最初の１、２通のメールを見るとbozo入りぽい人でも実は良いコミッターになったという例もある。

特徴 メールアドレスが変 大文字や強調が多いメール 空気をよまない リリースしようとしている時に、「ここは全部スクラッチから書き直した方がいいよ」とか言い出す奴 変な質問や下らない質問をしている 他者に対するrespectが無いから他者の時間を浪費しているのかもしれない

謙虚さ このソフトウェアはカスだ！という人 捨て台詞を言って出て行く人 俺は書いてやるんだ！俺のために手伝え！何故手伝わない！ 自称アイディアマン subversionが○○と同期して動けば、世界制覇できるよ！ 昔した議論を蒸し返しているだけ アーカイブを読んでないだけ 文句だけ言って、修正自体はしようとしない人達 協調できない人 コードを書きたいけど、他人と協調はしたくない人 自分の書きたいようにしか書かない人 実際はコード書きの時間よりも設計の方に時間がかかることも多い subversionのlock機構にはコードを書く時間の倍以上かかっている 設計には議論と協調が重要

patch is welcome open source way of saying "go screw yourself". patchを持ってくれば最高だ でも、多くの場合、単に黙るか、去っていく

Disinfecting your community

既に有害な人がコミュニティに入ってしまった場合