Облака в пакетах
В то время как звезды, рейтинги и статистика по количеству загрузок отражают общую популярность программных пакетов, они не всегда перекликаются с их распространением в инфраструктуре и технологических продуктах. Чтобы оценить степень распространения открытого программного обеспечения, исследователи из Гарвардской школы бизнеса и лаборатории инноваций (LISH) в партнерстве с Linux Foundation Research и Open Source Security Foundation (OpenSSF) провели исследование Census — уже третье по счету. Специалисты работали с компаниями, занятыми на рынке инструментов SCA для анализа состава программного обеспечения. FOSSA, Snyk, Sonatype и Black Duck передали исследователям анонимизированные данные о составе используемого программного обеспечения, полученные в ходе сканирования производственных кодовых баз своих клиентов.
В лучших традициях известного комикса xkcd про современную инфраструктуру, которая держится на одном проекте, самоотверженно и бескорыстно поддерживаемом никому не известным разработчиком, примерно 96% кодовых баз содержат open source компоненты. Однако, изучая новые данные, специалисты отметили резкий рост использования пакетов, специфичных для облачных сервисов. Примером может быть boto3 — python-библиотека для работы с виртуальными серверами и хранилищами S3 одного из крупнейших облачных провайдеров. Другой пример — набор библиотек google-cloud-go для работы с сервисами Google. Теперь он входит в восьмерку наиболее используемых компонентов (хотя еще три года назад он не входил даже в топ-500). Также в список часто встречающихся библиотек вошла go-genproto, которая содержит код gRPC для взаимодействия с профильными API в облаке Google.
По мнению исследователей, тренд связан с изменением парадигмы разработки облачных решений. «Раньше бизнес применял поход lift-and-shift и переносил существующие приложения в облако с минимальными изменениями, — пишет Дэвид Уилер, директор OpenSSF. — Сегодня разработчики чаще пишут софт, заточенный под работу в облаке, и стремятся использовать доступные в нем сервисы с помощью открытых библиотек».
Еще один инсайт — сохраняется распространенность пакетов, имеющих отношение к устаревающим версиям языков программирования. Так, Python 3 был выпущен достаточно давно, но переход на него до сих пор не завершен. Специалисты отметили присутствие большого количества компонентов, имеющих отношение к Python 2, поддержка которого прекратилась пять лет назад. В топ даже вошла библиотека six для написания совместимого кода, призванная «сгладить углы» между различными версиями Python. По мнению Уилера, этот факт показывает важность поддержания обратной совместимости при выпуске новых версий не только ЯП, но и софта в целом.
(НЕ) понятные имена
Авторы отчета Census III также отмечают, что наименования программных компонентов и библиотек слишком индивидуализированы. Инструменты могут по-разному хранить и обрабатывать различные типы пакетов, в итоге может быть сложно ссылаться на один и тот же пакет в контексте целой открытой экосистемы. С этой проблемой десятилетиями борются Linux Foundation и другие организации.
Один из вариантов стандартизировать процесс именования — использовать Common Platform Enumeration (CPE) — формальный язык для описания программных продуктов и аппаратных компонентов. Его используют системы управления уязвимостями, однако некоторые специалисты отмечают, что CPE не может служить долгосрочным решением и требует трудоемкой централизованной модерации.
Второй вариант — OmniBOR. Это — минималистичная схема для построения графа зависимостей компонентов. В ней роль уникальных идентифицирующих отпечатков играют криптографические хеши. И такой граф позволяет отслеживать каждый компонент, который используется в конечном программном продукте. Однако хеши чувствительны к малейшим изменениям в коде, даже если они не влияют на функциональность компонента. Так, эксперты из OpenSSF подчеркивают, что криптографические хеши, такие как OmniBOR, — это важная часть решения проблемы имен, но не панацея. Они не могут заменить собой семантическую информацию о зависимостях, которая важна для понимания структуры программного продукта.
Третий вариант подразумевает более широкое использование пакетных URL — pURL. Они помогают хранить, использовать и различать пакеты из разных экосистем. Идентификатор формируют семь элементов, объединённых в строку, включая обозначение пакетного менеджера, имя пакета и его версию, а также дополнительную информацию с указанием на архитектуру или операционную систему. Проблема в том, что предложенные решения известны и используются десятки лет, но их внедрение идет медленнее, чем того хотелось бы представителям индустрии.
Проблематика точного указания «координат» открытых компонентов действительно остро стоит в сообществе, но многие этого ещё не поняли, а тревогу всё больше бьют производители инструментов анализа: композиционный анализ (SCA), управление уязвимостями (VM), в первую очередь. Всё потому, что для них важно точно показать обнаруженный компонент и информацию по нему.
Когда был придуман CPE, его авторы пытались «закрыть» всё одним махом: и пользовательские приложения, и железо; а открытые компоненты (или библиотеки) ещё не пугали своим количеством. Мир изменился, и сейчас только готовых пакетов около 100 миллионов (всех версий); нужно понимать, как их идентифицировать в отношении экосистем, в которых они размещаются. К сожалению, использование CPE зачастую вносит больше энтропии в этот процесс, чем хотелось бы.
Но мир меняется, и сообщество предложило PURL, который призван более точно указывать на компоненты и их версии, а, соответственно, и давать возможность адресовать к ним полезные метаданные, такие как известные уязвимости, эксплойты, лицензии и особенности использования самой компоненты. Сейчас PURL уже интегрирован во многие инструменты и фиды, что позволяет проводить более точную работу с инвентарем Open Source.
— Алексей Смирнов, Основатель платформы безопасной разработки CodeScoring
Где деньги, Лебовски?
Инженеры GitHub и Linux Foundation совместно со специалистами из Гарвардской лаборатории инноваций (LISH) провели исследование, чтобы изучить финансовые потоки и экономическое состояние рынка open source. Их задачей было понять, как и почему организации поддерживают развитие открытого программного обеспечения.
Сегодня уровень вложений в OSS со стороны коммерческих компаний остается низким. 86% всех вложений — это коммиты и труд сотрудников компаний. Помощь в денежном выражении составляет лишь оставшиеся 14%. Компании делают регулярные или разовые пожертвования проектам через платформы вроде GitHub Sponsors. Площадка уже распределила больше 40 млн долларов. Однако на конец 2024 года всего 44 тыс. резидентов GitHub могли получать деньги по этой программе — крошечная доля от многомилионной пользовательской базы.
Но даже если предположить, что каждый open source проект зарегистрирован на этой и других подобных площадках, имеет «копилку» для пожертвований или собственный фонд, реальность такова, что экосистема open source включает в себя слишком большое количество разработчиков. При этом внимание сообщества и компаний чаще всего сосредоточено на крупных, известных или «хайповых» решениях, оставляя множество менее популярных, но не менее важных проектов без должной поддержки.
В попытке исправить ситуацию, постепенно появляются новые форматы сбора средств. Один из них — инициатива Open Source Pledge, направленная на корпорации и крупный бизнес. Компаниям предлагают присоединиться к инициативе и сделать добровольный взнос в размере 2 тыс. долларов за каждого разработчика в своем штате (вероятно, цифра выбрана произвольно, такова политика фонда). Затем собранные деньги направят мейнтенерам открытого программного обеспечения. Другая идея, которая привлекла внимание резидентов на Hacker News, направлена на обычных участников open source экосистемы. Один инженер предложил алгоритмически распределять «микрогранты» (до 200 долларов) между разработчиками небольших, но важных для интернет-инфраструктуры проектов — в том числе в зависимости от количества загрузок. Автор поста уже распределил 5 тыс. долларов между 866 разработчиками открытых решений. Однако к таким форматам стоит подходить с осторожностью, поскольку они уязвимы для злоупотреблений.
Не обошлось и без Брюса Перенса — автора определения open source и соучредителя Open Source Initiative. В прошлом году он представил первый набросок новой лицензии — Post-Open Zero Cost License. Это попытка переосмыслить подход к лицензированию и помочь разработчикам открытого ПО получать доход за свой труд. Например, можно обязать компании с годовым доходом более 5 млн долларов, использующие ПО под новой лицензией, перечислять процент от своих доходов профильной организации. Однако перспективы предложения пока неясны, поскольку не все согласны с необходимостью менять подход к открытым лицензиям. К тому же Post-Open Zero Cost License может оказаться сложнее для понимания и реализации по сравнению с традиционными лицензиями вроде MIT или GPL, что отпугнет часть разработчиков.
Еще одна предполагаемая идея и решение — запуск профильных фондов, которые бы собирали и распределяли пожертвования от частного сектора и правительств. Подобная модель столетиями поддерживает некоторые университеты, а у сообщества open source с ними много общего. Поэтому адаптация такой модели в целом возможна.
Open source-гранты уже развиваются на базе ряда крупных технологических компаний в России. Это — перспективное направление, причем как для независимых разработчиков, так и для организаций, оказывающих им поддержку. Первые получают от организаторов не только ресурсы (допустим, облачные), но и становятся более заметными для партнеров. А организации в процессе отбора проектов лучше понимают технологические тренды и возможности для развития в той или иной области, а также ведут скаутинг специалистов.
Другие модели поддержки в российском контексте не столь применимы. Распределение тем или иным образом средств из какой-то общественной копилки контрибьютерам — потенциально серая и бесперспективная история. Более многообещающей видится классическая open source-модель, когда сами организации задумываются, что могла бы им дать открытая разработка уже существующих или новых решений с точки зрения конкурентных преимуществ.
Когда такое понимание появляется не только у сотрудников (например, из числа open source-энтузиастов), а на уровне высшего руководства организации, она может дать рынку и контрибьютерам гораздо больше возможностей по сравнению с прямым финансированием. В целом появление большего числа компаний, образовательных структур и других организаций в open source стимулирует участие независимых специалистов в открытой разработке, дает им выбор технологической базы, чтобы показать себя и строить свои проекты.
Однако одной только публикации исходного кода и пресс-релизов об этом недостаточно для полноценного участия организации в open source. Требуется проактивная стратегия, включающая работу с сообществом и аудиторией, совершенствование бизнес-модели (с учетом возможностей по запуску дополнительных услуг на базе открытой разработки), а также развитие организационных структур для координации открытых проектов (хотя бы на уровне отдельных ролей open source-стратегов и евангелистов).
В России только появляются ростки профессионального управления открытой разработкой на уровне общей стратегии развития компаний и формирования конкурентных преимуществ на основе такого подхода. Это определенно даст результат и принесет пользу для всего open source-сообщества.
— Дмитрий Кабанов, эксперт по стратегическому управлению и разработке конкурентных стратегий и бизнес-моделей на основе open source
Интеллектуальные облака
Если говорить о рынке в целом, то согласно свежему отчету State of AI in the Cloud, использование открытых систем ИИ в облаке продолжает расширяться. Уже около 75% организаций размещают свои модели машинного обучения в облачных средах. Они эффективнее управляют ресурсами и снижают затраты на инфраструктуру.
В России рынок систем ИИ также демонстрирует рост — на 20–30% ежегодно. Провайдеры ИТ-услуг адаптируются и предлагают решения, которые отвечают растущим запросам рынка. Среди них — платформы для работы с данными и LLM в том числе на базе открытых решений. Облака ускоряют тестирование и масштабирование ИИ-проектов. Рост рынка опенсорсных моделей машинного обучения особенно важен, поскольку усиливает другие тренды в open source. Ведь открытые системы ИИ уже меняют подходы к разработке программного обеспечения.
Действительно, если посмотреть на отчёт конца 2024 года от Epoch AI, можно увидеть, насколько быстро модели с открытыми весами догоняют топовые проприетарные модели. 2024-й стал переломным годом для открытых моделей, и теперь компании всерьёз рассматривают их как альтернативу дорогим моделям от OpenAI, Anthropic и других лидеров рынка. Мы в beeline cloud также рассматриваем гибридные схемы для автоматизации внутренних процессов, когда более простые задачи решаются на небольших и дешёвых моделях, а большие модели уровня DeepSeek-R1 применяются только для действительно сложных и требовательных к вычислениям проблем. Мы предполагаем, что тренд на применение ChatGPT как универсального инструмента скоро закончится, и преимущество получат те облачные провайдеры, которые смогут предложить своим клиентам оптимизацию TCO за счёт гибкого ценообразования и применения минимально необходимой модели для решения каждой конкретной задачи.
— Олег Тарасов, занимается внедрением AI- решений в beeline cloud
