オープンソースプロジェクトの進め方(が難しい、という話)

私は、Jiemamy Projectというオープンソースプロジェクトを運営している。

ある意味、一人で作っている頃は楽だった。Javaにおけるpublicというキーワードの重みも知らず、複数人によるコミュニケーションのオーバーヘッドも気にすることなく、それはそれは勝手気ままにひたすらコードを書くだけだった。

当初、Jiemamyは「そんなに難しいモンじゃないだろw さっさと作って便利にしようぜww」くらいのノリで作っていたのだが、作れば作るほど色々な問題点も浮上し、勉強すればするほど新しい機能も欲しくなった。人の欲とは恐ろしいものだ。一人じゃ、もう作れない、限界がすぐに訪れた。

Jiemamyは、(私の知る限り)今までにあまり無い考え方を打ち出したプロジェクトだ。ただ語られていなかっただけかもしれないが、「私はこうあるべきだと思う」という理想(Jiemamy開発プロセス)を打ち出し、それを実現するためのソフトウェアを作る、というのが当時も今も変わらない、プロジェクトのスタンスだ。

あまり知られていない考え方であるがゆえ、世間に対する地道なプレゼンテーションが必要だった。Jiemamyを説明する時「まぁ一言で言えばアレのもっと良い奴だよ」という説明ができないから。そして、その度重なるプレゼンが実を結び、プロジェクトに興味を持ってくれる人が数人出てきてくれた。

それが、Jiemamyの共同開発のスタートだ。
しかし、既存のソースコードを読んでさらにそれに修正を加える、という行為は、自分自身も「労力がかかり難しい」と感じているため、メンバーを集めて勉強会をしたり、WikiやITSを立ち上げて情報共有をしたり、Javadoc教に入信したり、コーディング規約を整備したり、色々な工夫をしてきたつもりだ。企業資本が絡まないOSSの中では、それなりに情報が整っているプロジェクトだと思う。

しかし現状、正直プロジェクトは回っていない

解決しなければならない問題は山積し、それぞれに結論が出ない。私自身が時間を掛ければ解決する類の課題であれば、単に時間をかけるまでだが、悩んで行き詰まって「どうしよう」というデッドロックにはまった課題が積み上がっていく。こういった問題は、プロジェクトを一番理解している私にとって難しいのだから、プロジェクトメンバーにとっても困難な課題であるはずだ。

このような課題をメーリングリストに投げてみる。運がよければいくつかのレスがある「○○だとどうだろう?」それに対して「あぁ、それは××という制約があるからムリなんだ」と私が答える。…基本、そこで終了だ。結論は出ない。最悪のケースでは、レスが一本もない。

という状況が、v0.2のリリース以後、ずっと続いている。ありがたいことにJiemamyは各所で期待を頂いているが、その期待に現状しっかり応えられていないのが申し訳ない。

原因の列挙と考察

このような状態に陥っている原因ではないか?と思われる点はいくつかある。だが、これらが本当に原因なのかは分からない。分からないままだが、ひとまず列挙してみようと思う。自分自身による再確認の意味も含めて。中には表裏一体の要素もあるかもしれない。

Javadocを読めるようにして敷居を下げるつもりが、Javadocを書かなければならないので、それ以上に敷居が高くなっている。コーディング規約が厳格であるため、コーディングしづらい。

基本、コードを書くのは大変だ。しかし、せっかく「好きで作る」コードを、普段仕事でやっているようなカオス状態にはしたくない。この辺は技術力でカバーできないかな、と思っている。もしメンバーから異論があったら、トラックバックでも飛ばしておくれ。

コーディング規約は、あまり気にしないで済むように、自動化できるところはほぼ自動化してある。Eclipseのコードフォーマッタを使って。この規約とフォーマッタは自社内でも利用しているのだが、意外とすぐ慣れるようなので、問題はないと思っている。

早い時期から公開APIの互換性を気にしすぎている。

改善の余地あり。publicとしてリリースしたAPIは頑張って互換性を維持しようとしていたが、v1.0を出すまではAPIの互換性保証はしないスタイルにしようかと思ってる。公開APIの互換性を気にして、APIを公開できないんじゃ本末転倒だしね。

プロジェクトのリソース配分がズレている。

