Develop and Download Open Source Software

OpenSource Downloads

7-Zip  (4,014)  
HandBrake Japanese Language Version  (2,964)  
CrystalDiskInfo  (1,714)  
Boookends  (1,269)  
CrystalDiskMark  (874)  
Tera Term  (825)  
CotEditor  (626)  
FFFTP  (593)  
えこでこツール  (532)  
10  ffdshow  (524)  
11  SMPlayer  (503)  
12  Cabos  (492)  
13  ギコナビ  (475)  
14  Rappelz Server  (471)  
15  MergeDoc  (457)  
More >>

最近ブックマークされた記事

Torvalds氏はどのように批判に対処しているのか

2007年09月05日 10:23 Joe-Barr(2007年9月1日(土))
 読者の中にはカーネルハッカーを目指している人もいるだろう。その目標に向かって行動を起こす、つまり何らかのフリーソフトウェアまたはオープンソースの開発プロジェクトに参加する前に、それが多くの場合、(コーディングのスキルとは無関係に)批判や拒絶への耐性を絶えず試される険しく混沌とした道であることを知っておく必要がある。かのLinus Torvalds氏でさえ、そうした批判を免れることはできない。

 ほとんどのFOSS開発者は、自己満足のために、あるいは、ほかの人々の役に立つことで得られる心の温もりを求めてコードを書く。もちろん、額に汗して生み出した成果によってしばしば大企業から報酬を受け取っている、特別に選ばれた人々もいる。だが、一般の開発者にとっては(ここには、業界でも卓越した才能を持つ一部のプログラマも含まれる)、何の報酬も期待できないが存分に没頭できる作業、それがコーディングである。

 FOSSの開発は、最も優れたコードだけがプロジェクトに採用される能力主義の世界だとよく言われる。これはユーザにとっては悪い話ではないが、開発者にとってみれば自尊心を傷つけられ、プロジェクトを離れることにもなりかねない厳しい考え方である。開発者から出てくるコードはどんなものでも、同僚(ライバル開発者)やプロジェクト上層部からの激しい批判にさらされる可能性がある。そうした環境で生き残っていくには、かなりの図太さが要求される。

 Linuxカーネルの開発はFOSS活動としては最も著名なプロジェクトであり、そこから得られる見返りは(金銭的にも心理的にも)ほかのどんなプロジェクトよりも大きい。それほどの成功がかかっているとはいえ、Torvalds氏に(コードの採用を)拒否されたり、提出したコードが(Torvalds氏のもとに届く前にコードを淘汰する)メンテナの1人によって却下されたりすると、相当な精神的痛手を被るおそれがある。それは、FOSSコミュニティにおいて確固たる信用を得ている開発者でも同じである。

 輝かしい実績を持つ開発者の成果が不採用になった最も顕著な例が、Eric S. Raymond氏によるカーネル設定ツールCML2と、Con Kolivas氏によるカーネルのStaircase Deadline(SD)スケジューラ(彼は、このスケジューラにより、デスクトップ環境における応答性が改善されると主張していた)の2つである。しかし、Kolivas氏のスケジューラコードの採用拒否に対しては相当な反発が生じたため、Torvalds氏はその判断を擁護するという通常では考えられない対処を行うことになった。

最高意志決定者としてのTorvalds氏

 Linuxカーネルプロジェクトの創設者、そしてリーダーとして、Torvalds氏はメインカーネルツリーに何を含めて何を含めないかを決める最高意志決定者の役割を担っている。つまり、何度も「No」と言わなければならない立場にあるわけだが、Torvalds氏自身はどのように批判に対処しているのだろうか。そのあまりの重圧に耐えかねて、引退して公の場から姿を消そうと考えたことはないのだろうか。

 Torvalds氏は次のように語っている。

私の場合、そういうことはないね。その理由の一部は、本当に議論が好きなことにある(ときには行き過ぎもあるが)。だから、たまに激しい言葉の応酬になってもまったくどうということはないし、かえって元気になるくらいだ。

その一方で、ただ「なるに任せる」ということには実に長けていて、うんざりするくらい十分に議論した問題はそのままほったらかしにすることができる。それでも平気なのは、自分の間違いをすっかり認めなければならないことがあっても、とにかくその旨を伝える「謝罪」メールを送れるだけの度量があるからだろう。

それに私の場合、何事も細かいことに(たとえ議論の最中では細かい部分で強硬な姿勢をとることがあっても)こだわり過ぎるということがない。一部のサブシステムがほかのものよりも気に懸かるのは確かだが、最終的に私が技術的な選択肢の多くについて深く執着することはめったにない。どちらかといえば、特定のサブシステムの詳細よりも開発モデル全体の改善に気を配っている。

だからこそ、私は「なるに任せる」方向に振れやすいのだろう。言うべきことはきっちりと言うが、たとえ自分が正しいと確信していても、自分であまりコードを書きたくなければ、結局、そのコードを書いてくれる人々に喜んで意見を譲るようにしている。

こうしたことは、言うまでもなく性格の問題だろう。

もちろん、心配ごともあればとても苦い思いをすることもあるが、そういったケースは非常に珍しい。その代表的な例が、かつて「Linusのスケーラビリティ問題(Linux does't scale)」と呼ばれていた論争だ。この件では結局、私の使用していたツールや私のやり方を根本的に変えざるを得なくなった。あのときは実際のコードについて心配するよりもずっと大きな苦しみを味わったよ。

結び

 Linuxカーネルやその他のプロジェクトで自分のコードが却下されたからといって、それが無条件に悪いことだとは言い切れない。たとえばDaniel Robbins氏は、ほかの開発者との意見の不一致からあるプロジェクトを去り、Gentoo Linuxプロジェクトを創設した。そして、GentooはソースベースのLinuxディストリビューションとして一流になったが、一方のRobbins氏が去ったプロジェクトはというと、私はその名前さえ忘れてしまっているくらいだ。

 しかし、もっと重要な教訓は、FOSS開発の世界に身を投じて批判を受けるようになれば、ときにはひどく辛いこともある、ということだ。単にプログラマとして優秀なだけでは、FOSS開発者に「ふさわしい人材」にはなれない。自分が間違っていたときには自らの非を認め、思うように意思決定できないときには「なるに任せる」ことのできる力量が必要だ。そうした力量を持ち合わせているなら、FOSS開発を楽しみ、実りある経験を得ることができるだろう。でなければ、それなりの苦労を覚悟しなければならない。

Linux.com 原文

最終更新:2007年11月05日 17:07