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

2007/5/30

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

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

２つのポイント

その人はどうやって害を与えているのか？

その人は、今既にプロジェクトに害を与えているのか？

足を引っ張られているか

餌を与えてはいけない

突っつくと、スイッチが入ってしまう

とりあえず、無視する

しかし、

新規メンバーは注意深く観察すること

当初はうっとうしい奴に思えるかもしれない

単に言語の壁かもしれない

母国語が違うだけかもしれない

理解していない部分があるだけかもしれない

何回かやり取りしてみる事が重要

ダメな人かどうかの判断は焦らない

非常に失礼な暴言を吐きながら、バグを報告する人がいた

コミュニティとしては冷静に対処したが、バグはバグだった

暴言を吐いてはいたが、結果的にバグは修正された

非常にやる気がある学生がいた

最初はドキュメントを読んだり熱心だった

そのうち１時間毎にメールしてきた

メーリングリストの半分近くがこの人の質問関連になってしまった

皆に迷惑をかけていると気が付いていなかった

電話でいくら説明しても理解してもらえないかった

結局、この人が唯一、コミュニティから去ってくれと言った人だった

喧嘩しにきたんだ！

何で誰も相手をしない！と叫びまくる人もいた

オチ

これはOpen Sourceだけではない。どんなコミュニティでもそうだ。

Q & A

Q : アーカイブが巨大になりすぎたときに、どうやって新規メンバーにアーカイブを読めというのか？

A : 特定の部分を示して読めと言う場合もある。ドキュメント全部だとかなり巨大になるが、まとめてあるドキュメントをそろえてある。 subversionの本を書いた。フリーでも配っている。そこに無い内容があるのであれば、それは書かないといけないことである。

Q : コードを書かない専属コミュニティマネージャを置いたらどうか？

A : 最近は６割がコミュニティマネージメントで４割がコーディング。そのような人をおいているプロジェクトはあまり聞いた事がない。やっていくうちに良いコーダの一部が警察として機能してくれるようになる。結局、オープンソースコミュニティで言う事を聞いてもらうには尊敬されてないといけない。それには、そのコミュニティである程度コードを書いて貢献している必要があることが多い。

過去記事

過去記事一覧

超凄いIPv6解説書(488ページ)を無料配布します！