Open source компонент редко остается неизменным после того, как попадает в большой продукт. Если команде не хватает нужной функции, библиотека плохо стыкуется с внутренней системой или выпуск обновления безопасности не укладывается в запланированные сроки, то в ход идет доработка собственными силами. Часть изменений в таком случае отправляется в исходный репозиторий, тогда как остальные годами живут в отдельной ветке.

В конце 2025 года Linux Foundation Research опросила 567 специалистов о том, как их организации работают с такими изменениями. Результаты вошли в февральский отчет «ROI for Open Source Software Contribution». Формально исследование посвящено финансовой выгоде от вложений в open source, но нас в отчете больше всего заинтересовала практическая часть. По таблицам из отчета можно понять, что именно компании дорабатывают, когда отправляют код авторам проекта и в каких случаях сохраняют собственный форк.

Кого опрашивали

Исследование проводилось в октябре и ноябре 2025 года. Респондентов набирали среди подписчиков, участников и партнерских сообществ Linux Foundation. После проверки ответов в итоговую выборку вошли 567 человек. 

К участию допускали специалистов с опытом работы в IT, которые могли отвечать от лица своей организации. Разработчиками, инженерами или архитекторами работали 28% респондентов. Еще 19% занимались системным администрированием и инфраструктурой. В среднем участники имеют 12 лет опыта работы с открытым кодом и 14 лет в IT.

Компании разных размеров представлены в выборке неравномерно:

• 29% респондентов работали в организациях до 249 сотрудников;

• 31% – от 250 до 4 999 сотрудников;

• 40% – в организациях с 5 000 сотрудников и более.

51% участников – поставщики IT-продуктов и услуг. Еще 35% работали в компаниях, чей основной бизнес не связан с IT, а 14% – в государственных, некоммерческих и образовательных организациях.

Такая выборка хорошо описывает зрелых пользователей open source, но не весь рынок. В нее изначально допускали только организации, которые используют открытое ПО или участвуют в его развитии. Крупные компании составили 40% респондентов, а часть участников пришла из сообщества самой Linux Foundation. Поэтому результаты отчета не стоит автоматически переносить на любую отрасль и страну.

Что компании возвращают в исходные проекты

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

Участие в открытых проектах не сводится только к написанию кода. Компании также работают над документацией и тестами, помогают пользователям, организуют мероприятия и участвуют в управлении проектами. Организацию мероприятий отметили 33% участников. Поддержкой пользователей и продвижением проектов занимались по 29%, развитием сообществ – 28%, а созданием образовательных материалов – 27%. 

Однако технические изменения нагляднее всего показывают то, какие задачи бизнес решает вместе с сообществом. Ответы о коде распределились следующим образом:

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

Как компании совмещают разные модели

Авторы также собрали основные способы работы с открытыми компонентами:

• 68% используют хотя бы часть компонентов без изменений;

• 49% возвращают изменения в исходные проекты;

• 45% делают форки и поддерживают их внутри компании;

• 28% привлекают внешних специалистов для подготовки изменений;

• 26% участвуют в управлении проектами с открытым кодом.

Одной стратегии на весь открытый код у компаний обычно нет. Вполне нормально, когда один компонент может оставаться без изменений, патчи из второго регулярно уходят авторам, а третий приходится развивать отдельно из-за устройства продукта или требований регулятора.

Форк и вклад в исходный проект также могут идти последовательно. Внутренняя версия позволяет выпустить нужное исправление в срок, а уже после этого патч можно подготовить к публикации и обсудить с мейнтейнером.

Почему изменения остаются внутри компании

На вопросы о том, почему компания решает форкнуть проект, отвечали 238 респондентов. Разработку собственных функций назвали причиной 54%, а 44% дорабатывали компоненты для интеграции с внутренними системами. Исправления безопасности и требования регуляторов отметили 37%.

Дальше в списке причин расположились медленно развивающиеся или заброшенные исходные проекты (34%), необходимые исправления ошибок (32%), более быстрый цикл выпуска версий (29%), вопросы качества и стабильности (28%), оптимизация производительности (25%) и совместимость лицензий (18%).

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

