Pull to refresh

Дополнение к теме code escrow – депонированию исходного кода

Reading time2 min
Views1.8K
Недавно я опубликовал статью по теме code escrow – депонированию исходного кода, как страховке для заказчиков. Исходная статья короткая, если вы не читали, то проще быстро пройтись по ней. Но вкратце, code escrow — это процесс размещения исходного кода вашего приложения в стороннем репозитории, к которому заказчик имеет доступ при определенном условии. Обычно это нужно если компания-разработчик уходит с рынка. И это является своеобразной страховкой клиентов.
Эту тему я обсудил не только в комментариях на Хабре, но и вне его. И было несколько интересных вопросов, которые считаю полезным опубликовать вместе с ответами.

Какая версия должна храниться в репозитории?


Практика обычно такая. Устанавливается периодичность загрузки исходников в репозиторий. Например, только мажорные версии. Как только выпускается версия 2, то её исходники тоже загружаются. То есть публикация не по факту продажи, а по факту релиза. Частотность зависит от продукта.
Какая версия доступна клиентам, определяется соглашением с ними. Это может быть всегда последний релиз. Тогда нужно хранить только его. Или же все сборки.

Код устаревает, не факт, что он спустя N лет будет компилироваться при помощи актуальных версий компиляторов/IDE. Что вообще можно реально сделать с кодом 10-15 летней давности?


При публикации надо хранить не только исходники, но и очень детальное описание: ОС, IDE, фреймворки и их версии. Как развернуть окружение.
Обычно речь идёт о ситуациях, когда продукт используется, но по определённым причинам компания больше не может его сопровождать. То есть это не код 10-летней давности. Максимум несколько лет. И на самом деле даже старый код можно собрать.

Почему бы не хранить образ виртуальной машины, на которой будет все необходимое для сборки?


Это правильный подход. Однако распространение образов может быть лицензионно ограничено. Например, нельзя распространять MS Windows и Visual Studio. Если вы используете ПО и утилиты без подобных ограничений, то образы сильно помогут.

Не слишком ли эта редкая ситуация, когда компания внезапно исчезает?


Под термином «исчезает» скрывается несколько типов случаев, которые не такие и редкие. Помимо банкротства, компания может потерять исходники, например после атаки вируса-шифровальщика и бездарном отношении к бэкапам. А также компания разработчик может попасть под санкции. При появлении санкций клиент (как правило, зарубежный) теряет возможность общаться с вендором. В этом случае к репозиторию сохраняется доступ.

И последний, самый провокационный вопрос. Какие у меня гарантии что мой код не утечет на сторону?


Тут как с эскроу счетами. Гарантией служит только то, насколько вы доверяете репозиторию. Однако подумайте, кому на самом деле нужен ваш код. Мой коллега сказал, что он бы и копейки не дал за то, чтобы получить доступ к коду конкурентов. С учетом того, что все алгоритмы и так известны, а разбираться в чужих исходниках удовольствие сомнительное, то ценность стороннего кода невелика. А с учетом того, что это в явном виде неправомерный доступ и имеет последствия, то ценность такого доступа еще ниже.

Если вы не пользовались таким процессом раньше, готовы ли вы начать? Интересно мнение как со стороны разработчика, так и клиента.
Tags:
Hubs:
+3
Comments9

Articles

Change theme settings