オープンソースソフトウェア開発（OSSD）とは、オープンソースソフトウェア、またはソースコードが公開されている類似のソフトウェアを、オープンソースソフトウェアプロジェクトによって開発するプロセスです。これらは、オープンソースライセンスの下でソースコードが公開されているソフトウェア製品であり、設計の検討、変更、改善のために利用できます。人気のあるオープンソースソフトウェア製品の例としては、Mozilla Firefox、Google Chromium、Android、LibreOffice、VLCメディアプレーヤーなどがあります。

歴史

1997年、エリック・S・レイモンドは『伽藍とバザール』 [1]を執筆した。この本の中で、レイモンドは2種類のソフトウェア開発を区別している。一つ目は従来型のクローズドソース開発である。レイモンドによれば、この種の開発手法は、大聖堂の建設に似ており、中央集権的な計画、緊密な組織、そして最初から最後まで一貫したプロセスである。二つ目は漸進的なオープンソース開発であり、これはむしろ「様々な議題やアプローチが入り乱れる巨大なバザールであり、そこから首尾一貫した安定したシステムが生まれるには、奇跡の連続が必要不可欠である」という類推である。後者の類推は、オープンソース開発プロセスにおける議論を指し示している。

BarとFogelによると、2つの開発スタイルの違いは、一般的にバグレポートと機能要求の処理（および作成）と、プログラマが従う制約にあります。[2]クローズドソースソフトウェア開発では、プログラマはバグレポートの処理と作成、および機能要求の処理に多くの時間を費やすことがよくあります。この時間は、今後の開発計画の作成と優先順位付けに費やされます。その結果、開発チームの一部は、実際の開発ではなく、これらの問題に多くの時間を費やすことになります。また、クローズドソースプロジェクトでは、開発チームは、ソフトウェアの技術的な問題に干渉する管理関連の制約（期限、予算など）の下で作業しなければならないことがよくあります。オープンソースソフトウェア開発では、これらの問題は、ソフトウェアのユーザーを開発プロセスに統合するか、ユーザー自身にシステムを構築させることによって解決されます。[要出典]

モデル

オープンソースソフトウェア開発のためのプロセスデータモデル

オープンソースソフトウェア開発は複数のフェーズに分けることができます。ここで指定するフェーズは、Sharmaら[3]に由来しています。オープンソースソフトウェア開発のプロセスデータ構造を示す図を右側に示します。この図では、オープンソースソフトウェア開発の各フェーズと、それに対応するデータ要素が表示されています。この図は、メタモデリングとメタプロセスモデリングの手法を用いて作成されています。

オープンソースプロジェクトの開始

オープンソース プロジェクトの作業を開始するには、いくつかの方法があります。

  1. プロジェクトの必要性を感じた個人が、プロジェクトを展開する意図を公に発表します。
  2. 開発者は、限定的だが機能するコードベースで作業し、それをオープンソース プログラムの最初のバージョンとして一般に公開します。
  3. 成熟したプロジェクトのソースコードが一般に公開されます。
  4. 十分に確立されたオープンソース プロジェクトは、関心のある外部の当事者によってフォークされる可能性があります。

エリック・レイモンドは、エッセイ「伽藍とバザール」の中で、プロジェクトの意図を発表することよりも、実際に稼働しているプロジェクトを一般に公開することの方が通常は劣ると述べています。

既存の類似プロジェクトに貢献する方が効果的であるにもかかわらず、プロジェクトを開始するというのはよくある間違いです（NIH症候群）[要出典]。成功するプロジェクトを開始するには、既存のものを調査することが非常に重要です。プロセスは、既存のプロジェクトを採用するか、新しいプロジェクトを開始するかの選択から始まります。新しいプロジェクトを開始する場合、プロセスは開始フェーズに進みます。既存のプロジェクトを採用する場合、プロセスは直接実行フェーズに進みます。[原著研究？ ]

オープンソースプロジェクトの種類

オープンソースプロジェクトにはいくつかの種類があります。まず、スタンドアロンのコードで構成される、多種多様なソフトウェアプログラムやライブラリがあります。中には、他のオープンソースプロジェクトに依存しているものもあります。これらのプロジェクトは、特定の目的を果たし、明確なニーズを満たします。このタイプのプロジェクトの例としては、Linuxカーネル、Firefoxウェブブラウザ、LibreOfficeオフィスツールスイートなどが挙げられます。

ディストリビューションは、オープンソース プロジェクトの一種です。ディストリビューションとは、共通の目的を持つ同じソースから公開されるソフトウェアの集合体です。「ディストリビューション」の最も代表的な例は、オペレーティング システムです。Linuxカーネルと多くのユーザーランド コンポーネントを同梱したLinux ディストリビューション（Debian、Fedora Core、Mandriva、Slackware、Ubuntuなど）は数多く存在します。他にも、様々なオペレーティング システム向けのPerl プログラミング言語である ActivePerl や、 Microsoft Windows向けのオープンソース プログラムのCygwinディストリビューションなど、様々なディストリビューションがあります。

