オープンソースソフトウェアの経験がある方なら、「フォーク」と「ディストリビューション」という言葉を様々な場面で耳にしたことがあるでしょう。多くの人がこの2つの言葉の違いを明確に理解していないため、この記事ではその違いを明確に説明します。

[[412660]]

（LCTT 翻訳者注: 前回の取り組みに続き、バージョン管理ワークフローでは、同じリポジトリ内の「ブランチ」との混同を避けるため、「フォーク」を「レプリカ」に翻訳することを提案しました。ただし、プロジェクトやリリースのコンテキストではそのような混乱は発生せず、慣例的に「ブランチ」と呼ばれています。）

まず、いくつかの定義

ブランチとリリースの微妙な違いと類似点を説明する前に、まずいくつかの重要な関連概念を定義しましょう。

オープンソース ソフトウェアとは、次の特性を持つソフトウェアを指します。

• 特定のライセンス制限の下で、ソフトウェアはすべての人に無料で配布されます。
• 特定のライセンス制限の下では、ソフトウェアのソースコードは誰でも閲覧および変更できます。

オープンソース ソフトウェアは、次のように使用できます。

• バイナリまたはソースコード形式でのダウンロードは通常無料です。（例：Eclipse開発環境）
• 営利企業の製品であるため、ユーザーにサービスを提供して料金を請求する場合もあります。(例: Red Hat 製品)
• 独自のソフトウェア ソリューションに組み込まれています (一部のスマートフォンやブラウザーでフォントを表示するために使用されている Freetype ソフトウェアなど)。

フリー・オープンソース・ソフトウェア（FOSS）は、必ずしも「無料」または「無償」である必要はありません。これは、ソフトウェアライセンスに準拠している限り、ソフトウェアを自由に配布、改変、研究、使用できることを意味します。ソフトウェア配布者がソフトウェアの価格を設定する場合もあります。例えば、LinuxはFedora、CentOS、Gentooのような無料ディストリビューションの場合もあれば、Red Hat Enterprise Linux（RHEL）やSUSE Linux Enterprise Edition（SLES）のような有料ディストリビューションの場合もあります。

コミュニティとは、オープンソースプロジェクトで共同作業を行うグループまたは個人を指します。契約を遵守する限り、誰でも、あるいはどのグループでも、コード／ドキュメント／テストスイートの作成またはレビュー、会議の運営、ウェブサイトの更新などを通じて、オープンソースプロジェクトに貢献できます。例えば、Openhub.netのウェブサイトでは、政府機関、非営利団体、営利企業、教育機関などの組織が、様々なオープンソースプロジェクトに貢献している様子を見ることができます。

オープンソースプロジェクトとは、共同開発、ドキュメント、テスト結果の集合体です。ほとんどのプロジェクトでは、コード、ドキュメント、テストファイル、そして現在開発中のファイルを保存するための中央リポジトリが構築されています。

ディストリビューションとは、オープンソースプロジェクトのバイナリまたはソースコードのコピーを指します。例えば、CentOS、Fedora、Red Hat Enterprise Linux (RHEL)、SUSE Linux、UbuntuはすべてLinuxプロジェクトのディストリビューションです。Tectonic、GoogleのKubernetes Engine (GKE)、AmazonのContainer Service、Red HatのOpenShiftはすべてKubernetesプロジェクトのディストリビューションです。

オープンソースプロジェクトの商用ディストリビューションは、しばしば製品と呼ばれます。したがって、Red Hat OpenStack Platform は Red Hat OpenStack の製品です。これはアップストリーム OpenStack プロジェクトのディストリビューションであり、100% オープンソースです。

トランクとは、オープンソース プロジェクトを開発するコミュニティの主なワークフローです。

オープンソース ブランチ フォークは、オープンソース プロジェクトのメイン ブランチのバージョンであり、メイン ブランチから分離された独立したワークフローです。

したがって、ディストリビューションはブランチとは異なります。ディストリビューションは、アップストリームプロジェクトのパッケージであり、ベンダーによって提供され、多くの場合製品として販売されます。ただし、ディストリビューションのコアコードとドキュメントは、アップストリームプロジェクトのバージョンと一貫性が保たれます。ブランチ、およびブランチに基づくディストリビューションでは、コードとドキュメントのバージョンがアップストリームプロジェクトと異なります。アップストリームプロジェクトからブランチを作成するユーザーは、独自のブランチを維持する必要があるため、アップストリームコミュニティとの共同作業のメリットを享受できなくなります。

ソフトウェアの分岐をさらに説明するために、動物の移動を例に挙げてみましょう。クジラやアシカは北極からカリフォルニアやメキシコへ、オオカバマダラはアラスカからメキシコへ、ツバメをはじめとする北半球の多くの鳥は冬を過ごすために南へ渡ります。移動を成功させる鍵は、群れの中のすべての動物が協力し、リーダーに従い、餌と隠れ場所を見つけ、迷子にならないことです。

一人で行動することのリスク

鳥、オオカバマダラ、クジラなどは、群れから遅れをとると、集団から得られる保護や、食べ物、隠れ場所、目的地がどこにあるかを知ることなど、多くの利点を失います。

同様に、アップストリーム バージョンからブランチを取得し、それを独自に保守するユーザーや組織も、次のようなリスクに直面します。

• コードが異なるため、ブランチユーザーはアップストリームバージョンに基づいてコードを更新できません。これは技術的負債と呼ばれます。ブランチでコードが変更されるほど、そのブランチをアップストリームプロジェクトに再統合するために必要な時間とコストが増加します。
• ブランチユーザーは、安全性の低いコードを実行する可能性があります。コードの違いにより、オープンソースコードの脆弱性がアップストリームコミュニティによって発見され修正された場合でも、ブランチバージョンのコードには修正の恩恵が及ばない可能性があります。
• ブランチ化されたバージョンのユーザーは、新機能の恩恵を受けられない可能性があります。多くの組織や個人によってサポートされているアップストリームバージョンは、アップストリームプロジェクトのすべてのユーザーにメリットをもたらす多くの新機能を生み出します。組織がアップストリームからブランチ化した場合、コードの違いにより新機能を組み込めない可能性があります。
• 他のソフトウェアパッケージとの統合がうまくいかない可能性があります。オープンソースプロジェクトは単一のプロジェクトとして開発されることは少なく、他のプロジェクトとパッケージ化されてソリューションを形成することがよくあります。分岐したコードは、その開発者が上流の参加者と連携していないため、他のプロジェクトとの統合がうまくいかない可能性があります。
• ハードウェアプラットフォームで認定されていない場合があります。ソフトウェアパッケージは通常、ハードウェアプラットフォームで認定されているため、問題が発生した場合、ハードウェアエンジニアとソフトウェアエンジニアが協力して問題の根本原因を特定し、解決することができます。

簡単に言えば、オープンソースディストリビューションとは、上流の複数の組織が共同で開発し、ベンダーによって販売・サポートされる素材をパッケージ化したコレクションです。一方、ブランチはオープンソースプロジェクトにおける独立した開発ワークフローであり、上流コミュニティ内での共同作業の成果を享受できない場合があります。