オープンソースプロジェクトで実装刷新をスムーズに進める方法

土日にいくつかの論文を読んだ。そのなかで面白かったのが、産総研の上野乃毅氏が書いた「GNU Emacsにおける暗号化機能の刷新」（日本ソフトウェア科学会「コンピュータソフトウェア」Vol.26 (2009)掲載）だ。タイトルからは若干内容を想像しにくいが、オープンソースプロジェクトにおいて実装刷新をスムーズに進めるにはどうすればいいかについて語ったものである。同氏が開発したGNU Emacsの暗号化機能「PGG」を、新しい実装「PGG2」に刷新しようとした際に直面した抵抗やマージ拒絶の経験を踏まえ、コミュニティに受け入れやすい提案方法を提示したり、ロビー活動の重要性を語る内容になっている。詳しくは読んでもらった方がいいのだけど、簡単にまとめると提案されているのは以下のようなことだ（かなり意訳）。

1. 実装がある程度成熟してから提案する


2. 非互換性が生じるならば、それを予め明確にしておく


3. 実装提案は柔軟に受け入れる


4. 開発プロセスに関与してコミュニティの信頼を得る


5. 有力者へのロビー活動で無駄な議論を避ける

大まかにはLinuxカーネルの開発などで言われていることと同じだけど、(1)が決定的に違うのが興味深い。lkmlなどでは、完成品をドカンと投稿するよりも、アイディア段階から提案・議論を進めるのが良いとされているからだ。

最初は、プロジェクトの開発速度の差がこの違いを生んでいるのかなどと想像したが、プロジェクトにおける実装の位置付け次第なのかもしれないとも思えてきた。コアに近い部分の変更で、広い範囲に影響があるようなものなら議論してから実装の方が良いし、周辺機能の実装ならば、実装が完成してから提案する方がスムーズということではないだろうか。