Удалось пообщаться с Олегом Бартуновым, сооснователем и генеральным директором Postgres Professional. Делюсь текстовой версией разговора, в котором мы затронули историю компании и проблемы развития open source в России. Также мы поговорили о том, как менеджерам стоит смотреть на работу в формате open source.
Расскажите, пожалуйста, на этапе запуска все ли в команде были погружены в open source специфику? Как шло ваше развитие?
Ключевые люди были погружены в open source, но компанию строили не только они. С нами были и те, кто знал, как органичным образом построить жизнеспособный бизнес. Они помогли разобраться с выбором партнеров в энтерпрайзе и выстраиванием B2B-продаж. Кстати, в Postgres Professional не так много менеджеров по продажам. Дело в том, что мы выбрали оптимальную модель дистрибуции: даем партнёрам скидку, но не занимаемся продажами напрямую. Так мы делаем весь процесс прозрачным, если сравнивать с подходом, когда компании осуществляют прямые продажи клиентам.
Вы сразу же взяли за основу такую модель?
Нет. Такие решения появились по ходу нашего развития. Изначально я предполагал, что будет другая стратегия: предоставляем ванильный PostgreSQL и занимаемся платной поддержкой клиентов.
Классическая бизнес-модель.
Да, но в России она не работает. У нас любят платить за лицензии, а не поддержку, ещё часто пытаются наладить отношения с крупными вендорами. Последние же, как мы знаем на примере многих зарубежных коллег, закладывают отдельные средства на подобное «взаимодействие». Поэтому внести в энтерпрайз open-source решение с затратами только на поддержку было сложно.
В то время люди семьями дружили с коллегами, которые во многом руководствовались интересами зарубежных вендоров и работали с определенными бюджетами на постоянной основе. На фоне подобной культуры классическая модель, о которой я говорил выше, оказалась не особенно интересна. Это была одна из гримас нашего рынка.
Что вы решили делать в этой ситуации?
Чтобы изменить свой подход, мы оценили объем фич, которые еще не успели отдать сообществу, и сделали энтерпрайз-продукт. Однако даже с учетом того, что мы предлагали в несколько раз более низкие цены, на тот момент практически вся российская экономика была заточена на работу с Oracle и Microsoft. Хотя верхние эшелоны уже тогда были готовы к замещению, да и разработчики предпочитали open source, с которым всегда проще экспериментировать.
Ключевые сложности возникали на уровне руководителей управлений. Это были те люди, которые в 90-е и 00-е учились по материалам и проходили курсы вендоров в университетах. Получается, Россия за свой счет готовила работников для таких компаний. Даже сейчас в какой-то степени все это существует в рамках так называемой академической свободы. Но дело не только в том, что людям не хочется рисовать новые слайды и переписывать готовые материалы курсов (кстати, мы делаем и предлагаем новые образовательные материалы в вузы самостоятельно). Многим достаточно сложно понять, как изменить сложившийся у них подход для работы в новых условиях, чтобы строить системы на open source, а не проприетарных продуктах.
Руководители департаментов, которые выросли в такой образовательной среде, во многом боятся работать с open source. Они его не понимают. Они привыкли к формату «оплатил миллиард и думаю, что вендор уже меня не бросит». Они не знакомы с open-source экономикой, не понимают законы и ключевые принципы среды. Поэтому они опасаются работать с открытыми технологиями.
Я могу понять их опасения. У нас крайне мало open-source вендоров, которые берут на себя ответственность за решения и их поддержку. Тех, кто реализует полную линейку стандартных сервисов, ожидаемых от таких компаний-вендоров (от аудита и консалтинга до поддержки, образовательных курсов и сертификации), конечно же, еще меньше.
Хотя за счет всего этого ты формируешь рынок. В том числе поэтому мы начали с образования комьюнити, с документации. К моменту запуска компании у нас уже были наработки, но нужно было систематизировать их, перевести на русский язык и так далее.
Получается, первые сотрудники этим и занимались?
Да, мы начали с образовательных моментов. Это был первый сотрудник, с которым я познакомился еще до запуска компании. Он перешёл в Postgres Professional и теперь руководит отделом образования. Кстати, с момента запуска мы вложили уже более 250 млн рублей в различные образовательные инициативы: писали курсы, книги, сделали сертификацию. Все эти моменты мы планировали делать изначально.
На развитие повлияло и то, что у нас была сформулирована миссия. Я на этом настаивал тогда, потому что мало компаний уделяют внимание своей глобальной цели. Но все это — не про исключительно «заработать денег», речь должна идти о чем-то большем. Мы решили работать над формированием отрасли СУБД-строения в России, cчитая, что для технологической состоятельности страны это — необходимость. Сегодня же в понимании этого, как и многие, только укрепились.
Именно такой изначально и была миссия компании?
Да. Когда вы привлекаете сотрудников, деньги далеко не всегда являются решающим фактором и ключевым компонентом мотивации. Люди хотят работать в компании с хорошей кармой — там, где занимаются ценным делом. Для этого и нужна миссия, которая действительно находит отклик у людей.
И вы можете это контролировать с точки зрения лицензирования.
Конечно. Но и люди понимают это. Они видят, что мы — open-source компания, есть понятная миссия и руководство, все условия для работы. Поэтому к нам идут более идейные люди. Это полезно и с другой точки зрения —в системном программировании, которым мы занимаемся, нужны люди сильной воли. Тут проекты длятся годами — по пять, шесть, семь лет. Прикладной разработчик за это время выгорает, поскольку привык переключаться между обозримыми проектами.
Но у нас может быть в разы больше эмоций в работе. Ты сидишь и ковыряешься в «кишках», сталкиваешься с множеством трудностей, тебя может критиковать кто-то в сообществе, нужно защищать свою точку зрения в общении с коллегами. Все это сложно, требует устойчивости и понимания, для чего ты делаешь именно эту работу. Таких людей мало, но нам удается привлекать их в команду.
Если вернуться к подходу, когда разработанные в компании решения появляются у сообщества с лагом, он все еще в силе?
Да. Он все еще сохраняется, но стал более осмысленным. Лаг нужен, чтобы отработать ту или иную новую фичу. Пусть наши клиенты не обижаются, это — общемировая практика. Процесс отсаживания с избранными клиентами является нормой. В сообщество ты приходишь уже с валидированными решениями, опытом их совершенствования. Подобной аргументации сложно что-то противопоставить, и серьезные фичи именно так находят поддержку сообщества.
Также лаг — необходимый оверхед для выживания сообщества. Он может длиться годами, сотрудники могут испытывать эмоции, но это плата за то, что сообщество остается демократичным. Ты идешь по стандартной и длительной процедуре с обсуждением, когда любой может задать вопрос по фиче, а тебе нужно будет ответить ему.
Такие вещи не регулируют законами. Они существуют в виде этики в open-source среде. Компании должны понимать, что им следует делать, если есть желание в полной мере соответствовать подобной этике. В ином случае — у них не будет устойчивости. Например, если вы только берете, но не отдаете, а потом и другие в сообществе следуют этому примеру, оно быстро разлетается и прекращает свое существование.
Каким образом вы поддерживаете устойчивость?
Есть Code of Conduct, есть старики вроде меня, которые выросли в этом сообществе и понимают правила. Постепенно нас сменяют молодые, но не менее ярые энтузиасты open source. На этом все держится. Также у нас в сообществе принято делиться сразу со всеми — права принадлежат сообществу. Я не могу отобрать эти права. Это гарантирует независимость, например, от политики, и устойчивость.
В текущей обстановке мы понимаем, что у каждого есть эмоции. Но в публичном пространстве мы придерживаемся профессиональной этики и не показываем их. Когда определенный человек в гневе начал кричать о необходимости выгнать всех русских из сообщества и выкинуть все патчи, ему быстро объяснили, что без русских Postgres просто не будет Postgres. Наш вклад очень большой.
Сообщество показало устойчивость и адекватность. Кстати, даже американцы в прошлом году сами поставили нас на второе место по вкладу в PostgreSQL — выше Google, Microsoft и других. Историй подобных этой я пока не слышал в текущих условиях.
Если сравнить развитие условного разработчика проприетарного ПО и open source вендора, позволяет ли последнему такой формат работы иметь иную динамику? Планируете ли вы запускать новые разработки и решения вне Postgres-линейки?
Конечно, в open source все идет существенно быстрее. Да, мечта любого разработчика — сделать свою СУБД. Изначально мы и планировали подобный ход конем: набрать компетенции, развить сообщество, построить свои конкурентные продукты и так далее.
Сейчас мы концентрируемся на продуктах, которые нужны стране. Для принципиально нового решения нужно выделить как минимум несколько десятков специалистов. Найти такие ресурсы не просто, тем более в текущих условиях перегретого рынка и дефицита системных разработчиков.
Что уж тут говорить о том, что в Реестре ПО представлено больше сотни продуктов нашего класса, и почти все основаны на PostgreSQL. Это — еще одна гримаса open source в России. И определенные риски в использовании подобных решений действительно есть. Смогут ли вендоры, которые не обладают open-source компетенциями и не работают с сообществом, поддерживать и развивать их на системном уровне — большой вопрос.
Конечно же, не хотелось бы получить проблемы с такими продуктами в проектах, от которых зависит качество жизни людей (вроде критически важной инфраструктуры и ключевых сервисов, например, банковских), а после этого разбираться с имиджевыми последствиями для всего Postgres-сообщества.
Поэтому нужно двигаться в сторону объединения усилий в сообществе. Но, к сожалению, у нас в основном привыкли быть потребителями, но не создателями open-source решений. Пока нет определенной этики.
Такие паттерны характеры больше для интеграторов?
Нет. Это совершенно разные организации. Собственные продукты на основе PostgreSQL сделали крупнейшие разработчики софта, интеграторы, даже банки и логистические компании. И это в стране, где специалистов не хватает.
Но им нужно же поддерживать темп развития продукта в соответствии с тем, что есть в открытой версии, так?
Верно, но они хотят делать все у себя и продавать, если получится.
Выходит, на рынке теперь множество разнородных версий?
Да, поэтому люди идут к нам. Компания во многом понятнее за счёт полного цикла разработки и сопровождения, отсутствия цен, взятых с потолка.
Поддержка теперь стала более уместной и понятной?
Конечно. Поддержка нужна крупным клиентам. Сперва многие из них даже отказывали нам в референсах, чтобы не портить отношения с Oracle, хотя пользовались нашими услугами. Сегодня мы работаем с самыми различными организациями в масштабе страны. Учитывая, что у нас в целом высокий уровень цифровых сервисов в России, существенные нагрузки и требования, мы — в уникальных условиях. В мире таких кейсов почти и нет. На уровне стран и государственных сервисов в основном работают только Oracle и Microsoft. Поэтому мы гордимся нашим опытом и реальным кейсом развития бизнеса и команды на основе open source, причем в формате win-win для всех.
Как вы относитесь к тренду на source available? На примере кейсов Elastic, HashiCorp и подобных им с изменением лицензий.
Дело в том, что существует open source, контролируемый одной компанией, где подобные истории могут происходить. Плюс — чуть сложнее с устойчивостью и open-source этикой в целом. Если у тебя есть сообщество, заинтересованное в развитии продукта без перекосов в сторону одного крупного игрока, тогда соблюдается баланс.
Если вспомнить «Собор и базар», то сейчас в мире, конечно же, все несколько иначе. В Postgres-сообществе — «базар», а внутри каждой компании — «собор». Компании, которые входят в сообщество, общаются с энтерпрайзом, конвертируют обратную связь в нужные фичи, затем отдают их в open source. При этом главным конкурентом каждой из них — помимо других компаний — фактически остаётся ванильный Postgres. В силу того, что продукт сложный и дорогостоящий, компаниям выгодна такая модель. Они коллаборируют на уровне сообщества, и это — ключевой момент.
Получается, что идет смыкание принципов. Postgres стал профессиональным, когда его начали разрабатывать компании, отсюда и наше название. Но здесь крайне важно понимать, что именно коллаборация и коммуникация на уровне сообщества — тот самый «базар» — ключ к будущему настоящего open source.
В итоге мы говорим о модели «соборного базара», подразумевающей совместную разработку, а также вендорскую работу внутри каждой из компании в сообществе. Так можно выдержать устойчивую комбинацию интересов и компаний, и сообщества на условиях адекватной конкуренции. Наш пример в этом отношении показателен.
Появляется ли у интеграторов и компаний-разработчиков проприетарных продуктов больше интереса к open source?
Да. Один из активных участников нашего сообщества — Microsoft. Они выкупили одну из профильных компаний и не запрещают ей заниматься open source. Дело в том, что в сообществе PostgreSQL вендоры заинтересованы в реализации определенных стандартов.
Если смотреть на новые начинания, стоит ли мыслить так, чтобы изначально становиться open source компанией?
Конечно. Если у вас небольшая команда, вы не найдете так просто хороших специалистов с опытом, например, без инвестиций. Кстати, вполне возможно, инвесторы зададут вопрос о том, как вы планируете конкурировать с open source.
Поэтому пункт является скорее обязательным: нужно сразу разобраться, будет ли необходимо сообщество и на каких принципах, закрытая разработка или открытая.
Как тогда правильно отдавать решения в open source, чтобы сообщество не страдало от перекоса в сторону одной компании? Получается, что все это будет построено на честном слове?
Да, но здесь есть роль государства. Сейчас ситуация не очень хорошая — берут open source, переименовывают и продают. Это — пена, которая должна сойти, но развитию государства она мешает.
Если бы эти разработчики пришли к нам, мы бы получили ту самую дополнительную команду, которая занималась бы чем-то принципиально новым. Разрозненными усилиями серьезные решения не сделать, отдельные фичи предложить сообществу также сложно.
Мы видим, что сейчас многие из таких разработчиков пользуются тем, что наша команда отдала в сообщество. Тем не менее мы продолжаем делиться наработками, хотя я не уверен, что псевдоразработчики вообще задумываются о чем-то подобном.
Если возвращаться к этике, пришло время решать глобальные задачи, уходить от сиюминутной борьбы. Есть множество проблем бытового уровня, также есть космические угрозы и риски, над выявлением и решением которых стоит работать. Open source — хороший фундамент для организации такой работы и технологического прогресса. В России нужно развивать этику и правильные подходы к развитию open source.
Стоит ли ждать инициатив в этом отношении от топ-менеджеров или скорее от инженеров, которые хотят что-то открыть?
Для этого компания должна быть относительно устойчивой и чтобы у нее все было в порядке с экономикой. Тогда ты можешь себе позволить вот этот open-source оверхед. Плюс — нужно будет серьезно заниматься безопасностью, продвижением, сообществом. Менеджеры должны понимать весь спектр, чтобы делать это системно.
С какого момента вы в компании начали тратить на все это?
С самого начала. Мы отработали деньги инвестора, затем много тратили на создание команды и образовательные инициативы, чтобы конкурировать в том числе на уровне идей. У нас люди не просто получают достойное вознаграждение, но и понимают, что и зачем они делают.
Чего не хватает условному Сберу, чтобы конкурировать с open source вендорами вроде вас? Специализации или чего-то еще?
Дело в среднем персонале. Это они пишут бумаги высшему руководству, рисуют планы. Им также кто-то готовит материалы. Хотя и роль личности тут может быть велика. Например, на уровне какого-то вице-президента по технологиям может быть принято решение о сотрудничестве с open-source вендором вроде нас. Open source — это коллаборация, чего не хватает на многих уровнях.
Как объяснить менеджерам пользу грамотного и этичного подхода к open source? Допустим, с точки зрения коммерции, зачем он им?
Доверие. Например, доверие к open-source вендору дает многое. Пока менеджеры среднего уровня ориентируются скорее по собственным ошибкам. Получается, что они должны их допустить, чтобы понять разницу и увидеть на контрасте нашу стабильную работу.
В качестве завершения предложил бы порассуждать о будущем open source в России. Какие практические шаги нужны на ваш взгляд — помимо того, что вы уже отметили выше?
Я не видел курсы по данной тематике в университетах, а они нужны. Пока многие плохо понимают, что является open source, а что нельзя считать им. Также менеджеры слабо разбираются в OSS-лицензиях.
При этом сами вузы должны использовать open source не только для обучения, но и для разработки — выпускать свои решения и помогать студентам присоединяться к сообществу. Так люди быстрее разберутся, что им хотелось бы развивать, какую специализацию выбрать, какие есть требования в open-source сообществе и так далее.
Кстати, мы уделяем много внимания таким вопросам. Например, делаем свою книгу по теме для внеклассных занятий на уровне школы. Чтобы рассказать простыми словами о системной программировании — показать специфику на доступном уровне, дать людям осмысленный подход к профессиональному развитию, показать ключевые принципы.
В целом для страны и российских компаний сейчас главное — стать из потребителей открытых решений настоящими созидателями. Это — один из первоочередных моментов, без которого мы так и будем плестись в хвосте. Все это осуществимо: наша компания является примером того, как быть коммерчески успешными и оставаться мировым лидером по вкладу в крупный OSS-проект.
Дополнительное чтение по теме: ключевые OSS-отчеты и мнения.
Комментарии (10)
cross_join
15.10.2024 09:03люди, которые в 90-е и 00-е учились по материалам и проходили курсы вендоров в университетах
Такая риторика работает в обе стороны, в зависимости от цели. Например, сейчас много людей, учившихся на MySQL / Postgres, сходу предлагающих решения на том, что знакомо, не задумываясь о предстоящих проблемах, уже решенных коммерческими СУБД лет 20 назад.
funca
Продукты Oracle и Microsoft ещё примечательны тем, что они не требуют наличия DBA с бубном и тремя образованиями для развёртывания и сопровождения СУБД даже на масштабах среднего бизнеса. Вы платите вендору и нанимаете обычного админа с рынка.
Настройка и поддержка PostgreSQL - где вендоры зарабатывают на помогании вам справляться со сложностью - всю свою историю продолжает быть шаманством. Похоже, что сложность стала "системной" и "устойчивой" фишкой этого продукта, иначе у них развалится весь бизнес.
dmitrykabanov Автор
Не забывайте про вендорлоки и сложности при необходимости слезть с подобного «удобства». Плюс — в разы интереснее наблюдать развитие компаний с опенсорсной основой. Мегакорпорации также идут в эту сторону, но в силу общей неповоротливости не особо стремительно
funca
Пользуясь случаем, спасибо за классное интервью. Отдельно отметил вопросы, которые были заданы гостю, чтобы раскрыть тему. Олег старый лис, который кожей чувствует откуда ветер дует деньги и подбирает по ситуации нужную риторику.
Понятно, что одиночки не в состоянии вывозить проекты такой сложности. Нужны ресурсы и деньги, которые есть у корпораций. Но кроме плюшек они привносят с собой собственные интересы и противоречия. Разные проекты приходят к разному балансу. Вендор лок, в том или ином виде, вы получаете в любом случае, как только решаете купить чью-то кастомизацию.
Ситуация с PG похожа на классическую "трагедию общин", где многочисленные вендоры старательно избегают исправлять проблемы в оперсорсной версии, висящие годами, чтобы не случайно не подломать себе и коллегам бизнес. За то обильно обвешивают кодовую базу точками расширения, чтобы туда можно было вклинить собственное решение. А так же - пропиетарным инструментированием снаружи, без которого тоже не обойтись. Это приводит к ещё большему усложнению архитектуры. На мой взгляд модель Source Available, где корпорации более полно раскрывают решение, не боясь конкуренции, выглядит честнее.
dmitrykabanov Автор
Source available — это уже другой разговор, но не менее интересный. В данном случае полно нюансов вроде отложенного выхода под пермиссивные лицензии. Механизмов много. Но работать с ними пока сложно компаниям
ggo
Я видел множество инсталляций SQL Server, которые были развернуты неспециалистами, и просто работали.
Я видел множество инсталляций Postgres, которые были развернуты неспециалистами, и просто работали.
Но почти не видел инсталляций Oracle (Express не беру в расчет), имхо как раз Oracle требуется внимание спеца, начиная с этапа развертывания.