8 вопросов про Open Source проекты

Модератор круглого стола – Сергей Бережной, директор по взаимодействию с разработчиками в Яндексе; перевёл несколько проектов в Open Source во фронтенде (среди них – «Методология БЭМ»)

Олег Бондарь, Chief Product Officer YDB, вместе с группой единомышленников принимал участие в выводе базы данных в Open Source.

Егор Левченко, разработчик и амбассадор Open Source библиотеки doka.guide от Яндекс Практикум, разработчик Open Source библиотеки стилей в СберКорусе.

Иван Щеклеин, co-founder и CTO Iterative.ai, последние 6 лет – в команде разработчиков Open Source коммерческого проекта для девелоперов DVC (Data Version Control).

Материал подготовлен на основе онлайн-встречи YNDX Family, неофициального сообщества текущих и бывших сотрудников группы Яндекса. Присоединяйся к комьюнити, если ты тоже выпускник-яндексоид :)

Иван Щеклеин: Начну с себя. Наш продукт, DVC, это формат, который подразумевает Open Source, чтобы привлечь максимальную аудиторию. Мы бы не смогли инициализировать бизнес, если бы проект не был открытым: мы собираем большое коммьюнити разработчиков, и нам необходим широкий adoption.

Егор Левченко: Учитывая, что мы делаем документацию по web на русском языке, я считаю, что нужно опенсорсить всегда и при первой возможности. Ведь мы нацелены на начинающих разработчиков которым нужно, во-первых, где-то учиться, а во-вторых, получить опыт. Наша задача – дать эти возможности максимально просто и быстро.

Олег Бондарь: Я подойду с другой стороны: когда не стоит опенсорсить. Надо понимать, что Open Source проекты не бесплатные – их использование влечет для команды существенные накладные расходы. Кроме того, если ты не сможешь в дальнейшем взаимодействовать с комьюнити, не стоит заниматься Open Source. Если твой продукт в непонятном состоянии и ты не понимаешь, доведёшь ли его до конца – тоже не стоит.

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

Так что перед началом лучше спросить себя, готов ли ты вложить ресурсы и стоит ли оно того.

Сергей Бережной: Лицензии – дело тонкое. Мы помним кейсы MongoDB, Redis или Elasticsearch, когда облачные провайдеры, которые использовали решения разработчиков, заработали на них приличную сумму денег. Означает ли это, что им вообще не нужно было выходить в Open Source?

Олег Бондарь: Есть интересный противоположный пример: крупная компания Yugabyte, которая тоже делает распределённую базу данных, несколько лет пытались экспериментировать с лицензиями. Они начинали с разделения функциональности на открытую и закрытую, а также с бизнес-лицензий. Но в 2019 году полностью открыли свои исходники, потому что не получили приемлемый adoption. Я думаю, многие продукты с изначально открытой лицензией не смогли бы стать образцовыми сейчас, если бы запускались иначе.

Егор Левченко: Хочу затронуть другой аспект работы с лицензиями: целесообразность их внедрения. У нас в Doka – целый ворох лицензий. Например, в качестве лицензии на код платформы у нас используется eleventy от MIT. Другая – для контента. Мы не против, чтобы наш текст использовался на других ресурсах, но согласно лицензии, со ссылкой. Ещё одна лицензия – на изображения. Таким образом, наша документация тщательно отобрана и содержит чёткие правила использования. Поэтому я считаю,что важно осознанно подходить к выбору лицензий.

Сергей Бережной: Давайте разберём этот вопрос на примере юникорн-компании DataBricks. Она имеет такой статус, потому что в своём OS-сегменте делают настолько много, что никто и не захочет их обворовывать?

Иван Щеклеин: Мне кажется, нет. Data Bricks – это удобный облачный сервис с высоким спросом. Их заставляет оставаться на таком уровне то, что у них есть CS-компонент и лицензия поверх OS-решения.

Олег Бондарь: В этом смысле интересен их (Data Bricks) опыт как создателей Spark: они приобрели множество компаний и инструментов, инкорпорировали в свой продукт и создали сервис, базирующийся на Open Source продукте.

Сергей Бережной: Такой подход заставляет делать объём команды сильно больше, чем изначальный объём разработчиков OS-решения. А что делать тем, кто хочет оставаться инди-разработчиком? Существует ли какой-то способ выйти на окупаемость без внедрения колоссальных ресурсов?

Егор Левченко: Мы выросли из Яндекс Практикума, который нас спонсирует. Поэтому с ребятами оттуда у нас есть договорённость не конкурировать с основным сервисом компании. То есть мы не продаём знания, не торгуем курсами.

