Open source-тренды, деньги и облака

Согласно последним отчетам по теме, среди прочих все чаще используются специализированные облачные пакеты, предназначенные для взаимодействия с API сервис-провайдеров. Еще за последние пару лет в open source сформировался пул идей о том, каким может быть финансирование контрибьютеров и открытых проектов. Сегодня мы в beeline cloud ^[1] разбираем эти и другие open source-тренды.

Облака в пакетах

В то время как звезды, рейтинги и статистика по количеству загрузок отражают общую популярность программных пакетов, они не всегда перекликаются с их распространением в инфраструктуре и технологических продуктах. Чтобы оценить степень распространения открытого программного обеспечения, исследователи из Гарвардской школы бизнеса и лаборатории инноваций (LISH) в партнерстве с Linux Foundation Research и Open Source Security Foundation (OpenSSF) провели ^[2] исследование Census — уже третье по счету. Специалисты работали с компаниями, занятыми на рынке инструментов SCA для анализа состава программного обеспечения. FOSSA, Snyk, Sonatype и Black Duck передали исследователям анонимизированные данные о составе используемого программного обеспечения, полученные в ходе сканирования кодовых баз своих клиентов.

В лучших традициях известного комикса xkcd ^[3] про современную инфраструктуру, которая держится на одном проекте, самоотверженно и бескорыстно поддерживаемом никому не известным разработчиком, примерно 96% кодовых баз содержат open source компоненты. Однако, изучая новые данные, специалисты отметили резкий рост использования пакетов, специфичных для облачных сервисов. Примером может быть boto3 ^[4] — python-библиотека для работы с виртуальными серверами и хранилищами S3 одного из крупнейших облачных провайдеров. Другой пример — набор библиотек google-cloud-go ^[5] для работы с сервисами Google. Теперь он входит в восьмерку наиболее используемых компонентов (хотя еще три года назад он не входил даже в топ-500). Также в список часто встречающихся библиотек вошла go-genproto ^[6], которая содержит код gRPC для взаимодействия с профильными API в облаке Google.

По мнению исследователей, тренд связан с изменением парадигмы разработки облачных решений. «Раньше бизнес применял поход lift-and-shift и переносил существующие приложения в облако с минимальными изменениями, — пишет ^[7] Дэвид Уилер, директор OpenSSF. — Сегодня разработчики чаще пишут софт, заточенный под работу в облаке, и стремятся использовать доступные в нем сервисы с помощью открытых библиотек».

Еще один инсайт — сохраняется распространенность пакетов, имеющих отношение к устаревающим версиям языков программирования. Так, Python 3 был выпущен достаточно давно, но переход на него до сих пор не завершен. Специалисты отметили присутствие большого количества компонентов, имеющих отношение к Python 2, поддержка которого прекратилась ^[8] пять лет назад. В топ даже вошла библиотека six ^[9] для написания совместимого кода, призванная «сгладить углы» между различными версиями Python. По мнению Уилера, этот факт показывает важность поддержания обратной совместимости при выпуске новых версий не только ЯП, но и софта в целом.

(НЕ) понятные имена

Авторы отчета Census III также отмечают, что наименования программных компонентов и библиотек слишком индивидуализированы. Инструменты могут по-разному хранить и обрабатывать различные типы пакетов, в итоге может быть сложно ссылаться на один и тот же пакет в контексте целой открытой экосистемы. С этой проблемой десятилетиями борются Linux Foundation и другие организации.

Один из вариантов стандартизировать процесс именования — использовать Common Platform Enumeration ^[10] (CPE) — формальный язык для описания программных продуктов и аппаратных компонентов. Его используют системы управления уязвимостями, однако некоторые специалисты отмечают, что CPE не может служить долгосрочным решением и требует трудоемкой централизованной модерации.

Второй вариант — OmniBOR ^[11]. Это — минималистичная схема ^[12] для построения графа зависимостей компонентов. В ней роль уникальных идентифицирующих отпечатков играют криптографические хеши. И такой граф позволяет отслеживать каждый компонент, который используется в конечном программном продукте. Однако хеши чувствительны к малейшим изменениям в коде, даже если они не влияют на функциональность компонента. Так, эксперты из OpenSSF подчеркивают ^[13], что криптографические хеши, такие как OmniBOR, — это важная часть решения проблемы имен, но не панацея. Они не могут заменить собой семантическую информацию о зависимостях, которая важна для понимания структуры программного продукта.

