Открытое ПО — это пример неожиданного успеха, условия для которого создавались не одно десятилетие. Успех этот не имеет ничего общего с нулевыми годами этого столетия, когда компания Red Hat и ее проект JBoss предложили новый принцип, к которому до сих пор многие относятся скептически. Пожалуй, по части Red Hat до сих пор существуют сомнения: а не является ли это открытое акционерное общество, создающее открытый код, на самом деле стартапом стоимостью более миллиарда долларов. Тем не менее, сегодня при знакомстве с новым стартапом первый вопрос, который всех волнует — занимается ли он Open Source.

По этой причине мы не без интереса прослушали недавно увлекательное обсуждение, организованное венчурной фирмой Accel Partners. Его лейтмотивом стала предпосылка, что Open Source становится бизнес-моделью по умолчанию при разработке ПО. Вел дискуссию Пинг Ли, энтузиаст по части больших данных из фирмы Accel, а участие в ней приняли генеральные директора трех ее портфельных компаний: Cloudera, Cockroach Labs (нет, они не являются потенциальными конкурентами Terminex) и Sysdig.

Хорошим индикатором прогресса Open Source может служить сравнение данных ежегодного опроса «Future of Open Source», уже более десяти лет подряд проводимого компанией Black Duck Software. По данным опроса за 2015 г. оказалось, что с 2010 г. открытый код стали использовать вдвое активнее при управлении корпоративным ИТ-сектором. В отчете за нынешний год говорится, что открытый код преобладает в операционных системах, платформах БД и инструментах разработки кода, а через два-три года он будет доминировать в таких областях, как облака, базы данных и большие данные. Задумайтесь об этом.

Решение Splice Machine открыть код своего продукта стало очередным напоминанием о том, что на рынках развивающихся технологий методология Open Source становится больше правилом, чем исключением из него.

В свое время Open Source-компании были исключением, но затем переход с лицензирования по принципу GPL, не подразумевающему авторских прав на код, к более гибкой системе авторских прав по лицензии Apache открыл для компаний-разработчиков новый путь к получению прибыли за счет создания уникальной интеллектуальной собственности.

Не все модели Open Source одинаковые. В основном преобладает модель с открытым ядром (open core), оставляющая за автором право на определенную интеллектуальную собственность, при этом существуют несгибаемые поборники Open Source вроде Hortonworks или Red Hat, которые придерживаются стопроцентно открытой модели. К тому же не все ясно с вопросом открытости: по идее, открытое ПО задумано для того, чтобы разработчик не смог его заблокировать. Но что если какой-либо открытый проект поддерживает только один разработчик? На ум приходит метафора с хлопком одной ладонью.

В ходе дискуссии представители Accel обосновали принцип, который они окрестили Open Adoption Software (ПО с открытой моделью распространения). Он основывался на несколько устаревшей (образца 2011 и 2012 гг., но, вероятно, все еще актуальной) сравнительной характеристике количества скачиваний платформы Splunk, поставляемой на рынок в рамках традиционной проприетарной модели, и открытого аналога Elasticsearch. Последний скачивали в 200 раз больше. Справедливости ради, возможно, здесь сравнивалось теплое с мягким, так как Splunk — это поисковая система конкретно по логам, а Elasticsearch — это более обобщенный поисковый продукт, включающий в себя хранилище логов. И хотя бесплатные скачивания не являются прерогативой открытого кода, только в этой модели можно бесплатно получить полную версию продукта. Делаем вывод: Open Source склонен открывать море возможностей.

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

В своей аргументации относительно открытого кода Accel делает упор на сообщество. Однако не все открытые проекты представляют собой общественные усилия, и в этом мы могли убедиться еще более десяти лет тому назад. В портфеле самой Accel есть примеры полных противоположностей: здесь вам и Cloudera, которая занимается продуктом, базирующимся главным образом на проектах сообщества Apache, и MongoDB, ведущая свой собственный открытый проект, размещенный на GitHub.

В противоположность модели сообщества, компания MongoDB осуществляет главный контроль над программой развития одноименного открытого проекта. Хорошо, может, в реальности не все так однозначно. С тех пор, как MongoDB взяла на вооружение модульную архитектуру для движков хранилищ данных, в этой модели, где доминирует разработчик, наметились послабления. И даже в случае с ориентированными на сообщество Open Source игроками вроде Cloudera проекты обычно вынашиваются под контролем главного разработчика и в конечном итоге могут перейти под Apache-лицензию.

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

В Open Source-модели также существует проблема ясности, или, скорее, ее недостатка. О ней свидетельствуют длинная череда обновлений Android и упорядоченная неразбериха с платформой Hadoop, где у каждого коммерческого разработчика имеется набор различных версий кода открытых проектов. Но здесь можно провести параллель с миром проприетарного ПО: все компании-разработчики отличаются, так зачем же им менять эту стратегию только из-за того, что они занялись Open Source?

Все началось со стандартов. Фактическим и формальным стандартом для корпоративных баз данных стал SQL, при этом каждый крупный игрок на этом поле по-своему реализовывал SQL и поддерживал разный набор функциональных возможностей ANSI SQL, не говоря уже о всех тех вспомогательных инструментах (хранение данных, их оптимизация и прочие процедуры), которые являются определяющими характеристиками базы данных.

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

Интересно отметить, что, за немногочисленными исключениями (вроде SugarCRM), открытый код не получил распространение на уровне отдельных приложений. В сфере приложений наблюдается миграция не в Open Source, а в облако. Корпоративным программистам гораздо важнее настроить конфигурацию ПО, чем возиться с исходным кодом.

И даже внутри ИТ-инфраструктуры процесс перехода баз данных на открытый код еще далек от завершения. Такие широко известные бренды СУБД, как Oracle, IBM, Microsoft и Teradata, в ближайшем будущем уходить с рынка не собираются, и их проприетарным моделям ПО также ничего не угрожает. Уж слишком много там вложено интеллектуальной собственности — от физического устройства БД до принципа встраивания бизнес-логики, так что открытый код здесь неуместен даже с технической, не то что с экономической точки зрения.

Вопрос открытого кода касается будущего принципиально новых платформ, и ответ на него едва ли можно считать делом решенным. В облачном секторе есть OpenStack с его многочисленными открытыми реализациями, однако наличие открытой альтернативы вряд ли в ближайшем времени подтолкнет рыночного лидера, компанию Amazon (чья главная коммерческая ценность состоит в их повсеместно применяемой, многофункциональной облачной инфраструктуре) в этом же направлении. С точки зрения набора технологий Amazon — это облачный эквивалент Oracle: если вы пользуетесь хранилищем данных Redshift от Amazon в сочетании с их инструментами миграции БД, хранилищем S3, потоковыми средствами Kinesis, службой исполнения кода Lambda и вычислительным сервисом EC2, вам придется выполнить классическое портирование на другую платформу, чтобы добиться аналогичного набора функций на платформах Azure или SoftLayer.

В области платформ данных классический пример Open Source — это Hadoop. Но тут нужно сделать оговорку: Hadoop не просто открытый проект, а смесь конкурирующих и перемежающихся открытых проектов, разрабатываемых различными компаниями. И хотя наборы средств Hadoop как правило мало отличаются, спектр поддерживаемого открытого и проприетарного кода может разниться. Например, оба фреймворка Hortonworks Ranger и Cloudera Navigator построены на открытом коде и выполняют схожие задачи по обеспечению безопасности и управления, но при этом охватывают разные комплекты программных компонентов. Всегда можно переключиться с одной Hadoop-платформы на другую, но если есть необходимость в использовании компонентов, разработанных конкретной компанией, все равно их нужно будет портировать.

Что же касается лучших в своем роде операционных баз данных на основе модели NoSQL и аналитических платформ NewSQL с массово-параллельной архитектурой, в долгосрочной перспективе они будут тяготеть к открытому коду, с условием, что если продукт окажется чрезвычайно нишевым, то стратегическая важность (и выгода) такого проекта будет базироваться скорее на бизнес-модели, а не на сообществе его участников.

Вернемся же к нашему основополагающему вопросу: стал ли Open Source бизнес-моделью по умолчанию для корпоративного ПО? Неприятно это признавать, но ответ неоднозначный: все зависит от обстоятельств.