Linuxカーネルはコミュニティで開発されている代表的なオープンソース・ソフトウエアであり，コミュニティにより開発が進められている。筆者が勤務する日立製作所も，基幹系システムに適用可能な高信頼Linuxシステムを顧客に提供するためLinuxの開発に参加しており，Linuxに不足している機能を開発したり，問題点を改善したりしている。

　Linuxカーネル・コミュニティにおいては，世界中の開発者から毎日，数百通のパッチやレビューのメールがメーリングリストに投稿される。そのような状況下で，自分が開発したパッチを埋もれさせることなく，コミュニティ開発のカーネル，すなわちメインライン・カーネルに採用してもらうにはどうすればよいのだろうか。

　筆者は「カーネル開発者の関心を惹きつけることが最初の一手」であると考える。では，開発者達の関心を集めるにはどうすればよいのか？ 筆者の経験を交えて紹介する。

早い段階からコミュニティで議論しよう

　もし，あなたが実績ある著名なカーネル開発者やメンテナであれば，パッチを投稿するだけで関心を集め，すぐに議論され，あっと言う間にサブシステム・ツリーに採用されるかもしれない。しかし最初は誰もが無名であり，実績もない。この場合，スムーズにパッチを採用してもらうにはどうすればよいのか。

　我々の出した答えはこうだ。「早い段階で，F2F(Face To Face)で議論しよう」

　これはJonathan Corbet氏（関連記事）が「Linuxカーネル開発への参加方法」の第3章（和訳）で述べている内容にも一致する。コミュニティで適切なメンテナや主開発者を見つけ，問題の内容や自分のアイデアを早い段階から議論することは，開発効率を向上でき，有用である。特に自身がコミュニティでまだ無名の開発者である場合には，F2Fの議論は効果的だ。

F2F議論のメリット

　F2Fでの議論にはいくつかのメリットがある。まず，自分を認識してもらえること，そしてパッチが解決しようとする問題の背景・内容を容易に説明できることである。これらはその後のメーリングリスト投稿・議論に，大きな影響を与える。

　筆者もそうであるが，F2Fで話したことにある相手の投稿は，興味を持つことが多い。さらに既に理解している問題に関する内容であれば，その説明やパッチにも高い関心を持ち，その後の議論も，問題を解決する方向で有用な意見を出してくれる。

　例えば筆者のチームでは，UDPレイヤで使用するソケットバッファの合計使用量に制限をかけるパッチを投稿したことがある（投稿したパッチ）。他のOSのシステムで，TCPレイヤが使用するソケットバッファによってメモリが食い潰される障害事例がありLinuxでも同様の障害が発生し得るか事前検討したところ，UDPの場合のみ，問題があることに気付いた。そこでパッチを作成して投稿した。

　この時は筆者らの背景説明が不十分であったため，オーバーヘッド削減という実装上の議論に終始してしまい，肝心の問題解決に向けての議論に進まなかった。

　しかし，ネットワーク分野で活躍するDavid Miller氏（関連記事）やHerbert Xu氏といったカーネル開発者達とF2Fで話す機会があり，そこでパッチが解決したい問題を説明したところ，すぐに理解してもらうことができた。

　実は，過度のUDPパケットを受信することでソケットバッファが増加し，メモリーを圧迫する問題が存在していたため，バッファ使用量に制限をかける機能が欲しかったのである。その後は，メーリングリストでも問題解決に向けた議論が展開でき，最終的にF2Fでアドバイスしてもらった実装方法でメインライン・カーネルに取り込まれた。

　また，筆者も，ext3ファイルシステム上の問題*1に取り組んでいた時に，パッチ投稿前にext4ファイルシステムのメンテナであるTheodore Ts'o氏（関連記事）とF2Fで議論し，いろいろアドバイスしてもらった経験がある。後日LKMLにパッチを投稿した際には，彼は議論にも積極的に参加し，筆者の説明を補足したり有用な意見を投稿してくれた。そのおかげもあり，パッチ投稿から4日ほどで解決案が定まった。

　F2Fでの議論にはもう一つメリットがある。LKML(Linux Kernel Mailing List)などのメーリングリスト上での議論は，時差や他の仕事の関係で応答が遅く，議論が進まない時がある。しかしF2Fであれば集中して議論できるため進みが速く，また，表情から賛成・反対を読み取ることもできるのである。

*1 一時的なI/Oエラーにより，ファイルデータやファイルシステム自体が壊れる問題。I/Oエラーハンドリングが正しく行われているか調査している時に発見した。