Сколько стоит бесплатный open source: где прячется его ценник

MAATRIX

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

Что на самом деле бесплатно в open source

Термин «свободное ПО» изначально про свободу, а не про цену — в английском это различие видно в паре free as in speech / free as in beer, но по-русски оба смысла слились в одно слово «бесплатно», и это постоянно создаёт путаницу. Open source действительно бесплатен в узком смысле: вы можете скачать исходный код или готовый дистрибутив, установить его сколько угодно раз, не платить за количество серверов, пользователей или ядер CPU, и никто не пришлёт счёт за продление лицензии через год. Это реальная и существенная экономия — особенно если сравнивать с проприетарным ПО, где цена растёт вместе с масштабом использования.

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

Время на установку и настройку — первая скрытая статья

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

На практике это означает, что кто-то в команде должен:

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

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

Документация, самостоятельное решение проблем и отсутствие «одного звонка»

У платного продукта с поддержкой есть канал, куда можно написать или позвонить, когда что-то не работает: тикет, чат, иногда — выделенный менеджер. Ответственность за диагностику частично снимается с вас — вендор обязан разобраться, и обычно у него есть SLA на время реакции, за нарушение которого предусмотрены санкции (подробнее о том, как читать такие условия в договоре и что они реально гарантируют, у нас есть отдельный разбор).

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

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

Сервер для запуска нужен в любом случае

Отдельно стоит закрыть частое заблуждение: «бесплатный» софт всё равно нужно где-то исполнять. Open source не отменяет необходимость в вычислительных ресурсах — CPU, память, диск, сеть стоят денег независимо от лицензии приложения, которое на них работает. Более того, иногда open source-альтернатива требовательнее к железу, чем managed-версия того же класса задач, потому что в managed-сервисе оптимизацией движка занимается вендор, а в самостоятельной установке — дефолтная конфигурация, которую вы либо тюните сами, либо платите за неё избыточными ресурсами.

Здесь стоимость инфраструктуры не зависит от того, свободная у вас лицензия или нет — она зависит от нагрузки, отказоустойчивости и требований к резервному копированию. Но именно поэтому сравнение «open source бесплатен, а подписка на SaaS стоит N рублей в месяц» некорректно само по себе: у SaaS в эту сумму уже включён сервер, а у self-hosted open source сервер нужно арендовать отдельно и добавить к итоговой смете. Если вы уже держите инфраструктуру под другие задачи и просто добавляете туда ещё один сервис, предельные затраты на сервер могут быть небольшими. Если разворачиваете систему с нуля — стоимость аренды сервера входит в реальную цену вашего «бесплатного» софта наравне со временем инженера, и её нужно считать так же честно: подробная методика для инфраструктуры разобрана в статье про полную стоимость владения на горизонте трёх лет.

Обновления и патчи безопасности — расходы, которые растянуты во времени

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

С open source ответственность за то, чтобы система оставалась актуальной и безопасной, целиком на вас. Это касается и рутинных патчей безопасности, которые нужно накатывать регулярно, и более трудоёмких мажорных апгрейдов, где нужно заранее читать changelog, проверять breaking changes и тестировать на стейджинге перед проды. Если этим никто системно не занимается, происходит типичный сценарий: сервис работает годами на версии с известными уязвимостями просто потому, что «настроили и забыли», а обновление откладывается, потому что оно не бесплатно по времени и есть риск что-то сломать при апгрейде на проде.

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

Смещение стоимости, а не её отсутствие

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

Размен работает в вашу пользу, когда:

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

Размен работает против вас, когда:

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

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

Как посчитать реальную стоимость open source для своего случая

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

1. Оцените разовые затраты на внедрение. Сколько часов инженерного времени уйдёт на установку, настройку, интеграцию с остальной инфраструктурой и первичное тестирование — по своей оценке, с запасом, потому что первое знакомство с системой почти всегда занимает больше времени, чем кажется на старте.
2. Оцените регулярные затраты на эксплуатацию. Сколько часов в месяц потребуется на обновления, мониторинг, разбор инцидентов и ответы на вопросы «а почему не работает» — это стабильный поток расходов, который стоит закладывать не как разовую, а как постоянную статью.
3. Добавьте стоимость инфраструктуры. Аренда сервера под систему, резервное копирование, при необходимости — резервный узел для отказоустойчивости.
4. Заложите буфер на риск. Оцените вероятность и цену сценария «проблема специфична, готового решения в сообществе нет» — сколько будет стоить бизнесу день или два простоя или ручного разбора нестандартного случая.
5. Сравните итоговую сумму с ценой платной альтернативы за тот же период, включая её собственные сопутствующие расходы — сервер для неё тоже может понадобиться, если это не полностью управляемый SaaS.

Если сумма пунктов 1–4 меньше стоимости платной подписки за сопоставимый период — open source действительно экономит деньги, и не только на бумаге. Если больше — «бесплатное» решение на деле обходится дороже, просто расходы распределены иначе и не видны в одной строке счёта. Разница между этими двумя исходами в 90% случаев решается не характеристиками самого софта, а тем, есть ли у команды время и опыт, чтобы взять на себя роль, которую в платном варианте играет вендор.

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