オープンソースのガバナンス

そう、OSSプロジェクトはそれぞれ個性がある。意思決定の仕方、パッチに対する要求水準、ユーザーとの対話に関する姿勢、本当に千差万別なのである。まず、規模によって違う。その上で、同じ個人運営のプロジェクトでも、その個人の技術者としての性格や忙しさ次第で様々だ。自分の美意識を満足させる美しいものを作りたいからパッチはほとんど受け取らない人もいる。会社が組織として関わっているプロジェクトだって、Googleの幾つかのプロジェクトのように、事実上内部のソフトウェアのミラーなので意思決定は中央集権的でほとんどパッチを受け取れない体制になっているのもあれば、Jenkinsみたいにシステムを分割統治する事で共同作業が進みやすいようになっているのもある。こういう「プロジェクトを回す仕組み」みたいなものをガバナンスと呼ぶ。

songmuさんは、だからOSSに関わりたい人は個々のプロジェクトのガバナンスを知るために時間や手間を掛ける必要があると説き、それはそのとおりなのだが、僕は反対側の、OSSプロジェクトはどうしたらいいのかという話をちょっとしたい。

というのも、大抵のプロジェクトでは、中の人達は自分達のプロジェクトのガバナンスの不透明性が外部貢献者にどれほど障害になっているかが分かっていないからである。他人の家の台所で料理が作れないようなものだ。そのせいで、色々な無駄が、損が発生する。中の人には勝手知ったる我が家なので、ガバナンスは限りなく透明に思える。新しい貢献者だって、ちょっと経てば自分のした苦労の事など忘れてしまうか、苦労をしたのは自分のせいだと思ってしまう。

でも、新しく参加しようという貢献者にはこの不透明性が必ず障壁になる。潜在的な貢献者の数は多く、その人達は、みんなこのコストを支払わねばならない。技術者としての優秀さに関わらず。プロのシェフだって他人の台所の使いづらさは変わるまい。なのに、中の人にはその使いづらさが分からないから、なんだこの人大したことないな、などと思ってしまいやすい。全方向に実にもったいない。

ガバナンスをクリアにするための簡単な第一ステップは、CONTRIBUTING.mdを用意するという事だ。書き方についてはは色々なところが既に書いている。自分にとっては当然の事を、それを知らない他人に説明するというのは思いの外難しい。

この難しさを実感するためにお勧めしたいのは、他所のプロジェクトにパッチ1つでいいので貢献しようとしてみる事だ。以前、Cargoというプロジェクトにちょっとしたコードを提供しようとしたことがあったが、その敷居の高さにうんざりした記憶は、僕の中で大きな学びになった。新しい貢献者に直接聞いてみるというのもいい。Jenkinsの時には、新しい貢献者にヒアリングをするという取り組みを一時期やって、それもとても役に立った。ただ、うまく水を向けないと向こうもある程度の障壁は当然だと思っていて指摘してくれない・できない事もある。

ApacheやEclipseなど、財団傘下のオープンソースは横並びでガバナンスが統一されている事が多く、地味にこれがこれらのプロジェクトの発展に寄与している。財団の良いところの1つだ。この文章を書いているgeditのgetting started guideがとてもいい。

comments powered by Disqus