LXF160:Как сделать миллиард долларов способом Red Hat

Подписка на печатную версию Весь 2015 год (12 номеров) Первое полугодие (6 номеров) Второе полугодие (6 номеров)

Подписка на электронную версию Весь 2015 год (12 номеров) Первое полугодие (6 номеров) Второе полугодие (6 номеров)

Подшивки старых номеров журнала (печатные версии) Весь 2014 год (12 номеров) Первое полугодие (6 номеров) Второе полугодие (6 номеров)

Red Hat

Джонатан Робертс вы­яс­ня­ет, как крупнейшая в мире компания от­кры­то­го ПО заработала миллиард, сделав свободу предметом первой необходимости.

Red Hat достиг важного рубежа: на ко­нец прошлого финансового года они получили доход, превысивший $1,000,000,000 (то есть миллиард долларов). Эта цифра сама по себе шок, но еще инте­реснее, как умудриться заработать такие деньги?

Многие из успешных компаний, работающих в индустрии ПО, смогли занять и удерживать свою долю рынка благодаря действиям, которые в лучшем случае были сомнительными, а в худшем – незаконными. Со­кры­тие технологий; плановый моральный износ; а также пресловутое «за­тя­нуть, за­хва­тить, за­га­сить» [embrace, extend, extinguish – фраза, которой корпорация Microsoft отражала свою политику, – прим. пер.] – вот стратегии, при­ме­няв­шие­ся разными компаниями, которые также замедляли темп инноваций, увеличивали себестоимость и урезали свободу пользователя. Red Hat, с мо­мен­та ее появления в начале 1990-х, во­ро­ти­ла нос от подобных практик. Вместо этого, как заявил во вступительной части Отчета за 2003 год Мэтью Шулик [Matthew Szulik], бывший председатель и руководитель компании, Red Hat позиционирует себя «в центре отношений, связывающих потребителя, сообщество и партнеров», чтобы все оставались в выигрыше. Red Hat ведет свой бизнес ина­че.

По крайней мере, такое ощу­щ­ение есть. Мы попробуем раз­обрать­ся, что же это значит на самом деле – как Red Hat зарабатывает деньги на свободном ПО, какая часть ее репутации заслуженна, как она добилась успеха и где окажутся компания и движение открытого кода в будущем. Мы побеседовали с Джимом Уайтхерстом [Jim Whitehurst], руководителем компании с 2008 года, и Майклом Тиманном [Michael Tiemann], вице-президентом по делам открытого кода и основателем Cygnus Support, компании, занимающейся свободным ПО, которая зарабатывала миллионы еще до того, как появился Linux.

«Red Hat ведет бизнес ина­че. По крайней мере, такое ощу­щ­ение есть.»

Происхождение

Начнем мы с происхождения Red Hat, поскольку это отнюдь не история внезапного успеха. Как и у всех свободных программ, ее корни уходят в 1980-е годы, к Ричарду Стол­лме­ну [Richard Stallman], GNU Project, Free Software Foundation, и к Линусу Торвальдсу и ядру Linux.

После создания этих основных ингредиентов многие начали создавать и распространять свободное ПО, чтобы работать с ними. При наличии времени и навыков можно было собрать все составляющие и создать свободную UNIX-подобную операционную систему для обыч­ных ПК. Сейчас мы воспринимаем это как должное, но в конце 1980-х большинство корпораций работало на системах UNIX, которые стоили более 10 000 долларов. На­ли­чие свободной альтернативы стало истинным освобождением.

По крайней мере, так счел Марк Юинг [Marc Ewing]. Окончив университет, он основал софтверную компанию под названием Red Hat. Сперва он начал разрабатывать приложения для UNIX, но не мог себе позволить покупку терминала; как раз в это время появился Linux, причем бесплатный, так что он этим воспользовался для создания собственного приложения.

Однако в те времена Linux был не так отлажен и отнюдь не готов к работе с ходу, как сейчас. В интервью для Salon.com в 1999 году Юинг сказал, что «за несколько последующих месяцев... я обнаружил, что трачу свое время не на работу над собственным проектом, а на отладку Linux... Я вдруг осознал, что на самом деле должен со­брать дистрибутив Linux луч­ше­го каче­ства. Так я и поступил».

