NetBSDの将来

以下は8月30日にnetbsd-usersメーリングリスト他への投稿として公開され、大きな反響を呼んだものである(原題「The future of NetBSD」)。NetBSDという1プロジェクトのみならず、オープンソース・プロジェクトのガバナンスの今後を考える上で様々な示唆を持つと思い訳出した。訳の公開に当たっては、mycroftことCharles M. Hannum氏に許可を頂いた。

チャールズ・M・ハンナム

NetBSD Projectは停滞し、何の意味も持たないものになってしまいました。プロジェクトと関係があるということが、しばしば強みどころか不利にしかならないありさまです。ここで私は、どうしてこうなったのか、現況はどういったものなのか、そして状況を好転させるにはどうしなければならないかをお話したいと思います。

NetBSDの創始者4人のうちの一人である私は、かなり特異なポジションにいます。私はプロジェクトに継続的に参加し、その全歴史を通じてずっとプロジェクトを注視してきた唯一の人間です。多くの変更が行われ、同時に多くのものごとが昔のままに留まっています — いくつかの、私たちの初期の過ちも含めて。

私が、OSSマーケットが現在のようにまでなると予見していた偉大なヴィジョナリーか何かだと言えればいいのでしょうが、もちろんそんなことはありません。私たちがプロジェクトを開始した当時は、Linuxにしろ386BSDにしろ、小規模な趣味人向けのシステムに過ぎませんでした。どちらも相当にバグだらけであり、重要なハードウェア・サポートの多くを欠いていました。必要なパッチを当て、より多くのシステムで実行できるようにしたりバグを直したりした386BSDの完全なパッケージは存在しませんでしたし、(訳注: 386BSDの創始者である)ビル・ジョリッツが再び活発になって何か作業をするという兆候もありませんでした。私たちがやっていたのは、ようは「痒いところを掻く」(scratching an itch)ということだったのです。

プロジェクトの初期に私たちが体験した問題のおかげで、プロジェクト構造の多くは進化しました。私たちが下した最良の選択は、おそらくプロジェクトの開始当初から中央集権的なバージョンコントロールを使ったことでしょう。これによって、コード履歴を極めて広汎に閲覧することが可能になり、(ついには)多数の開発者が遠方から協力するのがずっと簡単になったからです。他のいくつかの仕組みは、必要に迫られて適当にでっちあげたものでした。例えば、私たちが内部的な「徒党(cabal)」を組んでプロジェクトを管理することにしたのは、(訳注: NetBSD の4人の創始者の一人である)クリス・デメトリオがすべてについて目を光らせるのにうんざりしてしまい、また大学を卒業するのに躍起になっていたからです。この徒党は、その後「コアグループ」と呼ばれるようになりました。ウェブは当時誕生したばかりでしたが、私たちはかなり早い時期からウェブサイトを用意し、プロジェクトやリリースについての情報を広めていました。

この初期の構造の多く(CVS、ウェブサイト、徒党制など)は、他の(この用語はまだ広く使われてはいませんでしたが)オープンソース・プロジェクトによって、忠実にコピーされました。プロジェクト名の形式や「コア」という用語まで含めてです。これはその後、オープンソース・プロジェクトを開始するための標準的なテンプレートのようなものになりました。

不幸なことに、私たちはここでいくつかの過ちを犯しました。その後何年にも渡って見てきたように、Linuxの偉大な成功の一つは、Linuxには目標と方向性を設定する強力なリーダーがおり、彼がして欲しいことを人々にさせる、あるいは誰か他にそれをしてくれる人を探すことができたということです。この後者こそが鍵となる要素です。Linuxの一部を誰かが「所有している」と感じられることはありませんでした(ある部分について事実上の「所有権」が発生しているということはありましたが)。もしあなたが何も生み出さないならば、リーナスは誰か他の人のコードを使うでしょう。もしあなたが人々に自分が作ったものを使ってほしければ、あなたは前進し続けなければならないのです。

NetBSDに無かったのはこれでした。人が足りなかったということもあるし、より協同的なメンタリティのせいかもしれませんが、プロジェクトはしばしば「ロック」されてしまいました。ある人が、あるプロジェクトについて作業していると言うと、他の皆はそれを参照しろと言われるのです。しばしばそうしたプロジェクトは停滞し、あるいは全く進展しませんでした。仮に進展したとしても、多くの場合意欲は大変低かったのです。結果として、多くの重要なプロジェクトは遅いペースでしか進展せず、あるいはそもそも実現することがありませんでした。

こうした問題を生む手助けをしてしまったのが私で、またNetBSDをお手本にした(おそらくNetBSDは1993年や1994年ごろ大変人気があったからでしょう)プロジェクトの多くまでが似たような問題を経験するに至ったと言うのは残念なことです。例えばFreeBSDやXFree86には、非常によく似た理由ゆえにフォークした後継プロジェクト(DragonflyやX.org)が存在します。

