В начале лета меня пригласили на Data Fest 2025 в секцию по менеджменту и научным инициативам в open source. Делюсь расшифровкой доклада, но не своего, а одного из коллег по секции. Это — Александр Нозик, директор Центра научного программирования.

Научный центр существует в рамках МФТИ и как некоторая отдельная сущность со своими разработками. Александр также выступает в роли преподавателя в МФТИ и руководит российским KUG (Kotlin User Group), а также уделяет много внимания раскрутке open source-проектов, связанных с индустрией — производством, промышленностью.

Далее рассказ идет от лица Александра, который согласился опубликовать его в моем блоге на Хабре (видео его доклада можно посмотреть или послушать здесь). Тема показалась мне одной из центральных в разговоре о развитии open source в России.

@darksnake: Начну с исторической справки о том, что моей группе и мне удалось сделать в рамках open source. У нас есть экосистема KScience — посмотреть основные проекты можно тут и тут. Все это родилось из необходимости анализировать данные физических экспериментов, конкретно — Troitsk nu-mass — в 2006-м.

Мы поняли, что нет смысла делать наши проекты закрытыми, поэтому они исходно развивались как открытые. Существенный буст случился, когда пошло развитие Kotlin. Так получилось, что я оказался заметным в этой экосистеме, а open source-проекты с этого момента начали у нас развиваться активнее.

Проект Controls-kt у нас флагманский. Это — основной кандидат на коммерциализацию и внедрение. 2023 год можно обозначить как начало коммерциализации нашего опенсорса. KMath — это самая большая наша библиотека. Она задумывалась как исследовательская, но сейчас уже внедрена в одном из крупных банков. Также есть индустриальное внедрение других наших библиотек. Путь к коммерциализации наших open source-разработок занял много лет, но этот процесс развивается.

Открытая экосистема KScience

Чуть подробнее о наших ключевых проектах:

• KMath — это высокоуровневый фреймворк для математических вычислений. Его функция — интеграция высокопроизводительных библиотек и сведение в единое пространство типов. Такой подход позволяет работать с разными фреймворками, но с одним application-интерфейсом. И строить свои реализации, которые позволяют работать без внешних зависимостей.

• DataForge — это, наверное, наименее известный наш проект, но с него все начиналось. Он был сделан для автоматизированного анализа данных в эксперименте Troitsk nu-mass. Сейчас только-только возникают идеи, как его коммерциализировать. Область применимости: автоматизированный ленивый анализ данных при работе со сложными системами данных.

• Snark — это дипломная работа моего аспиранта и партнера Сергея Терентьева, связанная с генерацией. Изначально он был ориентирован на генерацию статей, решал проблему отсутствия фреймворков для работы с данными и со статьями. Но сейчас мы его используем и для каких-то сайтов, связанных с данными — например, сайт Центра научного программирования работает на этой платформе. Какой-то интерес к коммерциализации здесь уже есть — в частности, в сфере автоматической генерации инженерной документации. И тут нужно сделать важное замечание, что это не LLM, а именно детерминированная генерация блоков текста.

• VisionForge/Plotly-kt — эти два проекта объединены в одну систему, которая используется в науке. Но мы внедряем её и для визуализации данных индустриальных процессов. Платформа научная, но уже может конкурировать с такими проектами, как Plotly-dash и Pannel. Причем она имеет ряд дополнительных функций, которых в Plotly-dash и Pannel нет. Например, трехмерную визуализацию и визуализацию в реальном времени.

• Controls-kt — флагманский проект, который создавался для обработки данных экспериментов. Мы его раскручиваем для создания систем сбора данных и систем с интегрированными инструментами анализа данных. Всем в последнее время хочется ML и AI «воткнуть» в процесс сбора и анализа данных на лету, а Controls-kt позволяет делать это без машинного обучения. Сейчас идет его внедрение в индустрии, хотя это и небыстрый процесс.

