Когда писал свой прошлый пост о том, как поменялось мое отношение к Xen, вспомнил, что еще в 2007 году (после покупки Citrix’ом компании XenSource), обсуждался вопрос о том, что Citrix может стать “новой Red Hat в виртуализации”. И действительно, для этого были все предпосылки — Citrix давний и хорошо известный игрок корпоративного рынка, а XenSource была молодой и амбициозной OpenSource-компанией, основанной участниками проекта Xen.
Но Citrix не стала «новой Red Hat в виртуализации». Почему? Ответить на этот вопрос поможет статья Питера Левайна (Peter Levine), который занимал пост CEO в XenSource как раз в 2007 году, во время продажи компании. Во второй части статьи я напишу, в чем, на мой взгляд, Питер Левайн прав, а в чем нет. Ну а у вас есть возможность высказаться об этом в комментариях, сразу же после прочтения статьи. ;-)
Открытое ПО (Open Source) является движущей силой мира информационных технологий. За прошедшие 10 лет мы наблюдали, как оно уверенно приходит в большинство областей информационных технологий. Без Open Source не было бы Facebook, Google, Amazon, и многих других современных технологических компаний. Благодаря удивительному сообществу талантливых программистов, open source стал основой для Cloud, SaaS, NoSQL, ПО для мобильных устройств и много другого.
Однако, одновременно с этим успехом, мы можем услышать и громкие голоса тех, кто пророчит поражение open source от конкурентов из лагеря проприетарного ПО. Они утверждают, что будущее Open Source это малопопулярное программное обеспечение и нишевые проекты. Что именно проприетарному ПО всегда будут доверять критические задачи и обработку действительно важных данных.
Так кто же прав? Ведь мы можем наблюдать, с одной стороны, успех технологических компаний использующих открытое ПО, а с другой, очевидный провал open source в сфере критически-важных прикладных решений. Обе точки зрения верны, но не по тем причинам, в которые хотели бы верить сторонники открытой и закрытой модели разработки ПО. Причиной успеха или провала open source, является не само программное обеспечение, а базовая бизнес-модель.
Всё это началось (и закончилось) с Red Hat.
Red Hat, это компания, которая известна благодаря своему дистрибутиву операционной системы Linux, и стоящая у истоков бизнес-модели продажи техподдержки на открытое ПО. Red Hat позволяет использовать свое ПО бесплатно, а доход получает от тех, кто обращается к ней за технической поддержкой, консультациями, обслуживанием и обучением. Как только Red Hat стала получать стабильную прибыль, начались попытки множества компаний разработать open source альтернативы различным категориям проприетарного ПО и заработать на техподдержке, в RedHat-стиле. Среди таких попыток были MySQL, XenSource, SugarCRM, Ubuntu, и Revolution Analytics.
Red Hat это удивительная компания, она является первопроходцем успешной коммерциализации open source. Однако, почти все попытки построить бизнес по-примеру Red Hat оказались провальными. Посудите сами, “модель продажи поддержки на открытое ПО” существует уже около 20 лет, и кроме Red Hat нет ни одной публичной и независимой компании, которая была бы способна предложить альтернативу проприетарным аналогам. Когда вы сравните рыночную капитализацию и выручку Red Hat с Microsoft, или с Amazon, или с Oracle, то даже успех Red Hat выглядит не так уж впечатляюще. Успех Linux это грандиозное достижение для сообщества Open Source, но в коммерческом плане он не пропорционален и разочаровывающе мал (даже для Red Hat).
Есть много причин, почему модель Red Hat'а не работает, но главным «слабым звеном» этой бизнес-модели является то, что нет возможности вкладывать достаточно средств в долгосрочное развитие. Следствием подхода открытой разработки является минимальное отличие продукта от конкурентов (если они на той же кодовой базе). Это приводит к ограничению возможностей ценообразования и, соответственно, к отсутствию прибыли. Как можно увидеть ниже, модель продажи поддержки открытого ПО дает только малую часть того, что можно получить при “модели лицензий”. По этой причине почти невозможно инвестировать достаточно средств в разработку продукта, его поддержку, или в канал продаж так, как это могут делать Microsoft, Oracle или Amazon.
И если то, что я сказал выше не достаточно убедительно, я расскажу и про другие факторы, которые играют против “настоящих” open source компаний. Планы разработки ПО в открытых проектах и требования, как правило, доступны всей группе разработчиков. Но если компания не нанимает к себе на работу большинство разработчиков этого open source продукта, то высока вероятность того, что проект никогда не сможет набрать нужный темп разработки. Кроме этого, риском является то, что другая компания может решить создать форк вашего продукта. И еще один аргумент — для небольшого распределенного коллектива разработчиков очень сложно определить грань между контролем стабильности кода и активной разработкой.
Усугубляется положение тем, что чем успешнее open source проект, тем больше крупные компании хотят самостоятельно управлять кодовой базой. Я сам столкнулся с этим, когда был CEO в XenSource — многие крупные игроки ИТ-рынка заимствовали нашу кодовую базу, а мы не получали взамен никакой выгоды. Мы сделали продукт таким простым в использовании, что никто не обращался к нам за техподдержкой, и таким важным, что никто не хотел делиться своими наработками с “конкурентами”. Такое положение очень удобно для тех, кто заимствовал наш код, но не так уж хорошо для нашего бизнеса.
Если вы думаете, что это всё осталось в прошлом и сейчас уже не актуально, я вам скажу, что вижу похожую ситуацию, происходящую сегодня с OpenStack, и такое, вероятно, происходит со многими другими успешными open source проектами. Как open source компания, вы конкурируете не только с проприетарными ИТ-решениями, вы конкурируете с самим Open Source сообществом. Это похоже на какой-то абсурд.
Если вам повезет и у вас успешный open source проект, то может быть, большая компания будет платить вам несколько долларов за каждое обращение в техническую поддержку, или попросит вас адаптировать что-то для своих ИТ-систем. Если вы супер-удачливы (как было у нас с XenSource), вас могут купить как “стратегически важный” актив. Но, большинство open source компаний не выпадает такой судьбы, шансы выйти со своими акциями на биржу и создать большую независимую корпорацию чертовски низки.
Даже со всеми этими обстоятельствами, которые складываются против компаний, разрабатывающих открытое ПО, мы по-прежнему видим предпринимателей, которые позиционируют себя как “следующий Red Hat в ...”. Это проблема с пониманием ситуации на рынке: за 20 лет попыток не появилось ни одной “новой Red Hat“. Это не значит, что мы никогда не увидим компании, которые успешно клонировали бы модель Red Hat, но шансы минимальны, это длинный путь и он усеян “трупами” тех, кто пытался зарабатывать по этой модели.
Но существует модель, которая работает.
Продажа открытого ПО как часть сервиса.
Надежная модель заработка на Open Source получается, если перевернуть “верх ногами” традиционный подход. Т.е. если продавать не дополнительный сервис к открытому ПО, а наоборот — какой-либо сервис, а open source как неотъемлемую его часть. При упаковке open source в сервис (как в cloud и software-as-a-service) или как часть комплекса ПО или аппаратного решения, компании могут монетизировать open source по более выгодной и гибкой модели.
Сегодня многие новые, успешные компании используют экосистему стандартных open source компонент, которые, как правило, повторно используются и обновляются всей ИТ-отраслью. Компании, которые используют эти open source компоненты, как блоки фундамента для своего бизнеса (например, для cloud и SaaS), намного охотнее вносят вклад в то, что поддерживает их успех.
В зависимости от сегмента ИТ и продукта, компания может комбинировать в разных пропорциях разработку открытого ПО, специфичного для их бизнеса, и свое проприетарное ПО. Amazon, Facebook, GitHub и многие другие смешали open source компоненты с их собственным проприетарным кодом, а теперь продают эту комбинацию как сервис.
Этот рецепт — сочетание open source c сервисом или продажа открытого ПО в составе комплексных продуктов — дает потрясающие результаты в сегменте разработки ПО. Новые подходы в использовании Cloud и SaaS внедряются на порядок быстрее, чем развертывание нового ПО в собственных ЦОД, и open source может стать основным инструментом реализации этих преобразований.
Но мне хотелось бы увидеть в ИТ-отрасли и другие модели (помимо Cloud/SaaS) надежной монетизации открытого ПО.
Итак, что же вы ждете?
Постройте большой бизнес, опираясь на успешную платформу или вокруг неё. Добавьте что-то своё, что одновременно является и составляющей частью этой платформы и отличается от нее. Для примера, посмотрите на систему междугородних дорог. Если рассматривать их как некую транспортно-перевозочную платформу, вы увидите фундамент для совершенно различного бизнеса, который существует именно благодаря существованию платформы — от почтовых пересылок до сетей бензозаправок и придорожных кафе. Один из сервисов организации групповых поездок именно так построил свой бизнес — с одной стороны, опираясь на платформу междугородних дорог, а с другой, на IaaS-платформу Amazon’s AWS.
Если вы будете рассматривать ситуацию с точки зрения платформы, вы поймете, что “модель продажи тех.поддержки” Red Hat составляет очень маленькую часть рынка. Как продажа чуть лучшей части дороги в вышеописанном примере (в случае с Red Hat, создание чуть лучшего дистрибутива операционной системы Linux), в ситуации, когда она (дорога и ОС Linux) и так уже достаточно хороша для большинства людей.
Итак, когда вы начинаете бизнес, построенный на открытых компонентах, вы, возможно, захотите быть похожими на Red Hat. Но если все пойдет хорошо, вы начинаете задумываться о подходе, который больше напоминает Facebook, GitHub, Amazon или Cumulus Networks, чтобы стать неким ценным «слоем» на вершине большой платформы и поставлять этот слой как сервис или часть комплексного решения. Стать «следующей Red Hat», это замечательная цель, но когда вы смотрите на современные ИТ- тренды, то может быть это Red Hat стоит подумать о том, чтобы стать следующей Amazon.
Послесловие переводчика: Как видите, подход Citrix заключается в том, чтобы использовать Xen как платформу (помните, я в прошлом посте писал как раз об этом) и построить свои продукты вокруг и над ней. Как вы думаете, был ли бизнес Citrix удачнее, если бы она использовала подход «продажи техподдержки», как это делает Red Hat? Как обойти те «подводные камни» бизнеса на открытом ПО, которые описаны в статье? Пишите в комментариях, давайте обсудим.
Но Citrix не стала «новой Red Hat в виртуализации». Почему? Ответить на этот вопрос поможет статья Питера Левайна (Peter Levine), который занимал пост CEO в XenSource как раз в 2007 году, во время продажи компании. Во второй части статьи я напишу, в чем, на мой взгляд, Питер Левайн прав, а в чем нет. Ну а у вас есть возможность высказаться об этом в комментариях, сразу же после прочтения статьи. ;-)
Открытое ПО (Open Source) является движущей силой мира информационных технологий. За прошедшие 10 лет мы наблюдали, как оно уверенно приходит в большинство областей информационных технологий. Без Open Source не было бы Facebook, Google, Amazon, и многих других современных технологических компаний. Благодаря удивительному сообществу талантливых программистов, open source стал основой для Cloud, SaaS, NoSQL, ПО для мобильных устройств и много другого.
Однако, одновременно с этим успехом, мы можем услышать и громкие голоса тех, кто пророчит поражение open source от конкурентов из лагеря проприетарного ПО. Они утверждают, что будущее Open Source это малопопулярное программное обеспечение и нишевые проекты. Что именно проприетарному ПО всегда будут доверять критические задачи и обработку действительно важных данных.
Так кто же прав? Ведь мы можем наблюдать, с одной стороны, успех технологических компаний использующих открытое ПО, а с другой, очевидный провал open source в сфере критически-важных прикладных решений. Обе точки зрения верны, но не по тем причинам, в которые хотели бы верить сторонники открытой и закрытой модели разработки ПО. Причиной успеха или провала open source, является не само программное обеспечение, а базовая бизнес-модель.
Всё это началось (и закончилось) с Red Hat.
Red Hat, это компания, которая известна благодаря своему дистрибутиву операционной системы Linux, и стоящая у истоков бизнес-модели продажи техподдержки на открытое ПО. Red Hat позволяет использовать свое ПО бесплатно, а доход получает от тех, кто обращается к ней за технической поддержкой, консультациями, обслуживанием и обучением. Как только Red Hat стала получать стабильную прибыль, начались попытки множества компаний разработать open source альтернативы различным категориям проприетарного ПО и заработать на техподдержке, в RedHat-стиле. Среди таких попыток были MySQL, XenSource, SugarCRM, Ubuntu, и Revolution Analytics.
Red Hat это удивительная компания, она является первопроходцем успешной коммерциализации open source. Однако, почти все попытки построить бизнес по-примеру Red Hat оказались провальными. Посудите сами, “модель продажи поддержки на открытое ПО” существует уже около 20 лет, и кроме Red Hat нет ни одной публичной и независимой компании, которая была бы способна предложить альтернативу проприетарным аналогам. Когда вы сравните рыночную капитализацию и выручку Red Hat с Microsoft, или с Amazon, или с Oracle, то даже успех Red Hat выглядит не так уж впечатляюще. Успех Linux это грандиозное достижение для сообщества Open Source, но в коммерческом плане он не пропорционален и разочаровывающе мал (даже для Red Hat).
Есть много причин, почему модель Red Hat'а не работает, но главным «слабым звеном» этой бизнес-модели является то, что нет возможности вкладывать достаточно средств в долгосрочное развитие. Следствием подхода открытой разработки является минимальное отличие продукта от конкурентов (если они на той же кодовой базе). Это приводит к ограничению возможностей ценообразования и, соответственно, к отсутствию прибыли. Как можно увидеть ниже, модель продажи поддержки открытого ПО дает только малую часть того, что можно получить при “модели лицензий”. По этой причине почти невозможно инвестировать достаточно средств в разработку продукта, его поддержку, или в канал продаж так, как это могут делать Microsoft, Oracle или Amazon.
И если то, что я сказал выше не достаточно убедительно, я расскажу и про другие факторы, которые играют против “настоящих” open source компаний. Планы разработки ПО в открытых проектах и требования, как правило, доступны всей группе разработчиков. Но если компания не нанимает к себе на работу большинство разработчиков этого open source продукта, то высока вероятность того, что проект никогда не сможет набрать нужный темп разработки. Кроме этого, риском является то, что другая компания может решить создать форк вашего продукта. И еще один аргумент — для небольшого распределенного коллектива разработчиков очень сложно определить грань между контролем стабильности кода и активной разработкой.
Усугубляется положение тем, что чем успешнее open source проект, тем больше крупные компании хотят самостоятельно управлять кодовой базой. Я сам столкнулся с этим, когда был CEO в XenSource — многие крупные игроки ИТ-рынка заимствовали нашу кодовую базу, а мы не получали взамен никакой выгоды. Мы сделали продукт таким простым в использовании, что никто не обращался к нам за техподдержкой, и таким важным, что никто не хотел делиться своими наработками с “конкурентами”. Такое положение очень удобно для тех, кто заимствовал наш код, но не так уж хорошо для нашего бизнеса.
Если вы думаете, что это всё осталось в прошлом и сейчас уже не актуально, я вам скажу, что вижу похожую ситуацию, происходящую сегодня с OpenStack, и такое, вероятно, происходит со многими другими успешными open source проектами. Как open source компания, вы конкурируете не только с проприетарными ИТ-решениями, вы конкурируете с самим Open Source сообществом. Это похоже на какой-то абсурд.
Если вам повезет и у вас успешный open source проект, то может быть, большая компания будет платить вам несколько долларов за каждое обращение в техническую поддержку, или попросит вас адаптировать что-то для своих ИТ-систем. Если вы супер-удачливы (как было у нас с XenSource), вас могут купить как “стратегически важный” актив. Но, большинство open source компаний не выпадает такой судьбы, шансы выйти со своими акциями на биржу и создать большую независимую корпорацию чертовски низки.
Даже со всеми этими обстоятельствами, которые складываются против компаний, разрабатывающих открытое ПО, мы по-прежнему видим предпринимателей, которые позиционируют себя как “следующий Red Hat в ...”. Это проблема с пониманием ситуации на рынке: за 20 лет попыток не появилось ни одной “новой Red Hat“. Это не значит, что мы никогда не увидим компании, которые успешно клонировали бы модель Red Hat, но шансы минимальны, это длинный путь и он усеян “трупами” тех, кто пытался зарабатывать по этой модели.
Но существует модель, которая работает.
Продажа открытого ПО как часть сервиса.
Надежная модель заработка на Open Source получается, если перевернуть “верх ногами” традиционный подход. Т.е. если продавать не дополнительный сервис к открытому ПО, а наоборот — какой-либо сервис, а open source как неотъемлемую его часть. При упаковке open source в сервис (как в cloud и software-as-a-service) или как часть комплекса ПО или аппаратного решения, компании могут монетизировать open source по более выгодной и гибкой модели.
Сегодня многие новые, успешные компании используют экосистему стандартных open source компонент, которые, как правило, повторно используются и обновляются всей ИТ-отраслью. Компании, которые используют эти open source компоненты, как блоки фундамента для своего бизнеса (например, для cloud и SaaS), намного охотнее вносят вклад в то, что поддерживает их успех.
В зависимости от сегмента ИТ и продукта, компания может комбинировать в разных пропорциях разработку открытого ПО, специфичного для их бизнеса, и свое проприетарное ПО. Amazon, Facebook, GitHub и многие другие смешали open source компоненты с их собственным проприетарным кодом, а теперь продают эту комбинацию как сервис.
Этот рецепт — сочетание open source c сервисом или продажа открытого ПО в составе комплексных продуктов — дает потрясающие результаты в сегменте разработки ПО. Новые подходы в использовании Cloud и SaaS внедряются на порядок быстрее, чем развертывание нового ПО в собственных ЦОД, и open source может стать основным инструментом реализации этих преобразований.
Но мне хотелось бы увидеть в ИТ-отрасли и другие модели (помимо Cloud/SaaS) надежной монетизации открытого ПО.
Итак, что же вы ждете?
Постройте большой бизнес, опираясь на успешную платформу или вокруг неё. Добавьте что-то своё, что одновременно является и составляющей частью этой платформы и отличается от нее. Для примера, посмотрите на систему междугородних дорог. Если рассматривать их как некую транспортно-перевозочную платформу, вы увидите фундамент для совершенно различного бизнеса, который существует именно благодаря существованию платформы — от почтовых пересылок до сетей бензозаправок и придорожных кафе. Один из сервисов организации групповых поездок именно так построил свой бизнес — с одной стороны, опираясь на платформу междугородних дорог, а с другой, на IaaS-платформу Amazon’s AWS.
Если вы будете рассматривать ситуацию с точки зрения платформы, вы поймете, что “модель продажи тех.поддержки” Red Hat составляет очень маленькую часть рынка. Как продажа чуть лучшей части дороги в вышеописанном примере (в случае с Red Hat, создание чуть лучшего дистрибутива операционной системы Linux), в ситуации, когда она (дорога и ОС Linux) и так уже достаточно хороша для большинства людей.
Итак, когда вы начинаете бизнес, построенный на открытых компонентах, вы, возможно, захотите быть похожими на Red Hat. Но если все пойдет хорошо, вы начинаете задумываться о подходе, который больше напоминает Facebook, GitHub, Amazon или Cumulus Networks, чтобы стать неким ценным «слоем» на вершине большой платформы и поставлять этот слой как сервис или часть комплексного решения. Стать «следующей Red Hat», это замечательная цель, но когда вы смотрите на современные ИТ- тренды, то может быть это Red Hat стоит подумать о том, чтобы стать следующей Amazon.
Послесловие переводчика: Как видите, подход Citrix заключается в том, чтобы использовать Xen как платформу (помните, я в прошлом посте писал как раз об этом) и построить свои продукты вокруг и над ней. Как вы думаете, был ли бизнес Citrix удачнее, если бы она использовала подход «продажи техподдержки», как это делает Red Hat? Как обойти те «подводные камни» бизнеса на открытом ПО, которые описаны в статье? Пишите в комментариях, давайте обсудим.