ソフトウェア開発におけるフォーク（英語: fork）即ち派生とは、あるソフトウェアパッケージのソースコードから分岐して、別の独立したソフトウェアを開発することである。
フリーソフトウェアやオープンソースソフトウェアでは、ライセンス上、原作者の許可なしにフォークが可能である。
ブランチング
多くのプロジェクトでは、バグ修正のみが行われる安定版（英: stable version）あるいはリリース版（英: release version）と、新機能を取り込む開発版（英: development version）とを別に用意している。これもフォークの一種である。このようなフォークは「ブランチ」と呼ばれるが、これは「フォーク」という言葉にネガティブなニュアンスがあるのと、この方法がソフトウェア工学における「ブランチ（英: branching）」に似ているためである。
フリーソフトウェア
フリーソフトウェアにおけるフォークの原因としては、目標の食い違いや個人的な対立などがある。フォークが発生した場合、開発グループがほぼ同じ内容のコードベースを使用するが、ソフトウェアの元々の名前とユーザーコミュニティについては、大抵の場合大きい方のグループ（または元々のアーキテクトの所属するグループ）が引き継ぐ。従って、フォークはソフトウェアの評判の点では不利益となる。分岐した開発チーム間の関係は、良好であったり（例：UbuntuとDebian）、対立していたり（例：X.Org ServerとXFree86、cdrtoolsとcdrkit、WebKitとBlink）、全く交流がなかったり（例：Linuxディストリビューションのほとんど）と様々である。
フォークはフリーソフトウェアによってもたらされる自由の一種であると考えることもできるが、開発の成果が重複する、利用者がどちらを使うべきか迷ってしまうなどの悪い点もある。各グループが協調してリソースを共有することも可能ではあるが、フリーソフトウェアライセンスではこの点について規定がなく、合意がとれた場合にしか行われない。そのため、開発作業は他のフォークとの差別化に重点を置いて行われることが多い。
1997年に公開された「伽藍とバザール[1]」では、"フォークの最も重要な特性とは、コードのやりとりのない競合プロジェクトを生み出し、潜在的な開発者コミュニティを分裂させてしまうことである"としている。しかし、現在ではこの定義は一般的ではない。
場合によっては、フォークが元のプロジェクトに併合されたり、元のプロジェクトに置き代わったりすることもある。EGCS (the Experimental/Enhanced GNU Compiler System) は元々GCCからのフォークであったが、オリジナルのプロジェクトよりも活発に開発が行われ、最終的にはオフィシャルのGCCプロジェクトとしてお墨付を得るに至った。この効果を意図的に狙ったフォークもあり、例えばMozilla FirefoxはMozillaの非公式プロジェクトであったが、開発の中心はMozilla SuiteからすぐにFirefoxに移った。
問題点
ジャーゴンファイルではフォークの問題点が以下のように述べられている。:
- フォークは「良くないこと」であると考えられている。理由として、フォークの結果多くの開発の労力が浪費されるという点だけでなく、本家争い、引き継ぎ、設計の方向性などについて、後継となるグループ間で激しい口論が行われる点がある。フォークには強い社会的圧力がついてまわる。そのため、ハッカー伝承に残るほど大きなフォーク（例えばGNU EmacsとXEmacsの分裂、386BSDの3グループへの分裂、短命に終わったGCCとEGCSの分裂）は非常に少ない。
フォークの表明自体は簡単だが、そこには独立した開発とサポートを続けるに足る十分な取り組みが要求される。十分なリソースなしにフォークを行えば、プロジェクトはすぐに活動休止状態に陥ってしまう。例えば、GNOMEからフォークしたGoneMEはある程度の知名度を得たにもかかわらず、すぐに開発中止となってしまった。大きな成功を収めたフォークとしては例えば X.Org X11サーバが挙げられる。X.Orgは開発者とユーザからの広範に渡る支援を得て、Xの開発スピードを上げることができた。
プロプライエタリソフトウェア
通常、プロプライエタリソフトウェア の著作権は個々の開発者ではなく雇用者側の組織が保持する。従って、例えば経営者が複数のバージョン（GUIバージョンとコマンドラインバージョンや、複数のオペレーティングシステム用のバージョン、例えばワープロソフトのIBM PC互換機バージョンとMacintoshバージョンなど）を開発しようとした場合など、プロプライエタリなコードではフォークがより発生しやすい。一般的に、これらの内部的なフォークでは、ルックアンドフィール・データフォーマット・ソフトウェアの振る舞いなどをできる限り同じにすることに力が向けられている。これは、一つのバージョンに精通したユーザが別のバージョンでも高い生産性を発揮したり、作成したドキュメントを複数バージョン間で共有したりできるための配慮である。多くの場合、このようなフォークはマーケットシェアの拡大を目的に行われるため、フォークによって発生した開発コストに対する見返りも得られる（ように計画して行われる）。
上記のケースに該当しないフォークとしては、各種のプロプライエタリなUnixが上げられる。これらは全てAT&T Unixから派生しており、全て “Unix” と呼ばれてはいるが、どれも相互互換性を失う方向へ進んでいる。UNIX戦争も参照のこと。
BSDライセンスではフォークしたバージョンがプロプライエタリソフトウェアとなることが許されている。商業的な理由がある場合、ソフトウェアのプロプライエタリ化はほぼ避けられないという意見もある。プロプライエタリなフォークの例としては EnterpriseDB （Oracle互換の機能を備えたPostgreSQLのフォーク）、プロプライエタリなESMストレージシステムと組み合わせて使われる Fujitsu Supported PostgreSQL、Netezza による PostgreSQL の高スケーラビリティ版が挙げられる。これらのベンダーは変更点を本家のプロジェクト側に提供する場合もあるが、競合製品に対する優位性を保つために提供しない場合もある。
その他の有名なフォーク
参考文献
関連項目
|
|---|
|
括弧内の年は正式バージョンのリリース年。†の製品はリリース終了、もしくは更新が長期間途絶えている製品。 |
| ローカルのみ |
| |
|---|
| C/S型 |
|
|---|
| 分散型 |
|
|---|
| 概念 | |
|---|
|
|