不幸なことに、今日でもこうした問題はNetBSD Projectに依然存在し、それを是正するための努力はは何も為されていません。

こうした問題について、そのいくつかが生じたのは確実に私のせいであったと言うことを除いては、特定の人々を名指しで非難しようとは思いません。今頃になって非常に強力なリーダーが必要だと非常にはっきり分かったとしても、後の祭りです。10年前に追求していれば、事態は全然違ったでしょう。後悔先に立たずが人生なのかもしれません。しかし、ここでは現在の状況についてお話しましょう。

今日、プロジェクトは異なった徒党によって運営されています。これは2000年から2001年にかけて起こったクーデタの結果、NetBSD Foundation が詐欺的な理事会の変更によって乗っ取られたからです (原注: 残念ながら、私がこれについて法的な救済を求めるにはおそらくすでに手遅れでしょう)。「NetBSD Project」と「NetBSD Foundation」とは最初から別の主体として意図されていたもの — 後者は前者のサポートインフラを提供することになっていた — なのですが、この区別は設立以来盛んに不鮮明にされてきました。結果として、現在のNetBSD Foundationの「理事会」は、NetBSD Projectの多くの側面をかなり厳しく掣肘しています。

NetBSD Foundationが有能なリーダーの集まりとして構成されていれば、この状況は、理想的とは言えないにしろ、いくらかは受け入れられるものになっていたかもしれません。問題は、現時点において、実際のところリーダーなど一人もいないということです。リリースへの「目標」はカスタマー・フィードバックや将来の必要性を見越したものではなく、予定通りに完成できるかどうかのみを念頭にふくらまされたようなものでしかありません。高次における方向付けは存在しないので、「スレッドに関する問題はどうするの?」とか「フラッシュに親和性あるファイルシステムは入れるの?」と聞いても、得られる答えはせいぜい「両方ともなんとかできたらいいねえ」です。しかし、そういったコーディングをしてくれる人々を募集する努力を払うということも、また既存の開発者がそういった作業をするよう促すということもありません。

この真空状態は、現在のプロジェクトの停滞に実質的に貢献しています。事実、NetBSDは非常に重要なプロジェクトにおいて、言語道断なくらいに遅れをとっています。スレッディングは複数CPUではちゃんと動きませんし、一つしかCPUがなくともいくぶんバギーです。フラッシュ向けのファイルシステムは存在しません。ジャーナリング付きのファイルシステムもありません(LFSを除いて。しかしLFSはまだいくぶん実験的なものです)。たとえサスペンドのサポートに関して最近作業が行われたといっても、大半が依然壊れています。電力管理は非常に原始的なものです。などなど。新しいハードウェア・サポートがNetBSDに起源を持つということも、もはや無くなりました。多くはFreeBSDやOpenBSDで開発されたもので、それが後でNetBSDに持ち込まれるというわけです(私が思うに、重要性のある最近唯一の例外はBluetoothのサポートくらいです)。

上記や他の理由から、プロジェクトはほとんど何の意味もないというところまで地歩を失っています(一部の人々は、そんな程度はとっくに通り越していると言うかもしれませんが、私は寛大であろうとしています)。これは不幸なことです。特にNetBSDの利用が、とりわけ組み込みの分野においては、先に述べたクーデタより前の2000年から2001年にかけて良好な割合で増えていたことを思えば。

ここに至って、おそらく読者の多くは、私が単にNetBSDプロジェクトへの弔辞を書いているだけなのではないかとお思いでしょう。ある意味で、その通りです。現在のままのプロジェクトには、何の将来もありません。今よりもさらに時代遅れとなり、今よりもさらに意味を失っていくだけでしょう。開始したときにはあんなにも輝かしい未来があったプロジェクトにしては、悲しい結末と言わなければなりません。

私の今後の見通しは間違っているかもしれません。しかし、NetBSDに貢献してきた人々、今後も貢献し続ける人々の多くは、こんなふうにプロジェクトが衰えていくのは見たくないだろうと思うのです。そこで、事態打開のための唯一の方法だと私が思うことの概略を述べてみることにします。

