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

в 8:30, , рубрики: arenadata, open source, open source в России, picodata, интервью, константин осипов, менеджмент, стратегическое управление

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

Константин Осипов, основатель Picodata (фото из архива Arenadata)

Константин Осипов, основатель Picodata (фото из архива Arenadata)

Если начать разговор с истории 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, а также последующие открытые проекты.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Команда Picodata (фото из архива Arenadata)

Команда Picodata (фото из архива Arenadata)

Как вы подошли к использованию 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, HashiCorp и подобных им.

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

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

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

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

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

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

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

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

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

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

Фотография — Slidebean — Unsplash License

Фотография — Slidebean — Unsplash License

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

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

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

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

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

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

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

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

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

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

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

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

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

Автор: dmitrykabanov

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js