Открытый исходный код пережил счастливое детство. На протяжении двух десятилетий он оставался ребёнком. Свободно развивался, безвозмездно делился результатами, доверял незнакомцам и не беспокоился о надзоре. Его можно было сравнить с палаткой с лимонадом, где принимали расписки от любого прохожего — бери сколько нужно, рассчитаешься когда сможешь, имя не требуется. Это была идиллия, хотя в ретроспективе — немного дикая. Однако около 2020 года что-то изменилось. Появились инциденты безопасности: SolarWinds, Log4Shell и другие. Цепочка поставок неожиданно обнаружила, что имитация была реальной. Взрослые пришли с правилами: указы, европейские регуляции, разрешения для множества направлений деятельности.

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

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

Главное требование для первой части — доказательство живости. Проект должен быть доступен, иметь путь раскрытия уязвимостей, доказывать, что за ним кто-то следит. Это не новая лицензия и не форк определения — это позиция, которую проект принимает или отклоняет.

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

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

Поставщики услуг (вендоры) предлагают решение двух неподъёмных для пользователя проблем: стабильные версии вместо постоянных обновлений и буфер времени для миграции при внезапном отказе проекта. Это не затвор, это профессиональная поддержка — "собака" остаётся вашей, вы просто платите за уход и предотвращение проблем.

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

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

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

В результате открытый исходный код из идеалистичного ребёнка трансформируется во взрослого, закалённого, ответственного. Это не утопия и не апокалипсис — это честная реальность. Сторонники свободного ПО, которые всегда говорили именно об этом, окажутся правы, хотя торжествовать они не будут.

Нужно назвать эту категорию. "Enterprise Source", "Resilient Source", "Load-bearing Source" — все варианты звучат неправильно. Это имя должно появиться из использования, а не по указу, так как в открытом коде всё решается именно так. Наименование должно прийти от людей, которые будут жить под этим определением.