オープンソースソフトウェア開発(OSSD )とは、オープンソースソフトウェアプロジェクトによって、オープンソースソフトウェア、またはソースコードが公開されている類似のソフトウェアが開発されるプロセスです。これらのソフトウェア製品は、オープンソースライセンスの下でソースコードとともに公開されており、設計の研究、変更、改善が可能です。人気のあるオープンソースソフトウェア製品の例としては、Mozilla Firefox、Google Chromium、Android、LibreOffice、VLCメディアプレーヤーなどがあります。
1997年、エリック・S・レイモンドは『大聖堂とバザール』を著した。[ 1 ]この著書の中で、レイモンドは2種類のソフトウェア開発を区別している。1つ目は従来型のクローズドソース開発である。レイモンドによれば、この種の開発方法は、中央集権的な計画、厳格な組織、そして最初から最後まで一つのプロセスで進められる大聖堂の建設に似ている。2つ目は漸進的なオープンソース開発であり、これは「さまざまな目的やアプローチが入り混じる大きなバザール」のようなもので、そこから一貫性のある安定したシステムが奇跡の連続によってのみ出現するように見える。後者の比喩は、オープンソース開発プロセスにおける議論を指し示している。
BarとFogelによれば、2つの開発スタイルの違いは、一般的にバグ報告と機能要求の処理(および作成) 、およびプログラマーが作業する制約にある。[ 2 ]クローズドソースのソフトウェア開発では、プログラマーはバグ報告の処理と作成、および機能要求の処理に多くの時間を費やすことが多い。この時間は、今後の開発計画の作成と優先順位付けに費やされる。このため、開発チームの一部は、実際の開発ではなく、これらの問題に多くの時間を費やすことになる。また、クローズドソースのプロジェクトでは、開発チームは、ソフトウェアの技術的な問題を妨げる管理関連の制約(締め切り、予算など)の下で作業しなければならないことが多い。オープンソースのソフトウェア開発では、ソフトウェアのユーザーを開発プロセスに統合したり、ユーザー自身にシステムを構築させたりすることで、これらの問題が解決される。