Третий вариант подразумевает более широкое использование пакетных URL — pURL ^[14]. Они помогают хранить, использовать и различать пакеты из разных экосистем. Идентификатор формируют ^[15] семь элементов, объединённых в строку, включая обозначение пакетного менеджера, имя пакета и его версию, а также дополнительную информацию с указанием на архитектуру или операционную систему. Проблема в том, что предложенные решения известны и используются десятки лет, но их внедрение идет медленнее, чем того хотелось бы представителям индустрии.

Проблематика точного указания «координат» открытых компонентов действительно остро стоит в сообществе, но многие этого ещё не поняли, а тревогу всё больше бьют производители инструментов анализа: композиционный анализ (SCA), управление уязвимостями (VM), в первую очередь. Всё потому, что для них важно точно показать обнаруженный компонент и информацию по нему.

Когда был придуман CPE, его авторы пытались «закрыть» всё одним махом: и пользовательские приложения, и железо; а открытые компоненты (или библиотеки) ещё не пугали своим количеством. Мир изменился, и сейчас только готовых пакетов около 100 миллионов (всех версий); нужно понимать, как их идентифицировать в отношении экосистем, в которых они размещаются. К сожалению, использование CPE зачастую вносит больше энтропии в этот процесс, чем хотелось бы.

Но мир меняется, и сообщество предложило PURL, который призван более точно указывать на компоненты и их версии, а, соответственно, и давать возможность адресовать к ним полезные метаданные, такие как известные уязвимости, эксплойты, лицензии и особенности использования самой компоненты. Сейчас PURL уже интегрирован во многие инструменты и фиды, что позволяет проводить более точную работу с инвентарем Open Source.

Алексей Смирнов

Основатель платформы безопасной разработки CodeScoring ^[16]

Где деньги, Лебовски?

Инженеры GitHub и Linux Foundation совместно со специалистами из Гарвардской лаборатории инноваций (LISH) провели исследование, чтобы изучить финансовые потоки и экономическое состояние рынка open source. Их задачей было понять, как и почему организации поддерживают развитие открытого программного обеспечения.

Сегодня уровень вложений в OSS со стороны коммерческих компаний остается низким ^[17]. 86% всех вложений — это коммиты и труд сотрудников компаний. Помощь в денежном выражении составляет лишь оставшиеся 14%. Компании делают регулярные или разовые пожертвования проектам через платформы вроде GitHub Sponsors. Площадка уже распределила больше 40 млн долларов ^[18]. Однако на конец 2024 года всего 44 тыс. резидентов GitHub могли получать деньги по этой программе — крошечная доля ^[19] от многомилионной пользовательской базы. 

Но даже если предположить, что каждый open source проект зарегистрирован на этой и других подобных площадках, имеет «копилку» для пожертвований или собственный фонд, реальность такова, что экосистема open source включает в себя слишком большое количество разработчиков. При этом внимание сообщества и компаний чаще всего сосредоточено на крупных, известных или «хайповых» решениях, оставляя множество менее популярных, но не менее важных проектов без должной поддержки.

В попытке исправить ситуацию, постепенно появляются новые форматы сбора средств. Один из них — инициатива Open Source Pledge ^[20], направленная на корпорации и крупный бизнес. Компаниям предлагают присоединиться к инициативе и сделать добровольный взнос в размере 2 тыс. долларов за каждого разработчика в своем штате (вероятно, цифра выбрана произвольно, такова политика фонда). Затем собранные деньги направят мейнтенерам открытого программного обеспечения.

Другая идея, которая привлекла ^[21] внимание резидентов на Hacker News, направлена на обычных участников open source экосистемы. Один инженер предложил алгоритмически распределять «микрогранты» (до 200 долларов) между разработчиками небольших, но важных для интернет-инфраструктуры проектов — в том числе в зависимости от количества загрузок. Автор поста уже распределил 5 тыс. долларов между 866 разработчиками ^[22] открытых решений. Однако к таким форматам стоит подходить с осторожностью, поскольку они уязвимы для злоупотреблений.

Не обошлось и без Брюса Перенса — автора определения open source и соучредителя Open Source Initiative. В прошлом году он представил первый набросок новой лицензии — Post-Open Zero Cost License ^[23]. Это попытка переосмыслить подход к лицензированию и помочь разработчикам открытого ПО получать доход за свой труд. Например, можно обязать компании с годовым доходом более 5 млн долларов, использующие ПО под новой лицензией, перечислять ^[24] процент от своих доходов профильной организации. Однако перспективы предложения пока неясны, поскольку не все согласны с необходимостью менять подход к открытым лицензиям. К тому же Post-Open Zero Cost License может оказаться сложнее для понимания и реализации по сравнению с традиционными лицензиями вроде MIT или GPL, что отпугнет часть разработчиков.

