0057 号 巻頭言
改めてオープンソース開発について考える
Rubyはこの 2 月で誕生してから 25 周年にあたり、それを記念して Ruby 25 というイベントが開催される予定である。 日本 Ruby の会は Ruby アソシエーションとともにこのイベントの後援として名前を連ねている。
また、今年は「オープンソース」という言葉ができてちょうど 20 年だそうで、その命名者である Christine Peterson が、「オープンソース」という言葉が生まれた時のことを初めて（！）語る記事が公開された。
Ruby の 25 周年に対してオープンソースの 20 周年というのは、むしろ Ruby の開発の長さを感じさせるが、この 20 年の間にオープンソースの評価が定着したことは感慨深い。
一方で、最近はオープンソースの意味、意義といったことについては、今さら感もあるせいか取り立てて論じられることが少なくなってきたように感じられる。 論じるまでもなく重要だと思われていることは良いことかもしれないが、むしろ新参者には不親切になっているところもあるのかもしれない。 また年月を経て、オープンソースの開発の位置付けも変わってきたところがある。 以前のオープンソース開発者というのはある種の開拓者・改革者であったかもしれないが、企業が自社のプロダクトとしてオープンソースソフトウェアをリリースしたり、他人・他社がリードするオープンソース・ソフトウェアに業務として関わることもめずらしくない昨今では、オープンソース開発者というだけでは当たり前のことをしている者としか思われないかもしれない。
そんなこともあり、本稿では改めて「オープンソースとは」「オープンソースの意義」といった基本中の基本について、今の観点から説明してみたい。
オープンソースとは
「オープンソースソフトウェアとは何か」と問われた時には、「ライセンスがオープンソースライセンスになっているソフトウェア」と答えればまずは及第点がもらえるだろう。
例えばあるソフトウェアのバイナリやソースコードを見て、それがオープンソースか否かを答えることは原理的にできない。 オープンソースソフトウェアというのはソフトウェア自体が内在しているものではなく、ソフトウェアのライセンスによって規定されるものだからだ。 オープンソースソフトウェア普及活動の中心であった OSI(Open Source Initiative) が管理しているオープンソースの定義 (OSD、The Open Source Definition) を見ても、ほぼ全項目に「ライセンス」という言葉が含まれている。 言い換えると、「オープンソースの定義」とは、「オープンソースソフトウェアのライセンスの定義」と言ってよいだろう。
オープンソースソフトウェアの開発に参加する、というのは、ソフトウェアのライセンスとしてオープンソースライセンスが適用されたソフトウェアの開発に参加することである。このような理解は間違ってはいない。しかし、これだけでは話は終わらない。
オープンソースと開発体制
オープンソースについて語る際に避けて通れない文献がある。エリック・レイモンド「伽藍とバザール (The Cathedral and the Bazaar)」である。
http://cruel.org/freeware/cathedral.html
「伽藍とバザール」自体はオープンソースという言葉が生まれる前に書かれたものなので、バザール方式がオープンソースの開発手法で伽藍方式が非オープンソースの開発手法だということはない。 しかし、エリック・レイモンドがオープンソースの普及に大きな役割を果たしたこともあり、結果的にオープンソース開発にバザール方式が多く採用され、「オープンソース開発≒バザール方式」という（いろんな意味で正しくない）考えが広まってしまったのは否めない。
とはいえ、ある種のオープンソース開発には、バザール方式はとても有用であったことは間違いない。そもそも、「伽藍とバザール」の主張は「フリーソフトウェア開発においては、意外にも伽藍方式よりもバザール方式の方が優れている」という主張なので、オープンソース開発でも同様のことが言えることは間違いない。
また、バザール方式は、外部に広く開発者がいることを前提としているため、クローズドなソフトウェア開発には適用しにくいというか、困難である。 そのようなこともあり、20 年前ならさておき、オープンソース開発では概ねバザール方式が導入されている。
そのため、決してイコールでは結ばれないにしても、「オープンソース開発と言えばバザール方式」という考えが広まったことは意外でもない。
オープンソースとツール
もう一つ無視できないものとしては、バザール方式を支えるツールやサービスがある。
ソフトウェア開発の場においては、Git や GitHub はもちろん、Jenkins や Travis CI や Circle CI といった継続的インテグレーション・継続的デリバリーを支援するツールやサービス、Vagrant や Docker などの仮想化ツールなど、さまざまなツールとサービスが開発され、使われてきた。 これらはオープンソース開発の現場でなければ使えないものではないが、この 20 年の間にオープンソース開発の現代化にとって、非常に大きな役割を果たしてきた。
もちろん、ツール自体がオープンソースだったり、またツールやサービスそのものはオープンソースではなくても、それらの中でさまざまなオープンソースソフトウェアが使われているという事情もある。 しかし、それ以上に大切なことは、自身がオープンソースかどうかに加えて、オープンソース開発と開発支援サービス・ツールが合わせて進化してきたことだ。 そもそもバザール方式が提唱された背景には、開発したソースコードの配布とフィードバックのやりとりにインターネットを使って高速化を図れるようになりつつあったことが挙げられると思われる (「伽藍とバザール」でエリック・レイモンドがバザール方式を試してみるきっかけとなったのがfetchmailというメールのためのツールであったことも示唆的である)。
ソフトウェア開発に使えるツール・サービスが増えるということは、ソフトウェア開発手法そのものを変えることがある。これはオープンソース開発にももちろん当てはまる。
オープンソースと文化
このようなバザール方式を上手く進めるには、単なる開発の作法・ルールやツールを導入しただけでは足りない。 G. W. ワインバーグの言うコンサルタントの第2の法則、「一見どう見えようとも、それはつねに人の問題である」の通り、「人」の問題を何とかしなければならない。
この問題に対処するための振る舞いや経験則とその結果などをまとめたものは、このような文脈では「文化」と呼ばれる。 その意味では、うまく回っているオープンソース開発のチームやコミュニティには、よい文化が備わっていることが多い。
とはいえ文化の問題は、作ろうと思って作れるものではないということにある。あくまで結果としてできてしまうものでしかない。 また、できあがった文化というのは、開発チームや開発コミュニティによって異なる。文化の中身も、文化のできるプロセスも、文化のできる速度も、似ている場合もあれば似ていないこともある。他のコミュニティの文化をそのまま持ってきて導入するということはできない。
それでも、文化を作っていく経験というのは何物にも代えがたく、またその経験は他の場所でも役に立つこともあるだろう。そのような知見を集め、育てる場としても、オープンソース開発は大きな役割を担っている。
まとめ
オープンソースソフトウェアとは、原則としてオープンソースライセンスのソフトウェアのことである。 しかしながら、現代的なオープンソースソフトウェア開発は、バザール方式やそのためのツールやツール、そしてそれを支える文化といったものと密接に関わっており、そしてそれらはオープンソース以外の現代的なソフトウェア開発にも大きく影響を与えている。 この 20 年に渡ってオープンソースが果たしてきた役割とは、オープンソース開発そのものはもちろん、今日のソフトウェア開発一般をより良いものとする、その一端を担ってきたことにあるのではないか。
Ruby やそれ以外のプログラミング言語を使ってオープンソースを利用したり開発したりすることで、その運動にリアルタイムで関われたことはとてもよい経験であり、大変幸せなタイミングだったと思っている。そして、これからもオープンソースがソフトウェア開発を、さらにソフトウェア開発を通して世界の様々なことをより良いものとしていけることを祈りたい。