BSD系などの他のオープンソースプロジェクトでは、オペレーティングシステム全体、つまりカーネルとそのコアコンポーネント全体のソースコードを単一のリビジョン管理システムで管理し、単一のチームでシステム全体を共同開発しています。これらのオペレーティングシステム開発プロジェクトでは、他のディストリビューションベースのシステムよりもツールが密接に統合されています。

最後に、書籍や独立したドキュメントプロジェクトがあります。これらのプロジェクトは通常、オープンソースソフトウェアパッケージの一部としては提供されません。Linuxドキュメンテーションプロジェクトは、 Linuxオペレーティングシステムのさまざまな側面をドキュメント化する多くのプロジェクトをホストしています。この種のオープンソースプロジェクトの例は他にも数多くあります。

方法

ウォーターフォールモデルのような従来型のソフトウェア開発手法でオープンソースプロジェクトを運営するのは難しい。なぜなら、こうした従来型の手法では、前のフェーズに戻ることができないからだ。オープンソースソフトウェア開発では、プロジェクトの開始前に要件が収集されることは稀で、ロビンズが述べているように、要件はソフトウェア製品の初期リリースに基づいて収集される。[4]要件に加えて、ソフトウェアの初期リリースに基づいてソフトウェア製品の開発を手伝ってくれるボランティアスタッフが増えることもよくある。アブラハムソンらによると、このネットワーキング効果は不可欠で、「導入されたプロトタイプが十分な注目を集めれば、徐々に多くの開発者を引きつけ始める」という。しかし、アブラハムソンらは、コミュニティがクローズドソースソフトウェアのビジネス界と同様に非常に厳しいとも指摘し、「顧客を見つければ生き残れるが、顧客がいなければ死んでしまう」と述べている。[5]

フゲッタ[6]は、「ラピッドプロトタイピング、漸進的かつ進化的開発、スパイラルライフサイクル、ラピッドアプリケーション開発、そして最近ではエクストリームプログラミングやアジャイルソフトウェアプロセスは、プロプライエタリソフトウェアにもオープンソースソフトウェアにも同様に応用できる」と主張している。また、彼はエクストリームプログラミングがオープンソースソフトウェア開発に極めて有用な手法であると指摘している。より一般的には、すべてのアジャイルプログラミング手法は、その反復的で漸進的な特徴から、オープンソースソフトウェア開発に適用できる。その他のアジャイル手法は、オープンソースソフトウェア開発とクローズドソースソフトウェア開発の両方に同様に有用である。例えばインターネットスピード開発は、分散開発の原則を採用しているため、オープンソースソフトウェア開発に適している。インターネットスピード開発では、地理的に分散したチームが「24時間体制で作業」する。この手法は、主に大規模なクローズドソース企業に採用されているが（異なるタイムゾーンに開発センターを置くことができるのは彼らだけであるため）、大規模なボランティアグループによって開発されたソフトウェアは、当然ながら開発者がすべてのタイムゾーンに分散する傾向があるため、オープンソースプロジェクトにも同様に有効である。

ツール

コミュニケーションチャネル

オープンソースプロジェクトの開発者とユーザーは、必ずしも全員がプロジェクトに近接して取り組んでいるわけではありません。そのため、何らかの電子的なコミュニケーション手段が必要です。オープンソースの開発者とユーザーの間では、電子メールが最も一般的なコミュニケーション手段の一つです。多くの場合、電子メールのメッセージが関係者全員に一度に届くように、メーリングリストが使用されます。これにより、メンバーの少なくとも1人が返信できるようになります。リアルタイムのコミュニケーションを実現するために、多くのプロジェクトでは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などが挙げられます。[要出典]

バグトラッカーとタスクリスト

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

テストおよびデバッグツール

OSSプロジェクトは頻繁に統合が行われるため、システム統合時のテストを自動化するツールが活用されています。そのようなツールの一例として、Tinderboxが挙げられます。Tinderboxは、OSSプロジェクトの参加者がシステム統合中にエラーを検出できるようにします。Tinderboxは継続的なビルドプロセスを実行し、問題のあるソースコードの部分と、その問題が発生するプラットフォームをユーザーに通知します。[7]

デバッガとは、他のプログラムをデバッグ（場合によってはテストや最適化）するために使用されるコンピュータプログラムです。GNUデバッガ（GDB）は、オープンソースソフトウェア開発で使用されるデバッガの一例です。このデバッガはリモートデバッグ機能を備えているため、オープンソースソフトウェア開発に特に適しています。[要出典]

メモリリークツールまたはメモリデバッガは、メモリリークやバッファオーバーフローを検出するためのプログラミングツールです。メモリリークとは、コンピュータプログラムが不要になったメモリを解放できないことで発生する、不必要なメモリ消費の一種です。Mozillaが使用するメモリリーク検出ツールの例としては、XPCOM Memory Leak Toolsが挙げられます。検証ツールは、コードが指定された構文に準拠しているかどうかを確認するために使用されます。検証ツールの例としては、Splintが挙げられます。[要出典]

