Страница 29 из 105
Как говорит Фрай, «когда мы пытались отвечать на вопросы медленно и взвешенно, то сразу было заметно, что мы либо слишком медленны, либо недостаточно откровенны. Это совершенно не соответствовало уровню обмена информацией, привлекательному для разработчиков Linux». Фрай как-то сказал своей команде: «Я отключаю вас от корпоративной сети. Вы можете обсуждать вопросы, связанные с Linux, только через внешнее сообщество». И с тех пор вся команда использовала для общения только те форумы, на которых общались остальные разработчики Linux.
Также IBM столкнулась с основополагающей разницей между двумя способами создания программ — традиционным, принятым в компании, и способом, привычным для разработчиков открытого кода. Хотя сами шаги по разработке остаются прежними — дизайн, разработка, тестирование, поддержка, — но открытые сообщества тратят гораздо больше времени на внедрение, тестирование и поддержку, чем на пользовательские требования или программные спецификации. Традиционный проект может месяцами планироваться и проходить согласования ещё до того, как будет написана хотя бы одна строчка кода. Открытые же проекты могут начать разрабатываться сразу же — просто один человек, написав часть программы, размещает её в Сети. Новый код или компиляции программы могут размещаться ежедневно, давая тем самым глобальному сообществу возможность постоянно тестировать программу и исправлять её недочёты. А так как конечный продукт является бесплатным и код может меняться любым участником, программа сохраняет статус «в разработке» ещё долгое время после того, как она реально «была выпущена».
Фрай понял, что IBM, как новичку в b-web разработчиков открытого кода, придётся адаптироваться, и компания адаптировалась к более открытой, прозрачной схеме сотрудничества с внешними разработчиками. Её сотрудники должны были относиться к сотрудничеству с внешним сообществом так же честно, как к взаимодействию с коллегами по собственной компании. Использование принятых в сообществе средств коммуникации, даже для общения внутри своей команды, облегчило становление группы из IBM полноправными членами сообщества. А использование инструментов программирования, принятых в сообществе (пусть и не столь изощрённых по сравнению с инструментами самой компании), позволило улучшить сотрудничество с программистами, находившимися вне пределов IBM.
IBM приняла не только продукты и процессы, принятые в открытом сообществе, но и его философию, смысл которой состоял в улучшении качества и обеспечении роста, а не в получении прибыли от управления Правами или владения интеллектуальной собственностью. В какой-то момент IBM имела возможность выпустить собственную версию Linux — назвав её «дистрибуционной», термином, принятым в сообществе Linux. Однако компания предпочла не заниматься дистрибуцией самостоятельно, А поддержала вместо этого усилия по дистрибуции, предпринимаемые такими компаниями, как Red Hat и Suse.
Отказ от контроля в таких масштабах был, по меньшей мере, необычен, однако принёс неплохие плоды. IBM ежегодно тратит примерно юо миллионов долларов на развитие Linux. Если всё сообщество прикладывает Усилий на 1 миллиард долларов и хотя бы половина этих усилий полезна для клиентов IBM, это означает, что компания, вложив юо миллионов долларов, получает программного обеспечения на 500 миллионов. «Linux предлагает нам жизнеспособную платформу, заточенную под наши нужды, всего за 20 % цены, которую мы заплатили бы за операционную систему, защищенную патентами», — говорит Коули.
По всем оценкам, вовлечённость IBM в сообщество разработчиков Linux стала большой победой для обеих сторон. В то время когда доверие к Linux и её надёжность находились под большим вопросом, IBM «застраховала» риски клиентов. А вовлечение в процесс Big Blue и взятые ею на себя финансовые обязательства позволили компании существенно улучшить свои позиции относительно конкурентов, таких как Sun и Microsoft. IBM получила жизнеспособный продукт, являвшийся настоящей альтернативой серверам под управлением Windows на платформе Intel. Linux также смог откусить кусочек прибыли и доли рынка у Sun, став реальной угрозой её бизнес-модели.
Не менее важно, что IBM приобрела опыт и знания в рамках новой модели создания ценности. Компания, которая на протяжении пятнадцати лет была закрытой, вертикально интегрированной и концентрировалась на защите своей интеллектуальной собственности, теперь активно сотрудничала с сообществом разработчиков открытого кода и стала рассматриваться как партнёр, открытый и достойный сотрудничества. IBM наслаждается хорошим отношением тысяч независимых и корпоративных разработчиков, разделяющих принципы Linux и стремящихся развить своё сообщество. Навыки партнёрства и сотрудничества, а также особенные знания в области управления связями с сообществами, напрямую не контролируемыми компанией, стали её действующими стратегическими инструментами, которые конкурентам ещё предстоит разработать.
Открытые коды позволили IBM ускорить инновации и снизить прежние огромные расходы. Со стратегической точки зрения, такой подход к производству на равных является формой творческого аутсорсинга. Творческий аутсорсинг лучше всего работает в областях, не являющихся основными для вашего продукта или центром вашей бизнес-модели. Из этих стратегических заключений проистекает ряд уроков, которые могут быть полезны для вас и вашего бизнеса.
Во-первых, играйте на собственных слабостях. Посмотрите на сферы рынка, где ваши позиции ослабевают. Сотрудничество обойдётся вам дешевле (IBM на момент начала сотрудничества уже потерпела поражение в борьбе с веб-серверами и операционной системой OS/2, поэтому, даже в случае неуспеха с открытыми кодами, она не потеряла бы большой доли рынка). В то же время, ищите возможности, привлекающие клиентов или имеющие потенциал для взрыва вашего отраслевого рынка.
Во-вторых, используйте сбалансированный подход. Спросите себя: готовы ли вы выступить в качестве лидера сообщества, работающего по принципам производства на равных? А может быть, вы сможете лучше исполнить свои задачи, просто присоединившись к существующим «движениям»? В большинстве случаев присоединение к существующим, активно развивающимся движениям приведёт к лучшим для вас результатам. Не отказывайтесь от вертикальной интеграции и иерархий. Попытайтесь вместо этого совместить модели открытых систем и защищенной интеллектуальной собственности. Смешанный подход позволит именно вам адаптировать стратегии к взрывным возможностям, появляющимся с развитием проекта, — так, как это сделала IBM, вручив части своего кода «в подарок» сообществу.
В-третьих, адаптируйтесь к правилам сообщества и скорости его работы. Не пытайтесь управлять им, пока вы не заработали в сообществе авторитет. Не критикуйте — Фрай видел многое из того, что ему не нравилось, однако оставался спокоен. Критика сообщества — право тех, кто уже доказал что-то, внеся в его развитие важный вклад. Используйте инструменты и методы коммуникации, принятые в сообществе. И помните: открытые сообщества любого типа имеют тенденцию развиваться быстрее, чем иерархические системы. IBM потребовалось уделить особое внимание тому, чтобы её инженеры работали так же быстро, как внешнее сообщество.
И последнее сделайте это приоритетом. Компании, которые подумывают о работе с открытыми сообществами и при этом пытаются сохранить интеллектуальные права, могут быть крайне чувствительны к рискам. Когда IBM только начинала знакомство с новым сообществом, уровень воспринимаемых компанией рисков был высок. «Поначалу вопрос решался на самом верху», — говорит Коули. Компания назначила ответственным за проект одного из вице-президентов, создала комитет по работе с Linux и проводила ежемесячные совещания руководителей, на которых оценивался прогресс работ. «Со временем, — продолжает Коули, — мы почувствовали себя комфортнее и стали обращать на текущую работу меньше внимания. Теперь же открытые коды стали частью нашей культуры, частью нашей стратегии».