オープンソースが「開発系」で強い理由

開発者とOSSの良好な関係を生むエコ・システム

（2007年04月19日）

関連するOSSの集合で
「バザール」が成り立つ

　以上から、OSS開発者は大量の開発系ソフトウェアを開発しているということがわかる。これらの中には、自分のために開発し、開発した以上は公開するというプライベート・プロジェクトに近いものから、自分の考えた開発手法の正当性を実証し広報するためのプロジェクト（その例としては、アジャイル開発に対する「JUnit」が挙げられる）までがある。

　こうして公開されたプロジェクトの成果物が広く利用されるようになると、複数の関連プロジェクトが生まれることになる。いわば、OSS開発のポジティブ・スパイラルが発生するわけだ（図5）。例えば、SourceForge.netでJUnitを検索すると200を超えるプロジェクトが見つかる。これらの中には、ビルド・ツールの「ANT」にJUnitを組み込むための「ANT Junit Task extension with javadocs」や、JUnit用ヘルパ・クラス・ライブラリの「JUnit-addons」のように、あるソフトウェアを他のソフトウェアに組み込むためのもの、あるいは、特定のソフトウェアの機能を補うためのアドオンといった付加的なものなどがある。

図5：OSSのポジティブ・スパイラル

　エリック・レイモンド氏は、『伽藍とバザール』という論文の中で、1つのソフトウェアに不特定多数の開発者がコミットしていく開発モデルを“バザール・モデル”と呼び、その開発モデルが奏功してLinuxの開発が成功したと説明している（注2）。しかし実際には、JUnitの例のように、元のプロジェクトに触発された開発者が新たなプロジェクトを開始することで、元のプロジェクトを中心に多数の関連プロジェクトが集まり、バザールが形成されると考えられる（ただし、『伽藍とバザール』では、単一のソフトウェア開発に開発者が収斂すると限定しているわけではない）。

　前述のRAAの場合も、全体で1,500ほどになるプロジェクト群を、Rubyの周辺に形成されたバザールと見なしても間違いではあるまい。なぜなら、Rubyが存在しなければ、これらのOSS群が生まれることはなかったからだ。

注2：Linuxそのものはカーネルなので、実際にシステムとして動かすためには関連する多数のソフトウェアが必要となる。そのため、実際にはここで述べているような関連プロジェクトの多数の集合であると見るべきかもしれない

「だれからも利用されないOSS群」の意義

　このような観点に立てば、他のOSSから完全に独立したプロジェクトは、それほど多くないということになる。したがって、OSSを否定的に評価する場合に引き合いに出される「だれからも利用されないOSS群」についても、その存在意義を見直すべきではないか。これらは実際には、無駄なものではない。なぜならば、だれからも利用されないOSSは、中心となるOSSのバザールを広げるという役割を持つからだ。関連プロジェクトの数には、中心となるOSSに対する人気投票や信任投票的な意味合いがあると考えられるのだ。

　関連プロジェクトが増えれば、中心にあるOSSに関する知識を持つ開発者が増えることになる。そうした開発者は、中心にあるOSSの新規ユーザーに対して信頼できるサポートを提供することになるだろう。また、関連プロジェクトが多いということは、アドオンの開発が容易、あるいは参考となるソースコードが存在する可能性が高いといったように、開発者にとってよい条件がそろっているということでもある。そのため、新たな関連プロジェクトを立ち上げようと考えるOSS開発者を呼び寄せることにもなる。

　さらに、関連プロジェクトは、中心的なOSSの新規ユーザーの獲得にも貢献することになる。例えば、前出のANT Junit Taskを知った開発者が、ANTによるビルドで自動実行できるのならJUnitを利用しようと考え、新たにJUnitユーザーになるといったようなことは十分に起こりうることだ。

技術者の育成にも貢献する
OSSのエコ・システム

　これらの相乗効果により、開発系OSSは開発者を取り込みながらそのコードベースを大きく膨らませていくことになる。したがって、開発系OSSの数が多いのは当然とも言え、また、それらのOSSが開発者に対して一種の修行の場を提供することで、OSS開発のエコ・システムが成立するわけである（図6）。ライセンスの点から付け加えると、GNU GPL（GNU General Public License）の“伝播性”という特徴は、ソフトウェアがソフトウェアを産み出すという構造を機能させるうえで大きな役割を果たしている。

図6：OSS開発のエコ・システム

