Реестровый софт против open source: сравнение по стоимости эксплуатации

MAATRIX

Выбор между продуктом из реестра отечественного ПО и open source-альтернативой почти всегда сводится к одной фразе: «реестровое дороже». Это правда, только если сравнивать ценник лицензии с нулём в графе «open source» и на этом остановиться. Сравнивать нужно полную стоимость владения на весь срок эксплуатации — лицензии, зарплаты специалистов, риск миграции при смене решения и, отдельной строкой, требования комплаенса, которые иногда делают экономический расчёт вообще неприменимым. Разберём эти четыре фактора по порядку и дадим методику расчёта для своего случая.

Что такое реестр отечественного ПО и почему считать нужно по TCO

Реестр российского программного обеспечения ведёт Минцифры — это перечень продуктов, формально признанных отечественными: они дают преференции при госзакупках по 44-ФЗ и 223-ФЗ, а для ряда организаций фактически становятся обязательными. Попадание в реестр — вопрос юридического статуса, а не качества кода: продукт может быть форком известного open source-проекта с коммерческой обвязкой или полностью самостоятельной разработкой — реестр не делает между ними различия, если формально выполнены критерии происхождения кода и прав на него.

Именно поэтому сравнивать «реестровое ПО» и «open source» как два однородных лагеря некорректно: внутри реестра есть и чисто коммерческие продукты с закрытым кодом, и открытые дистрибутивы вроде Astra Linux, которые сами построены поверх open source-компонентов и добавляют к ним сертификацию, поддержку и юридический статус. Сравнение честно только тогда, когда вы считаете не цену лицензии саму по себе, а совокупную стоимость эксплуатации (TCO) за весь горизонт использования — обычно 3–5 лет, потому что на более коротком отрезке скрытые статьи расходов ещё не успевают проявиться, а на более длинном начинают доминировать риски, о которых часто забывают на старте.

TCO складывается из четырёх частей: стоимость лицензий, стоимость персонала, стоимость риска при вынужденной миграции и — отдельно, потому что она может обнулить весь предыдущий расчёт — обязательность реестра по комплаенсу для вашей категории организации. Дальше — по каждому пункту.

Стоимость лицензий: реестровое против «бесплатного»

У реестрового ПО стоимость лицензии — конкретная и предсказуемая статья бюджета: годовая подписка, разовая покупка с последующей поддержкой, оплата по числу пользователей, серверов или ядер — модель зависит от вендора, но в любом случае вы получаете счёт, который можно заранее заложить в финансовый план. В стоимость обычно уже входит какой-то уровень поддержки — от базового тикет-канала до выделенного инженера, и это меняет расчёт следующего раздела про кадры: часть работы, которую при open source делает ваш штатный специалист, здесь частично закрывает вендор.

У open source лицензии нет как таковой, но это не значит, что стоимость эксплуатации равна нулю — она смещается в другие статьи расходов: время на внедрение, поддержку, обновления и разбор нестандартных проблем без гарантированного SLA. Подробно этот механизм — куда именно утекает «бесплатность» open source и как его посчитать — мы разбирали в статье про реальную стоимость бесплатного open source; здесь не повторяем методику целиком, а фокусируемся на разнице именно с реестровым вариантом.

Ключевая тонкость, которую часто упускают: значительная часть реестрового ПО — это не оригинальная разработка «с нуля», а дистрибутив или форк открытого проекта с добавленной сертификацией, локализацией и коммерческой поддержкой. Классический пример — линейка Astra Linux, построенная на базе Debian: вы платите не за уникальный код ядра, а за сертификацию ФСТЭК, мандатное разграничение доступа и контракт на поддержку. Это означает, что реальная альтернатива для сравнения TCO часто не «реестровый продукт против абстрактного open source», а «тот же open source-фундамент с обёрткой вендора против него же без обёртки» — и тогда разница в цене буквально равна цене сертификации, поддержки и юридической чистоты происхождения, а не цене другой технологии.

Кадры: где искать специалистов и сколько стоит их найм