Еще одна предполагаемая идея и решение ^[25] — запуск профильных фондов, которые бы собирали и распределяли пожертвования от частного сектора и правительств. Подобная модель столетиями поддерживает некоторые университеты, а у сообщества open source с ними много общего. Поэтому адаптация такой модели в целом возможна. 

Open source-гранты уже развиваются на базе ряда крупных технологических компаний в России. Это — перспективное направление, причем как для независимых разработчиков, так и для организаций, оказывающих им поддержку. Первые получают от организаторов не только ресурсы (допустим, облачные), но и становятся более заметными для партнеров. А организации в процессе отбора проектов лучше понимают технологические тренды и возможности для развития в той или иной области, а также ведут скаутинг специалистов.

Другие модели поддержки в российском контексте не столь применимы. Распределение тем или иным образом средств из какой-то общественной копилки контрибьютерам — потенциально серая и бесперспективная история. Более многообещающей видится классическая open source-модель, когда сами организации задумываются, что могла бы им дать открытая разработка уже существующих или новых решений с точки зрения конкурентных преимуществ.

Когда такое понимание появляется не только у сотрудников (например, из числа open source-энтузиастов), а на уровне высшего руководства организации, она может дать рынку и контрибьютерам гораздо больше возможностей по сравнению с прямым финансированием. В целом появление большего числа компаний, образовательных структур и других организаций в open source стимулирует участие независимых специалистов в открытой разработке, дает им выбор технологической базы, чтобы показать себя и строить свои проекты.

Однако одной только публикации исходного кода и пресс-релизов об этом недостаточно для полноценного участия организации в open source. Требуется проактивная стратегия, включающая работу с сообществом и аудиторией, совершенствование бизнес-модели (с учетом возможностей по запуску дополнительных услуг на базе открытой разработки), а также развитие организационных структур для координации открытых проектов (хотя бы на уровне отдельных ролей open source-стратегов и евангелистов).

В России только появляются ростки профессионального управления открытой разработкой на уровне стратегии развития компаний и формирования конкурентных преимуществ на основе такого подхода. Это определенно даст результат и принесет пользу для всего open source-сообщества.

Дмитрий Кабанов

эксперт по стратегическому управлению и бизнес-моделям на базе open source ^[26]

Интеллектуальные облака

Если говорить о рынке в целом, то согласно свежему отчету State of AI in the Cloud, использование открытых систем ИИ в облаке продолжает расширяться ^[27]. Уже около 75% организаций размещают свои модели машинного обучения в облачных средах. Они эффективнее управляют ресурсами и снижают затраты на инфраструктуру.

В России рынок систем ИИ также демонстрирует рост ^[28] — на 20–30% ежегодно. Провайдеры ИТ-услуг адаптируются и предлагают решения, которые отвечают растущим запросам рынка. Среди них — платформы для работы с данными и LLM в том числе на базе открытых решений. Облака ускоряют тестирование и масштабирование ИИ-проектов. Рост рынка опенсорсных моделей машинного обучения особенно важен, поскольку усиливает другие тренды в open source. Ведь открытые системы ИИ уже меняют подходы к разработке программного обеспечения.

Действительно, если посмотреть на отчёт ^[29] конца 2024 года от Epoch AI, можно увидеть, насколько быстро модели с открытыми весами догоняют топовые проприетарные модели. 2024-й стал переломным годом для открытых моделей, и теперь компании всерьёз рассматривают их как альтернативу дорогим моделям от OpenAI, Anthropic и других лидеров рынка.

Мы в beeline cloud ^[1] также рассматриваем гибридные схемы для автоматизации внутренних процессов, когда более простые задачи решаются на небольших и дешёвых моделях, а большие модели уровня DeepSeek-R1 применяются только для действительно сложных и требовательных к вычислениям проблем.

Мы предполагаем, что тренд на применение ChatGPT как универсального инструмента скоро закончится, и преимущество получат те облачные провайдеры, которые смогут предложить своим клиентам оптимизацию TCO за счёт гибкого ценообразования и применения минимально необходимой модели для решения каждой конкретной задачи.

Олег Тарасов

Занимается внедрением AI-решений в beeline cloud

beeline cloud ^[1] — secure cloud provider. Разрабатываем облачные решения, чтобы вы предоставляли клиентам лучшие сервисы.