Как число форков растет вместе с компанией

В среднем авторы отчета насчитали 86 внутренних форков на одну организацию и 60 часов работы с каждым из них за цикл выпуска. В пересчете на все собственные версии получилось 5 160 часов. Затем ответы разделили по размеру компаний в сводной таблице.

Расчеты относятся к подвыборке организаций, отвечавших на вопросы о форках. Они не означают, что любая крупная компания поддерживает такое количество проектов. Связь с размером организации при этом заметна – растет и число отдельных веток, и объем работы с каждым компонентом.

У внутреннего форка появляются собственные риски для анализа уязвимостей. Допустим, компания исправила уязвимость собственным патчем, но сохранила номер публичной версии. При обычном сопоставлении с базой уязвимостей компонент продолжит выглядеть уязвимым. Возможна и обратная ситуация. Внутренний патч закрывает одну проблему, однако ветка отстает от исходного проекта и пропускает следующие исправления.

Такую ветку приходится учитывать как отдельную сборку. Команде нужна связь с исходным проектом и конкретным коммитом, а также перечень внутренних патчей и ответственный за сопровождение. Анализ уязвимостей должен учитывать фактическое состояние внутренней версии, иначе сканирование будет продолжать показывать уже исправленную проблему или, наоборот, не отразит новый разрыв с основным проектом.

Где компании зависят от open source, но редко участвуют

Авторы также сравнили критичные для бизнеса технологии с теми, куда компании на самом деле отправляют патчи.

Самый большой разрыв оказался у языков программирования и сред выполнения. Критичными их назвали 53% организаций, а изменения отправляли только 17%. Для баз данных разница составила 31 пункт, а для операционных систем – 30.

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

На основной диаграмме отчета 36% участников отдельного блока сообщили о частых задержках продукта из-за отсутствующих функций или исправлений. Среди организаций с 5 000 сотрудниками и более доля выросла до 54%. В таких случаях 49% компаний создают внутренние обходные решения, а 30% поддерживают собственные патчи или форки.

Что участники проектов получают взамен

Авторы отдельно спросили 252 респондентов, как участие повлияло на работу их организаций. В ответах появились еще несколько заметных чисел.

• 44% часто или очень часто добивались включения нужных функций в план развития проекта;

• 55% заметили более быстрые ответы сопровождающих на сообщения об ошибках и проблемах безопасности;

• 53% узнавали о важных изменениях как минимум за месяц;

• 66% сообщили об ускорении разработки продукта.

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

При регулярной работе с проектом (и коммуникацией с мейнтейнерами) компания также раньше узнает о планах, понимает требования к PR и может предложить изменение до того, как внутренняя ветка далеко разойдется с исходным кодом. Даже отклоненный патч помогает понять, в какую сторону развивается проект и стоит ли дальше ждать включения изменения.

Когда форк становится внутренним продуктом

Любопытно, что авторы отчета рассматривают внутренние форки как форму технического долга. Такая оценка, на наш взгляд, подходит не для каждого случая. Некоторые изменения слишком специфичны для внутренней инфраструктуры, содержат закрытые интеграции или расходятся с целями основного проекта. Патч безопасности тоже иногда приходится выпускать раньше, чем закончится публичное обсуждение.

Технический долг появляется уже тогда, когда временное расхождение веток становится постоянным, а команда продолжает относиться к форку как к обычной внешней зависимости. Между тем у него могли появиться собственные версии, свой график релизов и отдельный набор рисков.

Отчет не дает правила, по которому каждое изменение следует возвращать авторам. Он показывает, насколько часто компании сочетают использование готовых компонентов, внутренние форки и работу с исходными проектами. Для каждого измененного компонента команда должна ответить на три вопроса.

• От какой версии и какого коммита отделилась внутренняя ветка?

• Какие собственные патчи в нее вошли и какие проблемы они исправляют?

• Кто следит за изменениями исходного проекта и принимает решение о синхронизации?

Если этих ответов нет, значит внешняя зависимость уже превратилась во внутренний продукт, но компания пока не начала им управлять.