あなたが小さなチームであろうと大企業であろうと、市場で有名な製品を開発しているのか、新しいスタートアップを始めているのかは関係ありません。ある時点で、顧客は「あなたの会社が突然閉鎖した場合はどうなりますか？」という質問であなたのところに来るでしょう。有名な名前もチームの規模も、製品が存在し、突然消えないことを保証するものではありません。
製品が重要なタスクを実行しない場合、または限られた範囲で使用される場合、別のソフトウェアへの切り替えによる損失はわずかです。また、特定のソフトウェアが重要な役割を果たす大規模な組織の場合は、保険をかける必要があります。そのような保険の1つは、コードエスクローです。アプリケーションのソースコードを特別なリポジトリに配置します。会社が存在しなくなった場合、顧客はそれにアクセスできます。
コードエスクローには、アクセス契約とストレージ自体（サードパーティ）という2つの重要な要素が含まれています。クライアントのリポジトリへのアクセスに関する合意は非常に詳細である必要があり、通常は次の要件が含まれています。
- 会社がソースにアクセスするための条件。
- アクセスオブジェクト定義：1つのアプリケーション、バージョン、またはグループ。
- ソースと規則性（メジャーバージョン、マイナーバージョンまたはパッチ）を更新する義務。
ロシアの法律では、「エスクロー」という用語は2014年に登場し、契約を結ぶときに使用できます。
ソースを適切にデポジットする方法。アーカイブの正しい構成には、コンパイルする必要のあるソースコード自体、および展開の詳細な手順が含まれます。サードパーティのコンポーネントまたはツールが必要な場合は、それらをリストする必要があります。通常、サードパーティのコンポーネントをソースコードとして再配布することはできないことに注意してください。
コードエスクローのメンテナンスはコストのかかる手順です。費用には、コードストレージ、ソースの更新、および法的な作業に対するサードパーティへの支払いが含まれます。このような保険サービスの費用は製品の価格に含めることができますが、ほとんどの場合、エスクローは個別の契約として、または顧客の優先サポートの一部として形式化されます。すべてのクライアントがソースにアクセスする必要があるわけではありません。また、コードエスクローの存在は、会社のイメージにプラスの影響を及ぼします。
欧米の企業、特に大規模なソフトウェアメーカーでは、このアプローチはロシアの企業よりも頻繁に使用されています。コードエスクローサービスプロバイダーにはたくさんのオプションがあります。コードエスクローの代わりに、製品またはその主要部分をオープンソースで公開することもできます。
私の経験からすると、製品がインフラストラクチャにインストールされているかSaaSであるかに関係なく、クライアントが大きいほど、コードエスクローの役割が重要であると言えます。