Open source в Enterprise: как понять, готово ли решение к внедрению
«Open source» давно перестало быть просто техническим фактом и превратилось в маркетинговый ярлык: открытый код в представлении многих автоматически означает «надёжно», «бесплатно» и «можно не думать о вендоре». Но открытость исходного кода сама по себе не гарантирует ни устойчивости проекта, ни предсказуемости лицензирования, ни качества поддержки. Последние годы дали несколько показательных примеров. В марте 2024 года разработчик Andres Freund обнаружил бэкдор в xz-utils — компоненте, который использовался в ряде популярных дистрибутивов Linux. Уязвимость CVE-2024-3094 получила максимальную оценку критичности CVSS 10.0. Инцидент стал результатом длительной социальной инженерии, в ходе которой злоумышленник получил доверие сообщества и права на сопровождение проекта. В том же 2024 году Redis перевёл будущие версии с BSD 3-Clause на лицензии RSALv2 и SSPLv1, а годом ранее HashiCorp перевёл Terraform и другие ключевые продукты на Business Source License. Оба случая привели к появлению независимых форков: Valkey и OpenTofu соответственно. При этом позднее и Redis, и Elastic внесли изменения в свои лицензионные модели: Redis с выходом Redis 8 добавил AGPLv3, а Elastic в 2024 году добавила AGPLv3 как ещё один вариант лицензирования Elasticsearch и Kibana. Все эти истории объединяет одно: наличие открытого исходного кода не отменяет рисков, связанных с тем, кто управляет проектом, как принимаются решения, как выпускаются исправления и что произойдёт с лицензированием будущих версий. Готовность к Enterprise это не факт наличия репозитория на GitHub, а совокупность нескольких независимых характеристик: модель управления, безопасность, стабильность лицензии, доступность поддержки и предсказуемость обновлений. Проект может быть звездой GitHub и при этом оказаться неподходящим для критичной инфраструктуры компании, где стоимость простоя значительно выше бюджета на само внедрение. Читать далее