В первый раз с санкциями я столкнулся пять лет назад. Они не выглядели шумными, с публичными заявлениями. Просто одна крупная западная компания перестала продавать компонент другой крупной западной компании. Без объяснения причин. Это привело к потерям в несколько сотен тысяч долларов. Но закончилось относительно хорошо, так как компонент не был критичен, и его удалось заменить. Когда похожая ситуация повторилась через несколько лет, она ударила сильнее, поскольку «санкционированный» модуль уже участвовал в критической части функциональности. Это научило меня всегда учитывать риски отключения независимо от продукта или страны.

Идеально устойчивый продукт тот, который разрабатывается полностью собственными силами, с использованием открытых технологий. Но если рассматривать рынок в целом, то какие особенности ПО делают его наиболее независимым от ограничений.

Использование code escrow

Code Escrow (депонирование исходного кода) – это размещение исходного кода продукта в депозитарии, вместе со всеми компонентами и инструкциями, необходимыми для сборки. Более развернуто я описал данный подход в статьях: основной, и дополнении.

Условиями получения доступа к исходному коду являются, например, невозможность вендора обслуживать продукт, или ликвидация компании. Но могут быть установлены и другие правила. Проецируя на текущую ситуацию, при уходе компании с рынка вы можете получить доступ к исходникам.

Обычно на сайте производителей вы сходу не найдете информации, подписывают ли они такой контракт на сервис. Причина – это не массовая услуга, и предлагается только крупным клиентам. При этом каждый крупный производитель софта старается размещать свой исходный код, или имеет процедуры для этого.

Сервис явно имеет ценность для покупателя. На практике у меня было 2 клиента, для которых наличие code escrow являлось критическим условием. Тем не менее, величина ценности не максимальна. Факторы, снижающие значение:

• в исходном коде надо разбираться, то есть иметь штат разработчиков,

• для сборки вам потребуются соответствующие инструменты, а также компоненты, которые используются в продукте,

• услуга дорогая, стоимость ее перекладывается на плечи клиентов.

Архитектура на неконтролируемых третьей стороной технологиях

Даже имея доступ к исходникам, в случае ухода компании у вас остается риск того, что и производитель платформы тоже по какой-то причине перестанет с вами работать. Тут вариант практически один. Это фокус на различных открытых и royalty-free технологиях: Linux против Windows, Android против iOS, использование AV1 вместо HEVC и так далее.

Здесь в полной мере сработало то, ради чего открытые лицензии и создавались. Это отсутствие vendor lock-in и обмен технологиями, а не бесплатность.

Ценность данного подхода для клиента высока, если он сам ориентирован на такой же технологический стек. И отрицательна, если используются определенные, не открытые технологии.

Для тех кто разрабатывает продукты, в статье "Two-Sided Competition of Proprietary vs. Open Source Technology Platforms and the Implications for the Software Industry" приводится анализ и сравнение двух подходов.

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

Очевидно, что если часть приложения исполняется на стороне, которая не принадлежит вам, то при отключении серверов продукт перестает работать. Подавляющее большинство крупных клиентов требует, чтобы критичное ПО работало локально или развертывалось в частном облаке. Не только, для контроля, но и для обеспечения безопасности данных.

Это означает, что все *aaS подходы являются рискованными с точки зрения устойчивости. Интересно, что все SLA описывают доступность до долей процента, но ни один не включает в себя устойчивость к санкциям. Скорее наоборот, действия правительств могут относить к форс-мажору.

Возможность развернуть решение у себя добавляет ценность продукту. Но есть и факторы, снижающие ее, это:

• затраты на инфраструктуру и обслуживание,

• пользователь становится зависимым не от сервиса, а от оборудования; если над оборудованием нет контроля, то риск прекращения обслуживания остается.

Бессрочная лицензия, а не подписки

Подпискам удалось вытеснить бессрочные лицензии. Это приносит больше денег производителям ПО. Бессрочные лицензии либо совсем убираются, либо на них устанавливается заградительная цена.

Бессрочное владение – это безусловно ценность для клиента. Производители со своей стороны, чтобы иметь прогнозируемый денежный поток могут продавать сервисные контракты, как они делали раньше. Что вместе со страховкой code escrow очень хорошее предложение.

Контракт, предполагающий использование старых версий после разрыва

Этот пункт относится к компонентам, которые используются для разработки других продуктов или решений. Что произойдет, если вендор не продлит контракт с вами. В худшем случае вам придется остановить распространение всех версий вашего продукта в котором используется компонент.

В штате команды должен быть самый злобный и въедливый юрист. В договор необходимо включать пункт, который разрешает распространение всех ранее выпущенных версий компонента в составе вашего решения, если контракт не будет продлен. В лучшем случае неограниченно по времени.

Портрет идеального устойчивого ПО

Соберем характеристики устойчивого к санкциям ПО

• В стоимость лицензии, а на самом деле в стоимость сервисного контракта, входит депонирование исходного кода.

• Продукт разработан на открытых технологиях.

• Архитектура продукта не использует внешних сервисов, и позволяет устанавливать его локально или в частном облаке.

• Продукт предлагается по бессрочной лицензии.

• Для компонентов, в контракте есть правила, которые позволяют использовать его старые версии и после прекращения.

Когда я взглянул на эти требования со стороны, то мне показалось, что я вижу типичный продукт 1985 – 2005 годов. Интересно перекликается и с другими технологиями. Хочешь хранить информацию долго и с гарантией прочтения в любое время – пиши на бумаге.

Взгляд со стороны вендора

Производитель ПО будет делать то, что приносит деньги. Если рынок будет требовать продукты, которые устойчивы к уходу с рынка, то такое предложение появится. Тут выбор за всеми нами.

Нужно ли играть на опережение? По моей оценке, по пунктам, которые не связаны с технологическим стеком да. Даже можно вернуться к бессрочным лицензиям, продавая по подписке сервисные контракты и по-прежнему считать любимые метрики – количество активных пользователей за период. Сами лицензионные модели могут быть сложнее. Включать в себя модели по рабочим местам, по утилизируемым ресурсам, а также зависеть от других условий. Например исследование, которое оценивает две модели в зависимости от параметров: Perpetual Versus Subscription Licensing Under Quality Uncertainty and Network Externality Effects.

С технологическим стеком сложнее. Клиент приобретает продукт под свою инфраструктуру. Если там проприетарные платформы, то не получится продать неработающее решение.

Все эти пункты относятся к сегменту b2b. На потребительском b2c рынке вопрос стоит менее остро из-за наличия разных предложений, и не критичности. Но на бессрочные лицензии я бы согласился. Да и использование облаков у меня уже не вызывает такой радости, хотя пару лет назад на противников облачных хранилищ я смотрел с удивлением. А сейчас долго вытаскиваю архивы.