オープンソースソフトウェア開発

オープンソースソフトウェア開発（、OSSD）とは、オープンソースソフトウェア、またはソースコードが公開されている類似のソフトウェアをオープンソースソフトウェアプロジェクトとして開発するプロセスである。これらのソフトウェアは、オープンソースライセンスの下で研究、変更、改善できる。有名なオープンソースソフトウェアの例としては、Mozilla Firefox、Chromium、Android、LibreOffice、VLCメディアプレーヤーなどがある。

**歴史**
1997年、エリック・レイモンドは『伽藍とバザール』を執筆した。この本で、レイモンドは2種類のソフトウェア開発手法を区別している。1つ目は従来のクローズドソース開発であり、レイモンドによると、この開発方法は伽藍の建設に似ている。これは、中央計画、緊密な組織、最初から最後まで一貫したプロセスを特徴とする。2つ目は進歩的なオープンソース開発であり、これは「さまざまな議題とアプローチが衝突する大きなバザールのようなもので、そこから一貫性のある安定したシステムは奇跡の連続によってのみ出現するようである」。後者のアナロジーは、オープンソース開発プロセスに含まれる議論を指している。
バーとフォーゲルによると、2つの開発スタイルの違いは、一般的にバグレポートと機能要求の処理（および作成）と、プログラマが従う制約である。クローズドソースソフトウェア開発では、プログラマはバグレポートの処理と作成、および機能要求の処理に多くの時間を費やすことがよくある。これにより、開発チームの一部は、実際の開発ではなく、これらの問題に多くの時間を費やすことになる。また、クローズドソースプロジェクトでは、開発チームは、ソフトウェアの技術的な問題を妨げる制約（期限、予算など）の下で作業しなければならないことが多い。オープンソースソフトウェア開発では、これらの問題は、ソフトウェアのユーザーを開発プロセスに統合するか、これらのユーザーにシステム自体をビルドさせることによって解決されるdate=November 2014。

**モデル**
オープンソースソフトウェア開発におけるプロセス-データモデル
オープンソースソフトウェア開発は、いくつかのフェーズに分けることができる。ここで指定されているフェーズは、Sharmaらから言及されているものである。オープンソースソフトウェア開発のプロセス-データ構造を示す図が右側に示されており、この図では、オープンソースソフトウェア開発のフェーズが、対応するデータ要素とともに表示されている。この図は、メタモデリングとMeta-process modelingの手法を使用して作成されている。

**オープンソースプロジェクトの開始**
オープンソースプロジェクトの作業を開始するには、いくつかの方法がある。
# プロジェクトの必要性を感じた個人が、プロジェクトを開発する意志を公に発表する。
# 限定的だが機能するコードベースで作業している開発者が、オープンソースプログラムの最初のバージョンとしてそれを公にリリースする。
# 成熟したプロジェクトのソースコードを公にリリースする。
# 十分に確立されたオープンソースプロジェクトを、関心のある外部の当事者がフォークする。
エリック・レイモンドは、エッセイ『伽藍とバザール』の中で、プロジェクトを開発する意志を発表することは、通常、実際に機能しているプロジェクトを一般に公開することより劣ると指摘している。
既存の類似プロジェクトに貢献する方が効果的であるのに、プロジェクトを開始するのはよくある間違いである（NIH症候群）date=October 2019。成功するプロジェクトを開始するには、すでに存在するものを調査することが非常に重要である。プロセスは、既存のプロジェクトを採用するか、新しいプロジェクトを開始するかの選択から始まる。新しいプロジェクトを開始する場合、プロセスは開始フェーズに進む。既存のプロジェクトを採用する場合、プロセスは直接実行フェーズに進む。