　ここで、再びFLOSS-JPの調査から、今度はOSS開発者の職種についての調査結果を示す（図7）。この結果からは、ソフトウェア技術者とプログラマーで、OSS開発者の半数以上を占めていることがわかる。「その他」の中には、情報系コンサルタント／管理職／役員／営業といった、微妙な位置づけの人たちが含まれているため、実際にはソフトウェア技術者の割合がもっと多いと考えることもできる。例えば、OSS開発者の年齢（図8）を見ると、その年齢層は50代にまで及んでいる。ここからは、かつてはソフトウェア技術者で、現在は管理職や役員あるいはコンサルタントとなった開発者が、昔取った杵柄で本業の合間にOSSを開発しているという姿が浮かび上がる。

図7：OSS開発者の職種　＊資料：オープンソース／フリーソフトウェア開発者オンライン調査日本版 FLOSS-JP （三菱総合研究所）

図8：OSS開発者の年齢　＊資料：オープンソース／フリーソフトウェア開発者オンライン調査日本版 FLOSS-JP （三菱総合研究所）

　「開発者は年齢を重ねても開発者であり続けられる」という事実は、一般的に言われているSE35歳定年説やプログラマー30歳定年説が、少なくとも技術面では正しくないことを示している。もちろん、企業の人材育成プランとして、SEやプログラマーをある程度の年齢から管理者あるいはコンサルタントとして養成することを、XX歳定年説という言葉で表すという側面はあるだろうが。

　図8でもう1つ興味深い点と思われるのは、ピークが20代半ばと30代前半の2カ所にある点だ。20代半ばとは職業人となって（その多くがなんらかのソフトウェア技術者であることは図7から判断できる）、技術的な学習が急務となった時点だと考えることができる。また、30代前半とは、単にプログラムを開発する技術者からプロジェクト・マネジャーやソフトウェア・アーキテクトなどにキャリアアップする時期だと考えることができる。

　プロジェクト・マネジメントやシステム・アーキテクチャ策定のためには、システムに対する全体的な視点や考察が要求される。それと同時に、開発に利用するソフトウェア・インフラについての技術的知識や価値判断も求められることになる。これらの点から、このピークは開発者が実際の業務において次のステップへ進むための助走期間と見なせるのではないだろうか。この見方が正しければ、OSSのエコ・システムは、技術者のキャリアアップにおける助走路の役割も果たしていると言えよう。

COLUMN
開発者と年齢

　筆者が開発者の年齢について考えるとき、どうしても脳裏から離れないのは、Macintoshの最初の開発に携わったアンディ・ハーツフェルド氏が、米国PBSのテレビ番組『NerdTV』のインタビューに答えて語った以下のくだりだ。なお、BobはNerdTVのインタビュアーのロバート X. クリンジリー氏、Andyがハーツフェルド氏である。

Bob：今から10年後のあなたは何をしていると思う？
Andy：うわあ。もう60過ぎだよ、今51歳だからね。
Bob：僕もだ。僕らカッコイイと思わないか？
Andy：1953年生まれか。うん、2人ともいい格好だと思うよ。どうだろ、わからないけど、向こう10年で小説でも書いているかもね。それとは別に、面白いソフトウェア・プロジェクトをやりたいと考えてる。どっちも同じくらい面白そうだ。

＊資料：NerdTV翻訳／1-Andy Hertzfeld（hir氏による翻訳）
（http://www.isla-plata.org/wiki/pukiwiki.php?NerdTV%CB%DD%CC%F5%2F1-Andy%20Hertzfeld）

　これに続けて、ハーツフェルド氏は、30歳のときには、40歳になってもまだプログラムを書けるだろうかと自問したものだが、そういった心配にもかかわらず、自分は今でも有能なプログラマーなのだと答えている。このインタビューで語られている、コンピュータの進化そのものが、経験によって得た知見と共に老化による頭脳の衰えを補うことができ、それによりさらに上に行けるという、自負心にあふれたハーツフェルド氏の言葉には重みがある。

　本文の図8で30代半ば以降においても、それほど途切れることなくOSS開発者が見られるということは、定年制や人事的な異動がついて回る企業内開発者というポジションとは別に、OSSの開発であれば年齢や役職に関係なくいつまでも続けることができるということを示唆している。言い方を変えると、OSS開発者は、わざわざ余暇にOSSの開発をするほど、ソフトウェア開発が好きな人間であるのだ。OSSは、彼らのソフトウェア開発に対するモチベーションの発揮／吸収の場としての役割も担っていると言えよう。

前のページへ < ｜1｜2｜3｜ > 次のページへ

▲ページの先頭へ戻る