Приблизительно тогда же Боб Янг [Bob Young], еще один предприниматель в области технологии, основал ACC Corporation. Он ушел со своей работы и начал работать в швейном закутке жены, где и публиковал информационный бюллетень New York UNIX и каталог ПО под названием ACC PC Unix and Linux Catalog.

Когда по­шли разговоры об октябрьском – “Halloween” – бе­та-ре­ли­зе Red Hat, дистрибутива Юинга, Янг позвонил ему, чтобы договориться о внесении этого дистрибутива в каталог. Они быстро выяснили, что их таланты – техниче­ские способности Юинга и знания Янга в финансах и маркетинге – идеально сочетаются. В 1995 году Янг купил компанию Юинга, объединил ее с собственной, и они оба за­се­ли за работу под брэндом Red Hat Software. Поскольку изначально их бизнес строился на свободно рас­про­стра­няе­мых программах с открытым кодом, они продолжили выпускать все, что создавали, как программы с открытым кодом, так­же распространяя их свободно. Первой задачей Юинга после слияния двух компаний стала переделка Red Hat, чтобы упростить ее загрузку с сайтов FTP по всей сети.

Прагматичный идеализм

Здесь не было никакой идеологиче­ской подоплеки, мотивированной глубокой верой в то, что ПО должно быть свободным, как у Столлмена, когда он запустил GNU Project. Юинг не планировал заниматься свободными программами, а Янг начинал, распространяя и свободные, и коммерче­ские программы – лишь бы заработать денег.

При этом важность свобод, гарантированных лицензиями GNU, ми­мо них не про­шла: последние пару десятилетий оба говорили о воздействии, оказанном идеологией свободного ПО на их ранние усилия.

На по­верх­но­ст­ный взгляд, без свободного ПО их предприятие про­сто бы не со­стоя­лось, из-за до­ро­го­виз­ны проприетарного UNIX. Но если копнуть глубже, оба сознавали, что происходит нечто большее.

С техниче­ской точки зрения, Юинг оценил преимущества методологии открытого кода. В том же интервью для Salon.com он сказал: «...как программист, имеющий академическую подготовку и работавший с программами с открытым кодом... я знал, что это намного более эффективный и производительный способ разработки ПО».

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

Бизнес-модель

Янг осознавал важность открытого кода, выбирая бизнес-модель, которая позволила бы им зарабатывать деньги на свободном ПО. В книге Open Sources: Го­ло­са ре­во­лю­ции от­кры­то­го ко­да он объяснял, что «надо фокусироваться на размере рынка, а не на его доле... Чем больше пользователей Linux в целом, тем больше пользователей будет у Red Hat для своей продукции».

Это наблюдение означает, что пред­по­сыл­ка успеха Red Hat – успех соперничающих с ним дистрибутивов Linux, и лицензии на ПО с открытым кодом по­мог­ли быстрее внедрить их в жизнь. Когда Red Hat улучшала какую-то программу, все ее соперники-дистрибутивы, в том числе и основанные на ее продуктах, получали от этого пре­имущество; когда другие дистрибутивы улучшали какие-то программы, Red Hat и ее клиенты тоже получали от этого преимущество. Как сказал Янг: «Производитель программ с открытым кодом начинается с каче­ственного продукта. Фо­кус в том, чтобы найти эффективный способ зарабатывать деньги, предлагая своим клиентам преимущества открытого кода». Этим трюком Red Hat овладела в совершенстве, и Уайтхерст объяснил нам, как она использует его сегодня.

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

Что мы делаем – и это одна из основных ценностей, предоставляемых на­ми нашим клиентам – каждый два года мы замораживаем спецификацию, и создаем версию Red Hat Enterprise Linux, и принимаем на себя обязательство по его поддержке без нарушений двоичной совместимости в течение 10 лет».

Это вовсе не простая задача. Каждый релиз Red Hat Enterprise Linux ве­дет команда из более чем 100 инженеров, сопровождающих этот релиз на протяжении всего его 10-летнего жизненного цикла. Они портируют исправления ошибок и обновления системы безопасности из новых программ на­зад в старые, изначально бывшие в поставке, не нарушая двоичной совместимости.