Open Source – это дорого: редакторы, домены, сервера – всё стоит денег. Поэтому возникает вопрос: насколько много прибыли мы приносим основному бизнесу, чтобы нас продолжали поддерживать? Один из способов выживать самостоятельно – донаты. И тут снова вопрос, на этот раз юридический: желающие нам помочь есть и в России, и в странах ЕС, и в Украине; везде свои законы, которые регламентируют эту сферу. А денег на юристов у бесплатных проектов нет. Если у OS-проекта нет спонсора «сверху», каким, например, можно считать Linux для Fedora или Red Hat, то у проекта вряд ли будут деньги.

Иван Щеклеин: Если рассматривать эти сервисы с точки зрения инвесторов, то они им вообще не интересны: это не про стартапы от слова совсем. Развитием своих версий операционок могут заниматься коммерческие компании, но инвестиций откуда-то ещё ожидать не стоит.

Олег Бондарь: Есть и другой способ монетизации – Open-Core Model, когда компания зарабатывает за счёт дополнительной функциональности продукта.

Сергей Бережной: При этом зарабатывать можно по-разному. Например, есть библиотека компонентов MUI. Это витрина, которая приманивает посетителей на индивидуальные проекты компании под заказ. Так они могут продавать часть фронтенда дороже, чем на бирже. То есть ядро – это бесплатный Open Source-проект, а дальнейшая разработка – за деньги.

Иван Щеклеин: Снова замечу: с точки зрения инвесторов, которые интересуются стартапами, гораздо привлекательнее, когда сверху OS-проекта есть ещё один цельный продукт, как, например, у Spark. Это работает, когда во втором продукте другая аудитория, другой value. Например, OS-сегмент – для небольших команд разработчиков, а второй – для крупных. Правда, есть и сложности: у разных продуктов разная динамика, разные показатели product-market fit. И их надо учесть, чтобы OS-проект был на слуху, а CS – продавался.

Егор Левченко: Можно ещё продавать не столько сам продукт, сколько документацию к нему. Например, в России после ухода Microsoft есть потребность в операционных системах для защищённых проектов. Основная ценность отечественных версий Linux в том, что у них есть, например, сертификат ФСТЭК. Таким образом, твой продукт может взаимодействовать с государством. Поэтому главное в таком проекте не он сам, а его юридическая ценность.

Сергей Бережной: Есть ещё один сценарий. Можно продавать облачный сервис, вместе с ним – Compute. А за счёт того, что сверху развёрнуты IDB-Managed, можно сделать наценку. Такая же схема работает и с managed-датабазами других типов.

Сергей Бережной: Как вы думаете, помогает ли опыт участия в OS-проектах при поиске работы?

Как человек, который принимает решение о найме, скажу, что количество OS-проектов поможет засветиться на радарах у рекрутера и попасть на скрининг, но не более того: дальше – стандартная проверка технических навыков. Ни разу не было такого, чтобы кандидату с абсолютно зелёной стеной на GitHub мы выкатили оффер.

Иван Щеклеин: Соглашусь с Сергеем. В больших компаниях есть одна тенденция – стандартизация найма. Ведь при сложных пайплайне и динамике никто не захочет каждый раз изобретать велосипед.

Олег Бондарь: Решение многих задач могут стать крутым дипломным проектом для студента – будущего специалиста. Здесь мы не требуем от контрибьютора результат, а смотрим на уровень его мотивации и умение написать хоть что-то. Open Source – это очень хороший базовый фильтр.

Иван Щеклеин: Я считаю, что это однозначно хороший старт для карьеры. Такая уникальная возможность есть только в нашем Software Engineering, когда бесплатно специалисты уровня Олега могут и готовы обучить контрибьюшну.

Олег Бондарь: При этом в качестве менторов выступают топовые разработчики. В моё время такого не было!)

Сергей Бережной: Кстати, существует ли опасность спама в pull requests или безответственных контрибьюторов?

Олег Бондарь: Люди спамят вниманием: сначала толпа людей с горящими глазами берётся за задачи, а потом никто ничего не делает: у кого-то сгорел ноутбук с мышкой, а ещё собака монитор проглотила и т.п.

Сергей Бережной: Вопрос простой: сможет ли нейронка создать OS-продукт по запросу?

Егор Левченко: Кажется, что работа с документацией у нейросети идёт гораздо легче, чем работа с кодом, но нередко AI-сервисы выдают полный бред. Есть ещё один аспект: в процессе работы с Open Source проектом человек учится; это своего рода интерактивный учебник. Когда в роли универсального подсказчика возникает нейросеть, потребность что-то узнавать и запоминать попросту отпадает.