Это фактор, который часто перевешивает разницу в цене лицензий, и именно его недооценивают при первом сравнении. У open source — широкий и в целом более дешёвый рынок труда: базовые навыки администрирования Linux, PostgreSQL, Nginx, Kubernetes есть у огромного числа специалистов, это стандарт де-факто в индустрии, знания переносятся между работодателями. Найти инженера, который уже работал с конкретным open source-стеком, обычно не проблема — проблема в том, что глубокая экспертиза именно под вашу нестандартную конфигурацию всё равно потребует времени на погружение.

У реестрового ПО рынок специалистов уже, и это системная особенность, а не случайность: продукт может быть относительно новым на рынке, сертификационные курсы вендора стоят денег и времени, а спрос на конкретную экспертизу меньше, потому что меньше самих внедрений в стране. Это создаёт два эффекта одновременно: зарплатная премия за редкий навык и риск простоя проекта, если единственный в команде сертифицированный специалист уходит. Для нишевых продуктов — специализированных СУБД, ОС с мандатным доступом, VPN-шлюзов из реестра — своего специалиста часто приходится не искать на рынке, а растить внутри: отправлять на курсы вендора, оплачивать сертификацию, закладывать месяцы на выход на продуктивность. Это реальная статья бюджета, которую нужно ставить рядом со стоимостью лицензии, а не вспоминать о ней в момент, когда специалист понадобился срочно.

Практический ориентир для расчёта, без точных цифр (рынок труда сильно региональный и меняется во времени, но структура одна и та же):

• для open source-стека закладывайте премию за найм близкую к рыночной средней — предложение специалистов большое;
• для реестрового продукта закладывайте премию за редкость навыка — она может быть заметной для узкоспециализированных систем;
• отдельно закладывайте стоимость и время сертификационного обучения, если растите специалиста внутри команды, а не нанимаете готового;
• учитывайте, что вендорская поддержка по контракту частично компенсирует нехватку своего специалиста — но это часть стоимости лицензии, а не бесплатная страховка.

Риски и стоимость миграции при смене решения

Любое решение — реестровое или open source — рано или поздно может потребовать замены: вендор прекратил поддержку продукта, продукт исключили из реестра, open source-проект остановил разработку или изменил лицензию, или решение просто перестало закрывать ваши растущие требования. Стоимость такой миграции — часть TCO, которую нужно оценивать заранее, а не постфактум.

У open source миграционный риск обычно ниже по одной структурной причине: форматы данных и протоколы чаще стандартизированы или хотя бы широко документированы, потому что вокруг проекта — открытое сообщество, а не один вендор. Если проект остановился, часто есть форк или альтернатива с похожей архитектурой, и переход редко упирается в закрытый формат, который некому расшифровать. У реестрового ПО риск смены решения часто выше именно из-за закрытости внутренних форматов и специфичных для вендора инструментов — миграция может означать не просто установку другого дистрибутива, а переписывание интеграций, экспорт данных через нестандартные утилиты и повторную сертификацию на новом продукте.

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

Конкретный пример стоимости миграции на практике — переход между дистрибутивами Linux, в том числе на реестровый: мы отдельно разбирали, что реально ломается в первый день при переезде с Ubuntu на Astra Linux — другие репозитории пакетов и их версии, мандатный доступ, различия в systemd-юнитах. Это конкретные часы инженерного времени, которые нужно закладывать в стоимость перехода независимо от направления.

Практический вывод: закладывайте буфер на миграцию как процент от суммарного TCO за горизонт планирования, а не как разовую строку «на всякий случай». Чем более закрыт формат данных и специфичны инструменты продукта, тем выше должен быть буфер — вне зависимости от того, реестровый это продукт или open source-форк с закрытыми проприетарными надстройками.

Комплаенс: когда реестр обязателен независимо от цены

