«Перебросить код через стену из юристов — еще не значит сделать его открытым», — Константин Осипов, основатель Picodata

Продолжаю рассказывать об open source в России. На этот раз удалось пообщаться с @kostja ^[1]об открытой разработке с точки зрения ^[2] стратегии и управленческих аспектов. В том числе поговорили о лицензиях, работе с сообществом и интеграторами.

Если начать разговор с истории Tarantool, могли бы вы рассказать о том, как технология пришла в open source? В каком контексте было принято это решение?

Ещё до Tarantool я много лет занимался разработкой открытого программного обеспечения в компании MySQL. Мы экспериментировали с бизнес-моделями, поддержкой. Работа над открытым проектом была одним из условий моего перехода в Mail.ru в 2010 году, хотя мое взаимодействие с данной компанией началось задолго до этого момента — с консультаций по MySQL и выступлений на профильных конференциях.

В целом с начала 2000-х практически 100% программной инфраструктуры Rambler, Yandex, Mail.ru и похожих компаний составлял открытый LAMP-стек (Linux, Apache, MySQL, PHP/Perl). Также примерно в это время Игорь Сысоев опубликовал nginx. Все эти решения динамично развивались, поэтому лучшие разработчики старались участвовать именно в открытых проектах. Думаю, всё это внесло вклад в решение Mail.ru открыть код.

Первый публичный коммит (Initial public import) Tarantool/Silverbox был опубликован ещё до моего трудоустройства в августе 2010-го и составляет около шести тысяч строк кода на С. (Для сравнения: код Picodata сегодня — сотни тысяч строк, не считая third-party-модулей).

Однако важным было не столько само открытие кода (тогда это называлось «throw the code over the wall»), сколько открытие процесса разработки, а также — работа с сообществом. Даже сегодня разницу понимают далеко не все, и коммерческие вендоры используют открытый исходный код лишь как один из методов маркетинга. Для устойчивого развития открытых проектов необходимо сильное сообщество. Именно это я и попытался привнести в Tarantool, а также последующие открытые проекты.

Могли бы вы рассказать чуть подробнее об опыте ^[3] развития сообщества Tarantool? Какие моменты вы бы пересмотрели, если бы занимались им сегодня?

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

В Apache Software Foundation, Linux Foundation мы также видим живое участие множества компаний, в первую очередь, вкладывающих в программные решения свой труд в виде патчей, баг-репортов и т.д. Однако я не припоминаю значительных contribution в Tarantool со дня его основания. С образованием Picodata мы пытаемся изменить эту ситуацию.

Если же говорить о сообществе исключительно как о пользователях и клиентах, то все это ближе к классическому маркетингу, чем может показаться. Участие в конференциях, написание статей и, конечно же, бенчмарки — всё это помогает привлечь клиента.

В связи с последними событиями по отстранению российских разработчиков от участия в международных проектах, таких как Linux, и просто закрытием исходного кода открытых проектов, таких как Greenplum, с интересом ^[4] наблюдаю за попытками российских участников самоорганизоваться.

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

В ранних заметках о Tarantool вы упоминали ^[5] крупные компании, которые на тот момент уже использовали решение. Как вам удалось заполучить таких клиентов?

Это было значительно легче, чем добиться признания в США и Европе. Работали личные связи и опыт взаимодействия с пользователями, который я получил в MySQL.

Да и специфика Tarantool такая, что он интересен в основном крупным компаниям, где есть высокие нагрузки. В Вымпелком мы попали с легкой руки разработчиков Mail.ru, вышедших на один из проектов. В Альфа-банк — после выступления на HighLoad.

Были и неудачи: так, Сбербанк серьёзно выбирал между Tarantool и Ignite, но остановился на последнем, в том числе из-за отсутствия на тот момент коммерческой зрелости у Tarantool. Хотя со временем у нас появились специализированные кейсы, которые можно было проецировать на определенный сектор — например, банковский, телеком и проч.

Сегодня сложившаяся популярность Tarantool нам в чём-то даже мешает. Picodata — это качественно иной продукт, но мы только начинаем прикладывать усилия, чтобы рассказать об этом рынку.

Как вы приняли решение о начале работы над Picodata?

Tarantool со временем получил ряд структурных ограничений, которые можно было исправить, только в изрядной доле начав всё с нуля. Я — насколько возможно — подробно рассказываю ^[6] об этом в выступлении на конференции Database Internals. Это, в первую очередь, такие возможности продукта как управление кластером, расширяемость, поддержка SQL. Отдельно можно обсуждать пригодность Lua для масштабных проектов с in-memory-data-grid технологиями. Мы для этих задач применяем Rust.

