Страница:
Это все хорошо, поскольку все-таки происходит. Но это – объяснение того, что Вася Пупкин делает со своим патчем после того, как его написал, сделанное пост фактум. Другая половина объяснения, которая нам нужна – экономическое объяснение того, как Вася способен написать патч, вместо того, чтобы совершенствовать программу с закрытыми исходниками, которая, возможно, возвратила бы ему стоимость продажи. Какие деловые модели создают те ниши, в которых развитие открытых программ может процветать?
6. Причины для скрытия исходников
7. Модели, финансируемые за счет потребительской стоимости
7.1. Модель Apache: разделение затрат
7.2. Случай с Cisco: разделение риска
8. Почему получение продажной стоимости проблематично
9. Косвенные модели получения продажной стоимости
9.1. Торговля себе в убыток для занятия рыночной ниши
9.2. Покрытие «фенечками»
9.3. Отдавая рецепт, откройте ресторан
9.4. Дополнение аксессуарами
9.5. Открой потом, продавай сейчас
6. Причины для скрытия исходников
Прежде, чем систематизировать деловые модели, связанные с открытыми текстами, мы должны рассмотреть противоположную модель получения вознаграждения за программу вообще. Что мы защищаем на самом деле, когда мы скрываем исходный текст?
Скажем, Вы нанимаете кого-то, чтобы написать на заказ (допустим) специализированный пакет бухгалтерского учета для вашего бизнеса. Эта проблема не будет решена лучше в том случае, если исходники закрыты, а не открыты; единственный случай, в котором Вы могли бы желать, чтобы они были закрыты – это когда Вы хотите продать пакет другим людям, или исключить его использование конкурентами.
Очевидный ответ: то, что Вы защищаете – это продажная стоимость, но для 95 % программного обеспечения, написанного для внутреннего использования она не имеет значения. Так какая выгода в том, чтобы исходные тексты были закрыты?
Подвергнем этот второй случай (защита преимущества в конкуренции) маленькой экспертизе. Предположим, Вы открыли исходники этого пакета бухгалтерского учета. Он становится популярным и развивается за счет усовершенствований, сделанных сообществом. Теперь ваш конкурент также начинает использовать его. Конкурент получает выгоду, не платя за разработку и вмешивается в ваш бизнес. Это – аргумент против открытия исходников?
Возможно – а возможно, и нет. Реальный вопрос – превышает ли выгода от распространения разработки ваши потери из-за увеличения конкуренции со стороны нахлебников. Множество людей склонны рассуждать плохо о таких действиях, при этом a) игнорируя функциональное совершенствование за счет привлечения большего количества добровольной помощи; b) не рассматривая стоимость разработки как вложение капитала, в соответствии с неверной гипотезой, по которой Вы должны были оплатить затраты на разработку так или иначе, таким образом считая их стоимостью открытия исходных текстов (которое Вы пожелали произвести).
Есть другие причины для закрытия кода, являющиеся полностью иррациональными. Вы могли бы, например, действовать под влиянием заблуждения, что закрытие исходников сделает ваши используемые в бизнесе системы более безопасными против крекеров и злоумышленников. Если так, я рекомендую немедленную терапевтическую беседу с криптографом. Действительно профессиональные параноики лучше знают, что не стоит доверять безопасности программ с закрытыми текстами, поскольку они отучены делать это горьким опытом. Безопасность – часть надежности; не беспокоясь за безопасность, можно доверять только алгоритмам и их реализациям, которые могут подвергнуться экспертизе членов сообщества.
Скажем, Вы нанимаете кого-то, чтобы написать на заказ (допустим) специализированный пакет бухгалтерского учета для вашего бизнеса. Эта проблема не будет решена лучше в том случае, если исходники закрыты, а не открыты; единственный случай, в котором Вы могли бы желать, чтобы они были закрыты – это когда Вы хотите продать пакет другим людям, или исключить его использование конкурентами.
Очевидный ответ: то, что Вы защищаете – это продажная стоимость, но для 95 % программного обеспечения, написанного для внутреннего использования она не имеет значения. Так какая выгода в том, чтобы исходные тексты были закрыты?
Подвергнем этот второй случай (защита преимущества в конкуренции) маленькой экспертизе. Предположим, Вы открыли исходники этого пакета бухгалтерского учета. Он становится популярным и развивается за счет усовершенствований, сделанных сообществом. Теперь ваш конкурент также начинает использовать его. Конкурент получает выгоду, не платя за разработку и вмешивается в ваш бизнес. Это – аргумент против открытия исходников?
Возможно – а возможно, и нет. Реальный вопрос – превышает ли выгода от распространения разработки ваши потери из-за увеличения конкуренции со стороны нахлебников. Множество людей склонны рассуждать плохо о таких действиях, при этом a) игнорируя функциональное совершенствование за счет привлечения большего количества добровольной помощи; b) не рассматривая стоимость разработки как вложение капитала, в соответствии с неверной гипотезой, по которой Вы должны были оплатить затраты на разработку так или иначе, таким образом считая их стоимостью открытия исходных текстов (которое Вы пожелали произвести).
Есть другие причины для закрытия кода, являющиеся полностью иррациональными. Вы могли бы, например, действовать под влиянием заблуждения, что закрытие исходников сделает ваши используемые в бизнесе системы более безопасными против крекеров и злоумышленников. Если так, я рекомендую немедленную терапевтическую беседу с криптографом. Действительно профессиональные параноики лучше знают, что не стоит доверять безопасности программ с закрытыми текстами, поскольку они отучены делать это горьким опытом. Безопасность – часть надежности; не беспокоясь за безопасность, можно доверять только алгоритмам и их реализациям, которые могут подвергнуться экспертизе членов сообщества.
7. Модели, финансируемые за счет потребительской стоимости
Ключевой факт состоит в том, что различие между потребительской стоимостью и ценой позволяет нам замечать, что только продажная стоимость подвергается угрозе в случае перехода от закрытых к открытым исходникам, а потребительская стоимость – нет.
Если потребительская стоимость, а не продажная цена – действительно главная движущая сила разработки программного обеспечения, и (как обсуждалось в [1]), развитие программ с открытым кодом действительно, более эффективно и целесообразно, чем с закрытым, то мы должны ожидать обнаружения обстоятельств, при которых одна лишь ожидаемая ценность от использования финансирует развитие программы с открытым кодом.
И в самом деле, нетрудно определить, по крайней мере, две важных модели, в которых прибыль разработчика проектов с открытыми текстами полностью обеспечивается за счет потребительской стоимости.
Если потребительская стоимость, а не продажная цена – действительно главная движущая сила разработки программного обеспечения, и (как обсуждалось в [1]), развитие программ с открытым кодом действительно, более эффективно и целесообразно, чем с закрытым, то мы должны ожидать обнаружения обстоятельств, при которых одна лишь ожидаемая ценность от использования финансирует развитие программы с открытым кодом.
И в самом деле, нетрудно определить, по крайней мере, две важных модели, в которых прибыль разработчика проектов с открытыми текстами полностью обеспечивается за счет потребительской стоимости.
7.1. Модель Apache: разделение затрат
Предположим, Вы работаете для фирмы, которая имеет обусловленные спецификой бизнеса строгие требования к производительности и надежности сетевого сервера. Это возможно в электронной торговле, а возможно Вы работаете с сервером СМИ, имеющим высокую посещаемость и продающим рекламу, возможно, с порталом. Вам нужна круглосуточная работа семь дней в неделю, Вам нужна скорость, и Вам нужно соответствовать требованиям заказчика.
Как Вы собираетесь обеспечить это? Есть три основных стратегии, которым Вы можете следовать:
Купить разработанный кем-то веб-сервер. В этом случае Вы делаете ставку на то, что программа разработчика соответствует вашим задачам и продавец достаточно компетентен, чтобы написать программу должным образом. Даже допуская, что оба этих условия соблюдаются, изделие, вероятно, будет слабо настраиваемым в соответствии с требованиями заказчика; Вы будете способны модифицировать только его с помощью настроек, которые продавец захотел обеспечить. Дорожка, ведущая к чужому веб-серверу – не популярна.
Можно написать свой собственный. Создание собственного веб-сервера не стоит немедленно исключать; такие серверы не очень сложны, они сложны даже менее, чем браузеры, и специализированный сервер может быть очень простым и средним по возможностям. Идя по этой дорожке, Вы можете обеспечить точное соответствие особенностям и требованиям заказчика, каким пожелаете, хотя и заплатите за это временем, потраченным на разработку. Ваша фирма может также обнаружить, что у них проблемы, когда Вы уволитесь или возьмете отпуск.
Присоединиться к группе Apache. Сервер Apache был создан общающейся по Интернету группой веб-мастеров, которые поняли, что будет более разумно объединить свои усилия по улучшению одной программы, нежели управлять развитием большого количества параллельных разработок. Делая это, они были способны получить большинство преимуществ от создания своего собственного сервера, и мощный эффект от отладки при широкомасштабном параллельном мониторинге со стороны пользователей.
Преимущество от выбора Apache очень велики. Об их мощи мы можем судить по ежемесячному обзору Netcraft, который показал, что Apache устойчиво увеличивал долю присутствия на рынке по сравнению со всеми коммерческими веб-серверами с начала его разработки. С июня 1999, Apache и его производные имеют 61 %-ую рыночную долю – без формального владельца, без раскрутки, и вообще без какой-либо организации, осуществляющей обслуживание.
Историей Apache можно проиллюстрировать модель разработки, в которой пользователи программного обеспечения обнаруживают, что для них выгоднее финансировать развитие программы с открытым кодом, потому что это дает им лучший продукт, чем они могли получить в другом случае, и за меньшую цену.
Как Вы собираетесь обеспечить это? Есть три основных стратегии, которым Вы можете следовать:
Купить разработанный кем-то веб-сервер. В этом случае Вы делаете ставку на то, что программа разработчика соответствует вашим задачам и продавец достаточно компетентен, чтобы написать программу должным образом. Даже допуская, что оба этих условия соблюдаются, изделие, вероятно, будет слабо настраиваемым в соответствии с требованиями заказчика; Вы будете способны модифицировать только его с помощью настроек, которые продавец захотел обеспечить. Дорожка, ведущая к чужому веб-серверу – не популярна.
Можно написать свой собственный. Создание собственного веб-сервера не стоит немедленно исключать; такие серверы не очень сложны, они сложны даже менее, чем браузеры, и специализированный сервер может быть очень простым и средним по возможностям. Идя по этой дорожке, Вы можете обеспечить точное соответствие особенностям и требованиям заказчика, каким пожелаете, хотя и заплатите за это временем, потраченным на разработку. Ваша фирма может также обнаружить, что у них проблемы, когда Вы уволитесь или возьмете отпуск.
Присоединиться к группе Apache. Сервер Apache был создан общающейся по Интернету группой веб-мастеров, которые поняли, что будет более разумно объединить свои усилия по улучшению одной программы, нежели управлять развитием большого количества параллельных разработок. Делая это, они были способны получить большинство преимуществ от создания своего собственного сервера, и мощный эффект от отладки при широкомасштабном параллельном мониторинге со стороны пользователей.
Преимущество от выбора Apache очень велики. Об их мощи мы можем судить по ежемесячному обзору Netcraft, который показал, что Apache устойчиво увеличивал долю присутствия на рынке по сравнению со всеми коммерческими веб-серверами с начала его разработки. С июня 1999, Apache и его производные имеют 61 %-ую рыночную долю – без формального владельца, без раскрутки, и вообще без какой-либо организации, осуществляющей обслуживание.
Историей Apache можно проиллюстрировать модель разработки, в которой пользователи программного обеспечения обнаруживают, что для них выгоднее финансировать развитие программы с открытым кодом, потому что это дает им лучший продукт, чем они могли получить в другом случае, и за меньшую цену.
7.2. Случай с Cisco: разделение риска
Несколько лет назад двум программистам в Cisco (изготовитель сетевого оборудования) была поручена работа по написанию распределенной системы управления печатью для использования в корпоративной сети Cisco. Это было настоящим вызовом. Помимо поддержки возможности произвольному пользователю A печатать на произвольном принтере B (который мог быть в соседней комнате или на расстоянии в тысячу миль), система должна была удостовериться, что в случае окончания бумаги или чернил задание было направлено по другому адресу на принтер, расположенный недалеко от нужного. Система также должна была сообщать о таких проблемах администратору принтера.
Дуэт придумал интеллектуальный набор модификаций к стандартному программному обеспечению печати Unix, плюс несколько скриптов для оболочки, которые выполняли работу. И в этот момент они поняли, что и у них, и у Cisco проблема.
Проблемой было то, что ни один из них, вероятно, не остался бы в Cisco навсегда. В конечном счете, оба программиста ушли бы, программное обеспечение осталось бы без поддержки и начало «загнивать» (то есть постепенно переставать удовлетворять условиям совместимости, необходимым для работы). Никакой разработчик не желает видеть, как это происходит с его творением, и бесстрашный дуэт чувствовал, что Cisco заплатила за решение проблемы, не так уж неблагоразумно ожидая, что программа переживет их собственные рабочие места.
Исходя из этого, они пошли к своему менеджеру и убедили его разрешить выпуск программы управления печатью с открытыми текстами. Их аргументы заключались в том, что у Cisco нет возможности получить никакой прибыли от продажи программы, которые можно потерять, но при этом она может извлечь пользу. Поощряя рост сообщества пользователей и со-разработчиков, распространенных во многих корпорациях, Cisco могла эффективно застраховаться в случае ухода первоначальных разработчиков программы.
История Cisco иллюстрирует модель, в которой функция открытых исходных текстов не столько в том, чтобы понизить затраты, сколько в том, чтобы распределить риск. Все стороны находят, что открытость исходников, и присутствие совместного сообщества, финансируемого из множества независимых источников, обеспечивает предохранительные меры, которые представляют самостоятельную экономическую ценность – являются достаточно ценными для того, чтобы вести финансирование.
Дуэт придумал интеллектуальный набор модификаций к стандартному программному обеспечению печати Unix, плюс несколько скриптов для оболочки, которые выполняли работу. И в этот момент они поняли, что и у них, и у Cisco проблема.
Проблемой было то, что ни один из них, вероятно, не остался бы в Cisco навсегда. В конечном счете, оба программиста ушли бы, программное обеспечение осталось бы без поддержки и начало «загнивать» (то есть постепенно переставать удовлетворять условиям совместимости, необходимым для работы). Никакой разработчик не желает видеть, как это происходит с его творением, и бесстрашный дуэт чувствовал, что Cisco заплатила за решение проблемы, не так уж неблагоразумно ожидая, что программа переживет их собственные рабочие места.
Исходя из этого, они пошли к своему менеджеру и убедили его разрешить выпуск программы управления печатью с открытыми текстами. Их аргументы заключались в том, что у Cisco нет возможности получить никакой прибыли от продажи программы, которые можно потерять, но при этом она может извлечь пользу. Поощряя рост сообщества пользователей и со-разработчиков, распространенных во многих корпорациях, Cisco могла эффективно застраховаться в случае ухода первоначальных разработчиков программы.
История Cisco иллюстрирует модель, в которой функция открытых исходных текстов не столько в том, чтобы понизить затраты, сколько в том, чтобы распределить риск. Все стороны находят, что открытость исходников, и присутствие совместного сообщества, финансируемого из множества независимых источников, обеспечивает предохранительные меры, которые представляют самостоятельную экономическую ценность – являются достаточно ценными для того, чтобы вести финансирование.
8. Почему получение продажной стоимости проблематично
Открытые исходные тексты делают довольно трудным получение продажной цены напрямую за программное обеспечение. Трудность не является технической; исходный код – не более и ни менее подвержен копированию чем исполняемые файлы, поэтому распространение авторского права, и законодательства о лицензировании, разрешающих получать деньги за продажу программы, при необходимости не было бы более трудным для программ с открытыми текстами, нежели для программ с закрытым кодом.
Трудность находится скорее с характером общественного договора, который поддерживает развитие открытых текстов. По трем взаимно усиливающим друг друга причинам, главные лицензии на открытые программы запрещают большинство ограничений на использование, распространение и модификацию, которая облегчила бы получение дохода от продажи напрямую. Для понимания этих причин мы должны исследовать социальное окружение, в котором эти лицензии развились: хакерскую культуру Интернета.
Несмотря на мифы о культуре хакеров, в которые все еще (в 1999 году) широко верят посторонние, ни одна из этих причин не имеет отношения к враждебности к рынку. В то время как меньшинство хакеров действительно остается враждебным к получению прибыли, общая готовность сообщества сотрудничать с коммерческими производителями дистрибутивов Linux, подобными Red Hat, SUSE, и Caldera, демонстрирует, что большинство хакеров будет счастливо работать с корпоративным миром, когда это способствует достижению их целей. Реальные причины настороженного отношения хакеров к лицензиям, позволяющим напрямую получать доход, менее очевидны и более интересны.
Одна причина имеет отношение к соразмерности прав. В то время как большинство разработчиков программ с открытым кодом, в сущности, не возражает против других, получающих прибыль от их даров, большинство при этом требует, чтобы никто (с возможным исключением создателя части кода) не находился в привилегированном положении, для извлечения прибыли. Вася Пупкин позволяет Fubarco получать прибыль, продавая написанное им программное обеспечение или патчи, но только пока сам он также может сделать так.
Другая причина связана с неявными последствиями. Хакеры заметили, что лицензии, которые включают в себя ограничения и разрешают плату за «коммерческое» использование или продажу (самая общая и на первый взгляд, благоразумная форма попытки получить продажную стоимость напрямую), имеют очень опасные последствия. Один из специфических – бросание тени на действия наподобие распространения программы на недорогих антологиях CD-ROM, которые, в идеале, нужно было бы поощрять. В более широком аспекте ограничения на использование/ продажу/ модификацию/ распределение (и другие осложнения в использовании) ограничивают расходы на прослеживание соответствия и (в той степени, в какой повышается число программных пакетов, с которыми люди имеют дело) комбинаторный взрыв неуверенности в и потенциального юридического риска. Этот результат считается вредным, поэтому существует сильное общественное давление, направленное на то, чтобы держать лицензии простыми и свободными от ограничений.
Заключительная и самая критичная причина относится к сохранению возможности экспертизы со стороны членов сообщества и культуре даров, развитие которой описано в [2]. Ограничения лицензий, разработанные для того, чтобы защитить интеллектуальную собственность или получение напрямую цены продажи часто делают невозможным с юридической точки зрения ветвление проекта (так обстоит дело, например, с «лицензиями» «Community Source» Sun для Jini и Java). В то время как к ветвлению относятся отрицательно и оно рассматривается как крайняя мера (по причинам, обсужденным подробно в [2]), считается, тем не менее, важным, чтобы присутствовала возможность пойти на эту крайнюю меру в случае некомпетентности сопровождающего или его отступничества (например, перехода к более закрытой лицензии).
Сообщество хакеров имеет некоторую уступчивость к требованиям симметрии; таким образом оно допускает лицензии, подобные NPL Netscape, дающие немного привилегий создателям кода (определенное в NPL исключительное право использовать открытые тексты Mozilla в производных изделиях, включая программы с закрытыми исходниками). Это дает меньше поводов для причинения незапланированных последствий, и предохраняет от ветвления (чт о является причиной того, почему «схемы» «Sun Community License» для Java и Jini были признаны сообществом в значительной степени неудовлетворительными).
Это объясняет пункты «Определения открытых исходников» (Open Source Definition), которое было написано для того, чтобы выразить позицию сообщества хакеров по отношению к критическим особенностям стандартных лицензий (GPL, лицензия BSD, Лицензия MIT, и «Художественная лицензия» (Artistic License)). Эти пункты имеют следствием (хотя и не предназначены для этого) затруднение получение дохода от продажи напрямую.
Трудность находится скорее с характером общественного договора, который поддерживает развитие открытых текстов. По трем взаимно усиливающим друг друга причинам, главные лицензии на открытые программы запрещают большинство ограничений на использование, распространение и модификацию, которая облегчила бы получение дохода от продажи напрямую. Для понимания этих причин мы должны исследовать социальное окружение, в котором эти лицензии развились: хакерскую культуру Интернета.
Несмотря на мифы о культуре хакеров, в которые все еще (в 1999 году) широко верят посторонние, ни одна из этих причин не имеет отношения к враждебности к рынку. В то время как меньшинство хакеров действительно остается враждебным к получению прибыли, общая готовность сообщества сотрудничать с коммерческими производителями дистрибутивов Linux, подобными Red Hat, SUSE, и Caldera, демонстрирует, что большинство хакеров будет счастливо работать с корпоративным миром, когда это способствует достижению их целей. Реальные причины настороженного отношения хакеров к лицензиям, позволяющим напрямую получать доход, менее очевидны и более интересны.
Одна причина имеет отношение к соразмерности прав. В то время как большинство разработчиков программ с открытым кодом, в сущности, не возражает против других, получающих прибыль от их даров, большинство при этом требует, чтобы никто (с возможным исключением создателя части кода) не находился в привилегированном положении, для извлечения прибыли. Вася Пупкин позволяет Fubarco получать прибыль, продавая написанное им программное обеспечение или патчи, но только пока сам он также может сделать так.
Другая причина связана с неявными последствиями. Хакеры заметили, что лицензии, которые включают в себя ограничения и разрешают плату за «коммерческое» использование или продажу (самая общая и на первый взгляд, благоразумная форма попытки получить продажную стоимость напрямую), имеют очень опасные последствия. Один из специфических – бросание тени на действия наподобие распространения программы на недорогих антологиях CD-ROM, которые, в идеале, нужно было бы поощрять. В более широком аспекте ограничения на использование/ продажу/ модификацию/ распределение (и другие осложнения в использовании) ограничивают расходы на прослеживание соответствия и (в той степени, в какой повышается число программных пакетов, с которыми люди имеют дело) комбинаторный взрыв неуверенности в и потенциального юридического риска. Этот результат считается вредным, поэтому существует сильное общественное давление, направленное на то, чтобы держать лицензии простыми и свободными от ограничений.
Заключительная и самая критичная причина относится к сохранению возможности экспертизы со стороны членов сообщества и культуре даров, развитие которой описано в [2]. Ограничения лицензий, разработанные для того, чтобы защитить интеллектуальную собственность или получение напрямую цены продажи часто делают невозможным с юридической точки зрения ветвление проекта (так обстоит дело, например, с «лицензиями» «Community Source» Sun для Jini и Java). В то время как к ветвлению относятся отрицательно и оно рассматривается как крайняя мера (по причинам, обсужденным подробно в [2]), считается, тем не менее, важным, чтобы присутствовала возможность пойти на эту крайнюю меру в случае некомпетентности сопровождающего или его отступничества (например, перехода к более закрытой лицензии).
Сообщество хакеров имеет некоторую уступчивость к требованиям симметрии; таким образом оно допускает лицензии, подобные NPL Netscape, дающие немного привилегий создателям кода (определенное в NPL исключительное право использовать открытые тексты Mozilla в производных изделиях, включая программы с закрытыми исходниками). Это дает меньше поводов для причинения незапланированных последствий, и предохраняет от ветвления (чт о является причиной того, почему «схемы» «Sun Community License» для Java и Jini были признаны сообществом в значительной степени неудовлетворительными).
Это объясняет пункты «Определения открытых исходников» (Open Source Definition), которое было написано для того, чтобы выразить позицию сообщества хакеров по отношению к критическим особенностям стандартных лицензий (GPL, лицензия BSD, Лицензия MIT, и «Художественная лицензия» (Artistic License)). Эти пункты имеют следствием (хотя и не предназначены для этого) затруднение получение дохода от продажи напрямую.
9. Косвенные модели получения продажной стоимости
Однако, есть способы образования рынков, связанных с услугами в области программного обеспечения, которые представляют собой нечто, подобное получению косвенным образом продажной цены. Есть пять существующих и две выдуманных таких модели (др угие, может быть, появятся в будущем).
9.1. Торговля себе в убыток для занятия рыночной ниши
В этой модели Вы используете программное обеспечение с открытыми текстами для того, чтобы создать или поддерживать рыночное положение составляющего собственность программного обеспечения, которое обеспечивает прямой поток дохода. В самом общем варианте, программа-клиент с открытым кодом позволяет продавать программу-сервер, или подписку/рекламу сервисов, связанных с каким-либо порталом.
Netscape Communications, Inc преследовала эту стратегию, когда открывала исходники браузера Mozilla в начале 1998 года. Их бизнес, связанный с браузером, приносил около 13 % доходов и понижался, когда Microsoft начала распространять Internet Explorer. Интенсивный маркетинг IE (и полулегальные методы связывания, которые позже стали центральной проблемой антимонопольного судебного процесса) быстро отъел долю рынка браузера Netscape, и заставлял беспокоиться о том, что Microsoft намеревается монополизировать рынок браузеров а затем использовать фактический контроль над языком HTML, чтобы изгнать Netscape с рынка серверных приложений.
Открывая исходники своей все еще широко популярной программы, Netscape эффективно пресек для Microsoft возможность монополизации рынка браузеров. Они ожидали, что сотрудничество вокруг открытых текстов ускорит развитие и отладку браузера, и надеялось, что влияние Microsoft IE будет уменьшено до второстепенных значений, и он не сможет контролировать расширения HTML.
Эта стратегия сработала. В ноябре 1998 года Netscape фактически начал восстанавливать долю на рынке долю по сравнению с IE. К тому времени, как Netscape был приобретен AOL в начале 1999 года, конкурентоспособное преимущество в игре, обусловленное разработкой Mozilla было настолько ясно, что одно из первых публичных обязательств AOL состояло в том, чтобы продолжить поддерживать проект Mozilla, даже учитывая то, что он был в стадии альфа-версии.
Netscape Communications, Inc преследовала эту стратегию, когда открывала исходники браузера Mozilla в начале 1998 года. Их бизнес, связанный с браузером, приносил около 13 % доходов и понижался, когда Microsoft начала распространять Internet Explorer. Интенсивный маркетинг IE (и полулегальные методы связывания, которые позже стали центральной проблемой антимонопольного судебного процесса) быстро отъел долю рынка браузера Netscape, и заставлял беспокоиться о том, что Microsoft намеревается монополизировать рынок браузеров а затем использовать фактический контроль над языком HTML, чтобы изгнать Netscape с рынка серверных приложений.
Открывая исходники своей все еще широко популярной программы, Netscape эффективно пресек для Microsoft возможность монополизации рынка браузеров. Они ожидали, что сотрудничество вокруг открытых текстов ускорит развитие и отладку браузера, и надеялось, что влияние Microsoft IE будет уменьшено до второстепенных значений, и он не сможет контролировать расширения HTML.
Эта стратегия сработала. В ноябре 1998 года Netscape фактически начал восстанавливать долю на рынке долю по сравнению с IE. К тому времени, как Netscape был приобретен AOL в начале 1999 года, конкурентоспособное преимущество в игре, обусловленное разработкой Mozilla было настолько ясно, что одно из первых публичных обязательств AOL состояло в том, чтобы продолжить поддерживать проект Mozilla, даже учитывая то, что он был в стадии альфа-версии.
9.2. Покрытие «фенечками»
Эта модель – для изготовителей аппаратных средств ЭВМ (понятие «аппаратные средства ЭВМ» в этом контексте включает в себя все, что угодно – от Ethernet или других периферийных плат до полных компьютерных систем). Рыночные воздействия вынудили компании, производящие аппаратные средства ЭВМ писать и поддерживать программное обеспечение (от драйверов устройств и инструментов конфигурирования до целых операционных систем), но само программное обеспечение не является для них источником прибыли. Это накладные расходы – и часто существенные.
В этой ситуации, необходимость открытия исходных текстов очевидна. Нет никакого источника дохода, который можно потерять, так что в этом нет никакого риска. Прибылью продавца в данном случае является очень большое объединение разработчиков, более быстрый и гибкий ответ на потребности клиента, и лучшая надежность, которая обеспечивается благодаря мониторингу кода со стороны членов сообщества. Он также получает порты на другие платформы. Он, вероятно, также получает большую лояльность клиентов, так как технический персонал клиентов получает доступ к коду, и может сделать настройки, которые требуются покупателям.
Есть несколько возражений, обычно заявляемых разработчиками именно против того, чтобы открыть исходники драйверов аппаратных средств ЭВМ. Вместо того, чтобы смешивать их с обсуждением более общих проблем здесь, я написал приложение, посвященное этой теме.
Эффект «испытания будущим» открытых исходных текстов особенно силен в случае «покрывания фенечками». Аппаратные средства ЭВМ имеют ограниченный цикл производства и поддержки; после того, как он закончился, клиенты предоставлены сами себе. Но если они имеют доступ к исходнику драйвера и могут исправить его как необходимо, они, более вероятно, будут более довольны и повторно станут клиентами той же самой компании.
Очень драматичным примером принятия модели «покрытия фенечками» было решение Apple Computers в середине марта 1999 года открыть исходники «Darwin», ядра их серверной операционной системы MacOSX.
В этой ситуации, необходимость открытия исходных текстов очевидна. Нет никакого источника дохода, который можно потерять, так что в этом нет никакого риска. Прибылью продавца в данном случае является очень большое объединение разработчиков, более быстрый и гибкий ответ на потребности клиента, и лучшая надежность, которая обеспечивается благодаря мониторингу кода со стороны членов сообщества. Он также получает порты на другие платформы. Он, вероятно, также получает большую лояльность клиентов, так как технический персонал клиентов получает доступ к коду, и может сделать настройки, которые требуются покупателям.
Есть несколько возражений, обычно заявляемых разработчиками именно против того, чтобы открыть исходники драйверов аппаратных средств ЭВМ. Вместо того, чтобы смешивать их с обсуждением более общих проблем здесь, я написал приложение, посвященное этой теме.
Эффект «испытания будущим» открытых исходных текстов особенно силен в случае «покрывания фенечками». Аппаратные средства ЭВМ имеют ограниченный цикл производства и поддержки; после того, как он закончился, клиенты предоставлены сами себе. Но если они имеют доступ к исходнику драйвера и могут исправить его как необходимо, они, более вероятно, будут более довольны и повторно станут клиентами той же самой компании.
Очень драматичным примером принятия модели «покрытия фенечками» было решение Apple Computers в середине марта 1999 года открыть исходники «Darwin», ядра их серверной операционной системы MacOSX.
9.3. Отдавая рецепт, откройте ресторан
В этой модели, программа с открытыми текстами используется для того, чтобы создать рыночную нишу, но не для закрытого программного обеспечения (как в случае «торговли себе в убыток»), а для услуг.
(Я называл эту стратегию «Отдавая бритву, продавайте лезвия», используемая в статье метафора звучит не столь напряженно, как подразумевается при такой аналогии).
Это – то, что делают Red Hat и другие производители дистрибутивов Linux. То, что они на самом деле продают – не программы как самостоятельные биты, а ценность, которая добавляется при сборке и проверке управления операционной системой, которая гарантировано (целиком и полностью), будет пользоваться спросом и будет совместимой с другими операционными системами, несущими ту же самую марку. Другие способы зарабатывания ими денег включают свободную инсталляционную поддержку и различные варианты контрактов на продолжение поддержки.
Рынкообразующий эффект открытых исходных текстов может быть чрезвычайно мощным, особенно для тех компаний, которые неизбежно находятся в положении обслуживающих с момента создания. Один очень поучительный недавний случай – Digital Creations, компания веб-дизайна, созданная в 1998 году, которая специализируется на сайтах с поддержкой сложных баз данных и транзакций. Их главным инструментом, бриллиантом в короне компании, является серверная программа, которая сменила несколько названий и воплощений, и теперь называется Zope.
Когда сотрудники Digital Creations искали того, кто вложит капитал в их предприятие, то инвестор, которого они нашли, тщательно оценивал их предполагаемую рыночную нишу, персонал, и инструменты. Он порекомендовал, чтобы Digital Creations открыли исходные тексты Zope.
По традиционным стандартам промышленности программного обеспечения это было абсолютно сумасшедшим ходом. Традиционная мудрость бизнес-школы состоит в том, что основная интеллектуальная собственность, подобно Zope являющаяся фамильными драгоценностями компании, никогда и ни при каких обстоятельствах не может быть никому отдана. Но вкладчик привел два связанных между собой факта. Первый – на самом деле, фактически основной актив Zope – интеллектуальные способности и навыки его персонала. Второй – то, что Zope, вероятно, более ценен в качестве построителя рынка, нежели засекреченного инструмента.
Чтобы понять это, сравните два сценария. В обычном Zope остается секретным оружием Digital Creations. Давайте предположим, что он очень эффективен. В результате фирма будет способный выполнять работы с превосходным качеством и вовремя – но никто не знает этого. Будет легко удовлетворить клиентов, но тяжелее собрать постоянный контингент заказчиков с самого начала.
Инвестор вместо этого мог считать, что открытый текст Zope сыграет роль объявления о реальных активах Digital Creations – его людях. Он ожидал, что клиенты, оценившие Zope, сочтут более эффективным наем экспертов чем проведение внутренней экспертизы Zope.
Один из ведущих разработчиков Zope с тех пор подтвердил публично, что их стратегия, основанная на открытых исходных текстах, «открыла много дверей, в которые иначе мы бы не вошли». Потенциальные клиенты действительно реагируют на логику ситуации – и Digital Creations, соответственно, процветает.
Другим свежим примером является компания e-smith, inc. Эта компания продает контракты на поддержку программного обеспечения интернет-серверов «под ключ», которое представляет собой настроенный Linux. Один из руководителей, описывая распространение свободных копий программного обеспечения от «e-smith», говорит: «Большинство компаний, рассматривало бы это как пиратское программное обеспечение; мы считаем это маркетингом свободного рынка».
(Я называл эту стратегию «Отдавая бритву, продавайте лезвия», используемая в статье метафора звучит не столь напряженно, как подразумевается при такой аналогии).
Это – то, что делают Red Hat и другие производители дистрибутивов Linux. То, что они на самом деле продают – не программы как самостоятельные биты, а ценность, которая добавляется при сборке и проверке управления операционной системой, которая гарантировано (целиком и полностью), будет пользоваться спросом и будет совместимой с другими операционными системами, несущими ту же самую марку. Другие способы зарабатывания ими денег включают свободную инсталляционную поддержку и различные варианты контрактов на продолжение поддержки.
Рынкообразующий эффект открытых исходных текстов может быть чрезвычайно мощным, особенно для тех компаний, которые неизбежно находятся в положении обслуживающих с момента создания. Один очень поучительный недавний случай – Digital Creations, компания веб-дизайна, созданная в 1998 году, которая специализируется на сайтах с поддержкой сложных баз данных и транзакций. Их главным инструментом, бриллиантом в короне компании, является серверная программа, которая сменила несколько названий и воплощений, и теперь называется Zope.
Когда сотрудники Digital Creations искали того, кто вложит капитал в их предприятие, то инвестор, которого они нашли, тщательно оценивал их предполагаемую рыночную нишу, персонал, и инструменты. Он порекомендовал, чтобы Digital Creations открыли исходные тексты Zope.
По традиционным стандартам промышленности программного обеспечения это было абсолютно сумасшедшим ходом. Традиционная мудрость бизнес-школы состоит в том, что основная интеллектуальная собственность, подобно Zope являющаяся фамильными драгоценностями компании, никогда и ни при каких обстоятельствах не может быть никому отдана. Но вкладчик привел два связанных между собой факта. Первый – на самом деле, фактически основной актив Zope – интеллектуальные способности и навыки его персонала. Второй – то, что Zope, вероятно, более ценен в качестве построителя рынка, нежели засекреченного инструмента.
Чтобы понять это, сравните два сценария. В обычном Zope остается секретным оружием Digital Creations. Давайте предположим, что он очень эффективен. В результате фирма будет способный выполнять работы с превосходным качеством и вовремя – но никто не знает этого. Будет легко удовлетворить клиентов, но тяжелее собрать постоянный контингент заказчиков с самого начала.
Инвестор вместо этого мог считать, что открытый текст Zope сыграет роль объявления о реальных активах Digital Creations – его людях. Он ожидал, что клиенты, оценившие Zope, сочтут более эффективным наем экспертов чем проведение внутренней экспертизы Zope.
Один из ведущих разработчиков Zope с тех пор подтвердил публично, что их стратегия, основанная на открытых исходных текстах, «открыла много дверей, в которые иначе мы бы не вошли». Потенциальные клиенты действительно реагируют на логику ситуации – и Digital Creations, соответственно, процветает.
Другим свежим примером является компания e-smith, inc. Эта компания продает контракты на поддержку программного обеспечения интернет-серверов «под ключ», которое представляет собой настроенный Linux. Один из руководителей, описывая распространение свободных копий программного обеспечения от «e-smith», говорит: «Большинство компаний, рассматривало бы это как пиратское программное обеспечение; мы считаем это маркетингом свободного рынка».
9.4. Дополнение аксессуарами
В этой модели Вы продаете принадлежности, связанные с открытым программным обеспечением. Как минимум, кружки и футболки; максимум – профессионально отредактированную и отпечатанную документацию.
«O'Reilly Associates», издатели многих превосходных руководств к открытому программному обеспечению, является хорошим примером дополняющей аксессуарами компании. «O'Reilly» фактически нанимает и поддерживает хакеров, известных среди разработчиков открытых программ (типа Лэрри Вола (Larry Wall) и Брайена Бехлендорфа (Brian Behlendorf)) в качестве способа формирования своей репутации на выбранном ими рынке.
«O'Reilly Associates», издатели многих превосходных руководств к открытому программному обеспечению, является хорошим примером дополняющей аксессуарами компании. «O'Reilly» фактически нанимает и поддерживает хакеров, известных среди разработчиков открытых программ (типа Лэрри Вола (Larry Wall) и Брайена Бехлендорфа (Brian Behlendorf)) в качестве способа формирования своей репутации на выбранном ими рынке.
9.5. Открой потом, продавай сейчас
В этой модели Вы распространяете программное обеспечение откомпилированным и в исходнике с закрытой лицензией, которая включает в себя срок, в течение которого исходник будет закрыт. Например, Вы могли бы написать лицензию, которая разрешает свободное распространение, запрещает коммерческое использование без платы, и гарантирует, что программное обеспечение переводится под GPL спустя год после выпуска или в том случае, если продавец закрывается.
При использовании этой модели клиенты могут быть уверены в том, что изделие можно настроить в соответствии с их потребностями, потому что у них есть его исходный текст. Изделие «защищено от будущего» – лицензия гарантирует, что сообщество разработчиков открытых программ сможет использовать его и в том случае, если компания-производитель перестанет существовать.
Поскольку отпускная цена и объем продаж базируются на этих ожиданиях клиента, первоначальный производитель должен наслаждаться увеличенными доходами от программы по сравнению со случаем выпуска ее под исключительно «закрытой» лицензией. Кроме того, поскольку первоначальный код распространяется на условиях GPL, он может подвергнуться серьезной независимой экспертизе, устранению ошибок и добавление мелких усовершенствований, что избавляет производителя от примерно 75 % работ по поддержке.
Эта модель успешно использовалась Aladdin Enterprises, изготовителем популярной программы Ghostscript (переводчик PostScript, который может транслировать его на родные языки множества принтеров).
Главный недостаток этой модели состоит в том, что условия закрытия обычно запрещают независимую экспертизу кода и совместную работу над ним на ранних стадиях существования, именно тогда, когда они необходимы больше всего.
При использовании этой модели клиенты могут быть уверены в том, что изделие можно настроить в соответствии с их потребностями, потому что у них есть его исходный текст. Изделие «защищено от будущего» – лицензия гарантирует, что сообщество разработчиков открытых программ сможет использовать его и в том случае, если компания-производитель перестанет существовать.
Поскольку отпускная цена и объем продаж базируются на этих ожиданиях клиента, первоначальный производитель должен наслаждаться увеличенными доходами от программы по сравнению со случаем выпуска ее под исключительно «закрытой» лицензией. Кроме того, поскольку первоначальный код распространяется на условиях GPL, он может подвергнуться серьезной независимой экспертизе, устранению ошибок и добавление мелких усовершенствований, что избавляет производителя от примерно 75 % работ по поддержке.
Эта модель успешно использовалась Aladdin Enterprises, изготовителем популярной программы Ghostscript (переводчик PostScript, который может транслировать его на родные языки множества принтеров).
Главный недостаток этой модели состоит в том, что условия закрытия обычно запрещают независимую экспертизу кода и совместную работу над ним на ранних стадиях существования, именно тогда, когда они необходимы больше всего.