UCB (University of California at Berkeley）で開発されたUNIX、BSDは、1992年から1994年にかけて、AT&Tが起こしたライセンスに関する訴訟に巻き込まれていた。他方、当時、AT&Tのライセンスに触れないフリー･ソフトウェアとしてUNIX再現版システムを開発していたGNUプロジェクトのジグソー･パズルは、カーネル(kernel)を除いてほぼ出来上がっていた。まさにその「最後のピース」として渇望されていたカーネル、すなわちAT&Tのライセンスから自由で、かつソース・コードが公開されているフリー・ソフトウェアであるUNIX風カーネルとして、Linuxが登場したのである。UNIX型のOSはもともとツールと呼ばれる単機能プログラムの集合体であるために、差し替えがうまくいきやすい。こうした条件の下で、「PCで動くUNIX」のフリー・ソフトウェアが、ごく短期間のうちに完成した｡Linux成功の本質は、奇跡的な投入のタイミングにあった。無償、オープン･ソースという条件を揃えても、この現象には再現性がないのである(Takahashi & Takamatsu, 2013)。
Hatta (2018)は、オープン・ソース・ソフトウェア開発におけるいわゆる「ポリシー」に関する議論がこれまでどのように行われてきたかを、Debianプロジェクトを中心としたいくつかのプロジェクトのポリシー・メーリングリスト・アーカイブを用いて分析したものである。1990年代末から最近までの約7万通のメールを用い、流量の増減やどのようなトピックが語られていたかを検討した。結果として、流量の面では2005年にピークを迎えたこと、比較的少数の、ポリシー関係のみ登場する投稿者が多くのメールを投稿して議論をリードしていること、および2006年頃からそもそもポリシーだけではなくメーリング・リスト全体の流量が減少し、Wikiやchatなどその他に議論の場が移っている可能性があることが示唆された。
オープン・ソース・コミュニティ(OSC)は誰もが利用可能な集合的な知識を構築する場であり、必然的にフリー・ライダーを生み出す可能性がある。にもかかわらず、多くの企業がOSCに貢献している。Shiu and Yasumoto (2016)は、2010年から2013年の期間に、Androidスマートフォン10社について、各社の(a)ソース・コードへの貢献と、(b)最初のAndroidスマートフォンのリリース時期で測定した“time-to-market”の関係を分析した。その結果、10社は次の2群に分かれていた。(A)ソース・コードにより貢献することによって、競合他社より早く製品をリリースしている群と、(B) ソース・コードへの貢献が少なく、(A)群よりはリリースが遅い群である。加えて、わずか数年の間に、(B)群から(A)群へと移行する会社も観察された。
オープン・ソースへのタダ乗りは、深刻な問題になりつつある。Unix哲学に基づいて構築されたオープンソースの世界では、日の当たらない場所にある縁の下の力持ち的なプログラムが、知名度がない一人かごく少数の人間によって、主に個人的な理由で細々と維持されていることがある。しかし、ひとたび、底に近いこの細いプログラムが折れてしまうと、現代社会のインフラストラクチャ全体がバランスを失って崩壊してしまうかもしれない。この問題を八田(2022)、Hatta (2022)は「ネブラスカ問題(Nebraska problem)」と呼んでいる。そして、実際に発生した深刻なHeartbleed bugの事例から、これまではLinus's Lawで当たり前だと思われていた「目玉の数」を意図的に確保することが必要であり、かつSBOMのような補完策でリスクを事前に検討する必要があることがわかった。
無償のオープン・ソースであることは、ソフトウェア開発成功の必要条件ではない。ソフトウェア開発の成功指標の一つが「早めで頻繁なバージョンアップ」であるならば、ユーザーがテスターやデバッガのように機能することが重要なのであって、自らソース・コードを修正する必要はないからである。実際、有償で非オープン・ソースの日本のシェアウェア「秀丸メール」の開発では、一部のユーザーがテスターやデバッガのように機能している。そして秀丸メールの場合、開発者の早めで頻繁なバージョンアップというのは、実は、結果あるいはパフォーマンス指標なのではなく、ユーザーの内発的動機づけを引き出し、テスターやデバッガとして機能させるための手段だったこともわかった。事実、秀丸メールでは、開発者がユーザーのほぼすべての要望や報告に懇切丁寧に対応し、早く、頻繁にバージョンアップすることで、ユーザーをさらに要望や報告を提出するように動機づけている。従来の議論は、ソース・コードがオープンかどうかにこだわりすぎていて、ユーザーをいかにテスターやデバッガのように機能するように動機づけるかという組織論的な視点に欠けていた。ソースをオープンにすることでユーザーを動機づける可能性は確かにあるが、だからとって、オープン・ソースにすることが必要条件なのではなく、できるだけ多くのユーザーを開発に協力するように動機づけることが必要条件なのである。それができれば、無償か有償か、オープンか非オープンかには関係なく、ソフトウェア開発は成功する(Fujita & Ikuine, 2013)。
融通無碍なソフトウェアでは、その完成形を見極めるのが難しい。何をもってして完成品であるといえるのか不明である。それ故、完璧を期していては、いつまでたってもリリースできないので、とりあえず動くのであればリリースし、あとは、徐々に洗練していくしかない。その結果、ソフトウェアについては、「今後もたえず開発を続けていく」という保証が最良の品質保証であるという暗黙の通念が確立した。そのことをWindows対応の高機能メールソフト「秀丸メール」の事例で見てみることにしよう。IT化が進む現在、ソフトウェアの品質保証の考え方は、より広い製品やサービスにも適用できる可能性がある(Fujita & Ikuine, 2013)。
ソフトウェア開発の成功とは、単に「ある人物」「ある開発チーム」が開発に成功することではなく、開発者のあいだでスムーズに「世代交代」が行なわれて、一つのソフトウェアが長期にわたって次々とバージョンアップされていくことである。その時、世代の異なる開発者たちはソース・コードを共有することになる。そのプロセスを、日本のフリーウェアの「電信八号」を事例として取り上げて分析してみよう。電信八号は、当初、原作者一人によってクローズドソースで開発され、頻繁なバージョンアップを媒介にして、ユーザーを動機づけることに成功していた。やがてバージョンアップが滞りがちになると、それでも電信八号を使い続け、よりよくしたいという熱意を示し続けたユーザー・グループに対して、原作者はソース・コードを公開し、今度はソース・コードを継承したユーザー・グループが開発を継続する。この事例のように、ソフトウェア開発が成功し、開発者の世代交代が一つの会社の中にとどまらずに起きた場合には、「オープン・ソース」と呼ばれる現象が現れる。しかし、その逆は真ではない。つまりオープン・ソースになっても、開発が成功するとは限らない(Fujita & Ikuine, 2014)。
ソフトウェアについては、「今後もたえず開発を続けていく」という保証が最良の品質保証である。開発の継続のためには、原作者が開発を継続するか、あるいは開発者の世代交代が必要になる。世代交代のために、原作者がソース・コードを公開する「オープン・ソース」と呼ばれる手法が採用されると、動機づけられた、開発能力が高い人々が、開発プロジェクトに参加する可能性が高まることはこれまでも指摘されてきた。そのため、プロジェクトの存続は容易になる。だが同時に、ソース・コードを広く公開してしまえば、ソース・コードの分岐の可能性も高めてしまう。ソース・コードが分岐すると、高い能力と高い意欲をもつ人々が分散し、結果として、プロジェクトの存続が難しくなる。電信八号の事例では、ソース・コード公開に際して、ソース・コードの正統な守護者を決めることで、このジレンマを回避していた。オープン・ソースの代表例であるGNUプロジェクトとLinuxでも、それぞれ Richard StallmanとLinus Torvaldsが正統な守護者として分岐(fork)を回避していたと考えられる(Ikuine & Fujita, 2014)。
Hatta (2021)によれば、ハッカーのイメージは、1970年代に端を発し、1980年代から徐々に形成されてきた。特に1990年代から2000年代初頭にかけては、GNU/Linuxなどのオープン・ソースの台頭もあって、さまざまな文脈で活発に議論された。その後、時代の変化もあって、優秀なプログラマーに求められる資質は大きく変わった。従来はコードを書く能力が最も重視され、社会性は軽視されていたが、コンピュータがより一般的になり、社会的影響力を増すにつれ、ハッカーは様々な方法で社会と折り合いをつけなければならなくなり、多くのオープン・ソース・プロジェクトが行動規範を導入した。