Введение

Всем привет! Сегодня хочу поговорить с вами про open-source проекты. Слежу сейчас в основном за несколькими: pangolin, netbird, dokploy, n8n, и плюс проекты, которые пока ещё развиваются и не столь популярны, но имеют потенциал стать крутыми. Так вот, часто open-source проекты со временем переходят в фазу внедрения платных возможностей а-ля enterprise. Оценивать это можно по-разному. Со стороны пользователя это часто напрягает, появляется «лишняя кнопка» (по факту она лишняя и просто занимает место). Со стороны разработчика это способ заработка со своего проекта, и тут вроде бы всё нормально: пусть делают проект как хотят, хрен с ними.

Но вот в чём проблема: сейчас много людей используют ИИ, и если разработчик неправильно подошёл к вопросу, как мне реализовать enterprise, то этот «enterprise» можно взломать, убрав условные 2 if, которые блокируют доступ к нему. В этой статье разберём на примерах, как делать неправильно и как, по моему мнению, стоит делать правильно.

1. Никаких платных возможностей не должно быть упомянуто в открытом репозитории

Лично меня бесит, когда какой-то раздел мне недоступен в интерфейсе, это лишнее и не должно светиться в открытой версии вообще. Проще сделать где-нибудь пометку, что возможность доступна в платной версии, и показать её ссылкой на скриншот или запись экрана. Не нужно тащить в открытый репозиторий код закрытой возможности, которую пользователь всё равно не может использовать, это только создаёт соблазн её распаковать.

2. Проверка лицензии не должна жить на стороне пользователя (почти)

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

Если проверка платного статуса делается на стороне приложения без обращения к серверу подтверждения, то это можно назвать заглушкой (исключение: в зависимости от архитектуры проверки в некоторых проектах это норм). Условие «включена платная версия или нет» зависит от локального флага в настройках или от простого условия в коде, которое ничего не проверяет на удалённом сервере. Такое закладывается изначально как дыра, а не как недоработка, которую можно поправить позже. ИИ сейчас прекрасно умеет читать чужой код и находить такие заглушки за секунды.

Ну, как и пример, произошло это с Dokploy (не так давно начали появляться enterprise-фичи). ИИ, анализировавший весь проект, по моему запросу просто убрал эту «защиту», и все возможности открылись, потому что весь код уже лежал в открытом репозитории, а разделение держалось на паре условий и честном слове.

Разработчик уведомлен об этом и в скором времени исправится.

3. Открытая и платная версии — это два отдельных репозитория

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

Пример плохого решения: уже упомянутый Dokploy. У них на данный момент плохо реализована система защиты платных функций именно потому, что весь код физически лежит в одном месте.

А хороший пример: Pangolin, который я сейчас считаю близким к идеальному варианту. Когда разворачиваешь их проект, получаешь доступ исключительно к открытой версии, и код нельзя изменить так, чтобы разблокировать что-то, потому что там попросту нечего взламывать. Вся платная версия — это отдельный образ, доступный только при определённом условии: покупка + код доступа (токен/ключ).

4. Платная версия — это отдельный модуль, а не набор проверок внутри одной сборки

Если весь код коммерческой версии уже находится в основном репозитории, а разница заключается только в проверке лицензии, возникает закономерный вопрос: зачем вообще тащить этот код вместе с открытой версией?

Условие внутри общей сборки рано или поздно обойдут, это только вопрос времени. Отдельный образ или отдельная сборка, как у Pangolin, технически исключает часть путей обхода. А с развитием ИИ разбирать большие проекты стало проще, поэтому устройство, при котором платная функциональность полностью отделена и распространяется отдельно, сейчас выглядит гораздо более логичным, чем несколько лет назад. Раньше можно было спрятать всё за «ну кто будет разбирать наш запутанный код», сейчас это разбирается моделью за пару запросов.

5. Открытая версия должна быть полноценным продуктом, а не демо-версией

Открытая версия не должна ощущаться как урезанная демка. Если разворачиваешь проект и через каждые пару минут натыкаешься на «Только в платной версии», «Обновиться» или «Премиум», это начинает раздражать. Складывается ощущение, что тебе дали не открытый проект, а рекламную листовку коммерческой версии. Открытая версия должна полностью выполнять свою задачу. Да, платная версия может добавлять возможности сверху, но базовая должна быть законченной, а не искусственно порезанной ради продажи лицензии.

Плохой вариант выглядит так (примерный):

• создание пользователей только в платной версии;

• резервные копии только в платной версии;

• выгрузка данных только в платной версии;

• уведомления только в платной версии.

Это базовая функциональность продукта, которую сделали платной, потому что так проще, чем реально придумать, за что брать деньги.

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

• централизованный каталог пользователей (LDAP);

• единый вход через корпоративного поставщика подтверждения личности (SSO, SAML);

• ролевой доступ (RBAC);

• журналирование действий пользователей;

• отказоустойчивость и кластеризация;

• централизованное управление несколькими установками;

• отдельная линия поддержки.

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

6. Минимум рекламы внутри интерфейса

Не против платной версии как таковой. Разработчикам тоже нужно на что-то жить. Но не нравится, когда открытая версия превращается в рекламную площадку самой себя: половина меню не работает, на каждой странице кнопка «Обновиться», огромные баннеры «Купите платную версию», заблокированные вкладки через одну. Гораздо приятнее, когда открытая версия выглядит как самостоятельный законченный продукт, а информация про платную лежит на сайте, в документации, на отдельной странице сравнения (либо помечена нормально в документации), там, где её ищут осознанно, а не там, где она мешает работать.

7. Документация тоже должна быть разделена

То же самое касается инструкций. Неприятно дочитать до нужного раздела и увидеть «только в платной версии» прямо посреди руководства. В идеале, если есть коммерческая версия, то стоит сделать отдельную документацию или отдельный раздел сайта под неё (ну или хотя бы пометки предупреждениями, как и сказал в 6 пункте). Тогда пользователь открытой версии сразу понимает, какие возможности вообще относятся к его версии, а какие — это разговор для корпоративных клиентов.

8. Простой переход между версиями

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

9. Почему платная версия вообще нужна

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

Итак. Какой итог и как выглядит «Идеальная формула», как я её вижу:

• полноценная открытая версия без искусственных ограничений на базовый функционал;

• платная версия — полностью отдельный код;

• проверка лицензии на сервере, а не на стороне пользователя (БЫВАЮТ исключения);

• минимум рекламы внутри интерфейса открытой версии;

• документация тоже разделена по версиям (необязательно, см. 6-й и 7-й пункт!);

• платная версия продаёт новые возможности для команд и компаний, а не снимает искусственные ограничения с базового продукта;

• переход между версиями без остановки сервиса и без ручного переноса данных.

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

Заключение

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

А что думаете вы? Согласны с формулой или есть свои примеры хорошего и плохого разделения open-source и enterprise? Пишите в комментариях, интересно посмотреть на другие кейсы.

© 2026 ООО «МТ ФИНАНС»