パッケージ管理

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

プロジェクトの宣伝

ソフトウェア ディレクトリとリリース ログ:

  1. フリーソフトウェアディレクトリ

記事:

  1. Linuxウィークリーニュース
  2. IBM デベロッパーワークス

参照

参考文献

  1. ^ Raymond, ES (1999). The Cathedral & the Bazaar . O'Reilly http://www.catb.org/~esr/writings/cathedral-bazaar/ より引用.
  2. ^ Bar, M. & Fogel, K. (2003). CVSによるオープンソース開発、第3版. Paraglyph Press. ( ISBN 1-932111-81-6）
  3. ^ Sharma, S., Sugumaran, V. & Rajagopalan, B. (2002).ハイブリッドオープンソースソフトウェアコミュニティ構築のためのフレームワーク. Information Systems Journal 12 (1), 7-25.
  4. ^ Robbins, JE (2003).「オープンソースソフトウェアエンジニアリング（OSSE）ツールの導入によるOSSEプラクティスの導入」『バザールを理解する：オープンソースとフリーソフトウェアの展望』2003年秋
  5. ^ Abrahamsson, P., Salo, O. & Warsta, J. (2002).アジャイルソフトウェア開発手法：レビューと分析. VTT Publications.
  6. ^ Fuggetta, Alfonso (2003). 「オープンソースソフトウェアの評価」.システムとソフトウェアジャーナル. 66 (1): 77– 90. doi :10.1016/S0164-1212(02)00065-1.
  7. ^ abc 「25歳のティム・バーナーズ＝リーのウェブ活動：過去、現在、そして未来」Wired UK。
  8. ^ 「Gitの素晴らしさ - Linux Foundation」www.linuxfoundation.org . 2023年8月25日閲覧。

さらに読む

  • カバナ、ポール（2004）『オープンソースソフトウェア：実装と管理』ソフトウェア開発、アムステルダム、ボストン：エルゼビア・デジタル・プレス、ISBN 978-1-55558-320-0。
  • フェラー、ジョセフ編 (2005). 『フリーソフトウェアとオープンソースソフトウェアの展望』ケンブリッジ、マサチューセッツ州: MIT 出版. ISBN 978-0-262-06246-6。
  • コッホ、ステファン編 (2005).フリー・オープンソース・ソフトウェア開発ハーシー、ペンシルバニア州: Idea Group Publ. ISBN 978-1-59140-370-8。
  • フォーゲル、カール (2005). 『オープンソースソフトウェアの制作：成功するフリーソフトウェアプロジェクトの運営方法』（第1版）. 北京; セバストポル、カリフォルニア州: O'Reilly. ISBN 978-0-596-00759-1. OCLC  62322583。
  • スコット・P・ミューア（2005年）『オープンソースソフトウェア』Library Hi Tech、マーク・レゴット著。ブラッドフォード：エメラルド・パブリッシング・リミテッド。ISBN 978-1-84544-877-6。
  • フェラー、ジョセフ (2007).オープンソースの開発、採用、革新：IFIPワーキンググループ2. 13 オープンソースソフトウェアに関する会議、2007年6月11日～14日、アイルランド、リムリック。IFIP情報通信技術の進歩、ブライアン・フィッツジェラルド、ウォルト・スカッキ、アルベルト・シリッティ共著。ニューヨーク州ニューヨーク：シュプリンガー。ISBN 978-0-387-72485-0。
  • Sowe, Sulayman K.; Stamelos, Ioannis G.; Samoladas, Ioannis M. 編 (2008). 『フリーソフトウェアとオープンソースソフトウェアの新たな実践』 Hershey: IGI Pub. ISBN 978-1-59904-210-7. OCLC  84838909。
  • フォーゲル、カール（2009年）『オープンソースソフトウェアの制作：フリーソフトウェアプロジェクトを成功させる方法』セバストーポル：オライリーメディア社ISBN 978-0-596-00759-1。
  • エンガード、ニコール・C. (2010). 『図書館のための実践的オープンソースソフトウェア』 . Chandos情報プロフェッショナルシリーズ. オックスフォード: Chandos Publishing. ISBN 978-1-84334-585-5。
  • タッカー、アレン・B、モレリ、ラルフ、デ・シルバ、チャミンドラ (2012)。『ソフトウェア開発：オープンソースアプローチ』、チャップマン・アンド・ホール/CRC『ソフトウェア工学とソフトウェア開発におけるイノベーション』、ボカラトン：チャップマン・アンド・ホール/CRC、ISBN 978-1-4398-1290-7。
  • ハフ、ゴードン（2021年）『オープンソースがソフトウェアを食い尽くす：オープンソース運動の理解とそれ以上の事実』（第2版）バークレー、カリフォルニア州：Apress LP ISBN 978-1-4842-6799-8。