オープンソースソフトウェア開発は、いくつかのフェーズに分けられます。ここで指定されているフェーズは、Sharma ら[ 3 ]から派生したものです。右側には、オープンソースソフトウェア開発のプロセスデータ構造を示す図が示されています。この図では、オープンソースソフトウェア開発のフェーズと、それに対応するデータ要素が表示されています。この図は、メタモデリングとメタプロセスモデリングの手法を使用して作成されています。
オープンソースプロジェクトに取り組むには、いくつかの方法があります。
エリック・レイモンドはエッセイ「大聖堂とバザール」の中で、プロジェクトの意図を発表することは、実際に稼働しているプロジェクトを一般に公開することに比べて、通常は劣ると指摘している。
既存の類似プロジェクトに貢献する方が効果的な場合、新しいプロジェクトを開始してしまうのはよくある間違いです(NIH症候群)。成功するプロジェクトを開始するには、既存の状況を調査することが非常に重要です。プロセスは、既存のプロジェクトを採用するか、新しいプロジェクトを開始するかの選択から始まります。新しいプロジェクトを開始する場合は、プロセスは開始フェーズに進みます。既存のプロジェクトを採用する場合は、プロセスは直接実行フェーズに進みます。
オープンソースプロジェクトにはいくつかの種類があります。まず、一般的なソフトウェアプログラムやライブラリがあり、これらは独立したコードで構成されています。中には、他のオープンソースプロジェクトに依存しているものもあります。これらのプロジェクトは特定の目的を果たし、明確なニーズを満たします。このタイプのプロジェクトの例としては、Linuxカーネル、Firefoxウェブブラウザ、LibreOfficeオフィススイートなどが挙げられます。
ディストリビューションは、オープンソースプロジェクトの一種です。ディストリビューションとは、共通の目的のために同じソースから公開されるソフトウェアの集合体です。最も代表的な「ディストリビューション」の例は、オペレーティングシステムです。Linuxカーネルと多くのユーザーランドコンポーネントを同梱したLinuxディストリビューション(Debian、Fedora Core、Mandriva、Slackware、Ubuntuなど)は数多く存在します。その他にも、さまざまなオペレーティングシステム向けのPerlプログラミング言語であるActivePerlや、 Microsoft Windows向けのオープンソースプログラムのディストリビューションであるCygwinなどがあります。
BSD派生ディストリビューションのような他のオープンソースプロジェクトでは、オペレーティングシステム全体、カーネル、およびすべてのコアコンポーネントのソースコードを単一のバージョン管理システムで管理し、単一のチームとしてシステム全体を共同開発します。これらのオペレーティングシステム開発プロジェクトは、他のディストリビューションベースのシステムよりも、ツールをより密接に統合しています。
最後に、書籍や独立したドキュメントプロジェクトがあります。これらは通常、オープンソースソフトウェアパッケージの一部として提供されるものではありません。Linux Documentation Projectは、 Linuxオペレーティングシステムのさまざまな側面を文書化した多くのプロジェクトをホストしています。この種のオープンソースプロジェクトは他にも多数存在します。
オープンソース プロジェクトをウォーターフォール モデルのようなより伝統的なソフトウェア開発手法に従って運営するのは困難です。なぜなら、これらの伝統的な手法では前のフェーズに戻ることが許されないからです。オープンソース ソフトウェア開発では、要件はプロジェクト開始前に収集されることはほとんどなく、代わりに、ロビンスが説明しているように、ソフトウェア製品の初期リリースに基づいて収集されます。[ 4 ]要件に加えて、多くの場合、ボランティア スタッフがソフトウェアの初期リリースに基づいてソフトウェア製品の開発を支援するために集まります。アブラハムソンらによると、このネットワーク効果は不可欠です。「導入されたプロトタイプが十分な注目を集めれば、徐々にますます多くの開発者を引き付けるようになります」。しかし、アブラハムソンらは、コミュニティはクローズド ソース ソフトウェアのビジネスの世界と同様に非常に厳しいことも指摘しています。「顧客を見つければ生き残れますが、顧客がいなければ死んでしまいます」。[ 5 ]
フゲッタ[ 6 ]は、「ラピッドプロトタイピング、インクリメンタルおよびエボリューション開発、スパイラルライフサイクル、ラピッドアプリケーション開発、そして最近ではエクストリームプログラミングとアジャイルソフトウェアプロセスは、プロプライエタリソフトウェアとオープンソースソフトウェアの両方に等しく適用できる」と主張している。彼はまた、エクストリームプログラミングをオープンソースソフトウェア開発に非常に有用な手法として挙げている。より一般的には、反復的かつインクリメンタルな性質を持つため、すべてのアジャイルプログラミング手法はオープンソースソフトウェア開発に適用可能である。他のアジャイル手法も、オープンソースとクローズドソースの両方のソフトウェア開発に等しく有用である。たとえば、インターネットスピード開発は、分散開発の原則を採用しているため、オープンソースソフトウェア開発に適している。インターネットスピード開発は、地理的に分散したチームを使用して「24時間体制で作業」を行う。この手法は、主に大規模なクローズドソース企業によって採用されている(異なるタイムゾーンに開発センターを持つことができるのはこれらの企業だけであるため)が、オープンソースプロジェクトでも同様に有効である。なぜなら、多数のボランティアによって開発されたソフトウェアは、開発者がすべてのタイムゾーンに分散する傾向があるからである。
オープンソースプロジェクトの開発者とユーザーは、必ずしも全員が同じ場所でプロジェクトに取り組んでいるわけではありません。そのため、何らかの電子的なコミュニケーション手段が必要となります。電子メールは、オープンソースの開発者とユーザーの間で最も一般的なコミュニケーション手段の一つです。多くの場合、電子メールメッセージが関係者全員に一斉に配信されるように、メーリングリストが使用されます。これにより、少なくともメンバーの一人が返信できるようになります。リアルタイムでコミュニケーションを取るために、多くのプロジェクトではIRCなどのインスタントメッセージング方式が用いられています。最近では、Webフォーラムが、オープンソース製品の使用中に発生した問題に対するユーザーのヘルプを得るための一般的な手段となっています。Wikiは、開発者とユーザー間のコミュニケーション媒体として一般的になっています。[ 7 ]
オープンソースソフトウェア(OSS)の開発においては、参加者の大半はボランティアであり、地理的に様々な地域に分散しているため、参加者がソースコードの開発において協力し合うためのツールが必要となる。
2000年代初頭、Concurrent Versions System (CVS) は、OSS プロジェクトで使用されるソースコードコラボレーションツールの代表的な例でした。CVS は、複数の人が同時にプロジェクトに取り組む際に、プロジェクトのファイルとコードを管理するのに役立ちます。CVS を使用すると、複数の人が同時に同じファイルで作業できます。これは、ファイルをユーザーのディレクトリに移動し、ユーザーが作業を終えたらファイルをマージすることによって実現されます。CVS を使用すると、ファイルの以前のバージョンを簡単に取得することもできます。2000 年代半ば、 CVS に代わるものとしてSubversion リビジョン管理システム(SVN) が作成されました。これは、OSS プロジェクトのバージョン管理システムとして急速に普及しています。[ 7 ]
現在、多くのオープンソースプロジェクトでは、SVNやCVSのような集中型リポジトリよりも拡張性に優れた分散型リビジョン管理システムが使用されています。代表的な例としては、Linuxカーネルで使用されているgit [ 8 ]や、Pythonプログラミング言語で使用されているMercurial [ 9 ]などがあります。
ほとんどの大規模プロジェクトでは、プロジェクト開発における様々な問題の状況を追跡するために、バグ追跡システムが必要となる。
OSSプロジェクトは頻繁に統合されるため、システム統合中のテストを自動化するのに役立つツールが使用されます。そのようなツールの例としてTinderboxがあります。Tinderboxを使用すると、OSSプロジェクトの参加者はシステム統合中にエラーを検出できます。Tinderboxは継続的なビルドプロセスを実行し、問題のあるソースコードの部分と、これらの問題が発生するプラットフォームについてユーザーに通知します。[ 7 ]
デバッガとは、他のプログラムのデバッグ(場合によってはテストや最適化も)に使用されるコンピュータプログラムです。GNUデバッガ(GDB)は、オープンソースソフトウェア開発で使用されるデバッガの一例です。このデバッガはリモートデバッグ機能を備えているため、オープンソースソフトウェア開発に特に適しています。
メモリリークツールまたはメモリデバッガは、メモリリークやバッファオーバーフローを検出するためのプログラミングツールです。メモリリークとは、コンピュータプログラムによる不要なメモリ消費の一種で、プログラムが不要になったメモリを解放できない状態を指します。Mozilla が使用するメモリリーク検出ツールの例としては、XPCOMメモリリークツールがあります。検証ツールは、コードが指定された構文に準拠しているかどうかを確認するために使用されます。検証ツールの例としては、Splintがあります。
パッケージ管理システムとは、コンピュータへのソフトウェアパッケージのインストール、アップグレード、設定、削除といったプロセスを自動化するためのツール群のことです。Red Hat Package Manager (RPM) は .rpm ファイル用、Advanced Packaging Tool (APT) は.debファイル用として、多くの Linux ディストリビューションで使用されているパッケージ管理システムです。
ソフトウェアディレクトリとリリースログ:
記事: