Продолжаю рассказывать об опенсорсе в России — стратегиях и опыте развития российских организаций на базе открытой разработки. На этот раз на связи команда Аэродиска, которая делится историей запуска своего первого открытого проекта.
В интервью поучаствовали сразу несколько специалистов компании, поэтому рассказ получился подробный и разносторонний. Мы поговорили об особенностях открытой стратегии и ключевых возможностях Open vAIR — решения, лежащего в её основе.
Были ли у вас попытки запуска открытых проектов до Open vAIR? Что из себя представляет данное решение? Какие предлагает возможности?
Александр Тихонов
руководитель направления Open source
Это — наш первый open source-проект. До этого попыток выхода в открытую разработку у нас не было. Open vAIR мы изначально задумывали с прицелом на развитие в open source, хотя первоначальная разработка была закрытая. Мы смотрели, получится или нет, чтобы выложить более-менее достойный MVP.
Если простыми словами, мы сделали платформу, на которой реализована система виртуализации. Её можно установить как дополнительный софт, очень условно как VMware. Вам не нужно выделять сервер под это, какое-то отдельное устройство. Вы ставите решение рядом со всем остальным, чем пользуетесь каждый день.
Идея родилась у нас в отделе виртуализации. Получилось так, что через пару лет после запуска коммерческого vAIR мы решили двигать не только наши продукты (СХД и виртуализацию), но и вносить вклад в открытую разработку и делиться опытом.
Как только появилась идея открытого проекта, мы согласовали её с руководством и начали развивать силами небольшой команды. Это был 2021 год.
В этом проекте мы поставили перед собой цель протестировать ряд архитектурных решений и создать систему виртуализации с прицелом на то, чтобы успешные практики можно было внедрить внутри компании. При наличии интересных результатов нам бы хотелось, чтобы ими смогли воспользоваться и коллеги, занимающиеся разработкой СХД. С этой целью мы начали анализировать возможные варианты реализации, погружались в разные концепции и в итоге выбрали подход Domain-driven design.
Ориентировались ли вы на уже существующие решения в целевой нише? И сочетается ли Open vAIR с другими вашими разработками?
Есть Ovirt, еще одно из ближайших — Proxmox, хотя наше решение отличается. Однако многие сравнивают с Proxmox, но его не так легко кастомизировать. Еще он забирает у тебя какое-то одно устройство. Ты выделяешь сервер, и больше там ничего быть не может. Нам же хотелось сделать что-то максимально удобное, чтобы можно было бы использовать без дополнительных ресурсов. Например, есть вот у тебя ноутбук, и ты уже можешь использовать решение.
Что касается совместимости — к нам поступали запросы на интеграцию сторонних open source-инструментов с Open vAIR. Один из примеров не относится напрямую к виртуализации: речь шла о решениях для бэкапирования. Нам предложили, сказали, что было бы здорово, было бы удобно. Мы изучили, какие инструменты применяются для этих целей, и реализовали интерфейс, позволяющий подключать внешние решения.
Архитектура Open vAIR как раз позволяет расширять и кастомизировать его. Новый функционал добавляется как отдельный модуль. Для подключения таких модулей у нас есть готовые инструменты и есть документация — можно посмотреть на примере, как это делается. Модули могут содержать любую бизнес-логику, будь это система мониторинга или автоматизации. У нас есть готовые инструменты, чтобы все это подключать.
При этом можно не опасаться, что система упадет в силу проблем с отдельным модулем. У нас логика изолирована. Если модуль ломается, он не рушит остальное.
Такие «адаптеры» для модулей мы описали в документации. В целом же можно использовать наше решение as is, кастомизировать и закапываться глубже. Если что-то не понимаешь, то всегда можно задать нам вопрос.
В своем материале вы говорите о стремлении задать стандарт. Могли бы вы подробнее рассказать, речь о стандарте на уровне определенного класса решений? В чем могут быть преимущества такого стандарта?
«Стандартом» мы это обозвали уже по мере реализации. Дело в том, что сделать подобное решение на основе, допустим, профессиональной литературы не так легко. Чтобы заставить все это работать, нужно несколько лет «танцевать с бубном». В открытом доступе нет решений всех проблем, а если и есть, то крайне упрощенные. Их сложно развивать в серьезные технологические продукты.
Здесь же мы реализовали и обкатали определенный подход. Мы изучили теорию, на практике осуществили и теперь знаем, как это делается. Наш подход мы используем как стандарт. Новые наши продукты — не все, но часть из них — отталкиваются от этого стандарта. Зачем это нужно? Потому что всегда сложно запланировать, как будешь масштабироваться, а этот подход позволяет делать это свободно.
Ты не тратишь годы на то, чтобы придумать заново велосипед, заставить все работать. Уже есть стандарт того, как это нужно делать.
Как вы оценивали потенциальное влияние открытого подхода на компанию в целом, на развитие других её направлений и работу с сотрудниками?
Забавно, что коллеги из отдела СХД — основного нашего продукта — долгое время подшучивали над нами, мол, мы возимся с каким-то проектом, который не приносит прибыли. Но со временем начали заглядывать в наш код, задавать вопросы, проявлять интерес. Поняли, что с точки зрения понимания архитектуры мы уже ушли далеко вперед.
Сейчас они смотрят, что и как мы делаем. Мы прокачали технические компетенции, провели серьёзный ресёрч — и всё это теперь может пригодиться им. Они видят не теорию, а работающий результат. Теперь, приступая к новым разработкам и тестированию, они используют наш Open vAIR — он оказался эффективным, экономнее расходует ресурсы и позволяет запускать больше виртуальных машин.
Вы возглавляете open source-отдел. Это — относительно редкое явление, когда в компании выделяют такую структуру. Получается, компания выделила полноценные ресурсы, команду на открытую разработку?
Изначально мы начинали внутри отдела гиперконвергентной разработки, занимавшегося основным продуктом — vAIR. Тогда мы представляли собой небольшую группу специалистов, которые параллельно занимались чуть отличающимся направлением. Со временем эта инициатива выросла в полноценный проект, и теперь это уже отдельная команда, которая пять дней в неделю сосредоточена на развитии open source-решения.
Есть ли у вас какие-то метрики, по которым вы отчитываетесь перед руководителями? Как они могут отслеживать вашу работу?
Да, конечно, люди же тратят на нас деньги и хотят видеть, что мы делаем. У нас полноценный отдел разработки, у нас есть road map на год. Мы расписываем квартальные задачи, делаем спринты. На спринт может зайти любой сотрудник компании или кто-то из руководства, чтобы увидеть, кто и какие задачи сейчас делает, как они оцениваются по времени и так далее. Около полугода мы дублируем задачи на открытую канбан-доску. Там можно видеть, кто и что сделал. Если какой-нибудь человек со стороны изъявит желание, он может взять какую-то задачу и отправить нам решение.
Как вам удается балансировать свои планы по развитию открытого проекта и «хотелки» сообщества? Или таких вопросов пока не было?
Мы не предвидим конфликтов в плане интересов контрибьютеров и компании. Если к нам приходит контрибьютор, ему нравится продукт, и он хочет развивать его в своем направлении, мы только поприветствуем его. Такой опыт может быть интересен, а специализированный функционал может дополнить наше решение.
Для такого взаимодействия мы и делаем открытый проект. Например, чтобы получать обратную связь. Когда приходят люди со стороны и делятся мнением, это ценно. Особенно студенты очень активно предлагают интересные вещи. Это — расширение нашего кругозора и то, что нам, собственно, и нужно.
Как вы выбирали подход к лицензированию?
Мы долго выясняли, разбирались, как лучше сделать. Но пришли к пониманию того, что люди в основном доверяют Apache-лицензиям. Такую и выбрали. В том числе она позволяет в дальнейшем применять и другие лицензии на отдельные части продукта. От copyleft-подхода мы отказались, он не такой гибкий.
Есть ли у вас видение картины открытого развития проекта, допустим, в рамках пары-тройки лет? Допустим, это может быть количество новых модулей, доработок и так далее. На что примерно прицеливаетесь?
Александр Калинин
руководитель отдела развития продуктов
Мы работаем над продуктом с 2021 года — он еще молодой. Буквально в конце прошлого года мы сделали большой открытый релиз. Но мы нацеливаемся на формирование сообщества контрибьютеров, которые будут с нами на одной волне, в доверительных отношениях. Мы будем вместе создавать и развивать удобные продукты. Open vAIR — это только первый проект в нашем направлении.
У нас есть и другие планы, наработки. Мы хотим стать точкой сбора для энтузиастов, экспертов и для тех, кто в целом понимают, что такое open source и его полезность. Через пару-тройку лет мы видим свое участие в развитии уже нескольких продуктов, которые помогают людям в их деятельности.
Важно, что мы не стали выходить в открытое поле с «сырой» инициативой. Наоборот, сначала Александр и команда вложили время и усилия в проработку архитектуры, развитие экспертизы и поиск оптимальных решений. Мы создали качественный продукт — и только после этого открыли его миру.
Сейчас мы на этапе, когда начинаем выстраивать диалог с первыми участниками сообщества и совместно развиваем проект дальше.
Изменились ли ваши контент-активности с началом open source-истории?
Валерия Сумина
Специалист по маркетингу и рекламе
Раньше мы меньше рассказывали о разработке и не так активно что-то публиковали для аудитории разработчиков. Целевой аудиторией коммерческого продукта были системные администраторы. Open vAIR отличается от коммерческого, поэтому мы начинаем больше говорить о том, как он устроен.
Уже активно собираем комьюнити. Планируем делать митапы, выступать на конференциях и знакомиться с такими же энтузиастами.
Как — по вашему мнению — разработчики open source-проектов могут защитить себя от копирования и «переупаковки» открытых решений?
Александр Тихонов
руководитель направления Open source
Во-первых, мы не стали выкладывать сразу все фичи, которые только можно, чтобы не убивать коммерческий продукт. Мы выпустили MVP и далее будем разрабатывать его совместно с сообществом. С учетом того, как это видят его участники. Мы хотим развиваться совместно сообществом, наращивать его. Тогда нам будет нечего бояться. Это — самое главное, что может быть.
Если говорить о связи открытого продукта с коммерческим, то они разные. И скорее последний что-то потихоньку берет из Open vAIR, а не наоборот.
***
Александр Калинин
руководитель отдела развития продуктов
У нас есть идеи о том, как могут пересекаться open source-решения с коммерческими. Это будут технологии, которые дополняют друг друга.
Мы видим, как развивается отрасль, и понимаем, что положительный эффект от открытого развития технологий для коммерческих продуктов возможен, но он не может и не должен быть прямым, каким-то топорным с точки зрения заработка.
***
Александр Тихонов
руководитель направления Open source
Чего мы не будем делать с точки зрения «защиты» — это «патч-бомбы». Когда кто-то сделал форк открытого проекта, доработал его под себя, а потом выходит патч, и все ломается — появляются конфликты. Получается, что нужно забить на свой форк, делать новый и опять реализовывать ту же логику, которая уже была реализована. Вот такого мы делать точно не будем. Это уже не open source.
P.S. Пара ссылок по теме проекта: сайт, GitHub, тг-сообщество.