• Maps-kt — этот проект тоже стоит отметить, поскольку он единственный, который делался сразу под коммерческое использование. И самое забавное, что у него пока коммерческого использования нет — в изначальном виде он не подошел. Maps-kt поддерживает мультиплатформенную картографию и динамическое отображение данных на картах и схемах.

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

Open source «поддерживаемый»

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

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

Сперва давайте посмотрим, какой путь прошел open source в целом (и где он сейчас). Вообще, первый этап развития open source я называю «эрой эйфории». Код пишут программисты, а корпорации берут этот код, используют его в своих продуктах и продают (бедные программисты ничего за это не получают). Решение, предложенное Столлманом, на тот момент казалось замечательным (сейчас, наверное, это не совсем так). Он предложил сделать код бесплатным, открытым (free and open source software), т.е. трудиться как сообщество и создавать продукты, которые удобно использовать в этом сообществе. Если корпорации хотят, они могут приходить и покупать лицензии за деньги.

Этот подход во многом вылился в концепцию General Public License разных версий. В общих чертах она заключается в следующем: а) если хочешь участвовать в нашем сообществе, ты тоже должен писать библиотеки с открытым кодом, б) если хочешь использовать плоды наших трудов, тоже используй открытый код и ту же самую лицензию.

Проблема в том, как это продавать?

Изначальная концепция предполагала, что компании могут напрямую договориться с авторами о приобретении кода под альтернативной лицензией. Однако практика показала несостоятельность такого подхода. Для единичных проектов (например, отдельных продуктов уровня Linux) эта схема еще может работать — компания действительно может приобрести права. Однако ситуация меняется при работе с комплексными решениями, включающими цепочки взаимосвязанных библиотек c GPL: договориться с авторами всех библиотек в цепочке поставок невозможно. Приходится как-то изгаляться: поставлять GPL-модули отдельными кусками, использовать LGPL, которая позволяет runtime-линковку, но несовместима с GPL — то есть возникает куча вопросов.

Тут возникает вопрос: зачем вообще делать код бесплатным и давать индустрии на нем зарабатывать? Ответ прост: сегодня основными контрибьюторами в open source являются именно корпорации.

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

Сейчас open source настолько большой, что индивидуальные инвестиции там просто тонут в вале денег, который идет от компаний. Зачем им это? Во-первых, чем больше людей посмотрит код, тем выше будет его качество. Закрытый код практически всегда хуже кода, который идет в open source — я это неоднократно наблюдал. Во-вторых, хорошая реклама, репутационная история. Мы все знаем про Microsoft, которая начинала как «корпорация зла». И во многом за счет open source сформировала хорошую репутацию.

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

Есть еще одна история с коммерческим open source. Все слышали про Apache Foundation или Eclipse Foundation. Наверное, чуть меньше людей слышали о Common House Foundation, OpenJS Foundation, хотя они поддерживают огромное количество востребованных открытых проектов. И есть множество других open source фондов, не говоря уже про Open Source Foundation и Linux Foundation.

Дело в том, что бизнес не всегда может платить open source-разработчикам напрямую — у него нет логистических механизмов, позволяющих это сделать. Поэтому компании посредством пожертвований заносят деньги в фонд, а фонд распределяет эти деньги. Важно, что фонд решает, какие направления перспективные, и где надо побольше денег, а где — поменьше. И такая схема более или менее работает. За последние год-два появилось огромное количество важных и нужных проектов, например, у Apache Foundation. И если раньше эти проекты были огромными, то сейчас большое количество нужных проектов разрабатываются одним-двумя разработчиками.

Есть еще один аспект, который справедлив для России. Я это называю «большой open source». Есть крупные проекты: Postgres, Kafka, Hadoop и так далее. И есть компания-поставщик, которая берет эти проекты, превращает в продукт и продает индустрии. Поставщик обеспечивает гарантии, стабильность и валидацию версий — все то, что собственное айти внутри индустрии, как правило, сделать не может. В то же время разработчики из компаний-поставщиков на безвозмездной основе помогают расширять этот самый «большой open source» — контрибьютят «наверх».

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

Еще один пункт, который важен именно для России. Первые годы после 2022-го многие приходили с запросами вроде «Сделайте нам аналог Microsoft Project» или других зарубежных решений. Но когда они видели ценник, им становилось грустно, потому что многие решения просто очень дорого и долго делать. Такие проекты по силам только гигантам вроде Microsoft или Honeywell. Единственный сценарий, по которому эти решения могут быть повторены в России, подразумевает объединение усилий нескольких больших компаний. А реализовать это возможно исключительно в формате open source. Другой модели кооперации больших бизнесов в области разработки айти сейчас не существует. Все остальное, включая государственный заказ, не работает.

Модель нового open source

Я хотел бы представить модель, которую мы не просто разработали, а уже обговорили с индустриальными партнерами. Здесь написано «новая модель open source». Но это, скорее, «модель нового open source» — как делать новые проекты и работать с ними.

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

Дальше в дело вступает системный интегратор, который берет готовый продукт и занимается его внедрением в индустрии. Основным результатом его работы являются гарантии. То есть интегратор предлагает не просто продукт, а его адаптацию под конкретную индустрию. Индустрии платят за такую услугу очень большие деньги.

Размеры стрелочек на схеме пропорциональны объемам денежных потоков (и количеству людей). Поддержкой ядра разработки занимаются до 10 человек, штат компаний-разработчиков — 100-200 человек, интегратор — это тысячи человек. Но главное для нас (как разработчиков технологии) то, что есть бизнес-механизм, по которому денежки доходят до разработчиков. При этом нужна некоторая нейтральная территория, которая не принадлежит какой-либо компании (без конфликтов интересов). С одной технологией может работать несколько разных разработчиков и несколько разных интеграторов, только за счет этого история становится окупаемой. Хорошие индустриальные связи, репутация в индустрии, налаженный нетворкинг, который позволяет не строить это все с нуля. Источник притока новых разработчиков и идей, это тоже очень важно. 

И если на Западе фонды вроде Open Source Foundation были организованы на индустриальных проектах, то в России есть свое очевидное решение для создания такого рода хабов — это вузы. Более того, некоторые учебные заведения уже начали двигаться в этом направлении. Зачем это вузам?

Во-первых, увеличение престижа — все немножко за него борются. Во-вторых, возможность обеспечить актуальную проектную деятельность для студентов. Им надо на чем-то учиться, и это что-то должно быть не просто учебной задачей, а чем-то реальным, практичным и полезным. В-третьих, это возможность привлекать деньги — все более актуальная история за последнее время, так как все меньше можно рассчитывать на государство в смысле обеспечения работы вузов. Вузам очень важно привлекать коммерческое финансирование в любом виде. Плюс это возможность на базе вуза делать компоненты для open source — не на базе GPL, а на базе Apache 2.0, MIT, которые позволят выстраивать поверх них какие-то коммерческие модули.

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

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

Выводы 

Open source — не просто игрушка для повышения статуса, а по сути, единственный способ создания больших проектов. Это — важный коммерческий инструмент, который и надо рассматривать в таком разрезе. Недостаточно полагаться на Linux, Postgres, Hadoop и так далее. Их не хватает, нужно создавать новые решения. И для этого нужны инструменты для финансирования. Один из вариантов — создавать хабы на бренде вузов.

Модель можно сделать экономически привлекательной — но я не буду уже приводить числа. Скажу только, что мы «побили» прописанную экономическую модель об людей, которые очень хорошо понимают в бизнесе, и они считают, что это можно сделать. Так что сейчас дело за практической реализацией и проверкой гипотез, которые у нас есть.

Есть стартовый капитал — большое количество проектов, с которых можно начать для того, чтобы уже думать про их внедрение. Напоследок хочу сказать, что на самом деле open source сообщество уже есть. В ИТМО существует полностью сформированный open source-хаб. Начинает развиваться такое же сообщество в ФКН ВШЭ. Ну и наше сообщество SPC тоже действует, пожалуйста, подключайтесь, если хочется пообщаться.