Иван Щеклеин: Если это станет возможным, то в этом случае должно измениться и наше понимание модели работы – то, кого можно будет назвать junior, middle и senior специалистами. Например, может быть мидл по написанию кода, а может – по business requirements, а вторую часть процесса возьмёт на себя AI. Сейчас обе стороны этого дела должен досконально знать один человек. Надеюсь, вскоре мы сможем часть задач передать нейросети. Так мы освободим время на выработку креативных решений.

Егор Левченко: Я пессимистичен по отношению к такому подходу. Ведь документация имеет ценность только тогда, когда она проверена. А как можно быть уверенным в том, что создал человек, который не разбирается в предмете? Мой ответ: никак.

Егор Левченко: У нас есть core-команда, это 9 человек. Каждый из них отвечает за своё направление, внутри него он главный. На общем голосовании по его проектам финальное решение принимает он. Этот человек также отвечает за взаимодействие с сообществом внутри своей компетенции.

Иван Щеклеин: Мне важно, чтобы все инженеры так или иначе взаимодействовали с комьюнити, чтобы, во-первых, наращивать скилл в менеджменте, во-вторых, улучшить чувство общего дела через общение. Возможность такого взаимодействия – уникальная вещь, которая есть только у OS: в CS какого-нибудь B2B-проекта дистанция между разработчиком и потребителем значительно больше.

Егор Левченко: Это работает и в обратную сторону: участнику нашего сообщества не нужно проходить квест по уровням техподдержки – достаточно написать в наш чат, где есть вся наша core-команда.

Сергей Бережной: Каков период полураспада контрибьютера? Есть ли те, кто остаётся после первого раза?

Егор Левченко: У нас есть термин – серийный контрибьютор. Их у нас много. Более того, один из постоянных специалистов Doka, Игорь Коровченко, ответственный за инфраструктуру, сервисы и сервера, пришёл в роли контрибьютора и остался с нами.

Статистически средний срок жизни – 3 месяца. Хотя есть и уникальные случаи. Например, Антон Капустинский написал для нас 38 статей. Он начал взаимодействовать с нами ещё в школьном возрасте, сейчас он студент.

Иван Щеклеин: В нашем случае контрибьюторы влияют максимум на считанные проценты кода, потому что порог входа очень высокий как в техническом, так и в продуктовом аспекте.

Сергей Бережной: Предположим, наша главная цель не монетизация, а работа с аудиторией. У меня два вопроса: во-первых, как стимулировать прирост, а во-вторых, как его посчитать?

Егор Левченко: При работе с комьюнити важно понимать, зачем люди к нам приходят. В случае с Doka человек может написать статью на тему, которая у нас не освещена, предложить правки или другие улучшения. Но бывает такое, что человек берёт на себя инициативу, а затем пропадает. При этом он ничем тебе не обязан. Такие кейсы нужно тоже учиться отрабатывать, а ещё – корректировать и отстаивать своё видение, лавировать и развиваться. И всё это – без рекламы 👍

Олег Бондарь: Начну с метрик. Не буду скрывать: я каждый день смотрю за ростом звёзд на GitHub у YDB. Сейчас их у нас порядка 3,4 тысяч. Мне кажется, это эффективный способ измерить лояльность аудитории, в отличие, например, от метрики «Forks». Хоть она и призвана показать потенциальных контрибьюторов, но это скорее может вызвать ложные ожидания.

Иван Щеклеин: Мы дошли до показателя в 13 тысяч звёздочек; сейчас обращаем на них меньше внимания: для стартапа на этом уровне важнее становятся показатели доходности. Отношения с аудиторией мы выстраиваем вполне стандартно, но это работает: выступаем на конференциях, поддерживаем на высоком уровне документацию, выстраиваем адекватное общение с комьюнити по всем каналам коммуникации в сети.

Егор Левченко: Для нас важными метриками стали закрытые issues и pull requests. Последние для нас особенно значимы, потому что 9 человек – членов нашей редакции – вряд ли смогут написать всю документацию. Самое главное – чтобы человек пришёл и действительно что-то принёс.

Олег Бондарь: У меня есть убеждение: к Open Source-проектам важно привлекать студентов. Студенты энергичны и мотивированы: они развиваются, пишут дипломные работы по этим кейсам, и получают менторов, а ещё могут принести нам немного звёздочек :)

Open Source – удобный способ быстро войти в IT. Главное – понимать, с какой целью ты включаешься в OS-проект.

Хочешь глубже погрузиться в тему? Узнать, как монетизировать ML Open Source продукты или выяснить, почему звёздочки на GItHub – это реально круто? Присоединяйся к YNDX Family, чтобы получить доступ к записи круглого стола.

#YNDXFamily #yandex #яндекс #opensource #опенсорс #opensourcecode #разработка #разработчики #github