Всё сказанное выше — честный экономический расчёт, применимый там, где выбор действительно свободный. Но для части организаций выбора нет: использование софта из реестра — не рекомендация, а требование, зафиксированное на уровне нормативных актов. Это касается прежде всего государственных органов, организаций с преобладающим государственным участием и субъектов критической информационной инфраструктуры (КИИ) — для значимых объектов КИИ действуют отдельные требования по переходу на доверенное ПО и оборудование, и сроки перехода уже наступили для большинства категорий. Для госзакупок по 44-ФЗ и 223-ФЗ реестровый статус даёт формальный приоритет и часто делает закупку неучтённого софта невозможной без отдельного обоснования.

Для таких организаций расчёт TCO из разделов выше — не про «что выбрать», а про «как эксплуатировать то, что обязательно выбрано». Экономия на лицензии open source здесь не аргумент: цена несоответствия — это не переплата, а юридический риск, отказ в закупке или невозможность пройти обязательную сертификацию. Сравнивать реестровое ПО с open source по деньгам в этом случае так же бессмысленно, как сравнивать цену сервера в России и за рубежом для системы, которая по 152-ФЗ обязана хранить персональные данные на территории РФ — выбор уже сделан регулированием (похожая логика разобрана в статье про то, сколько стоит соответствие 152-ФЗ для небольшой компании).

Для коммерческих компаний без таких обязательств выбор действительно свободный, и весь расчёт из предыдущих разделов применяется без ограничений. Стоит только явно проверить: точно ли организация подпадает под категорию, где требование действует (форма собственности, госзаказ, статус субъекта КИИ — это юридическая квалификация, а не вопрос догадки), и не путаете ли вы обязательность реестра с обязательностью хранения данных на территории РФ по 152-ФЗ — это разные требования из разных актов. Это не юридическая консультация: точный статус стоит подтвердить с юристом или комплаенс-специалистом, поскольку перечни и сроки периодически уточняются.

Как считать TCO для своего случая

Ниже — методика без выдуманных цифр, потому что они всё равно будут разными для каждой компании, но со структурой расчёта, которую можно заполнить своими данными.

Шаг 0. Проверка обязательности реестра
  Если ваша организация подпадает под требование обязательного
  использования реестрового ПО (госорган, субъект КИИ, компания
  с гос. участием, закупка по 44-ФЗ/223-ФЗ с приоритетом реестра) —
  экономическое сравнение не нужно для факта выбора, но нужно
  для выбора КОНКРЕТНОГО продукта внутри реестра.
  Иначе → переходите к шагу 1.

Шаг 1. Лицензии за горизонт планирования (3–5 лет)
  Реестровое ПО: сумма подписок/покупок с учётом роста масштаба
  Open source: 0

Шаг 2. Персонал
  Стоимость найма/премии за редкий навык + обучение и сертификация
  + зарплата за весь горизонт для обоих вариантов

Шаг 3. Инфраструктура
  Сервер, резервное копирование, отказоустойчивость —
  считается отдельно от лицензии и одинаково для обоих сценариев,
  если решения сопоставимы по требованиям к ресурсам

Шаг 4. Риск миграции
  Буфер = вероятность вынужденной смены решения за горизонт
  × стоимость миграции (часы инженера + простой + повторная
  сертификация, если применимо)

Шаг 5. Сумма
  TCO = Лицензии + Персонал + Инфраструктура + Риск миграции
  Сравните итог за оба варианта на одном горизонте планирования

Если продукт реестровый, но построен поверх open source, в шаге 2 стоит явно разделить: часть работы инженера идентична для обоих вариантов (это стоимость эксплуатации самого open source-фундамента), а разница в TCO — это надбавка за сертификацию, поддержку вендора и юридический статус. Так расчёт становится честнее: вы платите не «за то же самое дороже», а за конкретные дополнительные свойства, и можете оценить, нужны ли они вам за пределами обязательного комплаенса.

Если сравниваете переход между уже развёрнутыми системами, а не выбор с нуля, отдельно оцените стоимость самого перехода — она может быть сопоставима с годовой экономией на лицензии и откладывать точку окупаемости на годы: методика такой оценки разобрана в статье про скрытые статьи цены перехода с проприетарного ПО на open source, логика симметрична и для перехода в обратную сторону, на реестровый продукт.

Частые вопросы