Самые важные события в сфере Open Source в 2025 г. были связаны с искусственным интеллектом, лицензированием/управлением, безопасностью и изменением бизнес-модели «коммерческого Open Source», пишет на портале ZDNet известный эксперт в этой области Стивен Дж. Воан-Николс.
В центре внимания в 2025 г. был ИИ, но также и многие другие разработки и опасения.
1. ИИ с открытым исходным кодом набирает обороты
Хотя бóльшая часть денег ушла на проприетарные модели, опенсорсные наборы данных для ИИ, фреймворки оркестрации, инструменты оценки и стеки защиты также продемонстрировали рост.
Такие проекты в области ИИ с открытым исходным кодом, как Common Corpus, наряду с десятками ИИ-проектов, размещенных группой AI & Data Фонда Linux, позволяют нам использовать для генеративного ИИ инфраструктуру сообщества, а не полагаться исключительно на проприетарные API, что делает открытые стеки ИИ серьезным вариантом для бизнеса и пользователей.
Хотя определение ИИ с открытым исходным кодом остается спорным и очень немногие проекты ИИ полностью соответствуют строгим требованиям определения ИИ от Open Source Initiative (OSI), ИИ по-прежнему строится на основе ПО с открытым исходным кодом. Дискуссия об открытых весах, данных и коде обучения будет продолжаться, но даже самые проприетарные большие языковые модели (LLM) не могли бы существовать без программ с открытым исходным кодом.
Агентный ИИ всем обязан Open Source. Для оркестрации последнего поколения агентов ИИ мы используем несколько программ. Наиболее важной из них на данном раннем этапе, по-видимому, является Model Context Protocol (MCP). Это открытый стандарт и Open Source-реализация для унифицированного подключения агентов к инструментам, файлам, базам данных и другим системам.
MCP все чаще становится «коммуникационным слоем» для многих агентов и IDE-помощников, и существует множество серверов и инструментариев MCP с открытым исходным кодом, которые позволяют любой совместимой агентной платформе подключаться к тем же инструментам.
MCP — не единственное промежуточное ПО для агентного ИИ, которое набирает популярность. Так, в июне Google передала свой протокол Agent2Agent, стандартизирующий взаимодействие агентов друг с другом, в Linux Foundation. Microsoft Agent Framework, SDK и среда выполнения с открытым исходным кодом, предназначенные для создания, развертывания и управления мультиагентными приложениями, поддерживающими MCP, также набирают популярность.
2. Продолжаются споры вокруг лицензий Open Source («открытый исходный код») и Source Available («доступный исходный код»)
Отчет Linux Foundation, опубликованный в августе, показал, что коммерческие компании, занимающиеся разработкой ПО с открытым исходным кодом и финансируемые венчурным капиталом, за последние 25 лет превзошли сопоставимых поставщиков закрытого исходного кода.
Этот отчет, наряду с данными о внедрении открытого исходного кода из апрельского опроса OSI, согласно которому 96% организаций поддерживают или увеличивают использование ПО с открытым исходным кодом, закрепил коммерческий открытый исходный код в качестве основного способа разработки ПО.
Вместе эти отчеты стимулируют привлечение большего финансирования, слияния и поглощения, а также стратегии «открытое ядро плюс сервисы» для критически важных Open Source-проектов.
Конечно, мы это знали и раньше. В конце концов, исследование Гарвардской школы бизнеса 2024 г. уже показало, что 96% коммерческих программ полагаются на открытый исходный код, а общая стоимость открытого исходного кода составляет внушительные 8,8 трлн. долл. Но это все еще не останавливает компании от совершения ошибки, когда они путают Open Source как модель разработки ПО с бизнес-моделью. Open Source никогда не была бизнес-моделью. И никогда ею не будет.
В 2025 г. мы наблюдали, как все больше компаний переходили от открытого к псевдооткрытому исходному коду. Например, команда ScyllaDB объявила в декабре 2024 г. о переходе на единый поток «ScyllaDB Enterprise» под лицензией Source Available.
На уровне библиотек можно увидеть громкие примеры того, как ранее либеральные проекты незаметно перешли на условия Source Available с оплатой за коммерческое использование. Так, библиотека тестирования Fluent Assertions .NET в январе перешла с лицензии Apache 2.0 на проприетарную лицензию Source Available с оплатой за каждого разработчика.
Другой пример: DevOps-программа Puppet. Хотя основной код Puppet по-прежнему находится под Open Source-лицензией Apache 2.0, её коммерческая материнская компания, Perforce, изменила способ распространения и лицензирования официальных сборок. Новые «защищенные» бинарные файлы и пакеты, созданные Puppet/Perforce, теперь распространяются из частного репозитория. Лицензионное соглашение конечного пользователя (EULA) для основного кода Puppet предлагает бесплатный уровень, ограниченный 25 узлами, а для дополнительных узлов необходима коммерческая лицензия. Фактически это делает Puppet программой с доступным исходным кодом, даже несмотря на то, что код технически всё ещё открыт.
В случае с Puppet результатом стало то же, что и в других подобных попытках закрыть некогда открытые проекты: недовольные программисты создали форк проекта. Он известен как OpenVox.
Эти «форкнутые» проекты, включая Elasticsearch с его форком OpenSearch, Redis с форком Valkey и Terraform с форком OpenTofu, достигли значительного прогресса, но в разных масштабах и с разным пониманием «успеха».
OpenSearch, по-видимому, является наиболее успешным. Он демонстрирует сильный рост, включая двузначный (78%) рост числа загрузок в годовом исчислении, и имеет в своем портфеле крупных партнеров, таких как Amazon Web Services, Canonical, SAP и Uber.
Valkey также оказался популярным. Сообщается, что последняя версия, Valkey 9, намного быстрее, чем новейшая версия Redis. В частности, пользователи Valkey сообщают, что он стабильно опережает сопоставимые версии Redis по пропускной способности, особенно при больших, требующих значительных ресурсов памяти рабочих нагрузках, где вступают в действие такие функции Valkey, как многопоточный ввод-вывод и предварительная загрузка данных в кэш (cache‑prefetching).
Хотя OpenSearch и Valkey продвинулись дальше своих родительских проектов, Terraform против OpenTofu — это уже совсем другая история. Люди по-прежнему считают, что OpenTofu и Terraform отличаются только лицензиями. Однако за последние несколько месяцев ситуация изменилась, поскольку OpenTofu, присоединившийся к Cloud Native Computing Foundation в апреле, всё больше движется в собственном направлении. В последних релизах теперь есть шифрование состояния — функция, которую сообщество Terraform ждало годами, — и раннее определение переменных (early variable evaluation).
Наконец, OpenVox продолжает позиционировать себя как «мягкий форк». Его руководители хотят, чтобы он оставался на 100% совместимым с Puppet, чтобы служить прямой заменой для развертываний Puppet. Однако, похоже, это больше невозможно: «Мы больше не можем гарантировать, что наши модули будут работать с Puppet Core или Puppet Enterprise», — заявил Джин Ливерман, руководитель OpenVox.
С точки зрения мейнтейнеров проекта, Perforce нарушает совместимость. Однако на данный момент OpenVox — это, по сути, здоровая спасательная шлюпка для сообщества, а не полноценная замена Puppet.
3. Open Source-проекты испытывают острую нехватку финансирования
Несмотря на то, что мы все зависим от Open Source, слишком многие проекты остаются недофинансированными. Другие, такие как NET 6, по-прежнему популярны, но их разработчики прекратили поддержку. Что же делать пользователю?
Это не новая проблема. Еще в 2021 г. компания Tidelift, занимающаяся вопросами безопасности и оказывающая финансовую поддержку мейнтейнерам Open Source-проектов, обнаружила, что 46% из них вообще не получали никакой оплаты. Немногим лучше то, что даже среди те, кто получал оплату, лишь 26% зарабатывали более 1000 долл. в год за свою работу.
С тех пор ситуация не улучшилась. На самом деле, она ухудшилась. В 2024 г. Tidelift обнаружила, что теперь 60% мейнтейнеров Open Source-проектов не получают оплату.
Как отмечалось в опубликованном в сентябре открытом письме, подписанном 10 Open Source-фондами, «большинство этих [Open Source] систем существуют на опасно хрупкой основе: они часто поддерживаются, работают и финансируются, полагаясь на добрую волю, а не на механизмы, которые связывают ответственность с использованием».
Согласно этому открытому письму, «небольшое количество организаций берет на себя бóльшую часть затрат на инфраструктуру, в то время как подавляющее большинство крупных пользователей, включая коммерческие организации, которые создают спрос и извлекают экономическую выгоду, потребляют эти услуги, не внося вклад в их устойчивое развитие».
Конкретный пример: FFMpeg, используемый всеми, кто смотрит видео в Интернете, ужасно недофинансируется, даже несмотря на то, что такие крупные компании, как Amazon, Google и Netflix, зависят от его кода. Существует множество других подобных проектов.
Решение состоит в том, что компании должны — обязаны — начать финансово поддерживать критически важные Open Source-проекты. Стоимость этого ничтожна по сравнению с ущербом, который они понесут, если эти проекты закроются или столкнутся с серьезной проблемой безопасности.
4. Цепочка поставок открытого ПО уязвима как никогда
В 2024 г. код библиотеки сжатия данных xz, преднамеренно зараженный вредоносным ПО, едва не внедрил бэкдор в Fedora, дистрибутив Linux от Red Hat. Если бы это удалось, он мог бы попасть в Red Hat Enterprise Linux (RHEL) и его клоны.
Это привело бы к крупнейшей на сегодняшний день катастрофе в области безопасности Linux. Нам удалось избежать этого.
К сожалению, безопасность цепочки поставок ПО с открытым исходным кодом подвергается постоянным и масштабным атакам, при этом кампании, направленные против npm и PyPI, усиливаются.
В 2025 г. несколько масштабных кампаний были направлены на компрометацию экосистем пакетов с открытым исходным кодом, особенно npm.
В ноябре исследователи из Wiz, Aikido и других организаций подробно описали волну троянизированных npm-пакетов под названием «Shai-Hulud 2.0», которые похищали учетные данные разработчиков и системы CI/CD из сред, использующих популярные библиотеки, связанные с основными SaaS- и облачными инструментами.
В рамках кампании были созданы десятки тысяч вредоносных репозиториев. Группа исследователей уязвимостей GitLab также сообщила об отдельной широкомасштабной атаке на цепочку поставок npm, в ходе которой были получены учетные данные для GitHub, npm и крупных облачных сервисов, а затем атака распространилась путем заражения дополнительных пакетов, принадлежащих жертвам.
Это не единичные случаи. В отраслевых отчетах об угрозах за 2025 г. описывается общий всплеск атак на цепочки поставок ПО, при этом октябрь установил новый месячный рекорд, и среди целей часто фигурируют экосистемы Open Source.
Анализ, проведенный исследовательской группой Unit 42 компании Palo Alto Networks и другими группами исследователей, отмечает, что злоумышленники все чаще предпочитают взламывать учетные записи мейнтейнеров и конвейеры публикации, а не основные репозитории исходного кода, поскольку этот путь позволяет незаметно отравлять доверенные пакеты в масштабе.
В исследовании ReversingLabs, опубликованном в марте, сообщается, что, хотя количество обнаруженных вредоносных пакетов с открытым исходным кодом несколько снизилось, риск сместился в сторону утечки секретов разработчиков и уязвимостей во время сборки.
Исследователи, изучающие популярные компоненты npm, PyPI и RubyGems, продолжают обнаруживать жестко закодированные учетные данные, слабую защиту приложений и оголенные данные внутри широко используемых бинарных файлов, развернутых на предприятиях. Такая ошибка была глупой еще в
Как сообщают специалисты в области JFrog и Veracode, cитуацию усугубляет то, что взрывной рост графов зависимостей, ускорение циклов выпуска и активное повторное использование Open Source-библиотек означают, что один вредоносный или уязвимый пакет может за считанные дни распространиться на тысячи приложений.
Эта плотная взаимосвязь делает радиус поражения атак, подобных кампаниям, направленным на npm в 2025 г., значительно больше, чем у многих более ранних инцидентов с открытым исходным кодом, особенно когда целевые библиотеки присутствуют в
Что мы можем с этим сделать? Нам необходимо более широко внедрять Software Bills of Materials (SBOM, перечни библиотек, конкретных файлов и зависимостей, имеющих отношение к разрабатываемому ПО), аттестации в стиле фреймворка SLSA (Supply-chain Levels for Software Artifacts) и инструменты из экосистемы Open Source Software Foundation (OpenSSF) для отслеживания происхождения и целостности Open Source-компонентов.
OpenSSF и его партнеры обращают особое внимание на такие инициативы, как Sigstore для бесключевой подписи, Scorecard для автоматизированной оценки рисков проекта и Open Source Project Security Baseline, которые призваны обеспечить более четкие ожидания в отношении безопасности как для мейнтейнеров, так и для потребителей.
Каждый год я говорю людям, что они должны серьезнее относиться к безопасности. В последнее время, поскольку нарушения в цепочке поставок открытого исходного кода становятся все более распространенными, я говорю, что необходимо убедиться, что код в вашей цепочке поставок безопасен и написан кем-то, кому можно доверять.
Заглядывая в будущее, я могу только удвоить эти предупреждения. За последние несколько лет у нас уже были серьезные нарушения безопасности. Вы помните: Solarwinds, JetBrains TeamCity и Apache Log4j — все они должны быстро прийти на ум. Какими бы ужасными ни были предыдущие катастрофы, в будущем нас ждут еще более серьезные проблемы с безопасностью, если мы не будем гораздо серьезнее относиться к безопасности цепочек поставок открытого исходного кода.
