Неважно маленькая ли вы команда или большая компания, развиваете ли вы известный на рынке продукт или делаете новый стартап. В какой-то момент к вам придет заказчик с вопросом: «А что произойдет, если вдруг ваша компания закроется?». Ни известное имя, ни размер команды не гарантирует того, что продукт будет существовать и внезапно не исчезнет.
Если продукт не выполняет критические задачи, или используется ограниченно, то потери от перехода на другой софт будут незначительными. А если это большая организация, в которой конкретное ПО выполняет ключевую роль, то нужно иметь страховку. Одной из таких страховок является code escrow – размещение исходного кода вашего приложения в специальном репозитории. Доступ к нему получают заказчики, в случае, если компания перестает существовать.
Code escrow включает в себя два важных элемента: договор на доступ и непосредственно хранилище (третья сторона). Соглашение на доступ ваших клиентов к репозиторию должно быть достаточно подробным, и как правило включать в себя следующие требования:
- условия, при которых компания получает доступ к исходникам;
- определение объекта доступа: одно приложение, версия, или группа;
- обязательство по обновлению исходников и регулярность (мажорная версия, минорная версия или патч).
В российском законодательстве термин «условное депонирование» появился в 2014 году и его можно использовать при оформлении договоров.
Как правильно депонировать исходники. Правильная организация архива включает в себя сам исходный код, который должен компилироваться, и подробные инструкции по развертыванию. Если требуются сторонние компоненты или инструменты, то они должны быть перечислены. Обратите внимание, что распространять сторонние компоненты в виде исходного кода обычно нельзя.
Ведение code escrow затратная процедура. Расходы будут включать в себя оплату третьей стороне за хранение кода, работы по обновлению исходников, работу юристов. Стоимость такого сервиса–страховки можно включать в цену продукта, но чаще всего эскроу оформляется либо отдельным контрактом, либо в составе приоритетной поддержки заказчика. Не каждому клиенту необходимо иметь доступ к исходникам. Также наличие code escrow положительно влияет на имидж компании.
В западных компаниях, особенно в крупных производителях ПО, такой подход применяется чаще чем в российских компаниях. Вариантов провайдеров code escrow service можно найти достаточно. Альтернативой code escrow может быть публикация продукта или основной его части в open source.
На основе своего опыта могу сказать, что чем крупнее ваш клиент, тем важнее роль code escrow, не зависимо от того, устанавливается ли продукт на инфраструктуре или это SaaS.
amarao
Прям так себе и представляю code escrow от гугла. "А если мы решим закопать очередной google reader/hangouts или обанкротиться, то вот вам исходный код".
MikhailZakharov Автор
И мне тоже Google Reader в голову пришел, когда я вспоминал о примерах! Очень это показательный случай. Escrow чаще применяется в b2b.
Хороший пример Blender. Они пошли не по стандартному пути, конечно. Сначала закрытый продукт, а потом open source.
Подумал, что хорошо, что вы привели этот пример. Тут важно рассмотреть, кто именно платит за продукт. В случае с Google Reader выручка шла не от пользователей. Основная группа это рекламодатели. А также сам Google, который мог собирать статистику. Что-то пошло не так, и продукт, как источник прибыли не оправдал себя.
Таким образом иметь escrow или даже передавать что-то в открытый доступ пользователям бессмысленно. Они не являются целевой группой, как ни странно.
petropavel
Так делают. Вон когда-то популярный BitKeeper в версии 2.x обещал, если не ошибаюсь, заплатившим клиентам отдать исходники под GPLv2 если вдруг перестанут его развивать.
Развивать не перестали, но все пользователи дружно ушли на git. И когда BitKeeper через десять лет всё равно открыли всем уже было пофиг.