**オープンソースプロジェクトの種類**
オープンソースプロジェクトにはいくつかの種類がある。まず、スタンドアロンのコードで構成されるありふれたソフトウェアプログラムとライブラリがある。中には、他のオープンソースプロジェクトに依存しているものもある。これらのプロジェクトは、特定の目的を果たし、明確なニーズを満たす。この種類のプロジェクトの例としては、Linuxカーネル、Firefox、LibreOfficeなどがある。
ディストリビューションは、別の種類のオープンソースプロジェクトである。ディストリビューションは、共通の目的を持つ同じソースから公開されるソフトウェアの集合である。「ディストリビューション」の最も顕著な例は、オペレーティングシステムである。多くのLinuxディストリビューション（Debian、Fedora、Mandriva Linux、Slackware、Ubuntuなど）があり、Linuxカーネルと多くのユーザランドコンポーネントが同梱されている。その他のディストリビューションには、さまざまなオペレーティングシステム用のPerlディストリビューションであるActivePerlや、Microsoft Windows用のオープンソースプログラムのCygwinなどがある。
BSD派生プロジェクトのような他のオープンソースプロジェクトでは、オペレーティングシステム全体、カーネル、およびそのコアコンポーネントすべてのソースコードを1つのバージョン管理システムで管理し、システム全体を1つの単位として共同で開発する。これらのオペレーティングシステム開発プロジェクトでは、他のディストリビューションベースのシステムよりもツールが密接に統合されている。
最後に、書籍またはスタンドアロンドキュメントプロジェクトがある。これらのアイテムは通常、オープンソースソフトウェアパッケージの一部として配布されない。Linux Documentation Projectでは、Linuxオペレーティングシステムのさまざまな側面をドキュメント化するこのようなプロジェクトが多数ホストされている。このタイプのオープンソースプロジェクトの例は他にも多数ある。

**手法**
ウォーターフォール・モデルのような従来のソフトウェア開発手法に従ってオープンソースプロジェクトを実行するのは困難である。これらの従来の方法では、前のフェーズに戻ることができないためである。オープンソースソフトウェア開発では、プロジェクトの開始前に要件がまとめられることはほとんどない。代わりに、Robbinsが説明するように、ソフトウェア製品の初期リリースに基づいて要件がまとめられる。要件に加えて、ソフトウェアの初期リリースに基づいてソフトウェア製品の開発を手伝うボランティアスタッフもいる。Abrahamssonらによると、このネットワーク効果は不可欠である。「導入されたプロトタイプが十分な注目を集めれば、徐々に多くの開発者を引き付け始める。」ただし、Abrahamssonらは、コミュニティが非常に厳しいことも指摘している。これはクローズドソースソフトウェアのビジネスの世界と同様である。「顧客を見つければ生き残れるが、顧客がいなければ死んでしまう。」
Fuggettaは、「ラピッドプロトタイピング、漸進的開発や進化的開発、スパイラルライフサイクル、ラピッドアプリケーション開発、そして最近ではエクストリーム・プログラミングやアジャイルソフトウェア開発は、プロプライエタリソフトウェアとオープンソースソフトウェアに等しく適用できる」と主張している。また、エクストリーム・プログラミングはオープンソースソフトウェア開発に非常に役立つ手法であると指摘している。より一般的には、反復的で漸進的な特徴を持つアジャイルプログラミング手法はすべて、オープンソースソフトウェア開発に適用できる。その他のアジャイル手法は、オープンソースソフトウェア開発とクローズドソースソフトウェア開発の両方に等しく役立つ。たとえば、Internet-speed developmentは、分散開発の原則を採用しているため、オープンソースソフトウェア開発に適している。インターネットスピード開発では、地理的に分散したチームが「24時間体制で作業」する。この手法は、主に大規模なクローズドソース企業によって採用されているが（異なるタイムゾーンに開発センターを設置できるのはクローズドソース企業だけであるため）、大規模なボランティアグループによって開発されたソフトウェアは、当然のことながらすべてのタイムゾーンに開発者が分散する傾向があるため、オープンソースプロジェクトでも同様に機能する。

**ツール**

**コミュニケーション手段**
オープンソースプロジェクトの開発者とユーザーは、必ずしも全員が近くでプロジェクトに取り組んでいるわけではない。何らかの電子的なコミュニケーション手段が必要である。電子メールは、オープンソースの開発者とユーザーの間で最も一般的なコミュニケーション手段の1つである。多くの場合、メッセージがすべての関係者に一度に配信されるように、メーリングリストが使用される。これにより、少なくとも1人のメンバーが返信できるようになる。リアルタイムでコミュニケーションするために、多くのプロジェクトではIRCなどのインスタントメッセージが使用されている。近年では、ユーザーがオープンソースソフトウェアの使用中に遭遇する問題についてサポートを受ける方法として、Webフォーラムが一般的となっている。また、ウィキは開発者とユーザーのコミュニケーション手段として広く使用されている。

**バージョン管理システム**
OSS開発では、参加者は主にボランティアであり、さまざまな地域に分散しているため、参加者がソースコードの開発で共同作業することを支援するツールが必要である。
2000年代初頭、Concurrent Versions System (CVS) は、OSSプロジェクトで使用されているソースコード共同作業ツールの代表的な例であった。CVSは、複数の人が同時にプロジェクトに取り組んでいる場合に、プロジェクトのファイルとコードの管理に役立つ。CVSを使用すると、複数の人が同時に同じファイルで作業できる。これは、ファイルをユーザーのディレクトリに移動し、ユーザーが作業を完了したときにファイルをマージすることで行われる。また、ファイルの以前のバージョンを簡単に取得することもできる。2000年代半ばには、CVSに代わるApache Subversion (SVN) が作成され、これはOSSプロジェクトのバージョンコントロールシステムとして急速に普及した。
現在、多くのオープンソースプロジェクトでは分散バージョン管理システムが採用されている。これはSVNやCVSなどの集中型リポジトリよりも拡張性に優れている。一般的な例としては、Linuxカーネルで使用されるgitや、Pythonで使用されるMercurialなどが挙げられるdate=November 2014。

**バグトラッカーとタスクリスト**
ほとんどの大規模プロジェクトでは、プロジェクトの開発におけるさまざまな問題の状況を追跡するために、バグ管理システムが必要である。

**テストとデバッグ**
OSSプロジェクトでは、システムインテグレーション中にテストを自動化するツールが使用される。このようなツールの例としてTinderboxがある。Tinderboxを使用することで、システムインテグレーション中にエラーを検出できる。Tinderboxは継続的なビルドプロセスを実行し、問題のあるソースコードの部分と、これらの問題が発生するプラットフォームについてユーザーに通知する。
デバッガは、他のプログラムをデバッグ（場合によってはテストまたは最適化）するために使用されるコンピュータプログラムである。GNUデバッガ（GDB）は、オープンソースソフトウェア開発で使用されるデバッガの一例である。このデバッガはリモートデバッグを提供するため、オープンソースソフトウェア開発に特に適しているdate=November 2014。
メモリデバッガは、メモリリークやバッファオーバーフローを検出するためのプログラミングツールである。メモリリークは、コンピュータープログラムによる特定の種類の不要なメモリ消費であり、プログラムが不要になったメモリを解放し忘れることで生じる。Mozillaが使用するメモリリーク検出ツールの例としては、XPCOMがある。また、解析ツールは、コードが指定された構文に準拠しているかどうかを確認するために使用される。例としては、Splint (programming tool)がある。

**パッケージ管理**
パッケージ管理システムは、コンピュータへのソフトウェアパッケージのインストール、アップグレード、設定、削除のプロセスを自動化するツールの集合である。.rpm用のRPM Package Manager (RPM) と.deb形式用のAdvanced Packaging Tool (APT) は、多くのLinuxディストリビューションで使用されているパッケージ管理システムであるdate=November 2014。

**関連項目**

**脚注**

**外部リンク ==