Естественно, сюда же входит и прочая работа, включая техподдержку, обеспечение документации и т. п., но в центре бизнеса Red Hat – обеспечение традиционным предприятиям доступности всей силы и мощи открытого кода, работа над его стабильностью, что­бы в него оп­рав­дан­но было делать солидные вложения.

Катализатор

Хотя вышеописанный сценарий представлят основной бизнес Red Hat, все же, согласно утверж­дению Уайтхерста, некоторые клиенты ценят именно ее тесную связь с сообществом откры­того кода.

«Самые яркие примеры – когда мы работали с ВМФ, встраи­вая ядро реального времени в пред­ше­ст­вую­щие про­ек­ты, или с Агентством национальной безопасности, встраивая SELinux в их ПО. В этих примерах мы работали непосредственно с компаниями над приоритетами, которые имелись у них рань­ше».

У этих компаний нет необходимых знаний или опыта для эффективной работы с ранее вы­шед­ши­ми проектами. Они не понимают, как работает общественный контроль над исходником или отчеты об ошибках, как работают списки рассылки и каковы стандарты кода в каждом сообществе. А вот у Red Hat есть и подобный опыт, и знания. Более того, Red Hat является такой же компанией, как и их компании, и она умеет разговаривать с ними на их же языке и стать мостом, соединяющим эти два мира.

Это важно не просто потому что обеспечивает их еще одной клиентской базой – теми, кому нужно интегрировать новые функции – но и потому, что делает их брэнд сильнее в глазах тех, кто заинтересован только в использовании программ с открытым кодом. В изначальном описании бизнес-модели Янг сказал, что больше всего их работа напоминает производство по­тре­би­тель­ских товаров, например, бу­ти­ли­ро­ван­ной воды или кетчупа. В том смысле, что любой может создать свой собственный кетчуп из имеющихся под рукой ингредиентов, не нарушая при этом никаких законов, однако никто такого не делает.

В чем-то это удобство – кому охо­та са­мо­му замешивать кетчуп? Но это не объясняет, почему Heinz захватил такую до­лю рынка. Heinz стал доминировать на рынке, где каждый потенциально способен создать конкурентоспособную альтернативу, потому что смог создать сильный брэнд – Heinz для многих си­ноним кет­чу­па.

Янг был убежден, что Red Hat может доминировать на рынке, где каждый может скопировать ее продукт, создав брэнд, равный по силе брэнду Heinz. Чего и до­би­лись по­став­кой каче­ственного кода, подкрепленного 10-летней поддержкой; но не в меньшей степени – соз­данием вес­ких оснований для претензии на роль идейного лидера в мире открытого кода, ко­то­рый в курсе всего происходящего и в деталях зна­ет весь процесс разработки.

Конечно, сообщества, с которыми работает Red Hat, являются независимыми организациями с собственными целями и желаниями – и собственными функциями, которые они хотят добавлять. Не об­хо­дит­ся без ситуаций, когда цели сообществ вступают в конфликт с целями Red Hat и ее партнеров; и мы спро­си­ли у Тиманна, что в таких случаях происходит.

«Мы де­ла­ем шаг назад и задаемся вопросом, что послужило причиной подобного противоречия; и нельзя ли создать новые условия, в которых этого конфликта бы не возникло? Это чаще срабатывало, чем нет.

И мы всегда смотрим на искомый компонент – а это может быть технология, способ организации пакетов, тестирование или решение, принятое руководством; но мы всегда смотрим на Fedora, как на единое целое, вплоть до самого кода, и спрашиваем: “Где узкое ме­сто на данный момент?”, и рас­ши­ва­ем его».

Значительные изменения

В случае Fedora можно видеть, что все эти разнообразные компоненты сообщества претерпели солидные изменения с момента ее появления. Самое примечательное в том, что еще за год до этого существовали общественные репозитории кода, ку­да каждый мог вносить свой вклад, и даже тогда это было в форме Extras, существовавших отдельно от основного дистрибутива.

