В опенсорс-чатах до сих пор (чуть ли не каждый день) спорят, является ли тот или иной проект по-настоящему открытым и по-любительски правильным. И в том же ключе сравнивают опенсорс от народа и коммерческий. К сожалению, в тумане флейма теряется главное: попыток совершенствовать подходы к открытому развитию технологий почти нет.
Попробуем исправить ситуацию и поговорить не о том, какой опенсорс теплее и ламповее, а о том, как взять лучше от двух миров: опенсорса профессионального (на плечах компаний) и любительского (на энтузиазме специалистов).
Почему (уже) нет смысла сравнивать
Спор о том, чей опенсорс лучше, продолжается вечность. На практике нового в таких дискуссиях мало. Чат-флеймы по теме опенсорса и проблем в этой области однообразны, и их с легкостью можно представить в формате компактного списка вредных советов:
Если начинаете разбираться в опенсорс-лицензиях, не забудьте сразу же оповестить честной народ о рисках копилефта и сорвать покровы с «вирусных» условий.
Со скоростью лучших стрелков Дикого Запада поправляйте всех, кто использует фразу «open source», потому что «у нас же есть свой хороший термин ‘’СПО’’». Термины обозначают разные сущности, но СПО-шерифа это не остановит.
Увидели опенсорс-проект — сразу дайте всем понять, что на самом деле перед вами «несвободная» технология (т.е. не «СПО»). Неважно, что разработчики просто открыто развивают решение и видят немало пользы в этом подходе.
Регулярно сожалейте о «несправедливости» в сфере опенсорса. Кто-то поменял лицензию на свои же открытые разработки? Выразите глубокую обеспокоенность этим. А еще лучше — почаще вспоминайте о старых временах, когда в опенсорсе были только пицца и энтузиазм, а компании не искушали нас открытыми решениями.
Кажется, это — основное. Разве что можно вернуться к дихотомии «любительский vs профессиональный» опенсорс. Однако здесь возникает вопрос, о чем же спор?
«Если под словом "профессиональный" понимать "получающий деньги за разработку", то в эту категорию попадают как корпоративные, так и частные проекты, потому что любой соло-дев может получать донаты… Но если "профессиональным" мы будем называть решение, написанное человеком с "профессиональными компетенциями", то в эту категорию также попадут почти все пет-проекты, — замечает разработчик Филип Храчек, чей пост по теме недавно обсуждался на Hacker News, Reddit и других площадках.
По размеру команды, развивающей открытый проект, также сложно однозначно сказать, что перед нами: профессиональный или любительский опенсорс. Компании и другие организации регулярно используют open source-проекты, которые поддерживает всего один разработчик. С другой стороны, корпоративные открытые проекты также часто развивают небольшие команды — об этом, кстати, говорил даже @veged из Яндекса.
Храчек же предлагает рассматривать опенсорс через призму ожиданий: высоких или низких. В качестве примера первых он приводит языки Swift и Go. Компании Apple и Google могут хоть завтра свернуть разработку, прекратить их развитие. Однако сообщество ожидает, что этого не случится, потому что организации продвигают эти технологии, предлагают их широкому кругу разработчиков. В противовес существуют тысячи и миллионы open source пет-проектов, ожидания от которых куда более скромные.
Это интересный подход к сравнению, и главное здесь — роль компаний в опенсорсе. За последние лет 10-15 она существенно выросла, причем этот факт отмечают исследователи в области менеджмента и стратегического управления.
Подобных работ множество. Так, в 2021 году в журнале IEEE Transactions on Software Engineering вышла статья международной группы исследователей, в которую вошли специалисты из Университета Шёвде, представители шведских технологических и консалтинговых компаний. Они отобрали восемь опенсорс-проектов — Apache CloudStack, Apache Solr, Bouncy Castle, Contiki-NG, Leshan, MariaDB, OpenStack и Papyrus — и провели интервью с 17 разработчиками, которые участвуют в их развитии, совмещая эту деятельность с работой в компаниях. В результате выяснилось, что некоторые контрибьюторы посвящали до 90% рабочего времени поддержке открытых проектов. Их работодателям такие проекты критичны с точки зрения развития технологических решений. Как отметил один из респондентов: «Если проект прекратит существование, наша компания погибнет вместе с ним — ведь на нем построено ядро нашего бизнеса».
В другой работе 2023 года специалисты из Университетов штата Орегон и Северной Аризоны провели серию интервью с 20 основателями и опенсорс-менеджерами из 17 компаний разного масштаба: от Microsoft до стартапов. Исследователи выяснили, что вовлечение компаний в такую деятельность, как правило, начинается неформально — обычно инициатива исходит от энтузиастов — рядовых разработчиков. Они добавляют функции и исправляют ошибки в открытых проектах, которые используют. Однако, как отметил один из респондентов: «Когда 300 систем полагаются на одну зависимость, эпизодического внимания становится недостаточно». Компании начинают систематически инвестировать время разработчиков в развитие опенсорса. Другой респондент поделился своим опытом: «В какой-то момент мы сформировали команду из 35–50 разработчиков, которая занималась поддержкой используемых в компании open source-проектов».
Однако, несмотря на рост активности и значимости организаций, в опенсорсе без сообщества не обойтись. Как видно из примеров выше, «любителями» и энтузиастами могут выступать такие же сотрудники компаний, которые пишут свои пет-проекты, используют и тестируют открытые разработки коллег. Именно поэтому важно больше говорить о том, как взять лучшее из двух миров: профессионального опенсорса в компаниях и любительского подхода, а не спорить, какой из них правильнее. Помимо прочего, это позволит выстраивать предсказуемые ожидания от открытых проектов и доверительные отношения между их разработчиками, сообществом и потребителями.
Отношенческая стратегия
Я поспрашивал коллег о любительском и профессиональном опенсорсе — о том, как он формировался, как выглядит у них в индустрии и компаниях (и какие возможности они видят в этой связи). И вот к каким выводам пришел с их помощью.
Во-первых, нужно выстраивать отношения с аудиторией вокруг качественного проекта (пусть иногда и экспериментального характера). Причем речь идет о том, что открытый проект должен быть не только интересным, но и хорошо документируемым, а главное — динамичным с точки зрения развития. Такие моменты, конечно же, остаются центральными в руководствах по оценке «успешности» открытых инициатив.
У нас профессиональный подход сложился как раз на стороне любителей. Энтузиасты сами экспериментировали с опенсорсом и хотели это делать не только на пет-проектах, но и с тем кодом, который пишут в компании. Это было и остается у нас основным драйвером перехода к профессиональному опенсорсу.
В целом всегда хочется больше участия энтузиастов, но их количество и вклад зависят от качества открытых проектов. Мы должны делать их такими, чтобы хотелось участвовать.
Мы открыли публичное превью SourceCraft — теперь можно диверсифицировать опенсорс по платформам, развивать открытые проекты в том числе и у нас. Мы работаем, чтобы сделать SourceCraft удобнее и интереснее для опенсорсеров
——————
Второе десятилетие XXI века стало парадом «каминг-аутов» компаний, заявивших о том, что они используют, причём существенным образом, OSS. Потребителями OSS стали крупные корпорации и правительства, а их потребности могут быть удовлетворены только разработчиками соответствующего масштаба.
На этом фоне изменился подход к развитию опенсорса. Изначально код писали энтузиасты — для опыта и исторической славы. В последние десятилетия лидерство перехватили коммерческие компании.
С начала 2010-х около половины всех коммитов в крупных опенсорс-проектах делаются в рабочее время, то есть — оплачиваются компаниями. Например, по данным исследования CNCF за 2023 год, 59 % разработчиков делают вклад в OSS в будни с 9 до 18, а 25 % занимаются этим full-time.
Это наглядно отражает переход от любительской разработки энтузиастов к системной разработке коммерческими компаниями, которые развивают открытый код не столько по идеологическим, сколько по практическим причинам
——————
СберТеху в этом году исполняется 14 лет. За это время мы накопили богатый опыт использования open source в самых разных форматах. У нас есть собственная AI-платформа для работы с кодом GitVerse а также проекты с открытым исходным кодом, которыми активно пользуются разработчики.
Например, мы в открытом доступе опубликовали исходный код инструмента для бэкенд-разработки и работы с данными Platform V DataSpace. Также мы активно используем open source в соответствии с лицензиями и дорабатываем его, что позволяет нам вносить свой вклад в развитие технологий.
На сегодняшний день мы пришли к формату виртуальной команды Open Source Programs Office. Эта команда отвечает за то, чтобы у разработчиков возникало меньше проблем с опенсорсингом, а бизнес и руководство понимали, зачем мы переводим проект или продукт в open source.
——————
Когда мы начинали работать с open source в компании АЭРОДИСК, это воспринималось больше как эксперимент — своего рода вызов себе: "Почему бы и не попробовать?". Как это часто бывает, энтузиазм быстро перешёл в конкретные результаты, и мы поняли, что настало время относиться к этому серьёзнее.
Так, постепенно в нашей компании сформировался профессиональный подход к работе с открытыми проектами: мы пришли к стандарту разработки, внедрили регулярные ревью и серьёзно занялись документацией, улучшили процессы и налаживаем обратную связь с сообществом. Это позволило нам не только улучшить качество своих решений, но и гораздо эффективнее использовать ресурсы.
Конечно, говорить о том, что сейчас всё идеально, было бы неправильно. Всегда есть к чему стремиться. Основная проблема, с которой мы сталкиваемся, — это ограниченность наших собственных ресурсов. Не каждая компания может позволить себе выделить ресурсы и вкладываться в open source, хотя многие проявляют искренний интерес и желание помогать. Нам не хватает рабочих рук и взглядов со стороны, которые могли бы значительно ускорить развитие проектов.
В связи с этим мы всегда рады новым контрибьюторам, будь то большие компании или энтузиасты-одиночки. Особенно приятно видеть, как некоторые участники становятся постоянными контрибьюторами и регулярно берут на себя решение задач, закрытие issue и внесение улучшений. Именно такие люди вдохновляют нас двигаться вперёд, делать больше и лучше. Мы стараемся развивать сообщество и с удовольствием отмечаем вклад каждого его участника».
Во-вторых, работать с аудиторией нужно проактивно — прилагать усилия в области контента: делиться опытом, проводить семинары и выпускать руководства.
Подобная активность, реализуемая на систематической основе, является признаком здоровья открытых проектов. Так, специалисты из Университетов штата Орегон и Северной Аризоны (про их статью я писал выше) приводят, цитату одного из респондентов: «Для открытого проекта критически важно разнообразие идей и мнений среди разработчиков». Кроме того, исследователи отмечают, что сотрудники, развивающие открытые проекты, регулярно принимают участие в подготовке руководств, статей и подкастов, делятся опытом по открытым проектам на конференциях и семинарах.
Действительно, важно различать взаимодействие с сообществом и профессиональными участниками рынка. С осторожным оптимизмом можно отметить, что, благодаря программе сотрудничества с вузами, вовлечение студентов и начинающих разработчиков в открытые проекты Arenadata в последнее время выросло.
Ключом к взаимодействию здесь служит открытость процесса разработки: открытый трекер задач, комментарии мейнтейнеров, репозиторий исходного кода, отдельная разметка для задач, доступных по сложности начинающим разработчикам. Это отличная возможность приобщиться к практике разработки индустриального ПО, повысить заметность собственного резюме.
Что касается нашего собственного вклада в открытые проекты, работа с open-source требует серьёзных вложений в процессы разработки и квалификацию команды. Чтобы сообщество принимало наши изменения, нужно строго соблюдать его правила: качественно документировать код, следовать стандартам, активно участвовать в обсуждениях и иногда писать тесты. Это трудоёмко, но позволяет влиять на развитие экосистемы
——————
Мы исходим из целей, которые ставят перед собой разработчики, выводя проект в open source. У всех разные потребности: кто-то хочет привлечь больше контрибьюторов, кто-то — проверить гипотезы, а кто-то — получить поддержку для бизнес-модели. В целом мы ориентируемся на то, чтобы наши проекты поддерживали другие разработчики.
——————
За открытыми решениями стоят как компании, консорциумы, так и отдельные специалисты, которых зачастую прёт не меньше, чем в чистых коммерческих компаниях (а то и больше). Но кейсы с полей им несут другие энтузиасты.
Компании часто получают популяризацию через сообщество. Например, за счет разработки правил определения уязвимостей или просто упоминания, что они что-то открыли в open source. При этом, коммерческие делятся своими разработками не всегда сполна, пример — статический анализатор Semgrep: движок открыт отчасти, правила формируются сообществом. Но то, что открыто — тоже крутое.
Опытные энтузиасты часто являют на свет толковые инструменты, например DeepSecrets — анализатор секретов Николая Хечумова, в который вложена душа автора и здравый подход по методам детекции.
В консорциумах, например в OWASP, также трудятся эксперты, но, когда проекты получают популярность, их может уже не хватать. В итоге решения поддерживают свое развитие в формате "для начинающих" и среднего класса. Часто не происходит развития по требованиям встраиваемости, производительности и ширине поддерживаемых технологий. Например, есть отличный проект DependencyTrack, но в нем уже сейчас исполнителей не хватает на все хотелки, а допиливать под себя может быть уже дорого. По сути, главный автор там один и много небольших контрибьюторов. Они крутые, но их мало.
Вот ещё пример: DefectDojo, решение для агрегации событий безопасной разработки. Это как раз пример энтузиазма без экспертизы. В первую очередь — инженерной, во вторую — эстетической. Так плохо сделать решение нужно постараться: напильник нужно доставать в первые дни использования. К сожалению, на каждой конференции об этом говорят, а исправляющих PR'ов всё нет. Видимо оно должно настояться или зайти под чьё-то опытное крыло.
Даже саму открытость программного обеспечения используют в качестве маркетингового инструмента — особенно в сферах, связанных с разработкой систем ИИ. Недавно специалист из Пекинского педагогического университета опубликовал работу, в которой утверждает, что стратегия разработчиков DeepSeek передать в open source пять компонентов — в том числе связанных с методами и библиотеками FlashMLA, DeepEP и DeepGEMM — безусловно помогла проекту получить конкурентное преимущество.
Мы открыли исходный код серверной части нашего корпоративного мессенджера больше года назад. Так как продукт коммерческий, не рассчитывали на участие комьюнити в развитии сервиса.
Мы пошли своим путем. Клиенты приходят к нам, когда им нужен защищенный корпоративный мессенджер. Чтобы каждый пользователь мог убедиться, что безопасность существует не только в описании продукта на сайте, мы открыли исходный код серверной части. Все прозрачно, каждый сотрудник компании, которая внедряет Compass, может проанализировать код на уязвимости и посмотреть, как сервис на самом деле защищает данные.
Так клиент может убедиться, что продукт, которому он доверяет свои данные, может их защитить. А мы получаем возможность улучшать продукт на основе реальной обратной связи
В-третьих, (продолжая мысль Евгения Перова) работа с аудиторией открытых проектов подразумевает проактивную обработку обратной связи. Интересно, что первые проекты, направленные на решение этой задачи, появились очень давно. Так, еще в начале 2000-х было представлено решение для сбора данных об имеющихся проблемах в коде, вкладе контрибьютеров и других аспектах развития открытых проектов. Разработчики решения еще тогда отмечали нехватку: а) механизмов контроля за быстрым ростом кодовой базы, б) методов мониторинга влияния изменений, в) инструментов для комплексной оценки состояния проекта. Сегодня эти потребности пытаются закрыть с помощью больших языковых моделей и интеллектуальных систем ИИ.
Своевременная реакция на обратную связь также важна — иначе есть риск оттолкнуть даже тех, кто регулярно участвует в жизни открытого проекта. Согласно исследованию специалистов из Университета Бари (Италия) и Университета Северной Аризоны (США), отсутствие такой реакции — одна из ключевых причин, по которым контрибьютеры покидают сообщество. Исследователи пришли к такому выводу на основе интервью с шестью разработчиками: пять из них были мейнтейнерами крупных open source-проектов, а один — работал в компании, которая сама развивает несколько открытых решений. Например, вот одна из цитат разработчика, который «откололся» от сообщества открытого проекта: «Я отношу себя к "спящим разработчикам"... Я сделал 60 коммитов и не получил ни одного отзыва, и предпочту больше не тратить время на этот проект».
Есть мнение о том, что уход разработчиков из открытого проекта — не катастрофа, даже если откалывается существенная часть сообщества. Однако группа исследователей из Бразилии, Бельгии и Нидерландов считает, что здесь не все так просто. Ученые проанализировали 1932 популярных GitHub-проекта, из которых выделили 315 заброшенных. Оказалось, что только 41% этих проектов смогли возродиться — найти новых мейнтенеров и продолжить развитие. Выяснилось, что в большинстве случаев инициаторами возрождения были специалисты, которые нуждались в конкретном проекте и столкнулись с необходимостью исправить критические ошибки.
Безопасная разработка изобилует объемом собственных вендорских решений, открытыми проектами и их «перекрашенными» в коммерцию собратьями, которые учатся собирать вторых. И везде есть свои энтузиасты, но разного качества и возможностей: от наличия времени и знаний, до видения рынка.
Над вендорскими решениями работают профильные специалисты, которые каждый день варятся не только в задаче «как сделать новую фичу», но и видят и понимают проблемы пользователей, которые им заплатили денег. И мы должны реагировать: не будет удобства и обратной связи — не будет бизнеса. Например, у нас в CodeScoring для этого есть и R&D и дата-аналитики и специальная служба Заботы о заказчике, которая разбирает изощренные кейсы, возникающие в полях.
Разговор только начинается
Феномен открытой разработки набирает обороты в российских компаниях и динамично развивается в мире. Поэтому разговор о том, как увязывать открытые корпоративные стратегии (open source-стратегии) с развитием сообщества и пользой для его участников, фактически только начинается и требует регулярного внимания, экспериментов и исследований, как и сами опенсорс-стратегии и бизнес-модели в данной области.
Код крупных свободных проектов уже разросся до огромных масштабов. Справиться с поддержкой и развитием таких систем уже нельзя без вклада более организованных и дисциплинированных коммерческих игроков.
Именно их работа в наше время составляет основную долю улучшений опенсорс-проектов. Мы радуемся, когда к развитию open source подключаются все новые компании. Чем больше игроков вкладываются в развитие ядра, тем крепче и надёжнее становится вся экосистема PostgreSQL.
Однако с этим связан и некоторый риск: новые сильные игроки могут изменить правила работы сообщества, что в дальней перспективе нарушит сложившиеся традиции, сделавшие Postgres столь успешным. Поэтому очень важно, чтобы компании продолжали ценить вклад и идеи отдельных энтузиастов и не делали открытый код заложником своих бизнес-интересов.
Пара других моих хабрапостов по теме:
