
ソフトウェア開発において、フォークとは既存のコードベースを複製して作成され、一般的にはその後オリジナルとは独立して変更されるコードベースのことである。フォークから構築されたソフトウェアは、最初はオリジナルコードから構築されたソフトウェアと同一の動作をするが、ソースコードが次第に変更されるにつれて、結果として得られるソフトウェアはオリジナルと比較してますます異なる動作をする傾向がある。フォークは分岐の一形態だが、一般的にはフォークされたファイルをリポジトリではなくオリジナルとは別に保存する。コードベースをフォークする理由としては、ユーザーの好み、オリジナルソフトウェアの開発の停滞または中止、開発者コミュニティ内の分裂などがある。 [ 1 ]プロプライエタリソフトウェア( Unixなど)を明示的な許可なしにフォークすることは著作権法で禁止されているが、フリーソフトウェアやオープンソースソフトウェアは定義上、許可なくフォークできる。
フォークという言葉は、14世紀にはすでに「枝分かれする、別々の道を行く」という意味で使われていました。[ 2 ]
ソフトウェア開発の文脈では、フォークは、1980年代にエリック・オールマンによってソースコード管理システムの文脈で、リビジョン管理ブランチを作成するという意味で使用されていました。[ 3 ]
ブランチを作成すると、プログラムのバージョンが「フォーク」されます。
この用語は1983年までにUsenetで使用され、議論のトピックを移動するためのサブグループを作成するプロセスを指していました。[ 4 ]
Lucid Emacs(現XEmacs)(1991年)やBerkeley Software Distributions(BSD)(1993-1994年)の誕生当初に、コミュニティの分裂の意味で「フォーク」が使われたという記録はないが、ラス・ネルソンは1993年にこの意味で「粉砕」という言葉を使った(ジョン・ギルモアの発言として)。[ 5 ] 1995年には、XEmacsの分裂を説明するために「フォーク」という言葉が使われ、 [ 6 ] 1996年までにGNUプロジェクトで理解される用法となった。[ 7 ]
この言葉は、実行中のプロセスを2つに分割するfork()システムコールにも同様に使用されます。通常、これは異なるタスクを並行して実行できるようにするためです。 [ 8 ]
フリーソフトウェアとオープンソースソフトウェアは、フリーソフトウェアの定義とオープンソースの定義の両方に従って、現在ソフトウェアを開発、管理、または配布している人々の事前の承認なしに合法的にフォークすることができます。[ 9 ]
改変したバージョンのコピーを他者に配布する自由(自由3)。これにより、コミュニティ全体があなたの変更の恩恵を受ける機会を得ることができます。ソースコードへのアクセスは、このための前提条件となります。
3. 派生作品: ライセンスは、改変および派生作品を許可し、元のソフトウェアのライセンスと同じ条件で配布することを許可する必要があります。
フリーソフトウェアでは、異なる目標や性格の不一致による分裂からフォークが発生することがよくあります。フォークでは、両者はほぼ同一のコードベースを前提としますが、通常は、より大きなグループ、またはウェブサイトを管理しているグループのみが、元の完全な名前と関連するユーザーコミュニティを保持します。そのため、フォークには評判の低下が伴います。[ 9 ]異なるチーム間の関係は、友好的なものになることもあれば、非常に険悪なものになることもあります。一方、友好的なフォーク、またはソフトフォークとは、競合する意図はなく、最終的には元のチームと合併することを望むフォークです。
エリック・S・レイモンドは、エッセイ『ノウアスフィアの開拓』 [ 12 ]の中で、「フォークの最も重要な特徴は、後にコードを交換できない競合するプロジェクトを生み出し、潜在的な開発者コミュニティを分裂させることだ」と述べています。彼はジャーゴンファイルの中で次のように述べています。[ 13 ]
フォークは悪事とみなされています。それは、将来的に多くの労力が無駄になることを意味するだけでなく、フォークは、正当性、継承、そして設計の方向性をめぐって後継グループ間で多くの争いや敵意を伴う傾向があるためです。フォークに対しては深刻な社会的圧力があります。その結果、大きなフォーク(Gnu-Emacs / XEmacsの分裂、 386BSDグループの3つの子プロジェクトへの分裂、そして短命に終わったGCC/EGCSの分裂など)は非常に稀であり、ハッカーの伝説の中で個別に記憶されています。
デビッド・A・ウィーラーは[ 9 ]フォークの4つの可能な結果を例とともに指摘している:
分散リビジョン管理(DVCS)ツールは、「フォーク」という用語のより感情的でない用法を普及させ、「ブランチ」との区別を曖昧にしています。[ 14 ] MercurialやGitなどのDVCSでは、プロジェクトに貢献する通常の方法は、まずメインリポジトリから独立したリポジトリの個人用ブランチを作成し、後で自分の変更をそのブランチに統合することです。GitHub 、Bitbucket、Launchpadなどのサイトは、独立したブランチを明示的にサポートする無料のDVCSホスティングを提供しているため、ソースコードリポジトリをフォークする際の技術的、社会的、および金銭的な障壁は大幅に軽減されており、GitHubはプロジェクトへのこの貢献方法を表す用語として「フォーク」を使用しています。
フォークされたソフトウェアは、元のソフトウェアが3.0、4.0、5.0といったバージョンであっても、プログラムの初期バージョンに通常使用される0.0.1、0.1、1.0といった番号からバージョン番号を振り直すことがよくあります。ただし、フォークされたソフトウェアが元のプロジェクトの代替として設計されている場合は例外となることがあります。例えば、 MySQLのMariaDB [ 15 ]やOpenOffice.orgのLibreOfficeなどが挙げられます。
BSDライセンスはフォークがプロプライエタリなソフトウェアになることを許可しており、コピーレフト支持者は商業的インセンティブによってプロプライエタリ化がほぼ不可避になると主張する。(ただし、コピーレフト ライセンスは、貢献者ライセンス契約の形でプロプライエタリな許諾とのデュアル ライセンスによって回避できる。) 例としては、 macOS (プロプライエタリのNeXTSTEPとオープンソースのFreeBSDに基づく)、CedegaとCrossOver ( Wineのプロプライエタリ フォークだが、CrossOver は Wine を追跡し、大きく貢献している)、EnterpriseDB ( PostgreSQLのフォークで、Oracle 互換機能を追加[ 16 ] )、プロプライエタリ ESM ストレージ システムを備えた PostgreSQL [ 17 ] 、 Netezza の[ 18 ]プロプライエタリで拡張性の高い PostgreSQL 派生製品などがあげられる。これらのベンダーの中には、コミュニティ プロジェクトに変更を還元するものもあれば、変更を自社の競争上の優位性として保持するものもある。
プロプライエタリソフトウェアでは、著作権は通常、個々のソフトウェア開発者ではなく、採用企業が保有します。そのため、プロプライエタリコードは、所有者がウィンドウ版とコマンドライン版など2つ以上のバージョンを開発する必要がある場合、またはIBM PC互換機とMacintoshコンピュータ用のワードプロセッサなど、異なるオペレーティングシステム用のバージョンを開発する必要がある場合に、フォークされるのが一般的です。一般的に、このような内部フォークでは、一方のプラットフォームに慣れたユーザーがもう一方のプラットフォームでも生産性を維持したり、作成したドキュメントを共有したりできるように、プラットフォーム間で同じ外観、操作性、データ形式、動作を実現することに重点が置かれます。これはほとんどの場合、より大きな市場シェアを獲得し、フォークによって発生した関連する追加開発コストを回収するための経済的な決定です。
この種のものではない注目すべきプロプライエタリフォークは、プロプライエタリUnixの多くの変種である。ほとんどすべてがライセンスに基づいてAT&T Unixから派生しており、すべて「Unix」と呼ばれているが、相互に互換性がますますなくなってきている。[ 19 ] Unix戦争を参照 。
フォークはオープン開発モデルの自然な一部であり、GitHubではほぼすべてのページに「独自のコピーをフォーク」ボタンが配置されていることで有名です。また、Nyman, Linus (2015). Understanding Code Forking in Open Source Software (PhD). Hanken School of Economics. p. 57. hdl : 10138/153135も参照のこと。
実務家はこれまでフォークをかなり狭義に定義していましたが、[...] 現在ではこの用語ははるかに広義に使用されているようです。従来はブランチ、新しいディストリビューション、コードの断片化、疑似フォークなどと呼ばれていた動作が、今では一部の開発者によってフォークと呼ばれることもあります。これは、GitHubによるフォークという用語の広義な定義と使用に少なからず起因していると思われます。