Как открытый код взрослеет под принуждением?

Около двух десятилетий открытый код жил почти по-детски: раздавал программы, доверял незнакомцам и редко требовал формальной ответственности. Получался ларёк с лимонадом, где покупатель мог забрать товар, оставить анонимную расписку и когда-нибудь расплатиться. Компании строили на этом критические системы, не считая расходы на сопровождение, безопасность и доверие. Идиллия была слегка диковатой. Несколько месяцев назад прозвучала формула «открытый код умер в марте», хотя год не назывался. Точнее сказать иначе: он не умер, а попал под мобилизацию. Это прогноз, а не инструкция; способ публично ошибиться, поставив под утверждением дату.
Как открытый код взрослеет под принуждением?
Изображение носит иллюстративный характер

Примерно в 2020 году у этой системы начался неловкий подростковый возраст: ломался голос, пробивалась воображаемая борода, высыпали прыщи. SolarWinds, Log4Shell, TeamPCP и Shai-Hulud показали, что учебная тревога в цепочке поставок была настоящей войной. Почти как в «Игре Эндера», где симуляция внезапно оказывается реальным сражением. Под ударом находились реальные машины, деньги и люди, а несущую нагрузку принимал код, который вчера воспринимали как любительский проект. Затем пришли исполнительные указы, европейские нормы и разрешительные процедуры. Сказочного взросления не получилось: открытый код условно призвали в восемнадцать лет, не спросив, готов ли он.
Война идёт с двух сторон. На одном фронте Mythos-class AI, то есть ИИ класса Mythos, ищет неизвестные уязвимости и собирает связанные цепочки zero-day быстрее, чем люди успевают разобрать очередь сообщений. Во вторник проект может выглядеть безопасным, а уже в следующий вторник понадобится срочный патч. На другом фронте поставка вредоносного кода поставлена на поток: заражаются репозитории, пакеты и сами каналы распространения. Обнаружение уязвимостей превратилось в оружие, доставка вредоносных компонентов тоже. Между ними оказался разработчик, который мог поддерживать библиотеку по вечерам и никогда не обещал дежурить круглосуточно.
Open Source с заглавных букв при этом никуда не денется. Это лицензионное определение, десятилетиями находящееся под опекой Open Source Initiative, или OSI. Полномочия OSI признаются добровольно, и в такой добровольности как раз заключена природа этой модели. Open Source Definition не требуется переписывать, забирать OSI под контроль тоже незачем. Изменится другое: какой код компании захотят брать и какой код регулируемым предприятиям разрешат использовать. Через несколько лет соблюдение нового порога, вероятно, станет для них обязанностью, а не хорошей практикой.
Возникнут две группы. Первая, пока без удачного имени, представляет «подмножество» проектов, пригодных для серьёзной корпоративной эксплуатации. Лицензия здесь ничего не решает. Важнее простые вопросы: кто-нибудь дома, можно ли связаться с проектом, куда отправлять сведения об уязвимости, жив ли репозиторий и найдётся ли человек, который выпустит исправление? В подмножество способны войти одиночный разработчик, сообщество, фонд или компания. Организационная форма сама по себе ничего не гарантирует. Остальные проекты останутся открытыми и продолжат выпускать код как раньше. Они не сделали ничего плохого и не обязаны обслуживать пользователей. Но регулируемой компании понадобится план: найти поставщика, который возьмёт компонент на поддержку, либо заменить его.
У обычного проекта нет кардиомонитора. За день до ухода сопровождающего и через день после него страница репозитория выглядит одинаково; разница обнаруживается, когда приходит критическая уязвимость, а ответа нет. Поэтому статус подмножества нельзя выдавать однажды, как диплом на стену. Нужны постоянный сигнал keep-alive, аналог «кнопки мертвеца», рабочая политика безопасности и канал раскрытия уязвимостей, а также выполнение требований, уже появляющихся в Cyber Resilience Act, CRA. Вместе с проверкой жизни требуется право на достойный уход. Человек, пятнадцать лет тащивший важную библиотеку, может выгореть или заняться другой работой. История сопровождающего xz-utils показала, чем заканчивается передача ключей без нормального преемника. Для таких случаев предлагается EmeritOSS, включая Chainguard EmeritOSS: «дом для вышедших на пенсию» проектов, где код продолжают проверять и поддерживать, не приговаривая автора к пожизненной службе.
Цена открытого кода лучше описывается фразой «бесплатно, как щенок», а не «бесплатно, как пиво». Щенка можно получить даром, но его приходится кормить, выгуливать и однажды, возможно, искать ему новый дом. «Кормить» зависимость означает держаться свежего выпуска: подмножество будет исправлять актуальную версию, а не сборку, замороженную три года назад. «Выгуливать» означает регулярно обновляться вместо бесконечной фиксации старого стека. «Пристраивать» означает заранее готовить миграцию, если проект покинет подмножество. Лицензионного платежа может не быть никогда, но останутся труд владельца, обновления, безопасность и замена компонентов. Двадцать лет индустрия вела себя так, будто щенок растит себя сам.
Поставщики продают освобождение от части этих забот. LTS-ветки и перенесённые назад исправления позволяют не держать весь парк на самой новой версии. Если проект внезапно теряет поддержку, поставщик стабилизирует компонент и даёт время для миграции. Плановый уход обслуживает «дом для пенсионеров», внезапный крах требует «приёмного покоя»; это разные аварии. В собачьей метафоре поставщик работает няней или дрессировщиком, которого вызывают, если питомец кого-то укусил. Код остаётся доступным там же и бесплатно. Платят за обещание: «В открытом коде нет контрактов, есть лишь текущее состояние». Коммерческий слой добавляет настоящий договор поверх программы.
Связь этой модели с Chainguard очевидна: компания строит услуги, которые, по её расчёту, скоро понадобятся рынку. Но назвать это убийством открытого кода трудно. Microsoft примерно два десятилетия тратила на борьбу с ним неисчислимые миллиарды и не добилась цели; один корпоративный прогноз тем более не способен закрыть отрасль. Бесплатный путь остаётся открытым, а поставщик не превращается в привратника между пользователем и репозиторием. Он берёт плату за LTS, бэкпорты, экстренную стабилизацию, договорную ответственность и запас времени, когда вытащить зависимость из продакшена за один вечер нельзя.
Совет «просто платите сопровождающим» разумен, но с 2021 года проблема точнее описывается как распределительная, а не финансовая. У корпораций есть бюджеты и некоторое желание платить. Труднее состыковать тысячи компаний, тысячи зависимостей и тысячи сопровождающих, у каждого из которых свои условия, потребности и отношение к деньгам. Даже один автор может продавать договор доступности, выпускать бэкпорты под другой лицензией или стать собственным поставщиком. Это законный выбор, но он не свяжет примерно десять тысяч компаний одновременно. Руководство Филиппо Вальсорды (Filippo Valsorda) «Как платить профессиональным сопровождающим» содержит длинный перечень предварительных условий именно потому, что отдавать деньги порой сложнее, чем находить их.
«Трагедия общин» здесь тоже плохо подходит. Код не вытаптывается, как общее пастбище: использование библиотеки одним человеком не оставляет второму меньше строк. Запущены были слой сопровождения, доверие и опоры под программами, несущими огромную нагрузку. Ответом становится агрегация. Фонд или большое сообщество может выступить единой стороной договора вместо десяти тысяч отдельных получателей, отделить управление проектом от денег и не дать сопровождающим потерять контроль. Коалиция Athena уже пытается применить подобную схему; планы угрозы и ответа описываются в материалах «Самый трудный форк» и «Сопровождающий последней инстанции». Европейский союз движется туда же: EU Cyber Resilience Act ввёл категорию open-source software steward, «распорядителя открытого ПО», то есть юридического лица, которое систематически и устойчиво поддерживает открытые продукты, предназначенные для коммерческого использования. Разбор этой границы содержится в материале «Акт ЕС о киберустойчивости: открытый код и роль распорядителя».
Сообщество Free Software с заглавных букв на таком фоне выглядит дальновиднее коммерческого лагеря. Сторонники GPL и принципа «свобода, а не цена» около сорока лет повторяли, что свободная программа не обязана быть «бесплатной, как пиво». Примерно двадцать лет назад они посмотрели на гонку за корпоративным внедрением и ответили: «Это не моя война». Теперь основатели open core и компании с венчурным, VC-backed финансированием разбираются с аудитами, документами CRA и коммерческими обязательствами. Они могут ждать от убеждённых сторонников GPL фразы «мы же говорили», но тем нечего подсчитывать: они не участвовали в этой гонке. Их ответ ближе к реплике Дона Дрейпера (Don Draper): «Я вообще о вас не думаю».
У новой категории всё ещё нет названия. Enterprise Source, «корпоративный код», звучит как капитуляция перед бизнесом; Resilient Source, «устойчивый код», слишком мягко и расплывчато; Load-bearing Source, «несущий код», передаёт нагрузку, но не объясняет условия эксплуатации. Ещё около дюжины вариантов тоже не прижились. Между тем категория уже набирает участников, а регуляторы заносят её лексику в законы. За последний год контуры прогноза стали заметно чётче, хотя он по-прежнему может оказаться ошибочным. Если разработчики, сопровождающие и пользователи не выберут слово сами, ближайшее десятилетие им придётся жить с термином, придуманным извне. Материалы «Athena», «Chainguard EmeritOSS» и «Как платить профессиональным сопровождающим» описывают уже складывающиеся части системы. Категория находится прямо перед глазами. Как её назвать?


Новое на сайте

Ссылка