Эта статья является продолжением рассмотрения положения сегмента свободного программного обеспечения (СПО) на ИТ-рынке, начатой в публикации “ Основные бизнес-модели и принципы современного рынка ПО”.

Основной тезис данной статьи – никакого непреодолимого противостояния между проприетарным ПО и СПО нет. ППО и СПО — это две взаимодополняющие части единого ИТ-рынка с отсутствием жесткого водораздела между ними. Связь между ППО и СПО определяется диалектическим законом единства и борьбы противоположностей. В этой связи сразу выскажем несколько ключевых моментов:

  • как пользователей, так и разработчиков ПО в реальной жизни интересуют не собственно теоретические бизнес-модели, применяемые для создания и распространения программных продуктов, а то, как эти модели реализуются на практике и как они способны решать их личные задачи;
  • на самом деле внутри лагерей ППО и СПО существует на практике множество “подмоделей” и течений, в том числе комбинированных схем. Поэтому повести четкий однозначный водораздел между этим двумя группами ПО порой очень сложно. А такие современные и перспективные подходы к организации ИТ, как SaaS и Cloud, вообще делают разделение на ППО и СПО бессмысленным;
  • если посмотреть на работу конкретных ИТ-компаний, то часто их почти невозможно отнести к одному или другому лагерю, поскольку они используют в своей работе обе модели;
  • ППО и СПО представляют собой фактически единый комплекс, когда одна часть не может существовать без другой. Точнее, СПО — просто не может без ППО, а ППО в значительной степени заинтересовано в развитии СПО. В частности, нужно сказать, что создание СПО идет во многом (по некоторым оценкам, не менее 50%) на инвестиции ППО-бизнеса, а результаты разработок СПО активно используются для создания коммерческих продуктов.

Уже давно является непреложным фактом то, что в общем случае информационные системы предприятий носят разнородный характер. При этом уровень неоднородности, как правило, растет с увеличением размеров систем. Причем в этой сфере также действуют две казалось бы противоположные, но на самом деле взаимосвязанные тенденции.

Первая — это как раз стремление к гетерогенности, но она объясняется не желанием получить независимость от одного поставщика (как это часто представляется), а вполне прозаической причиной — желанием использовать для решения конкретной задача наиболее подходящие для нее средства.

Вторая — это желание построить однородные системы от одного поставщика, пусть даже и с некоторой потерей оптимальности на отдельных участках систем. Причина этому проста — заказчик выигрывает в целом за счет снижения затрат на интеграцию компонентов и поддержку систем. Именно второй момент лежит в основе тенденции развития крупных ИТ-вендоров в направлении создания полного стека ПО, решающего максимально возможный круг задач клиентов.

Конечные продукты СПО можно представить как набор ПО от одного достаточно специфического “распределенного” вендора. Особенностью этого вендора является то, что его продукты создаются как бы в два этапа: разработка базового ПО (обычно в рамках OSS-проектов) и формирование на его основе коммерческими компаниями решений (дистрибутивов) для поставок. Такое разделение этапов имеет свои преимущества в плане оптимизации затрат на процесс разработки, но в то же время и некоторые принципиальные недостатки, которые выражаются, например, в том, что разрывается прямая связь между заказчиком и производителем базового ПО.

С точки зрения пользователя, СПО представляют собой продукты, которые отличаются от ППО в основном только схемами затрат на их приобретение и сопровождение (мы сейчас не задаемся вопросом, больше эти затраты или меньше). На практике подавляющее число пользователей почти не применяют в своей работе “четыре свободы” СПО, в том числе с целью его доработки и настройки (как мы писали ранее, эти задачи решают не изменением базового кода, а расширением продукта через разного рода API).

В то же время четвертьвековой опыт существования концепции СПО показывает, что данное сообщество в целом не готово создать полный самодостаточный стек ПО для решения задач корпоративных клиентов (причины тут, скорее, в организационных принципах сообщества СПО). Так, сфера применения СПО ограничена в основном инфраструктурными вопросами, его присутствие в прикладном сегменте, в том числе бизнес-приложений, минимальная. Опыт показывает: заказчики всегда имеют возможность решить все свои задачи в рамах только ППО, причем довольно часто — от одного вендора. В случае СПО такое невозможно. Следствием этой ситуации является то, что подавляющее число корпоративных систем строятся с использованием в качестве основы ППО (очень часто создание информационных систем идет от бизнес-приложения), а СПО применяется в качестве отдельных компонентов, как правило инфраструктурных, для оптимизации затрат на системы в целом. Интеграция компонентов системы выполняется с помощью общепринятых отраслевых методов, общих для ППО и СПО. Разумеется, широко распространена и практика прямого технологического сотрудничества между ППО- и СПО-вендорами (например, в сфере виртуализации, управления ИТ).

Если же посмотреть на взаимоотношения лагеря ППО и лагеря СПО в сфере собственно разработки ПО, то здесь мы увидим настолько переплетенную картину, что разделить ее по каким-то принципам “свободы” порой просто не представляется возможным. Вполне очевидно, что разработка ПО стоит денег, причем немалых и постоянно. Конечно, роль энтузиастов и добровольцев очень велика в созидании инноваций, но даже им нужны средства для работы и жизни. В стандартной схеме ППО разработка программ выполняется за счет прибыли, получаемой от реализации уже созданных продуктов. Как правило, начало работ ведется за счет коммерческих кредитов, которые нужно возвращать.

В случае СПО довольно обычной схемой является “некоммерческий” подход, при котором получаемые средства не возвращаются тем, кто их дает. Кто же выступает меценатами и зачем это им нужно? Основными инвесторами СПО являются государство и общественные фонды, а также те самые проприетарные (не только софтверные) вендоры. Фактически только наличие этих мощных инвесторов позволяют сообществу СПО создавать “бесплатные” продукты.

Причины, по которым в этом участвуют государство и общество, вполне понятны: это их реальный вклад в развитие ИТ-отрасли, поддержку стартапов, формирование конкурентной среды, проведение фундаментальных исследований. Вполне понятно, что государство не может напрямую финансировать R&D коммерческих компаний. Но через инвестирование СПО оно фактически участвует в поддержке отрасли в целом, в том числе ППО-разработчиков.

А зачем это нужно коммерческим компаниям? Ответ достаточно очевиден, хотя имеет довольно много аспектов.

Исследования и разработки (R&D) являются ключевым направлением деятельности ИТ-отрасли. Этот комплекс работ включает очень много разных форм и подходов, реализуемых в том числе в крупных ИТ-компаниях. Многие из этих работ ведутся в различных подразделениях (научные исследования, коммерческие разработки) внутри компаний. Но очень большая часть выполняется и во вне, в частности в университетах. Кроме того, для ИТ-отрасли очень важно иметь систему инновационных коммерческих разработок в виде независимых стартапов — опыт однозначно показывает, что независимые проекты порой бывают намного эффективнее, чем внутрифирменные.

Модель СПО-разработки является очень хорошей (но все же одной из возможных для исследовательских и стартаповских проектов с участием широкого круга энтузиастов) и одновременно очень удачной формой объединения инвестиционных усилий общества, государства и крупного бизнеса (в том числе разных представителей бизнеса в одном проекте). При этом вклад ППО-компаний заключается не только в прямом финансировании, но и в технологической и даже кадровой поддержке. Крупые вендоры (IBM, Microsoft) регулярно сообщают о переводе своих разработок и технологий в режим открытого и свободного ПО. Менее афишируется кадровая поддержка, но в целом, например IBM, не особо скрывает, что очень значительное число ее штатных сотрудников-инженеров работают над различного рода открытыми проектами.

Возврат инвестиций коммерческих компаний производится в виде возможности использования результатов СПО-проектов для создания своих коммерческих продуктов. На ИТ-рынке можно привести очень много таких примеров — скажем, открытый проект OpenOffice.org, который выполнялся под эгидой Sun, создававшей на его основе свой продукт StarOffice. Можно еще назвать аналогичный проект Eclipse, реализуемый большой группой ППО-компаний во главе с IBM.

Результаты исследования, проведенного еще в 2008 г международной аналитической компанией THE 451 GROUP, говорят о том, что 50% поставщиков ПО используют гибридные модели разработки, сочетая код, полученный в проектах с открытым кодом, и усилия собственных разработчиков. Например, IBM известна как один из самых рьяных сторонников гибридных методов разработки.

Отдельно нужно сказать об интересах несофтверных компаний (поставщиков аппаратных средств и услуг). Их инвестиции в СПО связаны порою с прямым коммерческим интересом: появление более дешевых продуктов позволяет повышать долю затрат пользователей на оборудование и сервис. Во многом активная поддержка СПО со стороны IBM объясняется именно этим аспектом: ведь четверть бизнеса Голубого гиганта приходится на поставки “железа”, а половина — на предоставление технических и консалтинговых услуг.

Из всего сказанного можно сделать вывод о том, что противопоставление так называемого “открытого” и “закрытого” программного обеспечения носит искусственный характер. Если допустить вариант “полной победы” СПО на рынке, то очень скоро этот сегмент просто потеряет ключевые источники своего финансирования.

На практике же мы сейчас можем видеть, что СПО-проекты в силу модели своей организации не могут перерасти некоторые критические размеры. В последние годы мы видим, что многие СПО-проекты фактически теряют статус независимых, попадая в прямое ведение ППО-гигантов. Вот примеры только последних лет: Xen — Citrix, JBoss — Red Hat, MySQL — Sun — Oracle. Утрата независимости СПО-проектов создает значительные проблемы для их развития в качестве общеотраслевых. Но на самом деле такой поворот событий носит вполне объективный характер: начиная с определенного масштаба работы, модель СПО работает все менее эффективно.