Продолжаю серию интервью «Open source в России» о стратегическом управлении и развитии российских компаний на базе открытой разработки. На этот раз я обратился к @glaschenko с вопросами по теме, и Андрей поделился уникальными инсайтами о выходе компании в open source и результатах работы в таком формате.
Расскажите, пожалуйста, как исторически развивалось участие компании в open source? Это был изначальный вектор развития? Или подход формировался постепенно? Какими были первые шаги и эксперименты в этой области?
В 2014 году мы выпустили «в свет» наш первый продукт для разработчиков — CUBA Platform. Это — сочетание фреймворка и инструментов, которые вместе позволяют быстро создавать корпоративные приложения. Но несмотря на хорошие отзывы, продукт «не взлетал». Ушло полгода, чтобы понять, что проблема была в проприетарной лицензии (мы делали что-то по аналогии с 1С). Мир уже не был готов разрабатывать решения на проприетарных технологиях, попадая в зависимость от вендора. Окончательно мы в этом убедились, пообщавшись основателем Eclipse Che, Трэвисом, на конференции JavaOne.
А затем — мы выпустили фреймворк CUBA Platform под лицензией Apache 2.0, а дополнительные инструменты оставили коммерческими.
Было очень волнительным отдавать бесплатно то, во что мы вложили столько сил. Но в итоге пользователи получили независимость своих продуктов, а мы сохранили источник выручки. Тогда за две недели мы продали больше, чем за предыдущий год, а самое главное — наконец начался рост сообщества продукта!
Как вы вписали работу в open source в общую стратегию развития компании? Какие преимущества дала и потенциально может дать открытая разработка?
Мы — небольшая компания относительно ИТ-гигантов (около 500 человек на сегодня) и не можем позволить себе тратить неограниченные ресурсы на создание рынков и технологий без возможности возврата инвестиций. Но мы поняли, что open source — это не страшно :)
Существует множество моделей, которые позволяют зарабатывать, одновременно обогащая open source-сообщество разработками. Это — коммерческая поддержка, консалтинг, premium-функциональность. В то же время open source — это чуть ли не единственная возможность широкого распространения продуктов без миллиардных инвестиций. Про open source можно писать статьи, выступать на конференциях, плюс — это радикально снижает порог для принятия решения об использовании технологий.
Для себя мы выбрали такой путь: все, что может быть включено в проекты наших клиентов, должно поставляться с открытым кодом. Это означает, что мы гарантируем независимость проектов от нас.
При этом монетизацию мы реализуем через платные инструменты (которые не являются обязательными, но повышают вашу продуктивность) или услуги, включая заказную разработку с использованием наших технологий.
Open source — это во многом история о работе с противоречивыми интересами разных групп стейкхолдеров и аудитории (от разработчиков-пользователей открытых решений до B2B-заказчиков разработок на основе open source). У каждой такой группы различные ожидания — открытый подход позволяет учитывать их и в каком-то смысле является платформой для объединения усилий самой аудитории. Расскажите, как вы подходите к подобным вопросам и задачам?
Да, конечно, для каждой группы нужно свое ценностное предложение. Есть разработчики-энтузиасты, которые активно участвуют в развитии фреймворка, пишут код. Они же — самые активные «распространители» технологии по «сарафанному радио».
Есть студенты, которым нужно быстро написать курсовую. Для них мы даем бесплатные лицензии на всю мощь нашего инструментария, чтобы сделать знакомство с open source-фреймворком наиболее комфортным.
Для корпоративных клиентов важно наличие готовых прикладных компонентов, чтобы сократить time to market. И мы создали целую экосистему (маркетплейс) платных и открытых аддонов вокруг фреймворка. А также индивидуальные программы обучения, SLA и, конечно же, сертификацию разработчиков.
Для широкой массы разработчиков — подготовили курсы на Udemy и Stepik чтобы максимально упростить вход в технологию. Сейчас приходится изучать столько нового, что это критически важно. Дополнительно работаем над ИИ-ассистентом, чтобы снизить этот порог входа еще больше.
Какие открытые проекты компании вы могли бы выделить? Какую бизнес-модель для данных проектов вы выбрали? Какие лицензии используете?
Выше мы поговорили о CUBA Platform, ныне Jmix. Это наш первый тиражируемый open source-продукт, фактически это — модель open core. В этом году на схожих принципах мы выпускаем OpenBPM — открытую платформу для BPM-разработчиков.
А еще уже в апреле будет публичный релиз OpenIDE — российского форка IntelliJ IDEA Community, который мы создаем в партнерстве с AxiomJDK и ГК Астра. Понятно, что на 95% мы используем открытый код компании JetBrains, но сверх того мы переписываем ряд компонентов с проприетарной лицензией (работа с Docker, например), переносим маркетплейс, отвязываем продукт от серверов JetBrains и т.д. Большая работа.
Есть еще небольшие инициативы, такие как библиотека для генерации отчетов yarg.
В общем, мы с open source давно и надолго.
Выбор лицензий — очень важная составляющая бизнес-модели. Основных вариантов немного: 1) разрешающие (permissive) лицензии типа Apache 2.0, MIT и BSD, которые накладывают минимум ограничений на использование кода; 2) copyleft — в основном вариации GPL; 3) и копилефт с исключениями на линковку типа LGPL.
Для кода, который войдет в состав конечного продукта наших клиентов, мы всегда выбираем permissive-лицензии, а именно Apache 2.0. Копилефт просто неприемлем для большинства коммерческих продуктов.
А вот для OpenIDE мы, наоборот, выбрали AGPL 3.0. Это — инструмент, и его использование не «заражает» копилефтом проекты, которые делаются с его помощью. Лицензия в данном случае не является проблемой для пользователей. Любой разработчик все так же может вносить свой вклад в развитие опенсорс-проекта. Но в то же время это — проект некоммерческий, и мы не хотим, чтобы кто-то мог взять наши наработки и использовать в закрытом коммерческом продукте. AGPL как раз это гарантирует.
Возможно, у вас есть что-то вроде open source program-офиса или специального отдела, который управляет активностями компании в этом направлении?
Нет, здесь работает индивидуальная стратегия для каждого продукта. Но у нас очень сильно развита DevRel-составляющая. Мы очень активно участвуем в жизни сообщества: доклады на конференциях, JUG, статьи на Хабре, ТГ-каналы, видосики… и здесь, конечно же, происходит обмен опыта между продуктовыми командами.
Какие глобальные цели вы ставите перед собой в нише open source? Планируете ли повлиять на развитие рыночных ниш и технологий?
Совершенно точно мы хотим стать большим явлением для российских разработчиков с OpenIDE :) Остальное — это скорее все-таки нишевые решения в рамках отдельных продуктов. Но тем не менее, даже ими пользуются тысячи разработчиков во всем мире, создают классные проекты. И это очень приятно.
Кого еще вы ожидаете увидеть в числе российских open source-вендоров?
Яндекс — крутые. ClickHouse, YDB — популярные проекты на мировом рынке. Хотелось бы, чтобы и другие «техи» подтягивались, ведь их размер как раз позволяет инвестировать в технологию вдолгую, не требуя финансовой отдачи. Но навскидку не могу вспомнить действительно популярные проекты, хотя, наверное, они есть…
С чего вы бы порекомендовали начинать эксперименты организациям без опыта работы в open source-среде? На что следует обратить внимание, чтобы в полной мере воспользоваться преимуществами открытой разработки?
В первую очередь, нужно честно ответить себе на вопрос «Зачем?». Вклад в open source будет устойчивым, только если компания четко понимает, зачем ей это нужно стратегически. Иначе получаем еще один брошенный проект (не дай бог, успешный) и фрустрированное сообщество.
Второй вопрос — кому ваш open source нужен? Даст ли он ценность сообществу? Как вы будете продвигать ваш проект? Готовы выделять на это ресурсы? Даже если он бесплатный и полезный, без маркетинга им скорее всего никто не будет пользоваться. Сейчас просто слишком много технологий. При этом open source — мощный катализатор популярности продукта, но он не работает волшебно сам по себе.
