Понять Open Source: модели использования

Для чего компании и отдельные люди вкладываются в Open Source?

Википедия предлагает воз и маленькую тележку ответов на этот вопрос. Я не буду здесь перепечатывать Википедию. Остановлюсь только на нескольких моделях работы с Open source. На тех, которые, как мне кажется, либо плохо проиллюстрированы в популярных источниках, либо не упомянуты вовсе.

Особое внимание я уделю подходам, появившимся относительно недавно. Тем самым я исполню обещание, данное в предыдущем посте на тему открытого кода – обещание поговорить о путях развития Open source.

В конце вас ждет несколько опросничков (которые упертый движок Хабрахабра упорно не позволяет вставлять в основной текст).

«Просто так» или «чтоб не пропало»

Иногда люди пишут софт для того, чтобы выполнить дипломную работу или решить научную задачу, или для каких-то других вспомогательных целей. Если код получается большим и полезным, создатели могут захотеть на нем заработать и продолжить развивать как проприетарный продукт. Так, например, когда-то произошло с симулятором Simics, созданным шведскими исследователями из академической среды.



Однако часто размер кода невелик или у создателей нет планов на коммерциализацию. Тогда они могут выложить код в Open Source «просто так».

Скорее всего, вы уже многократно сталкивались с этой анти-бизнес-моделью. Я о ней здесь упоминаю по двум причинам. Во-первых, хочу поделиться одним интересным для меня примером. А во-вторых, хочу предложить немного «лирики» на тему дарения.

Сначала пример. Софт, подаренный миру без планов заработать, я – как и многие другие разработчики – использую довольно часто. Однако досконально вникать в код, выложенный «просто так», пришлось лишь однажды. Именно об этом случае я и расскажу.

Как-то мне понадобилась клиентская native-библиотека для работы с HDFS. HDFS – это файловая система в составе Hadoop. Ничего страшного, если вы ничего об этом не слышали. (Однако все-таки интересно, знакомы ли вам эти слова. См. опросничек внизу). Основной момент этой истории в том, что Hadoop написан на Java (на эту тему внизу тоже есть опросничек), а мне нужно было получить доступ к HDFS в обход Java-машины. Для этого я нашел очень шуструю C-библиотеку под названием Hadoofus.

Видимо, я стал первым её серьезным пользователем, потому что сразу наткнулся на несколько очень существенных багов. Связался с автором, и он моментально все исправил.

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

Я много переписывался с автором Hadoofus’а. Благодаря чему узнал, что библиотеку он написал когда-то в качестве инструмента для выполнения собственной работы. Т.е. в каком-то смысле, ее создание оплачено его работодателем. Тем не менее, это ничуть не умаляет его готовности помогать другим.


На этом, пожалуй, закончим с мотивацией «просто так». Как я уже говорил в предыдущем посте, наиболее крупные и интересные проекты вырастают из мотивации другого рода. Но прежде, чем перейти к ним, приведу свою очень высокоуровневую шкалу мотиваций:

1. Существует горстка энтузиастов, для которых открытый код – это сама цель
2. Существует гораздо бОльшая группа людей, которые выходят в Open Source либо «чтоб не пропало», либо с неясными целями («А вдруг само как-то выстрелит?» и т.п.)
3. А есть люди и компании, для которых открытый код – это инструмент для достижения конкретных бизнес-целей.

Бывают еще смеси первого, второго и третьего в разных пропорциях.

Для меня мотивация третьего рода самая интересная. О ней дальше и будем говорить.

Непрофильный актив

Часто компании – особенно крупные – разрабатывают софт, который играет вспомогательную роль для обеспечения основного бизнеса. Сюда нередко попадают инфраструктурные приложения, вроде систем тестирования, менеджеров задач и средств анализа кода. Могут быть и более высокоуровневые вещи, вроде «системы учета чего-нибудь» или графического интерфейса для «чего-нибудь еще».