Само же решение было эмоциональным.

Даже после ухода из VK компания сохранила за мной права мейнтейнера проекта. Как мейнейнер, я считал себя ответственным за качество кода, и уже спустя полгода после ухода «ревертнул», т.е. удалил один из патчей, который — по моим представлениям — не соответствовал критериям качества. После этого компания отобрала у меня права на репозиторий, а я — сделал форк.

Как выглядела команда Picodata на момент запуска? Могли бы вы также охарактеризовать изменения в команде за несколько лет развития компании?

Компания стартовала как служба технической поддержки. Штат в 2019 году составлял пять человек. В 2020-м мы начали писать собственный код (конечно же, открытый). В 2021-м — строить собственные решения на его основе.

Тут стоит сказать, что немало моих бывших коллег из Mail.ru связали судьбу с трудовой миграцией. Слышал, что на Кипре и в Лондоне алюмни-сообщества — одни из самых больших. Picodata — это remote-first компания, и так сложилось, что у нас в основном работают ребята, для которых вопрос с выбором места жительства не стоит.

В 2021-м в команде было уже 12 человек, и мы зарегистрировали ПО Picodata. Постепенно зрелость нашего продукта росла, как и продажи. К слову, мы завершили сертификацию ФСТЭК ^[7] (двухгодичный процесс доработок и взаимодействия с регулятором).

Сегодня продуктовая команда — около 20 человек, и ещё около 20 занимаются поддержкой и внедрениями. Есть ребята из самых разных мест, мы активно нанимаем стажёров. В целом команда неоднородная, но все по-хорошему «болеют» общим делом.

Как вы подошли к использованию open source-стратегии на старте Picodata?

Когда у нас начали появляться внутренние наработки (2021 год), мы сосредоточили усилия на развитии Rust-модуля. Для нас было критичным сделать его открытым, чтобы VK не защищался от него, и модуль нормально работал с Tarantool. Поэтому мы выбрали open source-стратегию, продолжив развитие уже существовавшего модуля из сообщества. Так же пошло и с Picodata. Нам нужно сообщество, чтобы получать обратную связь о продукте. Нам нужно поддерживать открытую версию, чтобы заказчики понимали, что vendor lock-in отсутствует.

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

Корпоративные версии включают доп. возможности по безопасности, интеграцию с корпоративным ландшафтом и изменения с учетом сертификации во ФСТЭК. В целом в основе экономики open source-вендора была и остаётся идея о разделении труда, сформулированная ещё Адамом Смитом. Разработчики открытого ПО — это, в первую очередь, эксперты в своей области, которые экономят время и деньги клиента. 

Можно ли говорить о том, что для российского рынка характерен интерес к определенному типу услуг? Что сейчас нужно заказчикам?

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

В свою очередь, мы максимально адаптировали продукт под существующий корпоративный ландшафт. Наш основной протокол взаимодействия — PostgreSQL, также мы поддерживаем протокол Redis и ведём разработку протокола Cassandra. Это позволяет мигрировать на отечественное ПО, минимизируя изменения в прикладном ландшафте.

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

Могли бы вы немного рассказать о сообществе Picodata? Кто вносит вклад?

Picodata — активный участник Rust-сообщества. Наши внешние контрибьюторы — это, в первую очередь, участники Rust-экосистемы. Часто это — студенты, которым интересно получить опыт разработки системного ПО и поучаствовать в открытых проектах, либо опытные разработчики на других языках программирования, интересующиеся Rust.

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

Если говорить о стратегическом партнерстве с Arenadata, как вы к нему пришли? Участвуют ли специалисты Arenadata в развитии ваших core-технологий?

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

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

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

Платформенная стратегия также играет ключевую роль с точки зрения выбора вектора развития бизнеса и соответствующей лицензионной политики. Возьмём две успешные западные компании: Red Hat и MongoDB. Первая сохранила, насколько возможно, открытую лицензию и является одним из ключевых спонсоров развития ядра Linux, кластерной файловой системы Ceph и других открытых проектов. MongoDB же сменила лицензию своего основного продукта на проприетарную и сфокусировала усилия на развитии MongoDB Atlas — облачной версии ПО. Многие другие вендоры СУБД, например, CockroachDB, Redis Labs и ScyllaDB также меняют лицензирование на проприетарное.

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

Как вы относитесь к общемировому тренду на source available? На примере кейсов с изменением лицензий Elastic ^[8], HashiCorp ^[9] и подобных им.

Чтобы ответить на этот вопрос, я попробую обозначить критерии открытого ПО и придать им вес, который мне кажется релевантным. Для меня открытое ПО — это:

• права широкого круга участников на исходный код;

• широкий круг пользователей такого ПО;

• ПО решает сложную, при этом широкораспространённую проблему уникальным способом, то есть «экономика масштаба», которая делает осмысленным создание разделяемой ценности, а не решение задачи локально участниками сообщества;

• внятная, устойчивая бизнес-модель развития;

• наличие открытой модели работы с сообществом, публичной дорожной карты, процесса принятия решений;

• наличие внешних контрибьюторов, их существенный вес, независимость от воли одного разработчика или одной компании;

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

Если понятие «открытости» ПО оценивать по несколько более полному набору критериев, то большинство событий по смене лицензий — не самые значительные. На фоне закрытия отдельных продуктов менее заметно, но значительно растёт доступность и зрелость открытых компонентов, из которых эти продукты состоят. Основная причина закрытия проектов — венчурная природа компаний, стоящих за ними. Даже самые лояльные венчурные фонды не готовы «замораживать» инвестиции на десятилетия, а для возврата капитала необходимо показывать устойчиво растущий финансовый результат.

Считаю, что российскому открытому ПО необходимо искать собственный путь и не ориентироваться на мировые тренды. С одной стороны, у нас есть большой риск оказаться в замкнутой экосистеме. Если экосистема будет закрытой, это приведёт к отставанию и потере конкурентноспособности. В СССР тоже были СУБД, но кто знает о них сегодня? Если же мы сможем сохранить открытость нашей экосистемы, то на фоне повального закрытия западных продуктов это может стать ключевым конкурентным преимуществом. У России есть отличный опыт экспорта технологий, например в ядерной энергетике, почему бы не распространить его на инфраструктурное ПО?

В своих проектах вы в основном используете ^[10] лицензию BSD-2. Могли бы вы рассказать, почему остановили свой выбор на ней?

Стоит отметить, что MySQL использует GPL-лицензию, а PostgreSQL — BSD-2. Один из ранних участников проекта Tarantool — PostgreSQL committer, а ныне со-основатель компании Postgres Professional. В наших с ним дебатах о том, какая открытая лицензия самая правильная, победила BSD-2. Оглядываясь назад, считаю выбор оправданным.

«Виральность» GPL в действительности работает против создателей, хотя и бытует мнение, что GPL больше способствует коммерческим внедрениям. BSD-2 устраняет барьеры при создании derived software, а это, в свою очередь, и рождает ту самую экосистему, которая так необходима по-настоящему открытому ПО.

Возможен ли сейчас, на ваш взгляд, выход на международные рынки?

Сегодня, кажется, это — непреодолимая история. Даже на рынках Юго-Восточной Азии сформирована устойчивая привычка работать с западными брендами. Она практически не связана с технологиями под капотом того или иного продукта, дело в сложившемся массовом восприятии. Для работы там нужен сильный международный бренд, причем даже ведущим российским вендорам. Тогда положение дел может измениться.

На сайте компании вы отмечаете, что сотрудничаете с ИТ-интеграторами. Как в общих чертах выглядит такая работа? Какие тут есть особенности?

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

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

Если говорить об open source в России, появляется ли у интеграторов и компаний-разработчиков больше интереса к работе в открытом формате?

Если говорить о системном открытом ПО, то, безусловно, интерес есть. К сожалению, процесс взаимодействия с вендорами и экосистемой всё ещё не выстроен. Миссия системного интегратора в том, чтобы, имея опыт внедрения различных решений, предоставить клиенту выбор, максимально отвечающий его запросу. В случае с открытым ПО эта миссия нередко заводит системного интегратора в ловушку. Одна из тупиковых стратегий — это построение решений на основе community-версий открытого ПО и «терминация» на интеграторе всех обязательств по поддержке таких решений.

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

Другая распространённая сегодня тактика — это «перелицовка» открытого ПО под собственную разработку. Мы сегодня видим огромное количество клонов PostgreSQL, платформ данных, платформ для интернета вещей, искусственного интеллекта ^[12]. Всё это — открытое ПО, преподносящееся различными интеграторами как собственная платформа. Импульс «тоже» стать вендором открытого ПО возникает из непонимания влияния экономики масштаба. Век подобных «продуктов» обычно недолгий, ведь в долгосрочной перспективе это бьёт, в первую очередь, по самим интеграторам: создаёт красный океан конкуренции, в котором все интеграторы предлагают одно и то же, при этом не владея экспертизой и не создавая добавочной стоимости. В глазах клиента этот шаг лишает интегратора образа непредвзятости, так необходимой для того, чтобы заслужить доверие.

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