「ほとんどのディストリビュータが開発に何も協力してくれない」。GNU C Library（glibc）の中心開発者Ulrich Drepper氏はこう不満を漏らす。glibcは，多くのLinuxディストリビューションが採用する標準Cライブラリである。標準Cライブラリとは，C/C++言語で利用する標準関数やデータ構造，マクロなどを定義し格納する重要なシステム・コンポーネントである。Linuxカーネルをはじめとして，さまざまなソフトウエアがこれを利用している。
2002年10月3日には大幅な機能強化を果たした最新版バージョン2.3がリリースされた。このglibc-2.3は，9月30日に公開された「Red Hat Linux 8.0」にも先行収録されている。冒頭に挙げた発言は，このRed Hat Linuxが収録したglibcについて，Drepper氏が開発メーリング・リストにポストしたメールの一部である。
公開日から分かるように，Red Hat Linux 8.0が採用したのはglibc-2.3の正式公開版ではない。glibc-2.3の開発ベータ版（バージョン2.2.93）に，同社で修正を加えたものが使われている。同社が正式公開版ではなく，ベータ版を採用したことには批判もあった。ベータ版は安定性に欠ける恐れがある上，正式版との互換性が失われる場合もあるためだ。glibcに問題がある場合，それはシステム全体に極めて深刻な影響を及ぼす恐れがある。
実際，米Red Hat社には「前科」がある。Red Hat Linux 7.0の標準コンパイラに「GCC（GNU Compiler Collection）」の開発版を収録して，GCC開発者らから批判を浴びたことがあるのである。今回のglibc-2.3のベータ版収録についても，同じ轍を踏んだと見る向きが多かった。
開発コミュニティの中心人物を社員として雇用する
しかしDrepper氏は，glibc-2.3の場合はGCCと全く事情が異なるとする。先に挙げたメールでは，「最終ベータ版をRed Hat Linuxに採用するよう提案したのは自分だ。これは，glibcの正式版をリリースするため必要なテストや不具合修正を同社の組織や人材を使って行うためである。同社の積極的な協力が得られたおかげで，glibc-2.3の公開は6～9カ月は早まった」と全面的にRed Hat社を擁護している。その上で，開発に協力しない他のディストリビュータに不満を表明したのである。
実際に他のディストリビュータが開発に貢献していないかどうかは，ここでは問題にしない。しかしこの件に限らず，米Red Hat社は開発コミュニティとの付き合い方がうまいと感じることが多い。GCCの件のようなミスもたまにはあるとはいえ，慨して開発コミュニティからの成果物を迅速に製品に取り込むことに成功している。
しかしそれもそのはずである。同社は，Linuxカーネル開発プロジェクトなど，多くの開発コミュニティの中心人物を社員として雇用しているのである。Drepper氏も同社の一員だ。
開発者にとっても，このような雇用形態にはメリットがある。業務として開発作業に従事できるため，自分が開発するソフトウエアを責任をもって継続的にメンテナンスできるようになるのである。代表的なメール・サーバー・ソフトウエア「sendmail」の開発者であるEric Allman氏が，米Sendmail社を設立した目的の1つも「継続的なメンテナンス」を行うためであった。
日本企業によるオープンソースへの貢献も目立ってきた
日本国内ではこのような雇用スタイルは定着しているとは言いがたい。しかし，それは開発者がいないからというわけでも，開発力が劣っているからというわけでもない。その証拠に，比較的自由な活動が認められている大手ハードウエア・メーカーの研究所からのオープンソース開発プロジェクトへの貢献が，次第に目立つようになってきている。
例えば，glibc-2.3の改良点である「国際化された正規表現ライブラリの実装」，「ISO-2022-JP-3のような新しい日本語文字セットに対応した文字コード変換機構の実装」の作業は，日本IBM基礎研究所により行われている。また，富士通研究所では，Linuxカーネルのプロセス・スケジューラがキャッシュ・ミスを起こしやすい非効率な実装になっていることを突き止め，その改良についての報告をカーネル開発者に送っている（詳細情報）。
また，中堅企業も負けてはいない。VA Linux Systemsジャパンでは，より効率の良いNFS（Network Filesystem）処理を行えるようカーネルを改良しているし，組み込み関連企業でもプロセス・スケジューラの改良などさまざまな開発を行っている。ユーザー・プロジェクトにも，IPv6スタックの改良作業を進める「USAGI Project」のように，成果物がカーネルに次々と統合されているものがある。
コミュニティ参加にはノウハウも必要
現在，Linuxなどのオープンソース・プロダクトの社会的な重要性が広く認識されつつある。「オープンソース開発プロジェクトに貢献している」というイメージを確立したいと願う企業や組織は多いのではないだろうか。
Linuxカーネルに限ってみても，まだまだ改良の余地はあるし，後発の開発者が簡単にイニシアティブを取れそうな領域も多い（例えば，通信帯域制御機能などは開発があまり進んでいない）。自社の開発力をアピールすることによるビジネス波及効果が考えられるならば，開発プロジェクトへの参加を積極的に検討してみてはどうか。
ただし，開発コミュニティと上手に付き合うには多少のノウハウがある。例えば，「いきなり巨大な差分（パッチ）ファイルを送り付けても無視されたり適用を拒否されることが多い。何らかの改良を施す場合は，提案段階からコミュニティの人間と相談するようにするとスムーズに行く」（VA Linux Systemsジャパン技術部の高橋 浩和氏）という。これまでプロジェクトを支えて来た開発者らの顔をできるだけ立てるような配慮が必要だ。
また，開発コミュニティを構成するのも同じ人間である。最終的には「顔を突き合わせてのコミュニケーションも重要」（USAGI Projectの関谷 勇司氏）だ。USAGI Projectでは実際に海外まで何度も足を運び，開発コミュニティの人間と議論をすることで，改良作業がスムーズに運ぶようになったという。
（末安 泰三=日経Linux）