Продавать подобные приложения-инструменты для компании было бы непрофильным бизнесом. Однако и держать код взаперти тоже особого смысла не имеет (если конечно, он не содержит торговых секретов). Таким тулам прямая дорога в опен сорс. Например, Гугл так и поступил со своим приложением под названием ThreadSanitizer. Это инструмент для поиска ошибок времени выполнения в многопоточном код. Похоже, Гугл заботится о качестве своего кода, поэтому и озадачился разработкой Санитайзера. Пытаться делать деньги непосредственно на нем для Гугла было бы нелепо. Зато вывод тула в опен сорс позволяет привлечь к его развитию сторонних пользователей. Чем больше у приложения пользователей, тем более полезным и надежным его можно сделать.

Продвижение основного продукта

Существует множество примеров того, как софт с открытым кодом используется для продвижения платного ПО. На таких примерах мы здесь останавливаться не будем. Гораздо интереснее выглядят случаи, когда Open source используется для продвижения НЕ программных продуктов.

Таких примеров гораздо меньше. Но еще меньше случаев, когда речь идет о действительно больших Open source проектах, вокруг которых выстроено развитое сообщество разработчиков.

Однако они есть. Наиболее интересным мне здесь представляется пример Интела.

Интел несколько лет назад включился в разработку Open source компиляторов GCC и LLVM. Вот, например, скриншот с головной страницы сайта GCC. Я сделал его 25 декабря прошлого года.

Очень приятно видеть на странице такого популярного продукта как GCC имена людей, которые работают (или работали) в московском офисе Интела.

Однако зачем это Интелу???

Тут надо сделать шаг в сторону и сначала понять значимость компилятора как продукта для компании.

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

Может, компания и хотела бы заработать на компиляторах (кто знает…), но не зарабатывает. И даже более того. Допустим, прилетели инопланетяне, наставили на штаб-квартиру и заводы компании (и еще на CEO лично) лазерные пушки и сказали:
— Если будете брать деньги за компилятор, мы вас испепелим.

И вы знаете что? Интел продолжит делать компиляторы. Будет раздавать их бесплатно. Потому что компилятор для Интела – это стратегический продукт. Ибо он помогает продавать процессоры.

Думаю, теперь должно быть понятно, зачем Интел занимается развитием GCC. Это очень популярный компилятор, поэтому компания борется за то, чтобы на ее процессорах приложения, скомпилированные GCC, исполнялись лучше, чем на других.

С LLVM ситуация схожая. Сейчас этот компилятор резко набирает популярность. Он уже является системным компилятором для FreeBSD и некоторых версий OS X. Используется наравне с GCC для компиляции под Android. На нем же основан официальный компилятор ARM.
Среди причин, по которым разработчики системного софта переходят с GCC на LLVM – более гибкая лицензия, которая позволяет строить на базе компилятора проприетарные продукты.

Интел от этого свойства тоже может выиграть. «Разгонять» GCC – довольно сложное и рискованное занятие. Многие улучшения могут быть платформенно-независимыми, а значит, от них также выиграют и разработчики других платформ. LLVM позволяет скрыть все самые «лакомые» улучшения в проприетарном коде. Поэтому, с точки зрения коммерческих компаний, он гораздо интереснее GCC.

Если поспекулировать, то можно предположить, что в будущем многие проприетарные компиляторы (возможно даже, интеловский основной компилятор) окажутся построенными на базе LLVM.

(См. опросничек на тему компиляторов в самом низу)

Продвижение основного продукта 2

Еще один пример на ту же тему.

Сейчас крупные cloud-провайдеры вкладываются в развитие открытого системного ПО и инструментов виртуализации. Например, Google участвует в разработке Docker’а.

Мотив подобной деятельности очевиден: продажа облачных сервисов, построенных на этих продуктах.

Это формирующийся тренд, и дальше он будет только усиливаться. Причем, помимо ПО, которое позволяет продавать «инфраструктуру», облачные провайдеры, скорее всего, начнут все больше вкладываться в развитие популярных пользовательских приложений. Вероятно, появится что-то вроде «Cloud-ready open source», который будет обладать следующим свойствами:

• оптимизирован под конкретную облачную инфраструктуру
• совместим с популярными облачными платформами
• интегрирован с облачными сервисами
• являются частью «пайплайна», который продается как отдельный сервис (либо предлагается бесплатно, а клиенты платят за используемые вычислительные ресурсы)
• ваш вариант?

Оживить «тухлый» продукт

На мой взгляд, это один из самых новых сценариев. По крайней мере, крупные компании стали прибегать к нему только года два-три назад.

Идея здесь следующая. У вас есть продукт под называнием «тухлый продукт», в разработку которого вы вложили кучу сил и времени. Однако продается он совсем не так хорошо, как вам хотелось бы.

Причем продукт не обязательно плох. Он может быть качественным, полезным, но по каким-то причинам, невостребованным на рынке.

И тут вы решаете вдохнуть в него новую жизнь. Выкладываете в Open source. Желательно, под другим именем, что-то типа «свежий продукт». Вы надеетесь на то, что вам удастся построить вокруг своего детища широкое сообщество программистов и пользователей, и они помогу вам сделать его желанным для рынка. Продвинут в ниши, о которых вам даже и не снилось.

На чем основана ваша надежда? На наблюдении, что многие Open source продукты – вроде Hadoop – развиваются взрывными темпами как раз за счет большого и грамотного сообщества.

Допустим теперь, ваша идея выстрелила. Продукт получился отменным. Однако, как его теперь продать?

Оказывается, есть способ. Вы «упаковываете» его определенным образом, уже под третьим названием «супер продукт», и продаете. Причин, по которым рынок может захотеть его купить, может быть много. Все зависит от «упаковки». Это может быть готовое программно-аппаратное решение. Или решение, расширенное проприетарными модулями. Либо решение, дополненное сервисным обслуживанием. И еще много чего…

Изменив себе, конкретных примеров я здесь приводить не буду. Ибо над известными мне наиболее интересными проектами трудятся мои друзья из разных компаний. Не уверен, что они были бы рады увидеть названия своих детищ в таком контексте. Однако если вам известны подобные примеры, напишите, пожалуйста, об этом в комментариях. Будет интересно отследить судьбу таких проектов.

На перспективу

Способы, которыми компании вовлекаются в Open source, разнообразны и не всегда поддаются четкой классификации. Часто открытый код стоит «где-то сбоку» или вообще является побочным продуктом, на который компания соглашается ради какой-то отсроченной выгоды.

Примером здесь может служить деятельность компании Google в образовании под названием GA4GH – Global Alliance for Genomics and Health. Альянс был создан, чтобы разработать стандарты и эталонное ПО для обмена геномными и клиническими данными.

Но тут следует сделать небольшое лирическое отступление.

За последние лет 25 в геномике и смежных областях было совершено множество научных и технологических прорывов (см. опросничек внизу). Однако большая часть достижений до недавних пор имела «лабораторный» характер.

Но несколько нет назад мир осознал, что геномные технологии дозрели до коммерциализации и внедрения в клиническую практику. Начиная с 2013 года, IT-компании начали понимать, что перед ними многомиллиардный рынок, на который надо как-то войти. Было ясно, что тот, кто вовремя и правильно это сделает, сорвет большой куш. Непонятным было (и по-прежнему, до некоторой степени, остается), как туда войти.

Тем не менее, что-то делать было надо. И они начали делать. Сейчас свой крупный проект – а то и несколько – в области биомедицины не имеет только ленивый. SAP, IBM, Microsoft, Intel, даже Яндекс – все уже там.

По-настоящему большой куш никто еще не сорвал. Компаниям приходится изворачиваться и выбирать наиболее перспективные направления деятельности.

GA4GH – одно из направлений Гугла. Гугл осознает, что Альянс получился большой и международный. Поэтому высока вероятность, что из него что-то может вылиться. А значит, надо войти в него на раннем этапе. Чтобы влиять на стандарты в свою пользу, продвигать свои технологии, иметь доступ к международной экспертизе и, конечно же, использовать наработки в своих продуктах. Например, в платформе Google Genomics.

Софт, который создается силами альянса – прекрасная возможность «поиграться» с реализацией разрабатываемых стандартов на глазах у экспертов из разных областей. И отличный задел для того, чтобы потом упаковать его «как надо», либо вообще создать проприетарную реализацию.

На этом, пожалуй, закончим с моделями. Будем следить за появлением новых и развитием старых. К гадалке не ходи – нас ждут увлекательнейшие схемы!