強力なリーダーシップが必要です。そして、それは現在のようなものではありません。リーダーは、NetBSDが最高かつ最先端の機能を持つ、世界に通用するシステムであることを心から望まなければなりません。リーダーは積極的な目標を設定し、それを実装してくれる人々を活発に募集しなければなりません。
プロジェクトの「ロッキング」があってはなりません。ある人がある問題について作業していることになっているからといって、あなたがそれに取り組んではならないということがあってはならないのです。彼らのアイデアが愚かなものである場合、あるいは単に最善とは言えないというだけであっても、もっと良いものを作ってしまいましょう! もし何の進歩もなければ、飛び越えてしまえば良いのです。他の人を待つことはありません。
プロジェクトは、私が呼ぶところの「分量主義」(volumetocracy)ではなく、「本当の」実力主義にならなければなりません。現在最も強い影響力を行使している人々は、多くの場合最も使い物にならない製品を生み出した人々です。実際、彼らはしばしば綿ぼこりよりもどうでもいいことをするだけで(行の終わりの空白を変えるとか!)、おまけに動いているものまでおかしくすることがしばしばです。
上の続きですが、人々が動いているものを壊すのを止めさせるため、そういった行為にはネガティヴなフィードバックがあるべきです。これは10年以上に渡り、「開発者」たちの一部がしょっちゅうしでかしてきた問題でした。
NetBSDのアーキテクチャには、全くもって壊れているとしか言いようがない多くの側面があります。真剣な復興作業が必要です。繰り返しますが、こうしたことをやってくれる人を募集するのにリーダーシップが必要なのです。そういった側面には、以下のようなものが含まれます。
- 先ほども言及したように、スレッディング・アーキテクチャにおける深刻な問題 (ユーザ/カーネル間のインターフェースを含む)
- いかんともしがたいカーネル・モジュール・サポート
- 32/64ビットの互換性における恐るべき混乱。結果として、32ビットのアプリケーションは、しばしば64ビットカーネルではそのまま動きません。
- 「quirk」テーブルやチップ特有テーブルの濫用によって引き起こされる、尽きることのない保守作業。SCSIやATAPI、IDE、ACPI、SpeedStepのサポートに多く存在します。(実際のところ、SCSIに関して保守作業の多くをやったのは私ですが、現在はコミットすることが出来ていません)。
既存のNetBSD Foundationは解体されなければなりません。そして、その本来の目的を果たす組織、すなわち、日々の出来事まで管理しようとはせず、管理上の問題だけを処理する組織によって置き換えられるべきです。ほとんど何もしていない特別委員会は解体されるべきです–そういった委員会は、物事を分かりにくくするためだけしか機能していません。その他のすべては、技術的な利点のみに基づいた管理をされるために、歴史的に分離した主体、NetBSD Projectに戻されなければなりません。Foundationに参加すること自体に魅力があるべきではありません。Foundationは、Projectに対して献身的で、Projectを助けたいから参加しようと思う人々によってのみ構成されるべきです。

(ここで注意しておきたいのは、クーデタを被った苦い思い出があるのでFoundationを廃したいとかそういうことではないということです。NetBSD ProjectをFoundationと合体していない組織のままにしておくことは、実際にProjectを守るのに役立ちます。)
「コア」グループは、プロポーザルをレビューし、フィードバックを受け入れ、良い決定を下すだけの能力が実際にある献身的な人々によって置き換えられるべきです。もう少し言うと、重要なのは「コア」グループは必要とされるときのみ行動すべきだということです。技術的な判断のほとんどはコミュニティに任され、とことん話し合って決められるべきなのです。コミュニティがより良い解決を案出する前に、コアグループが先に行動して阻止するようなことがあってはなりません(そもそも、プロジェクトの成長期の大半においては、「コア」グループはこんなふうに運営されていたのです)。
コミットに関する一連の標準が必要です。たとえば、機能を変えない変更点をコミットするにあたり、いつなら受け入れられ。いつだと受け入れられないのか。あるいは、複数の変更点は一つのコミットにまとめられるべきなのか、などなど。現在のところ、良いコミットと悪いコミットを見分けるのは困難です。加えて、レビューにも標準が必要です。

今まで指摘してきた点を繰り返しておきましょう。現在のプロジェクトの「運営者」は、プロジェクトの問題を直すことはありませんし、プロジェクトが抱える問題を解決に導くこともありません。彼らは現状を維持するだけであり、他に何かをするつもりはないのです。プロジェクトが焼けこげた切り株から再び芽を出すためには、こうした「運営者」は解体され、ことごとく置換されなければなりません。それ以下の手段は解決策たりえないのです。

一部の皆さんには、私は謝りたいと思います。今になってさえ、良い仕事をしているNetBSD開発者は存在します。カーネル・ロッキングやUVMの問題、無線のサポート(私がやったrtwの広汎なバグフィックスがどうなったかはよく知りませんが)、Bluetooth、G5、改良されたARMサポートなどで作業している人々は特に評価し、感謝したいと思います。これらは皆良いものばかりです。しかし状況全体を眺めると、プロジェクトははるかに多くの作業を必要としているのです。

— チャールズ・ハンナム (Charles Hannum)はNetBSD ProjectおよびNetBSD Foundationの創始者、開発者であり、議長やディレクターを歴任しました。彼はNetBSD Missionを単独で運営しており、NetBSD CD Projectの運営者でもあります。