С течением времени Extras слились с Core, и теперь лю­бой может вносить посильный вклад в любую часть операционной системы. В самом начале это стало ис­точником трений между Red Hat и сообществом (чтобы разобраться в причинах, загляните на http://lwn.net/Articles/83360), но эта проблема уже улажена.

Эмоциональная победа

Когда слушаешь Тиманна, Уайтхер­ста и прочих из Red Hat, легко поддаться их энтузиазму относительно компании. Свои деяния они описывают так эмоционально и захватывающе, что невольно понимаешь, что их миссия – сделать этот мир лучше.

Вот что Тиманн говорит о ситуациях, приведших Red Hat к самым большим успехам:

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

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

История вклада Red Hat в сообщество открытого кода добавляет этим словам вес. Уайтхерст сказал нам, что «У нас есть 40 человек, работающих в команде настольных сис­тем, но на самом деле мы не продаем потребительских настольных сис­тем, их доля в на­шем бизнесе очень мала. Эта до­ля определенно не оправдывает работу аж 40 человек. Мы занимаемся этим только по единственной причине: это важно для сообщества открытого кода, это важно для разработчиков, занимающихся другими значительными компонентами Linux».

Собрав все эти факты вместе, легко вообразить, что у деятельности Red Hat гораздо больше общего с благотворительностью, чем с традиционным бизнесом.

Red Hat == Microsoft

Но если вы по­чи­тае­те финансовые документы Red Hat или рассмотрите ее историю, станет очевидна и другая сторона компании. В случае финансовых документов, мелькание фраз типа «использование сообщества с открытым кодом» ми­гом отгоняет мысли о филантропии и навева­ет идею о нещадной экс­плуа­та­ции добровольцев ради зарабатывания кругленьких сумм для Red Hat и ее акционеров.

Да и в истории Red Hat два случая отлично иллюстрируют, почему некоторые столь скептиче­ски настроены по отношению к ней.

В первом случае Red Hat версии 7 вышла с GCC 2.96, этапом разработки на пути к GCC 3.0. Именно эта версия компилировала код, несовместимый с более ранними версиями и с финальной версией, когда та вышла.

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

Многие усмотрели в этом происки темных сил. За два года до этого Red Hat трудилась, не покладая рук, привлекая партнеров – Oracle, SAP, Novell, HP, Compaq и Dell все согласились оказать поддерку Red Hat Linux, новому компилятору и всему прочему.

Же­лая разделить успех Red Hat, другие разработчики тоже долж­ны бы бы­ли переключиться на новый компилятор, против воли команды разработки GCC. Это, конечно, был отнюдь не конец света – другие дистрибутивы могли использовать тот же компилятор, поскольку и он сам и весь его код был открытым – но этот шаг вносил раздор, и выглядело это очень похоже на тактику Microsoft по защите своих рынков. Более того, у Red Hat наверняка имелись ресурсы для работы со всеми этими программами, которые не компилировались, а у других дистрибутивов их не было.

Скрытые за­пла­ты

Менее давний инцидент произошел в 2011 году, когда Red Hat изменила свою политику относительно за­плат ядра. В прошлом все за­пла­ты, которые она портировала в свои поддерживаемые релизы, предоставлялись в виде отдельных файлов, как де­ла­ли все остальные.

Любой, кто использовал ту же версию ядра, мог взглянуть на все эти за­пла­ты и увидеть, есть ли среди них пригодные и для его дистрибутива. Если они там были, их можно было применять выборочно, игнорируя другие, несовместимые. Таким образом можно было легко позволять всем пользоваться преимуществом открытого кода: делиться друг с другом улучшениями. В 2011 году Red Hat начала поставлять исходник ядра в виде одного большого tar-ар­хи­ва со всеми заплатами, уже примененными. И хотя все по-прежнему могли видеть код, стало намного сложнее определять, какие части были заплатами, созданными Red Hat, и какие проблемы они решали.

Red Hat настаивает на том, что это неважно, поскольку ее версии ядра настолько отличаются от тех, которые используются в других дистрибутивах, по функциям, внедренным из более новых версий ядра в процессе разработки, что большинство ее за­плат не соответствуют другим. Это, и тот факт, что она продолжает предоставлять всю свою работу над ядром и любые со­от­вет­ст­вую­щие за­пла­ты непосредственно другим производителям – и есть политика Red Hat.

Но что бы они ни говорили, яс­но, что это разозлило часть сообщества. Разработчик ядра Debian, Максимилиан Аттемс [Maximillian Attems], сказал, что «Red Hat следовало бы откатиться и не делать таких глупых с точки зрения управления шагов. Рядом с ними даже полуразработанная ветвь Oracle‚ “Unbreakable” 2.6.32, смотрится лучше».

Хотя мотивация, стоящая за всем этим, кажется вполне разумной – что­бы другие компании, занимающиеся Linux уровня предприятия, не предлагали клиентам Red Hat поддержку Red Hat Enterprise Linux за более низкую цену: благодаря запутанной системе за­плат третьим сторонам становится намного сложнее предлагать тот же уровень поддержки, что и сама Red Hat; все же многих в сообществе разочаровывают подобные поступки.

Как и прежде, это вовсе не мировая катастрофа. За­плат­ки Red Hat по-прежнему находятся в открытом доступе, как видно из поста http://lwn.net/Articles/430600 в списке рассылки; это просто затруднило работу всех остальных и огорчило членов сообщества открытого кода.

Симбиоз

Оба этих примера, а есть и другие, дают некоторым по­во­д предположить, что Red Hat ничем не отличается от других компаний. Пусть она и сотрудничала с сообществом, но когда в игру вступают интересы акционеров и растет заинтересованность менеджеров в добывании все больших сумм денег, она начинает мешать движению открытого кода, чтобы обезопасить свои преимущества. Справедливо ли рассматривать ситуацию в таком ключе?

Первое, что можно сказать в ответ, что это лишь отдельные инциденты за 20-летнюю историю. Если сравнить каждый из них с общим вкладом Red Hat в дело открытого кода, который иллюстрируют и ее работа над рабочим столом, и положение ведущего корпоративного помощника и участника разработки ядра, трудно счесть любой из них частью плана подрыва самого сообщества и конкуренции внутри открытого кода. Более того, наш разговор с Уайтхерстом объяснил, почему Red Hat никак и никогда не может целенаправленно подрывать движение открытого кода, даже если иногда и допускает неверные шаги в отношениях с широким сообществом.

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

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

Red Hat, конечно, использует сообщество открытого кода. Отдельные результаты труда всех этих разработчиков со всего мира – именно то, что дает компании ее основное преимущество. Это – бизнес для получения прибыли, и она зарабатывает деньги на результатах труда других; было бы ошибкой считать Red Hat этаким филантропом.

Мудрая бизнес-модель

Но не меньшей ошибкой было бы считать ее не интереснее, чем другие компании. По словам Уайт­херста, Red Hat не может просто «употреблять» сообщество. Идти в ногу с быстрым темпом разработок, в частности, в об­лас­ти ядра, практиче­ски невозможно, если не работать с пре­ды­ду­щи­ми. Грег Кроа-Хартман [Greg Kroah-Hartman], один из главных разработчиков ядра, отметил следующее об Android: «Не один год сообщество по разработке ядра предлагает этим компаниям поддерживать единство кода, чтобы быстрее выпускать исправления системы безопасности и легче переходить на новые API... но вот сейчас у них проблемы. Компании, чьи прграммы привязаны к различным платформам для Android или проприетарным драйверам, не могут использовать ранее наработанный код [upstream], что приводит к значительному увеличению времени разработки и усложнению поддержки».

Red Hat вынуждена поддерживать сбалансированные, симбиотиче­ские взаимоотношения, выгодные обоим партнерам; без этого стоимость включения в ядро новых функций и их под­держки значительно вырастает. Возможно, ей и удастся перенести некоторое увеличение стоимости, но, по словам Тиманна, Red Hat не может «взвалить на свои плечи бремя самостоятельного изменения мира» – на это уйдет куда больше, чем миллиард долларов. Это означает, что бизнес-модель, которую Янг и Юинг изначально создали для Red Hat, всегда будет гарантией того, что Red Hat останется хорошим партнером для сообщества, даже если и будет время от времени совершать ошибки.

Еще более примечательно в этой модели то, что она приносит куда большую выгоду тем, кто находится за пределами Red Hat, чем любая традиционная модель, но в то же время является самодостаточной, в отличие от любого филантропиче­ского поступка.

Здесь, в LXF, мы считаем, что это стоит по­хвал, и мы полагаем, что продолжающийся рост и успех Red Hat и в дальнейшем сможет приносить сообществу открытого кода только благо.

С днем рождения, RHEL!

Следуя за Red Hat Linux, Red Hat Enterprise Linux стал основным продуктом. В этом месяце исполняется десять лет со дня его первого релиза.

Основная разница между этими двумя продуктами в том, что скомпилированный и готовый двоичный дистрибутив RHEL не раздается бесплатно (хотя его исходный код по-прежнему находится в свободном доступе). Более того, компания начала сокращать частоту релизов, но увеличивать период поддержки своих продуктов. В самой компании изменения восприняли без энтузиазма. Тим Берк [Tim Burke], вице-президент Linux engineering, сказал, что «в компании хватало тех, кто говорил: “Вы, ребята, нас убиваете, мы уходим из бизнеса, вы просто не ведаете, что творите”, и в культурном смысле это был истинный прыжок в неведомое». Некоторые инженеры ушли из компании в связи с этим решением, потому что они действительно хотели продолжать работать над Red Hat Linux.

Решение было смелым, но оно себя оправдало. Бла­го­да­ря бо­лее долгому циклу релизов и прицельному вниманию Red Hat су­ме­ла привлечь множество крупных и влиятельных клиентов. Тиманн рассказал нам, что в 2003 году, году перехода, Red Hat была в состоянии делать «потрясающие вещи на Уолл-стрит, которые в итоге привели к тому, что Linux стал самой надежной платформой для корпоративных приложений. Мы действительно смогли стать сплачивающим фактором». В том же году восемь из десяти ведущих инвестиционных банков работали на системах на базе Red Hat.

Хотя этот переход мог снизить при­вле­ка­тель­ность Red Hat как настольного Linux, он не лишил других производителей возможности использовать плоды своего упорного труда. CentOS и Scientific Linux, популярные проекты, управляемые сообществом, перекомпилируют исходные коды Red Hat Enterprise, давая преимущество предприятиям малого бизнеса и научным учреждениям.

> Майкл Тиманн основал Cygnus Solutions, разработал часть C++ для GCC и сей­час является вице-президентом Red Hat по делам открытого кода.

Майкл Тиманн о возможностях

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

«Последнее, чему я стараюсь учить всех при­хо­дя­щих в Red Hat, это ци­та­та из Ганди. Он сказал: “Пусть вы делаете неважную работу – важ­но, что вы ее делаете”. Я осоз­нал, что открытый код дает механизм принятия содействия от каждого, независимо от его значимости и величины, делая каждого крайне важным.

В ми­ре открытого кода человек, работающий над J2BE, может перейти на Apache и исправить там что-то, и наоборот. А следствие та­ко­во, что десятки тысяч незаметных, крошечных инноваций ведут к созданию более понятной, более стабильной, быстрее адаптируемой платформы...

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

Говоря о самих трудностях, Тиманн, как ни странно, не упомянул среди них патенты на ПО или иные законодательные ре­фор­мы. Он сказал, что это – общие трудности, поскольку они «оказывают давление на то, что Бен Франклин, Джон Адамс и, черт возьми, Адам Смит изначально описывали, как свободный рынок». Настоящая проблема в понимании Тиманна, в том, чтобы создать ПО, отвечающее требованиям 2012 года, «когда каждый триллион долларов имеет значение» и когда БРИК (Бразилия, Россия, Индия и Китай) имеют тенденцию к росту вплоть до экономиче­ского превосходства.

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

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

Джим Уайтхерст об облачных вычислениях

Уже некоторое время темп роста Red Hat составляет более 20 % в год. Мы поинтересовались у Джима Уайтхерста, долго ли это, по его мнению, будет продолжаться и чем будет обу­слов­лен их рост в будущем.

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

В этой парадигме Linux повсеместно выбирается в каче­стве операционной системы. Почти все облака, кроме Azure, работает на Linux, используют виртуализацию с открытым кодом и программы-по­средники с открытым кодом. Мир идет к нам. Так что я думаю, в более широком смысле... я бы озвучил это так: мы хотим, чтобы открытый код стал выбором по умолчанию для следующего поколения компьютерной инфраструктуры, так же, как Microsoft был выбором по умолчанию в прошлом.

...и поскольку эта парадигма продолжает разрастаться, я полагаю, что Red Hat обладает огромным потенциалом среди существующих продуктов для быстрого роста. Нам еще далеко не конец».

Нас удивило, что глава компании с открытым кодом так свободно говорит об облаке. В конце концов, Эбен Моглен [Eben Moglen] все последние годы говорил о вреде облака для пользовательской свободы и безопасности данных – во многом оно кажется антитезой программ с открытым кодом. Уайтхерст отверг это предположение: «Централизация вы­чис­лений – одна из лучших вещей, про­ис­шед­ших с открытым кодом... возьмите простую вещь, Hadoop. Все, что происходит в мире больших данных, те­перь сначала происходит в открытом коде – а не в лабораториях IBM или Oracle. Причина в том, что у компаний ти­па Google, Amazon, Facebook, Yahoo есть техниче­ские проблемы, ре­шае­мые с помощью открытого кода.

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

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

«Пакеты, к которым люди привыкли, не работали.»

OpenShift

Говоря о включении OpenShaft (не OpenShift) в Fedora 17, мы разъяснили, что это инфраструктура, как проект Service. То есть она облегчает возможность быстро создавать новые виртуальные машины по мере роста вашего бизнеса и удалять их по мере его сокращения.

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

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

Именно это предоставляют компании в виде Platform as a Service [Платформа как сервис, PaaS], такие, как Heroku. Разработчики могут пользоваться всеми преимуществами облака и перебросить возню с задачами системного администрирования на людей, оказывающих им выбранную услугу.

Недавно Red Hat запустила собственную PaaS под названием OpenShift (не OpenShaft – ну да, мы знаем, что перепутать легко!). Она работает на Red Hat Enterprise Linux и использует технологии, которые мы все знаем и любим, типа SELinux (ну ладно, пускай хоть и не любим), чтобы обеспечить безопасное хранение данных и кода каждого приложения. Каждое работает в собственной «песочнице» без необходимости снабжать каждую собственной виртуальной машиной.

OpenShift может работать с приложениями, разработанными на Node.js, Ruby, Python, PHP, Perl и Java, но это могут и другие PaaS. Интересным OpenShift делает то, что он с открытым кодом – и неудивительно, раз уж его предлагает Red Hat. А ста­ло быть, вы можете работать с ним на любой хост-системе, какую пожелаете – будь то собственная хост-версия от Red Hat, или вы установите свою собственную на Amazon Web Services, или возьмете ремикс Fedora, чтобы запустить его на оборудовании в вашем собственном офисе.

Уникальная культура

Вера Red Hat в модель открытого кода простирается далеко за пределы разработки ее программ. Ею пропитана вся корпоративная культура. Уайтхерст сказал нам: «Мы считаем, что создание во всей организации культуры, которая более открыта и свободна и являет собой практиче­ски саморазвивающиеся сообщества – наилучший способ управлять нашей компанией, в финансах или где бы то ни было еще».

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

Чтобы решить эту проблему, Red Hat создала парт­нерскую программу, согласно которой новых работников для приема в штат рекомендуют сотрудники компании (в этом году на работу принято более 1000 человек). Однако при интеграции приобретенных компаний нужен более активный подход.

«Когда мы купили JBoss – это было пять лет назад – это было очень, очень круто, потому что это было первое крупное приобретение, и это была совершенно иная культура. Мы извлекли из этого урок, и сегодня мы очень усердно трудимся над тем, чтобы не просто прийти и сказать: “Добро пожаловать на борт”, но и объяснить все “как” и “почему” нашей культуры. Так что мы очень много общаемся.

Возьмем, например, как мы купили Qumranet... когда мы завершали эту сделку, я встречался с нашими отделами продаж и отделами технологии и производства, и я привел целую армию, и встречался со всеми. Мы уст­раи­ва­ли пикники и затевали множество всяких вещей вместе с командой, просто давая им понять, кто мы и почему мы делаем то, что мы делаем, именно так».

Fedora 17 «Beefy Miracle»

Проект Fedora Project был основан, когда Red Hat решила прекратить выпуск своего свободного дистрибутива Red Hat Linux, чтобы сфокусироваться на версии Enterprise. Сегодня это проект, ве­до­мый сообществом, где инженеры из Red Hat сотрудничают с людьми из других компаний и проектов над разработкой и внедрением самого современного и превосходного ПО.

За последние девять лет он стал одним из самых популярных дистрибутивов и заработал немалое уважение за тесное сотрудниче­ство с пред­ле­жа­щи­ми разработчиками и интеграцию самых передовых технологий. Если вас интересует будущее компьютерных технологий уровня предприятия, Fedora – именно тот дистрибутив, который стоит попробовать. На диске этого месяца вы найдете версию Fedora 17, известную также как “Beefy Miracle”, ее самый последний релиз. Многие новые функ­ции – результат интеграции в дистрибутив самых последних разработок, и там есть от чего прийти в восторг.

Фиш­ки рабочего стола

Поместите его в DVD-привод, и, когда он загрузится, вы увидите рабочий стол на основе Gnome Shell, дополненный фирменной маркой Fedora. Рабочий стол – одна из основных новых функций в этом релизе, теперь он основан на самой свежей версии, Gnome 3.4. Это крупное обновление: в нем содержатся не только отладки и исправления ошибок, но и совершенно новые приложения. Самое примечательное – Boxes, простой инструмент для создания и управления новыми виртуальными машинами KVM и удаленными соединениями VNC с физиче­скими машинами.

Еще одна вещь на рабочем столе, на которую стоит обратить внимание – это интеграция файлов в результатах поиска режима Overview, вызов видео в Empathy и появление GIMP 2.8 – первого релиза, пре­достав­ляю­ще­го поддержку режима с единым окном для холста и панелей инструментов.

Открытые об­ла­ка

Помимо рабочего стола, мы счастливы видеть последнюю версию OpenStack под названием Essex. Это – конкурент с открытым кодом Amazon Web Services (AWS), изначально разработанный NASA и Rackspace.

Его можно использовать, чтобы запустить собственное частное или общественное облако, позволяющее реплицировать Amazon Elastic Compute Cloud and Simple Storage Service. Его API совместимы с API от Amazon, так что замечательные инструменты AWS будут с ним работать.

Вы как-то не уверены, что вам нуж­ны подобные программы – в конце концов, почему не использовать Amazon или традиционное резервное копирование и обслуживание файлов? Ну, во-первых, традиционное решение по резервному копированию даже близко не может сравниться по масштабу или обеспечить такую высокую скорость чтения и записи данных. OpenStack означает, что при необходимости вы сможете легко и быстро добавить больше данных для хранения. Относительно Amazon, сайт OpenStack ссылается на Центр суперкомпьютеров Сан-Диего [San Diego Supercomputer Centre], который считает провайдеров проприетарных облаков более дорогостоящими для долгосрочной работы. Также у них вызывает беспокойство их поддержка решений по альтернативному хранению – что, если в будущем они решат перейти на другую платформу, или даже использовать одновременно несколько платформ для снижения риска? Поскольку API у OpenStack открытые, эти риски значительно меньше.

Динамиче­ские брандмауэры

Более того, если вам надоела необходимость циклов в модулях сетевых фильтров вашего ядра для быстрого (или даже временного) изменения правил брандмауэра, вы будете рады узнать, что теперь бранд­мау­эром по умолчанию в Fedora является firewalld. Поскольку бранд­мау­эр стал демоном, пользователи могут настраивать правила, активировать сервисы и закрывать порты, даже не прикасаясь к модулю ядра.

Будущее пред­при­ятие

Red Hat анонсировал выход следующего релиза Red Hat Enterprise Linux в 2013 году, так что можете рассчитывать увидеть некоторые из опи­сан­ных функций в этом релизе.

Конечно, учитывая собранный на текущий момент объем данных и количе­ство компаний, заинтересованных в безопасности облака и возможности содержать его на имеющемся у них оборудовании, стоит ожидать, что Red Hat воспользуется OpenStack. Это развивающийся стандарт, и Canonical начинает его поддержку вместо Eucalyptus, и уже более 100 других компаний принимают участие в проекте.

Все это, вкупе с усовершенствованиями ext4, позволяющих поддерживать файловую систему размером более 16 терабайт, делают Fedora и будущие релизы Red Hat Enterprise Linux крайне привлекательными для пользователей и поставщиков крупной инфраструктуры. |

> Fedora 17 включает некоторые новые версии приложений Gnome, в том числе и Boxes — простой менеджер виртуальных машин.

«Мы счастливы видеть самую свежую версию OpenStack.»