В конце 2025 года инфраструктура хранения данных MinIO без предупреждения перешла в режим maintenance mode. Для тех, кто не знаком с этим инструментом: MinIO — это фактически стандарт де-факто для объектных хранилищ (аналог S3) в open-source среде, который используют сотни тысяч компаний по всему миру для своих критичных данных. И когда такой проект внезапно «замораживает» разработку, это становится проблемой планетарного масштаба. Клиенты остались без поддержки. Клиенты остались без поддержки — новые функции не принимаются, патчи безопасности рассматриваются «в индивидуальном порядке», готовые сборки больше не публикуются. Проект с 59 000 звёзд на GitHub и миллиардом скачиваний с Docker Hub предложил только коммерческую альтернативу — от $96 000 в год. Компании, строившие архитектуру на этом решении, оказались перед выбором: платить, мигрировать или принять риски эксплуатации неподдерживаемого ПО. Рассказываем о том, что обязательно нужно учитывать при использовании open source и какой стратегии стоит придерживаться.
Не аномалия, а паттерн
История MinIO — не исключение из правил, за последние три года аналогичный путь прошли несколько крупнейших open source проектов. HashiCorp перевёл Terraform на проприетарную лицензию BUSL. Elastic сменил Apache 2.0 на SSPL, фактически запретив облачным провайдерам использовать Elasticsearch. Redis ввёл двойное лицензирование, ограничив коммерческое применение.
Закономерность связана с ростом популярности решений, с определенного момента условия меняются и вперед выходит монетизация. Так происходит, потому что проекты, контролируемые одной компанией, рано или поздно сталкиваются с давлением инвесторов и необходимостью показывать выручку.
Когда открытый проект меняет правила игры, могут помочь управляемые сервисы с предсказуемым SLA и локальной поддержкой. Например, у MinIO есть альтернативы — российский рынок решений растет и активно развивается, согласно рейтингу CNewsMarket «Российские S3-хранилища 2025» сформировалась стойкая пятерка лидеров: VK Object Storage, MWS, Т1 Облако, Yandex Object Storage и Росукреп. По сути, зрелость отечественного рынка объектных хранилищ уже дает возможность выбора качественного вендора, который берёт на себя ответственность за весь жизненный цикл сервиса.
Модель управления — ключевой фактор
Главная опасность заключается в риске внезапного прекращения обслуживания или изменения правил игры, когда вы уже «выстроили на этом фундаменте свой дом». Здесь мы сталкиваемся с фундаментальным заблуждением: многие компании путают лицензию на использование кода и модель управления проектом.
Лицензия Apache 2.0 или MIT даёт право использовать, модифицировать и распространять код. Но она не гарантирует, что завтра владелец репозитория не изменит условия для новых версий, не прекратит поддержку или не удалит публичные сборки — именно это и произошло с MinIO.
Выбирая решение для своей инфраструктуры, всегда стоит задавать два вопроса: кто контролирует roadmap технологии, на которой ты все строишь — сообщество или вендор? И, самый важный, есть ли у вас план «Б» на случай изменения условий лицензирования?
К открытому коду надо подходить с умом
Использование готовых open-source решений или их фрагментов — это нормальная мировая практика, в том числе и в России, которая эффективно ускоряет разработку, повышает качество за счёт коллективной проверки и обеспечивает прозрачность, невозможную для проприетарных решений. Программное обеспечение с открытым кодом остаётся фундаментом современной IT-индустрии. По данным Synopsys OSSRA Report 2025, 97% всех приложений содержат open source компоненты, а согласно GitHub Octoverse 2024 время исправления критических уязвимостей в open source проектах сократилось с 37 до 26 дней — улучшение на 30% за год.
Важно понимать, что когда компания принимает решение использовать компоненты open-source, она либо доверяет безопасность тому вендору, который включает их в свое решение и берет на себя ответственность за проверку и сопровождение, либо сама берет ответственность за обеспечение безопасности решений на основе этого кода.
Использование open-source требует зрелого подхода к управлению безопасностью: регулярного аудита кода, контроля обновлений, мониторинга уязвимостей и соблюдения требований регуляторов. Тогда такие решения становятся не риском, а инструментом для быстрого развития. При условии формирования зрелой и комплексной системы управления жизненным циклом всей программной экосистемы.
Какой путь выбрать
При использовании открытого кода в корпоративной среде существуют два возможных подхода, и выбор между ними определяет не только бюджет, но и уровень стратегического риска. Первый путь — доверить ответственность вендору, второй — взять ее на себя, но это требует зрелой внутренней экспертизы для регулярного аудита и контроля обновлений.
Ценность же любого отечественного решения сегодня определяется отнюдь не происхождением каждой строки кода, а профессиональным опытом, который в него вложен: адаптацией под требования российского рынка, сертификацией по стандартам ФСТЭК и локальной поддержкой. В конечном счёте риском для безопасности является не открытость кода, а исключительно незрелый подход к его использованию. Защититься от этого можно, переведя критические технологии под свое управление, через форк или через партнёрство с вендором, который возьмет ответственность.
Поделиться