意外と深刻かも。プロジェクトのリソースが「ドキュメントの作成」「規約の策定」「サーバの運用」とか、副次的なタスクに流れすぎているのかもしれない。しかし、「最先端のインフラを使って、そしてハックして、スムーズな開発環境を作る」ってのは、私の裏テーマだったりする。この追求の成果として、去年の日経ソフトウエア特集を書くことができた、と言っても過言ではない。うーん…。この辺は俺が好きだからなぁw 対応が難しい。

企業資本を絡めたくない、という(私の)エゴがある。

プロジェクト創始者として、エゴを出させてもらってるのがコレだ。プロジェクトに特定の企業色をつけたくない。好きなように作りたいので、投資は受け付けない。このご時世、寄付を受けただけで商標権を持って行かれることもあるようですし…w

まぁ、冗談はさておき。プロジェクト内からは「パトロンでもつかない限り、解消は難しいのではないか」という声もある。この辺り、エリック・レイモンドのOSS四部作*1から感じられるものがあった気がするので、まずは伽藍とバザールから読み直してみている。これによると、OSSプロジェクトの推進に企業資本が不可欠な訳ではない、気がするけど。

ところが実は、従来型のマネジメントが不可欠だと考えるような、インセンティブ構造や組織的なコントロールなんかまったくなしに、きちんと方向性を保って有能な管理者コミュニティをずいぶん長期にわたって維持してきたオープンソースプロジェクトはたくさんある。

The Cathedral and the Bazaar: Japanese
Skypeをコミュニケーションのベースにしているため、MLやその他のナレッジベースに情報が流れづらい。

Jiemamyでは色々なコミュニケーション手段がある。ML, Skype, ITS(JIRA), Wiki…。そして、個人的にSkypeに疑念がある。プロジェクト開始当初は、チャットでスピーディーな意志決定ができるメリットがあったのだが、今抱えている課題はチャットでも結論が出ない。チャットはリアルタイムに参加する必要があるから、たまたまそこに居ない人は議論に参加出来ない。また、チャットは気軽なので、大事なことを「MLに投げる」よりも「チャットに書き込む」ことを選択しがちだ。

ただ、本件に関しては、id:happy_ryoが「チャットの廃止」に激しく反対している。私自身、今は「チャットの廃止を激しく推進しよう」とはしていないため、激しい反対に対して論理的に反論できない。ひとまず、上に挙げたデメリットかもしれないものは解決できないのだが、自由意志で入退室ができる(プロジェクトメンバー以外も!)IRCに切り替えてみたりして、様子を見てみよう、なんて考えている。

みんな忙しい。

OSSプロジェクトに参加するような技術者は、押し並べて高い技術力を持ってる。…業務の世界では、そういう人にタスクが流れやすいンデスヨネー。そういう人ほど本を読むし、そういう人ほど時間のやりくりが大変だ。前述の通り、Jiemamyに業務で携わる人は一人もいないため、メンバーから「忙しい」と言われたら「そうですか」と返すしかない。本件は企業資本の話にもつながる。

メンバーのモチベーションを上げる要素が足りない。

これも伽藍より。ごほうびが足りないw ここはもっと工夫が要るな。もしかしたら、一番の問題点なのかもしれない。頻繁なリリースが足りないのが原因だろうか。しかし、ただ頻繁にリリースするだけで解決するのだろうか。

リーヌスは、ハッカー/ユーザたちをたえず刺激して、ごほうびを与え続けたってことだ。刺激は、全体の動きの中で一員となることでエゴを満足させられるという見込みで、ごほうびは、自分たちの仕事がたえず(まさに毎日のように)進歩している様子だ。

The Cathedral and the Bazaar: Japanese
プロジェクト(プロダクト?)自体に魅力がない。

なんか、最後、すげー後ろ向きだけどw これだったら…、救いようがないなw まぁ、これは「無い」と信じるしかあるまい。自分は魅力があると思っているし、期待もされているのだから。

参考文献、というか自分メモ


あと、この本も読み直してみるかな。

オープンソースソフトウェアの育て方

オープンソースソフトウェアの育て方

*1:俺、3部作だと思ってたんだけど、第4部があったのね…。

*2:そうそう、ひとつ言っておくと、伽藍がおもしろくなってくるのは後半だ。前半でめげてはいけない。まだ読んだことがない人は是非。