オープンソースソフトウェア
オープンソースソフトウェアのアーキテクチャは利用者および開発者により決定され、その戦略的決定を利用者の意見や他の多くの要因に依存する。長期に渡って固定された具体的な仕様や開発計画に依らず、複数の要因による柔軟なアーキテクチャ決定を通して仕様や開発計画を決定する。オープンソースソフトウェアの利用者は各個により良いアーキテクチャを決定する権利を持ち、メインストリームのソフトウェアおよび派生したソフトウェアのアーキテクチャとしてそれを採用することができる。
ソフトウェアの開発者が複数名からなり、修正が頻繁になされるオープンソースソフトウェア開発では、ソースコードの修正内容、修正履歴の閲覧、そして修正の差し戻しを助けるためソースコードリポジトリにバージョン管理システムが用いられる。
ソースコードリポジトリはソフトウェアのソースコード一式を保存し、ソースコードの変更者、変更時刻、変更時コメントを残す。ソースコードの変更はユニークなID(連番の数字やハッシュ値)が割り当てられ、変更の記録を遡って特定して変更内容を確認することができる。ソースコードリポジトリはローカルファイルシステムに置くものや、インターネットを介したネットワーク上に置くものもある。オープンソースソフトウェアの利用者はソースコードリポジトリをフォークして独自のソースコードリポジトリを構築し、そのソースコードリポジトリ上でオープンソースソフトウェアを利用、修正、再頒布してより良いオープンソースソフトウェアを提供することができる。
ソースコードリポジトリをホスティングサービスとして提供するウェブサービスには、SourceForge、GitHub、Bitbucketなどがある。それらのウェブサービスは一般にソースコードが公開されるバージョン管理されたソースコードリポジトリを提供し、オープンソースソフトウェアの開発を支援している。それらのリポジトリはソースコードの閲覧、フォークは二次開発者が自由に行えるが、メインストリームのソースコードリポジトリに置かれたソースコード修正は主管開発者やその権限が与えられた開発者のみに許されており、不適切なソースコード修正がメインストリームのソースコードリポジトリに反映されて品質を損なうことを防いでいる。
オープンソースソフトウェアの開発者間のコミュニケーションはメーリングリスト、IRC、インスタントメッセージ、バグトラッキングシステムなどのインターネットコミュニケーションが用いられる。これらのコミュニケーションツールはオープンソースソフトウェアのソースコードの実装についてだけではなく、オープンソースソフトウェアの開発に関わるプロジェクトの方針、設計の検討、テストの実施、不具合の報告などの多岐に渡った話題のためのコミュニケーションに利用される。
コミュニケーションツールはプロジェクトの話題に限定したIRC、Skype、Slackなどのチャット、ソースコードリポジトリ、バグトラッキングシステム、ウィキを統合したGitHub、Bitbucketなどのホスティングサービス、プロジェクトやソフトウェアを限定しない雑多なStack Overflow、redditなどのコミュニティサイトが存在する。
オープンソースソフトウェアのリリースは複数の公式バージョンを配布している。一つは「安定版」で、機能が安定している、致命的なバグがない、実行環境への最適化がなされているなどの、利用者がそのソフトウェアを定常的に利用しても大きな問題が発生することが想定されていないバージョンである。一つは「検証版」で、試験的な機能が実装されている、バグが存在している、幾つかの環境でのみ動作するなどの、利用者がソフトウェアの開発および検証を目的として用いるバージョンである。安定版は検証版より長い間隔でリリースされることもあり、幾つかの検証版のリリースを経て安定版がリリースされることがある。検証版はアルファ版、ベータ版、RC(Release Candidate、リリース候補)版などの名称を持つ。オープンソースソフトウェアの特性上、安定版ですべての機能が完成して開発が終了するものを示すものではなく、安定版もまた継続してリリースされる。
オープンソースソフトウェアのリリースサイクルは短い間隔でリリースされる。ソフトウェアのソースコードが公開されていることにより、利用者はスナップショットのソースコードでソフトウェアをビルドすることが可能で、そのソフトウェアを非公式リリースとして頒布することもできる。短い間隔でのリリースを実現するため、継続的インテグレーションツールを用いてナイトリー版のビルドをリリースするソフトウェアもある。
多くのプロジェクト・ソフトウェアがオープンソースソフトウェアのソフトウェアを開発している。1980年代にプロプライエタリソフトウェア、クローズドソースに移行したオペレーティングシステム・プログラミング言語コンパイラも2000年代移行にオープンソースソフトウェアとして開発・普及している。
GNUプロジェクトはフリーソフトウェアのGNUユーティリティとしてLinux・Windows・macOS・その他OSで動作するユーティリティソフトウェアを開発している。
リーナス・トーバルズが1980年代から開発しているLinuxはオープンソースソフトウェアのオペレーティングシステムとして広く使われている。Linuxは様々なベンダー・ユーザーにより派生したソフトウェアが開発されLinuxディストリビューションの総称で呼ばれている。2007年以降、LinuxはLinux Foundationが開発主体となった。
Apacheソフトウェア財団はApache HTTP Serverを代表にC/C++のソフトウェア・ライブラリ、Javaのソフトウェア・ライブラリを開発している。また、Sun Microsystemsが開発していたオフィスソフトウェアの後継Apache OpenOfficeや、Adobeが開発していたFlashビルドツールの後継Apache Flex、HTML5アプリケーションプラットフォームの後継Apache Cordovaなど、企業が開発していたソフトウェアの後継メンテナンスも行っている。
カノニカルは2004年にユーザビリティの高いLinuxディストリビューションとなることを目標としてDebianから派生してUbuntuを開発した。Googleは2009年にウェブブラウザChromeをベースにしたChrome OSを開発した。
Googleは2012年3月にマルチコアのマシンでプログラマが意識することなくマルチスレッドを最適化して実行するGo言語を発表した。Mozilla Foundationは2012年1月に速度、安全性、平行性を言語仕様特徴として謳うシステムプログラミング向けのRust言語を発表した。Appleは2014年6月にiOS、macOS用プログラミング言語のObjective-Cの文法をモダンにリフォーマットしたSwiftを発表した。
多くのソフトウェアベンダー・ハードウェアベンダー・ソフトウェアライセンサーはオープンソースソフトウェアのフレームワーク・モジュール・ライブラリを彼らの製品に利用している。一方で、オープンソースソフトウェア開発はソフトウェアのソースコードを共有・利用・修正・再頒布を認めるという特性から収益を得るビジネスモデルを成立させることが難しく、様々な手法でのビジネスモデルの確立が試行されている。
オープンソースソフトウェアをビジネスで利用するメリットは、開発者にとってはソフトウェアのソースコードを公開し、利用者を増やすことで市場シェアを伸ばすことができる。利用者にとっては無償で利用できる、目的に併せて改変できる、コミュニティによって新しいバグが即座に修正されるという利点がある。
ビジネスモデルの例として、デュアルライセンスやサポートサービスは、ソフトウェアのライセンスに複数の選択肢を与え、基本機能のソフトウェアや過去のバージョンのソフトウェアのソースコードはオープンソースライセンスで開示し、Upsellingのソフトウェアやテクニカルサポートを有償で提供する。クラウドファンディングや投資組織は、ソフトウェア開発の前に開発資金を確保して、その資金をもってソフトウェア開発プロジェクトの運営を行い、完成したソフトウェアの販売やプロダクトの権利譲渡、先行投資アドバンテージなどにより資金援助元へ還元する。有償コンテンツ・拡張機能の販売は、ソフトウェア本体は無償のオープンソースソフトウェアとして利用者にリリースし、ソフトウェアを利用するためのコンテンツやより便利にするための拡張機能を有償販売する。ドネーションウェア・アドウェアは、ソフトウェアは完全に無償で全ての機能を利用可能とした上で、寄付や広告による収益を得る。
The Cathedral and the Bazaar(1999年、O'Reilly Media、978-1565927247)は、エリック・レイモンドによるオープンソースソフトウェア開発のエッセイである。同著書ではGNUプロジェクトのトップダウン開発手法をカテドラル方式、Linux・Fetchmailのボトムアップ開発手法をバザール方式と評して、バザール方式のソースコードを公開・共有したソフトウェア開発の有効性について述べている。エッセイの主題はバザール方式におけるエリック・レイモンドが提起したリーナスの法則「十分な目玉があれば、全てのバグは洗い出される」という点で、オープンソースソフトウェアでは利用者を共同開発者と捉えて、利用者と共にソフトウェア開発を進めることでより良いソフトウェアを開発することができると述べている。
Open Sources: Voices from the Open Source Revolution(1999年、O'Reilly Media、1-56592-582-3)、Open Sources 2.0(2005年、O'Reilly Media、0-596-00802-3)は、オープンソースソフトウェア分野の著名人のエッセイをまとめた書籍である。マーシャル・カーク・マキュージック、マイケル・ティーマン、リーナス・トーバルズ、ポール・ヴィクシー、ラリー・ウォール、イアン・マードック、ラリー・サンガー、ティム・オライリーなどが寄稿している。
Revolution OS(2001年)は、1970年代末から約20年間のGNUプロジェクト・Linux・フリーソフトウェア・オープンソースの歴史をまとめたドキュメンタリー映画である。オープンソースソフトウェア分野の著名人のリチャード・ストールマン、リーナス・トーバルズ、エリック・レイモンド、ブルース・ペレンズが特別出演している。
フリーソフトウェア運動(Free Software Movement)は、フリーソフトウェア財団を主体にした自由ソフトウェアの利用者の自由を尊重する思想を啓蒙する社会運動である。フリーソフトウェア運動はGNU宣言を代表として、自由ソフトウェアの定義・コピーレフト・Defective by Design・BadVista・TiVo化批判・フリーソフトウェアの歌など、理念的なものから他者批判的なもの、ユーモラス的なものまで多種多様である。
フリーソフトウェア運動の理念の1つとして、フリーソフトウェアとオープンソースは別物でありオープンソースソフトウェアの名の基にフリーソフトウェアを用いるのは不適切であるという考えがあり、フリーソフトウェア運動家はフリーソフトウェアとオープンソースのソフトウェアの総称を「OSS(オープンソースソフトウェア)」ではなく「FLOSS(Free/Libre and Open Source Software)」もしくは「フリーソフトウェアとオープンソースソフトウェア」と明確に別けて呼称する。
自由ソフトウェアは、広義のオープンソースソフトウェアの定義においてオープンソースソフトウェアの部分集合であるが、オープンソースソフトウェアと自由ソフトウェアは根源的なコンセプトが異なる。オープンソースソフトウェア(オープンソース)がソフトウェアのソースコードを公開・共有する「開発の方法論」である一方で、自由ソフトウェアは利用者の自由(実行・研究・変更・コピーを変更ありまたはなしで再配布するという自由)を尊重する「社会運動」である。コンセプトが開発の方法論と社会運動と異なるため、本来は並列に比較するようなものではない。
その上で、自由ソフトウェアという社会運動のための一つのツールとしてオープンソースソフトウェアという開発の方法論を用いようとした場合、オープンソースソフトウェアは利用者の自由を尊重するのに機能不十分なツールである。この機能不十分な点を比較した場合、オープンソースソフトウェアが許容する幾つかのライセンスは不適切であり、自由ソフトウェアはコピーレフトに代表されるような利用者の自由を尊重するための条項が含まれたライセンスを推奨している。
機能不十分な例としては、オープンソース・イニシアティブがオープンソースライセンスとして承認しているSybase Open Watcom Public Licenseは利用者が修正したソースコードから作られたソフトウェアを個人的な用途で公開した場合にはソースコードの公開を必要としていない。これは修正されたソフトウェアは一般に公開されているにも関わらず、そのソフトウェアのソースコードは非公開となっており、二次利用者の自由を妨げている。もう一つの例としては、オープンソースソフトウェアは利用者がソフトウェアもしくはそのソフトウェアが動作するハードウェアをTiVo化 (tivoization) することを許容するライセンスの存在を許し、二次利用者の自由を妨げることを否定していない。
シェアードソースソフトウェアは、ソースコードを開示し、利用者にソースコードおよびソフトウェアの動作の参照およびデバッグのための利用を認めている。ソフトウェアのソースコードの共有を主な観点としており、営利団体の商業ソフトウェアのソースコードを協力機関(研究機関・大学・利用者)に開示する用途で利用されている。
オープンソースソフトウェアとシェアードソースソフトウェアの違いは、シェアードソースソフトウェアはソースコードの修正、再頒布に対して制約的である所である。利用者に対してソースコードの参照、デバッグを目的とした利用は認めているが、修正したソースコードそのものや、修正したソースコードから生成されるソフトウェアの頒布は私的使用に限って認めるなどの制約を伴う場合がある。また、シェアードソースソフトウェアでは商用目的でソースコードを利用(閲覧)することが出来ない場合がある。それらの制約はシェアードソースソフトウェアに課せられるライセンスの内容に依る。
マイクロソフトは2001年より自社ソフトウェア製品のためにシェアードソースイニシアティブを立ち上げている。マイクロソフトのシェアードソースライセンスは幾つかの種類があり、制約の緩やかなライセンスはオープンソースイニシアティブ公認のオープンソースライセンスであるが、制約の厳しいライセンスは同社との提携契約の上でソースコードの参照のみが許されるプロプライエタリライセンスである。Sony Computer Entertainment of America (SCEA) は2005年にPlayStationのソフトウェアのためにSCEA Shared Source Licenseを設けていた。
プロプライエタリソフトウェアは、ソフトウェアの利用・頒布に制限を課し、場合によってはその制限を解除することで利益を得るソフトウェアの総称であり、オープンソースソフトウェアとの違いは利用・修正・再頒布に制限を設ける・設けない点が主な違いである。
プロプライエタリソフトウェアのソースコードの公開・利用の可否に明確な線引きはないが、ソースコードを開示していてもソースコードの入手が有償である、ソースコードが非公開(クローズドソース)であるなど、基本的にソフトウェアの利用者がソースコードを自由に利用することは出来ない。ソフトウェアのソースコードを非商用目的に限り利用・修正・再頒布を認め、商用目的での利用・修正・頒布を認めない場合もオープンソースソフトウェアではなくプロプライエタリソフトウェアと呼ばれる。
個人や組織がオープンソースソフトウェアを選ぶ主要な4つの理由に安価・情報セキュリティ・ベンダーロックインでない・より良い品質がある。ソフトウェア開発企業は必ずしもソフトウェアの販売に依存しないため、相対的にプロプライエタリソフトウェアの必要性は低くなってきている。Novellのような企業は、製品の一部をオープンソースソフトウェアに切り替えているため、継続的にオープンソースソフトウェア上でのビジネスモデルを思案している。
多くの主張者が、多くの人間がソースコードを閲覧・編集・変更するため、オープンソースソフトウェアはソースコードが非公開のプロプライエタリソフトウェアに比べて本質的により安全であると主張している。オープンソースソフトウェアであるLinuxのソースコードは1000行あたり0.17個のバグがある一方で、プロプライエタリソフトウェアのソースコードは一般的に1000行あたり20–30個のバグがある。
コベリティは2014年にCoverity Scan Open Source Reportにおいて、オープンソースソフトウェアの品質がプロプライエタリソフトウェアの品質を越えたというレポートを発表した。この評価は750百万行からなるソースコード、700以上のC/C++エンタープライズプロジェクトとJavaプロジェクトを対象に実施された。レポートの要点として4つ、C/C++プロジェクトではオープンソースソフトウェアがプロプライエタリソフトウェアの品質を越えている、Linuxがオープンソースの品質向上に貢献している、C/C++開発者は重大なバグをより多く改修する傾向にある、JavaプロジェクトではHBaseが品質向上に貢献している、を挙げている。
自由ソフトウェア支持者は自由ソフトウェアの理念を社会に浸透させる社会運動において、オープンソースソフトウェアは不適切な概念であると考えている。
フリーソフトウェア財団の代表リチャード・ストールマンはオープンソースの概念は自由ソフトウェアが主観にしている利用者の重要な自由を守るに足りえないとして、オープンソースソフトウェアは自由ソフトウェアの的を外していると批判している。同様の観点でオープンソース・イニシアティブの創設者の一人ブルース・ペレンスは、オープンソース・イニシアティブの設立の1年後に、オープンソースが自由ソフトウェアから離れすぎていることを挙げて「今こそフリーソフトウェアについて再び語るべきときだ」と述べて、オープンソース・イニシアティブから離脱した。
GNUプロジェクトのリチャード・ストールマンはGNUツールを用いてオペレーティングシステムとして成り立っているLinuxは「GNU/Linux」と呼称するべきであると主張しており、GNU/Linux名称支持者とLinux名称支持者の間でLinuxに対する名称論争が存在している。
GNU/Linux名称支持者は、オペレーティングシステム全体においてLinuxカーネルは機能の一部でありGNUプロジェクトのソフトウェア群によって完成していることを挙げて併記を求め、また呼称への拘りがフリーソフトウェアコミュニティの理想主義への啓蒙を兼ねていることを説明している。DebianプロジェクトはGNU/Linuxの呼称を受け入れており、公式なディストリビューションの名称としてDebian GNU/Linuxと名乗っている。
Linux名称支持者は、Linuxが既に十分に一般的な通称となっており名称を変更する必要性を感じていない。明示的な理由を挙げているエリック・レイモンドは、ジャーゴンファイルのLinuxの節でGNU/Linux名称は縄張り争いと承認欲が根元にあり、リチャード・ストールマンとその近しい友人以外には受け入れるのは難しいと述べている。Linuxの開発者リーナス・トーバルズは、Revolution OSのインタビューの中で、GNU/Linuxの名称はGNUプロジェクトがGNUディストリビューションを開発したならば適切であるとした上で、Linuxの総称としては不適切であるとコメントしている。
エリック・レイモンドはマイクロソフトのオープンソースソフトウェア・Linuxへの潜在的戦略に関する機密文書を入手し、1998年11月3日にハロウィーン文書としてリークした。マイクロソフトは1998年11月5日にリークされたハロウィーン文書に対して公式コメントとして、同文書の内容は内部的な検討資料として日常的な適切なものであるが、Linuxに対する公式の立場のものではないと発表した。
ハロウィーン文書でマイクロソフトは、オープンソースソフトウェアが公開された標準規格、プロプライエタリソフトウェアに比べて低いTCOにより幅広く支持を受けていると述べ、その上で、オープンソースソフトウェアに対抗する戦略としてFUD戦略・3E戦略を挙げている。実際にマイクロソフトはFUD戦略として、オープンソースソフトウェアをロビン・フッドに例えて不安定性を訴える、「Linuxを学ぶほどにコンシューマーにとっての価値の少なさを感じている」と紹介する、第三者評価機関を援助してLinuxの否定的評価結果を挙げる、などの活動を行った。オープンソースの低いTCOに対しては、シェアードソースで同等のTCOを模索し、一定の評価を得ていると自己評価を出している。
SCOグループは2003年に自らがUnixの知的財産権保持者であり、更にLinuxにUnixのソースコードが盗用されていると主張した。SCOグループは、UNIXの知的財産権を保持している、LinuxがUnixのソースコードを利用している、の2点を根拠にLinux関係者に対して権利行使に基づくライセンスビジネスを発表したが、Linux関係者は不適当な権利行使であるとして受け入れなかった。この主張の相違がSCOグループとLinux関係者の論争の起点となり、ここからSCO・Linux論争が始まった。
SCOグループがUNIXの知的財産権を保持しているという主張は2007年8月10日に退けられ、NovellがUnixの権利を保持していると判決が出された。また、NovellはLinuxにUnixのソースコードが含まれているとは考えていないと声明を出し、LinuxがUnixの知的財産権を侵害しているという疑惑は払拭されている。
FLOSS (Free/Libre and Open Source Software) は、フリーソフトウェアとオープンソースの複合語である。これは、フリーソフトウェア財団とオープンソース・イニシアティブが根源的な部分で活動理念を異にしており、フリーソフトウェア財団の定義するフリーソフトウェアとオープンソース・イニシアティブの定義するオープンソースは別物で区別しなければならないというリチャード・ストールマンの考えに基づいている。ソースコードとソフトウェアの利用、修正、再頒布を認めるという表面的な同一視をした場合に、それらの用語を同列かつ個別のものと見なし、その上でそれらをまとめて言い表すために、複合語としてFLOSSという用語が使われる。
オープンソースソフトウェアという用語がソフトウェアおよびそのソースコードのみに適用される一方で、ソースコードを伴うソフトウェア以外の事柄の利用者にその事柄の利用、修正、再頒布を認める場合は、「オープンソース」を冠したオープンソースハードウェア、オープンソースジャーナリズム、オープンソースガバナンス、オープンソースエコロジーのような用語が存在する。ソースコードは存在しないがその事柄の利用、修正、頒布を認める場合は、「オープン」を冠したオープンアクセス、オープンシステム、オープンコンテントのような用語が存在する。オープンソースおよびオープンを冠していても、オープンソースソフトウェアの定義と同じくその事柄の利用・修正・再頒布を認めているかどうかは各用語によって異なるため、それらの用語の意味するところについてはそれぞれ注意して扱うべきである。