1. Неотличима от волшебства

У богини Керидвен из валлийского мифа был большой котел, который мог с помощью волшебства порождать еду — при произнесении заклинания, известного только богине. В современной науке Бакминстер Фуллер (Buckminster Fuller) дал нам понятие «эфемеризации» при которой технология становится одновременно более эффективный и менее дорогой, в той степени, в которой материальные ресурсы, вложенные в проекты ранее, все более заменяются «информационным» содержимым. Артур К. Кларк (Arthur C. Clarke) соединил противоположности, заметив, что «любая достаточно современная технология неотличима от волшебства».

Для многих людей успехи сообщества разработчиков программ с открытыми исходными текстами напоминают невероятное волшебство. Высококачественное программное обеспечение материализуется «добровольно» — это приятно, но кажется нежизнеспособным в нашем мире с его соревновательностью и дефицитом ресурсов. В чем выгода? Котел Керидвен — только ли фокус? А если нет, то как эфемеризация работает в этой ситуации — какое заклинание произносит богиня?

 

2. Среди компьютерщиков, дары приносящих

Опыт, накопленный в культуре открытых исходных текстов, разумеется, не согласовывается со многими из ожиданий тех, кто изучал разработку программ, не зная о нем. В «Соборе и Базаре» [1] даются рецепты того, как разработчики свободных программ, действуя совместно и независимо, могут действенно опровергнуть закон Брукса, достигая в отдельных случаях надежности и качества небывалого уровня. В статье «Заселяя ноосферу» [2] исследуются социальные процессы, происходящие при разработке программ в «базарном» стиле, а также говорится, что наиболее эффективно они могут быть истолкованы не в обычных терминах обменной экономики, а с использованием введенного антропологами понятия «культуры даров», члены которой состязаются за статус, отдавая вещи. Данную работу мы начнем с опровержения некоторых общепринятых мифов об экономике разработки программного обеспечения; затем продолжим анализ [1] и [2] в терминах экономики, теории игр, и бизнес-моделей, развивая новые концептуальные подходы, необходимые для понимания пути, следуя которым культура даров разработчиков открытых программ может выжить в обменной экономике.

Чтобы следовать этой линии анализа не отвлекаясь, мы будем должны отказаться (или по крайней мере согласиться временно его игнорировать) от объяснения с точки зрения «культуры даров». В [2] утверждалось, что поведение, характерное для культуры даров, возникает в ситуациях, когда необходимых товаров достаточно много для того, чтобы утратить интерес к соревнованию по обмену ими; но в то время как такое объяснение кажется достаточно мощным в качестве объяснения поведения с психологической точки зрения, его недостаточно для объяснения разного рода экономических ситуаций, в которых фактически работает большинство разработчиков программ с открытыми текстами. Для большинства из них обменная игра потеряла свою привлекательность, но не способность выступать в качестве стимулирующей силы. Их поведение должно содержать достаточно смысла, будучи рассмотренным с точки зрения материальной экономики, основанной на дефиците ресурсов, для того, чтобы оно продолжало оставаться в зоне наличия излишков, порождаемых культурой даров.

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

(Последнее замечание перед обзором: обсуждение и защита развития открытых исходных текстов в данной работе не должны рассматриваться ни как утверждение о том, что написание программ с закрытыми текстами по сути своей неправильно, ни как обвинительная речь против права интеллектуальной собственности на программное обеспечение, ни как альтруистический призыв «делиться». В то время как эти аргументы все еще популярны среди членов активного меньшинства членов сообщества разработчиков открытых программ, опыт, накопленный с периода написания [1] прояснил, что они не нужны. Достаточное количество прецедентов разработки программ с открытыми текстами опирается на их технические и экономические результаты — лучшее качество, более высокая надежность, более низкие затраты, и увеличенные возможности выбора).

 

3. Заблуждение относительно производства

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

Потребительская стоимость программы — ее экономическая ценность как инструмента. Цена программы, или ее продажная стоимость — ценность ее как ликвидного товара. (Говоря языком профессиональных экономистов, цена — стоимость конечного товара, а потребительская стоимость — цена полуфабриката).

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

1. Большинство рабочего времени разработчика оплачено за счет цены программы, полученной при ее продаже.

2. Цена программного обеспечения пропорциональна стоимости его разработки (то есть стоимости ресурсов, требуемых для того, чтобы заново ее разработать) и ее потребительской стоимости.

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

Начнем с того, что код, написанный на продажу — только вершина айсберга программного обеспечения. В эпоху до появления микрокомпьютеров 90 % всего кода в мире были написаны для внутренних нужд в банках и страховых компаниях, и это было общепризнано. Очевидно, даже не должно обсуждаться то, что другие отрасли промышленности намного более программоемки сейчас, и доля товарно-денежных отношений соответственно понизилась по отношению к общему количеству — но мы скоро увидим, основанное на опыте свидетельство тому, что приблизительно 95 % кода все еще пишется для внутренних нужд.

Этот код включает в себя большинство информационно-управляющих систем, финансовых программ и программ для управления базами данных, в которых нуждается каждая средняя и большая компания. Он включает в себя код низкого уровня наподобие драйверов (почти никто не зарабатывает деньги, продавая драйверы, к этому мы возвратимся позже). Он включает в себя все виды кода в ПЗУ для все более и более возрастающего количества микропроцессорных устройств — от станков и лайнеров до автомобилей, микроволновых печей и тостеров.

Большая часть такого кода для внутреннего использования объединена со средой, окружающей его, способами, которые делают использование в других условиях или копирование его очень трудным. (Это верно независимо от того, является ли «окружающая среда» набором процедур, принятых на конкретном предприятии, или топливным инжектором комбайна.) Таким образом, поскольку окружающая среда изменяется, требуется много работы для того, чтобы, непрерывно поддерживать программное обеспечение в соответствии с ней.

Это называют «сопровождением», и любой разработчик программного обеспечения или специалист по системному анализу скажет вам, что оно составляет большую часть (более 75 %) оплаченной работы, которой занимаются программисты. Соответственно, большинство времени работы программиста потрачено (и большая часть жалования ему платится за) написание или поддержание внутреннего кода, который не имеет никакой цены вообще — факт, который читатель может с легкостью проверить, исследуя списки рабочих мест для программистов в любой газете с разделом «Требуются».

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

Быстро станет ясно, что, даже при использовании наиболее широкого определения «продажи», по крайней мере, девятнадцать из двадцати предлагаемых вакансий финансируются строго за счет потребительской стоимости, то есть цены как промежуточного звена). Это — причина для того, чтобы считать, будто только 5 % производства стимулируется деньгами, полученными от продаж. Обратите внимание, однако, что следующая ниже в этой работе часть анализа относительно нечувствительна к этому числу; если бы это были 15 %, или даже 20 %, экономические последствия остались бы, в сущности, теми же самыми.

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

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

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

Поведение розничных торговцев в том случае, когда производитель свертывает свою деятельность, очень показательно. Это говорит нам о том, что они знают о чем-то, чего продавец больше делать не будет. А знают они вот что — цена, которую платит потребитель, обусловлена ожидаемой в будущем ценностью сервиса, оказанного продавцом (при этом слово «сервис» понимается в самом широком смысле, и включает в себя апдейты, апгрейд, и последующие разработки).

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

Стоит разобраться, почему мы обычно склонны в это верить. Может быть, просто дело в том, что меньшая часть разработчиков программ, которая пишет их на продажу — также единственная, которая рекламирует свои продукты. Однако, некоторые из примелькавшихся и интенсивно рекламируемых программ — поденщина наподобие игр, требует немного поддержки и обслуживания (но это — исключение, а не правило) [4].

Также стоит отметить, что «производственное заблуждение» поощряет ценовые структуры, которые в корне не соответствуют фактическому механизму образования затрат на разработку. При ситуации (являющейся правилом), когда более чем 75 % типичных затрат на программное обеспечение производятся за счет обслуживания, отладки и обновлений, общая ценовая политика, состоящая в установлении высокой цены и относительно низкой или нулевой платы за поддержку, должна приводить к ситуации, когда все участники рынка обслуживаются неудовлетворительно.

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

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

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

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

Если не фабричная модель, то какая? Чтобы эффективно рассуждать о реальной структуре стоимости жизненного цикла программного обеспечения (как в неформальном, так и в экономическом смысле слова «эффективность»), нам потребуется ценовая структура, основой которой являются контракты на обслуживание, подписка, и продолжающийся обмен средствами между продавцом и клиентом. В условиях свободного рынка, поощряющих поиск эффективных моделей деятельности, мы можем предсказывать, что это — вид ценовой структуры, которому будет, в конечном счете, следовать большая часть представителей развивающейся отрасли программного обеспечения.

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

Термин «свободный» также вводит в заблуждение, но иначе. Понижение стоимости товара имеет тенденцию к увеличению, а не уменьшению, инвестиций в инфраструктуру, которая занимается поддержкой. Когда цена автомобилей понижается, спрос на автомехаников повышается — вот почему даже те 5 % программистов, которые живут за счет продаж, вряд ли, будут страдать в мире открытых исходников. Потеряют при таком переходе не программисты, а инвесторы, которые делали ставку на стратегии, основанные на закрытом коде там, где они неприменимы.

 

4. Миф о том, что «информация хочет быть свободной»

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

Самая общая форма этого мифа с легкостью опровергается при рассмотрении ценности информации, которая представляет собой средство распоряжения спорным товаром или благом — карта сокровища, скажем, или номер счета в швейцарском банке, или коды доступа к услугам типа компьютерного пароля. Даже при том, что информация, содержащаяся в коде, может быть дублирована по нулевой стоимости, вещь, на которую предъявляется требование — не может. Следовательно, отличная от нуля стоимость самого товара может быть унаследована и информацией, необходимой для распоряжения им.

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

 

5. Община наоборот

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

Это — вопрос, который подвергается проверке на нескольких различных уровнях. На одном уровне, мы должны объяснить поведение индивидуумов, которые вносят вклад в проекты с открытым кодом; на другом мы должны понять экономические силы, которые поддерживают сотрудничество в таких проектах, подобных Linux или Apache.

С другой стороны, мы должны сначала уничтожить широко распространенную в народе модель, которая является препятствием для такого понимания. При попытке объяснить совместное поведение мы можем обратиться к «Трагедии общин» Гаррета Хардина.

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

Большинство людей интуитивно поддерживает модель совместного поведения, которая очень напоминает эту. Это — вообще-то, плохая модель для характеристики экономических проблем открытых исходников, являющихся в большей степени ориентированными на «нахлебников» (что, в соответствии с данной моделью, должно привести к нехватке ресурсов), нежели на вклад в общественную собственность (и интенсивн ое ее и спользование). Однако, это — аналогия, которую я вижу в качестве основы большинства непродуманных возражений.

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

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

На самом же деле, из накопленного опыта видно, что события имеют противоположную тенденцию. Широта и объем развития программ с открытыми текстами (судя, например, по количеству обновлений в день на Metalab или постингов в день в freshmeat.net) устойчиво увеличиваются. Ясно, что существующий способ их критики, с использованием модели «Трагедии общин», не в состоянии отразить то, что происходит на самом деле.

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

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

Может быть, более близко к истине то, что эту цену не просто трудно получить, а, в общем случае, трудно даже назначить. Мысленный эксперимент позволяет нам предполагать, что в Интернет появилась теоретически идеальная система микрооплаты — безопасная, универсально доступная, с нулевыми издержками. Теперь скажем, Вы написали, патч из категории «Исправления к ядру Linux: разное». Как Вы узнаете, какую цену запросить? Как потенциальный покупатель, не видя патч, узнает, сколько заплатить за него?

То, что мы имеем, почти походит на изображение в кривом зеркале из «проблемы вычисления» Ф. А. Хайека — требуется сверхсущество, способное оценить функциональную ценность патча, которому доверят, установление соответствующих цен, и которое будет стимулировать торговлю.

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

При анализе этого вида сотрудничества, важно обратить внимание что, в то время как существует «проблема халявщиков» (работа может быть сделана в расчете на что-либо, в отсутствие денег или иной материальной компенсации), она не уравновешивается ростом числа конечных пользователей. Сложность и избыток коммуникаций в разработке программы с открытыми текстами почти полностью зависит от числа вовлеченных разработчиков; наличие большего количества конечных пользователей, которые никогда не смотрят на исходники, не дает ничего. Это может увеличить количество глупых вопросов, появляющихся в списках рассылки проекта, что относительно легко предотвращается с помощью списков часто задаваемых вопросов и игнорирования вопрошающих, которые не читали его (и в самом деле, оба этих метода достаточно типичны).

Реальные проблемы халявщиков в области открытого программного обеспечения в большей степени порождены затратами на препирательства при внесении патчей нежели чем-нибудь еще. Потенциальный сотрудник проекта с небольшой долей в культурной игре репутаций (см. [2]), в отсутствии денежной компенсации, может подумать, что-то типа: «Не стоит посылать этот патч, потому что я должен буду просмотреть его, написать ChangeLog, и заполнить сопроводительные документы для FSF…» Поэтому число сотрудников (и, следовательно, успех) проекта в значительной степени обратно пропорционален числу препятствий, которые он заставляет пользователя пройти, чтобы внести в него вклад. Такие затраты могут быть организационными в такой же степени, как и техническими. Вместе они могут объяснить, почему ничем не сдержанная, аморфная Linux-культура привлекла в себя больше затрат совместной энергии чем более сильно организованная и централизованная BSD, и почему значение Фонда свободного программного обеспечения понизилось после того, как возросло значение Linux.

Это все хорошо, поскольку все-таки происходит. Но это — объяснение того, что Вася Пупкин делает со своим патчем после того, как его написал, сделанное пост фактум. Другая половина объяснения, которая нам нужна — экономическое объяснение того, как Вася способен написать патч, вместо того, чтобы совершенствовать программу с закрытыми исходниками, которая, возможно, возвратила бы ему стоимость продажи. Какие деловые модели создают те ниши, в которых развитие открытых программ может процветать?

 

6. Причины для скрытия исходников

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

Скажем, Вы нанимаете кого-то, чтобы написать на заказ (допустим) специализированный пакет бухгалтерского учета для вашего бизнеса. Эта проблема не будет решена лучше в том случае, если исходники закрыты, а не открыты; единственный случай, в котором Вы могли бы желать, чтобы они были закрыты — это когда Вы хотите продать пакет другим людям, или исключить его использование конкурентами.

Очевидный ответ: то, что Вы защищаете — это продажная стоимость, но для 95 % программного обеспечения, написанного для внутреннего использования она не имеет значения. Так какая выгода в том, чтобы исходные тексты были закрыты?

Подвергнем этот второй случай (защита преимущества в конкуренции) маленькой экспертизе. Предположим, Вы открыли исходники этого пакета бухгалтерского учета. Он становится популярным и развивается за счет усовершенствований, сделанных сообществом. Теперь ваш конкурент также начинает использовать его. Конкурент получает выгоду, не платя за разработку и вмешивается в ваш бизнес. Это — аргумент против открытия исходников?

Возможно — а возможно, и нет. Реальный вопрос — превышает ли выгода от распространения разработки ваши потери из-за увеличения конкуренции со стороны нахлебников. Множество людей склонны рассуждать плохо о таких действиях, при этом a) игнорируя функциональное совершенствование за счет привлечения большего количества добровольной помощи; b) не рассматривая стоимость разработки как вложение капитала, в соответствии с неверной гипотезой, по которой Вы должны были оплатить затраты на разработку так или иначе, таким образом считая их стоимостью открытия исходных текстов (которое Вы пожелали произвести).

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

 

7. Модели, финансируемые за счет потребительской стоимости

 

Ключевой факт состоит в том, что различие между потребительской стоимостью и ценой позволяет нам замечать, что только продажная стоимость подвергается угрозе в случае перехода от закрытых к открытым исходникам, а потребительская стоимость — нет.

Если потребительская стоимость, а не продажная цена — действительно главная движущая сила разработки программного обеспечения, и (как обсуждалось в [1]), развитие программ с открытым кодом действительно, более эффективно и целесообразно, чем с закрытым, то мы должны ожидать обнаружения обстоятельств, при которых одна лишь ожидаемая ценность от использования финансирует развитие программы с открытым кодом.

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

 

7.1. Модель Apache: разделение затрат

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

Как Вы собираетесь обеспечить это? Есть три основных стратегии, которым Вы можете следовать:

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

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

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

Преимущество от выбора Apache очень велики. Об их мощи мы можем судить по ежемесячному обзору Netcraft, который показал, что Apache устойчиво увеличивал долю присутствия на рынке по сравнению со всеми коммерческими веб-серверами с начала его разработки. С июня 1999, Apache и его производные имеют 61 %-ую рыночную долю — без формального владельца, без раскрутки, и вообще без какой-либо организации, осуществляющей обслуживание.

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

 

7.2. Случай с Cisco: разделение риска

Несколько лет назад двум программистам в Cisco (изготовитель сетевого оборудования) была поручена работа по написанию распределенной системы управления печатью для использования в корпоративной сети Cisco. Это было настоящим вызовом. Помимо поддержки возможности произвольному пользователю A печатать на произвольном принтере B (который мог быть в соседней комнате или на расстоянии в тысячу миль), система должна была удостовериться, что в случае окончания бумаги или чернил задание было направлено по другому адресу на принтер, расположенный недалеко от нужного. Система также должна была сообщать о таких проблемах администратору принтера.

Дуэт придумал интеллектуальный набор модификаций к стандартному программному обеспечению печати 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)). Эти пункты имеют следствием (хотя и не предназначены для этого) затруднение получение дохода от продажи напрямую.

 

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, даже учитывая то, что он был в стадии альфа-версии.

 

9.2. Покрытие «фенечками»

Эта модель — для изготовителей аппаратных средств ЭВМ (понятие «аппаратные средства ЭВМ» в этом контексте включает в себя все, что угодно — от Ethernet или других периферийных плат до полных компьютерных систем). Рыночные воздействия вынудили компании, производящие аппаратные средства ЭВМ писать и поддерживать программное обеспечение (от драйверов устройств и инструментов конфигурирования до целых операционных систем), но само программное обеспечение не является для них источником прибыли. Это накладные расходы — и часто существенные.

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

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

Эффект «испытания будущим» открытых исходных текстов особенно силен в случае «покрывания фенечками». Аппаратные средства ЭВМ имеют ограниченный цикл производства и поддержки; после того, как он закончился, клиенты предоставлены сами себе. Но если они имеют доступ к исходнику драйвера и могут исправить его как необходимо, они, более вероятно, будут более довольны и повторно станут клиентами той же самой компании.

Очень драматичным примером принятия модели «покрытия фенечками» было решение 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», говорит: «Большинство компаний, рассматривало бы это как пиратское программное обеспечение; мы считаем это маркетингом свободного рынка».

 

9.4. Дополнение аксессуарами

В этой модели Вы продаете принадлежности, связанные с открытым программным обеспечением. Как минимум, кружки и футболки; максимум — профессионально отредактированную и отпечатанную документацию.

«O'Reilly Associates», издатели многих превосходных руководств к открытому программному обеспечению, является хорошим примером дополняющей аксессуарами компании. «O'Reilly» фактически нанимает и поддерживает хакеров, известных среди разработчиков открытых программ (типа Лэрри Вола (Larry Wall) и Брайена Бехлендорфа (Brian Behlendorf)) в качестве способа формирования своей репутации на выбранном ими рынке.

 

9.5. Открой потом, продавай сейчас

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

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

Поскольку отпускная цена и объем продаж базируются на этих ожиданиях клиента, первоначальный производитель должен наслаждаться увеличенными доходами от программы по сравнению со случаем выпуска ее под исключительно «закрытой» лицензией. Кроме того, поскольку первоначальный код распространяется на условиях GPL, он может подвергнуться серьезной независимой экспертизе, устранению ошибок и добавление мелких усовершенствований, что избавляет производителя от примерно 75 % работ по поддержке.

Эта модель успешно использовалась Aladdin Enterprises, изготовителем популярной программы Ghostscript (переводчик PostScript, который может транслировать его на родные языки множества принтеров).

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

 

9.6. Открой программу, продавай марку

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

(Именно так «Sun Microsystems» должны были бы поступить с Java и Jini).

 

9.7. Открой программу, продавай наполнение

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

(Это — причина, по которой AOL должна открыть исходный код своей программы-клиента.)

 

10. Когда открыть, а когда закрыть

 

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

 

10.1. В чем выгода?

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

Вознаграждение за секретность битов хорошо понятно; традиционно модель бизнеса по продаже программного обеспечения была построена на этой основе. До недавнего времени выгода, получаемая за счет независимого аудита кода со стороны сообщества не была понята в достаточной степени. Операционная система Linux, однако, внедрила в сознание урок, который мы должны были усвоить годы назад на опыте развития основных программ, обеспечивающих работу Интернет и других отраслей разработки: что независимая экспертиза открытых исходных текстов — единственный масштабный метод для достижения высокой надежности и качества программы.

Поэтому на конкурентном рынке клиенты, ищущие высокую надежность и качество, вознаградят производителей программного обеспечения, которые идут путем открытия исходного кода, а заодно откроют способы поддержки потока дохода от обслуживания, способы создания добавленной стоимости, и также вспомогательных рынков, связанных с программным обеспечением. Этот процесс лежит в основе удивительного успеха Linux, доля которого росла от нулевой отметки в 1996 году до более чем в 17 % на рынке серверов к концу 1998 года, и кажется, собирается доминировать на этом рынке в течение двух лет (в начале 1999 года IDC прогнозировала, что рост Linux до 2003 года будет происходить быстрее чем всех других операционных систем, вместе взятых).

Почти настолько же важное преимущество открытых исходников — полезность их использования в качестве способа распространения открытых стандартов и построения рынков вокруг них. Лавинообразным ростом Интернет во многом обязан тому факту, что TCP/IP никому не принадлежит; ни у кого нет права распоряжаться основными протоколами Интернет как своей собственностью.

Стоящие за успехом TCP/IP и Linux эффекты, обусловленные совместной работой над ними, должным образом прояснены, и, в конце концов, приводят нас к мысли о следствиях доверия и симметрии: потенциальные участники разделенной инфраструктуры могут обоснованно доверять ей в большей степени, если смогут полностью проследить, как она работает, и предпочтут инфраструктуру, в которой все стороны имеют равные права, нежели ту, в которой одна сторона находится в привилегированном положении, которое использует для того, чтобы получать арендную плату или осуществлять контроль.

Однако, на самом деле, не столь уж необходимо использовать эффект от совместной работы, которые обеспечивают симметрию прав, чтобы поднять свой вес в глазах пользователей программы. Никакой потребитель программного обеспечения не будет сознательно стремиться запереть себя в контролируемую поставщиком монополию, становясь зависимым от закрытых исходных текстов, если существует любая альтернатива приемлемого качества, код которой открыт. Роль этого аргумента растет по мере того, как программное обеспечение становится более критичным для бизнеса потребителей программного обеспечения — чем более от него зависит существование бизнеса, тем менее потребитель может допустить контроль извне.

Наконец, важное преимущество для потребителей открытого программного обеспечения, связанное с доверием — то, что оно является защищенным от будущих проблем. Если исходные тексты открыты, клиент может надеяться на помощь даже в том случае, если продавец пошел ко дну. Это может быть особенно важно для «покрывания фенечками», так как циклы эксплуатации аппаратных средств ЭВМ имеют тенденцию к сокращению; однако, этот эффект является более общим и влечет за собой увеличение ценности открытого программного обеспечения.

 

10.2. Как они взаимодействуют?

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

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

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

После анализа, представленного в [1], мы можем ожидать, что открытый исходный текст дает высокую отдачу там, где (a) надежность/ стабильность/ масштабируемость — критическое требование, и (b) правильность проектирования и реализации проекта можно без труда проверить другими средствами, кроме независимой экспертизы кода. (Второй критерий встречается на практике в случае с большинством хоть сколько-нибудь сложных программ.)

Рациональное желание потребителя избегать того, чтобы оказаться запертым в рамках монополии одного поставщика, увеличит его интерес к открытым текстам (и, следовательно, конкурентоспособность поставщиков открытых программ), поскольку программное обеспечение становится более критичным для него. Таким образом, появляется еще один критерий (c): тенденция движения к открытости кода появляется тогда, когда программное обеспечение становится критическим для бизнеса местом размещения капитала (как, например, во многих корпоративных информационно-управляющих системах).

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

Фактически, способность потенциальных клиентов рассуждать о будущих последствиях стратегии продавца и их нежелание принимать монополию одного поставщика подразумевает более сильное ограничение; уже не обладая подавляющей властью над рынком, Вы можете выбрать либо стратегию, направленную на увеличение распространения открытого продукта или стратегию «доходов напрямую из закрытых исходных текстов» — но не обоих. (Аналоги этого принципа видимы и в других сферах, например на рынках электроники, где клиенты часто отказываются покупать устройства, имеющие только одного производителя). Ситуация может быть сформулирована без противопоставления: там, где эффект от совместной работы (положительные его аспекты) преобладают, открыть исходные тексты, вероятно, будет правильным.

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

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

Программы, обеспечивающие работу Интернет, Apache, и реализация отвечающего стандартам ANSI Unix API под названием Linux — главные образцы программ, удовлетворяющих всем пяти критериям. Дорожка к открытости в развитии таких рынков хорошо-иллюстрирована переходом сетей передачи данных на TCP/IP в середине 1990-ых после пятнадцати лет неудавшихся попыток построить империю на закрытых протоколах типа DECNET, XNS, IPX, и им подобных.

С другой стороны, открытые тексты, кажется, наименее пригодны для компании, которая является единственным обладателем приносящей доход программной технологии (строго выполняющей критерий (e)), которая, вместе с тем, являются (a) относительно нечувствительной к ошибкам, (b) может без труда быть проверенной другими средствами помимо независимой экспертизы кода; которая (c) некритична для бизнеса, и которая не увеличивают существенно свою ценность (d) из-за совместной работы над ней или повсеместного распространения.

Приведу пример такого чрезвычайного случая: в начале 1999 года меня спрашивала, «мы должны открыть исходный текст?» компания, которая пишет программы для вычисления способов распила древесины на лесопилках, обеспечивающих максимальный выход теса из необработанного лесоматериала. Мое заключение было «нет». Единственный критерий, который выполнялся в данном случае — (c), но при необходимости опытный оператор мог бы произвести необходимые вычисления и вручную.

Важное условие — то, что, специфичность изделия или технологии, заключенных в этих критериях, может изменяться со временем, что мы увидим в следующем ниже социологическом исследовании.

В заключение сформулируем следующие критерии дифференциации, стимулирующие движение к открытости кода:

(a)

надежность/ стабильность/ масштабируемость является критической характеристикой;

(b)

правильность проектирования и реализации не может с легкостью быть проверена другими средствами, кроме независимой экспертизы;

(c)

программное обеспечение является критичным для пользователя в управлении его бизнесом;

(d)

программное обеспечение формирует или поддерживает общую инфраструктуру компьютерных систем и коммуникаций;

(e)

ключевые методы (или функциональные их эквиваленты) — общеизвестны из текущего уровня техники.

 

10.3. Doom: социологическое исследование

История пользующейся спросом игры Doom фирмы Id software иллюстрирует способы, которыми давление со стороны рынка и эволюция продукта могут серьезно изменить соотношение сил в споре между закрытостью и открытостью исходных текстов.

Когда игра Doom была сначала выпущена в конце 1993 года, мультипликация в реальном времени и от первого лица сделали ее совершенно уникальной (в противоположность критерию (e)). Это произошло не только из-за ошеломляющей техники визуального воздействия, но и потому, что в течение многих месяцев никто не мог выяснить, как это было достигнуто на маломощных микропроцессорах того времени. Эти секретные биты стоили некоторой очень серьезной арендной платы. Кроме того, потенциальная отдача от открытости кода была низкой. Как одиночная игра, программа была (a) терпимой к ошибкам в работе, (b) не сильно трудной для проверки правильности работы, (c) не критичной для пользователя, (d) не использовала преимущества от совместной разработки. Для Doom экономически рационально было оставаться закрытой.

Однако, рынок вокруг Doom не останавливался. Потенциальные конкуренты изобрели функциональные эквиваленты ее методов мультипликации, начали появляться другие игры-стрелялки от первого лица, наподобие Duke Nukem. Поскольку эти игры отъедали долю в рынке Doom, стоимость арендной платы за секретность битов понизилась.

С другой стороны, усилия по расширению доли на рынке ставили перед разработчиками новые задачи — лучшая надежность, больше функций игры, больше пользователей, многоплатформенность. С появлением режима мультиплеера («deathmatch») и сервисов для игроков в Doom, рынок начал демонстрировать существенные преимущества совместной разработки. Все это требовало часов программирования, которые id предпочла бы потратить на следующую игру.

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

 

10.4. Знать, когда отпустить

Doom представляет собой интересный предмет для исследования, потому что это ни операционная система, ни программное обеспечение, обеспечивающее коммуникации либо являющееся основой сети; он к настоящему времени далеко отстоит от обычных и очевидных примеров успеха, связанного с открытостью кода. Действительно, цикл жизни Doom, вместе с «точкой пересечения», может служить характерным примером, символизирующим экологическую нишу приложений среди остального программного кода — того, в котором коммуникации и распределенные вычисления создают серьезные проблемы с устойчивостью к ошибкам/ надежностью/ масштабируемостью, определяемые только при аудите со стороны членов сообщества разработчиков, и часто пересекающие границы между техническими окружениями и конкурирующими участниками рынка (со учетом всего подразумеваемого доверия и проблемами симметрии прав).

Doom развился от одиночной игры до «deathmatch». Все в большей и большей степени эффектом от совместной разработки становится вычисление. Подобные тенденции видимы даже в самых критических деловых приложениях, типа ERP ([enterprise resource planning] планировании ресурсов предприятий), в той степени, в какой сетевые виды коммерческой деятельности все более интенсивно имеют дело с поставщиками и клиентами — и, конечно, они присущи всей архитектуре World Wide Web. Из этого следует, что почти всюду, выгоды от открытых исходников устойчиво повышаются.

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

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

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

 

11. Деловая экология открытых исходных текстов

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

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

Эффект этого расслоения — в создании очень изменчивого внутреннего рынка для патчей. Разработчики конкурируют друг с другом, под наблюдением дистрибуторов и пользователей, соревнуясь в качестве своего программного обеспечения. Дистрибуторы конкурируют за пользовательские доллары, соревнуясь в уместности своей политики выбора, а также прибавочной стоимости, которую они добавляют к программному обеспечению.

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

Другой важный эффект — подъем планки и увеличение эффективности посредством специализации. Разработчики не испытывают давления, которые обычно ставят под угрозу обычные закрытые проекты и превращают их в смоляные ямы — никаких контрольных списков бессмысленных и отвлекающих возможностей программы от маркетоидов, никакие поручений от управляющих использовать неподходящие и устаревшие языки либо среды программирования, никаких требований, переизобртения колеса новым и несовместимым способом во имя дифференцирования изделия или защиты интеллектуальной собственности, и (что наиболее важно) никаких крайних сроков. Никакого стремительного выпуска в свет версии 1.0 прежде, чем она доделана — которое (как в случае с DeMarco и Lister, судя по наблюдению обсуждения их разработки в стиле «разбудите меня, когда ее доделаете» в [3]), вообще способствует не только более высокому качеству, но и фактически, самому быстрому написанию действительно рабочей программы.

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

И дистрибуторы и разработчики сохраняют объективность с помощью постоянной обратной связи и контроля со стороны пользователей, которые являются неотъемлемой частью метода открытой разработки.

 

12. Вкус победы

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

Есть несколько уровней, на которых можно задать этот вопрос. Наша альтернативная «Комедия общин» базируется на том аргументе, что ценность индивидуальных вкладов в открытые тексты трудно превратить в деньги. Но этот аргумент имеет намного меньше силы для фирм (подобно, скажем, дистрибуторам Linux), которые уже связали поток дохода с открытым кодом. Их вклад уже превращается в деньги каждый день. Действительно, устойчива ли их совместная роль сейчас?

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

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

Историческая аналогия, к которой обращаются люди при предположении, что Linux распадется на фрагменты — поведение продавцов, продававших свои собственные версии Unix в 1980-ых. Несмотря на бесконечный разговор об открытых стандартах, несмотря на многочисленные союзы и консорциумы и соглашения, собственнический Unix разваливался. Желание продавцов дифференцировать свои изделия, добавляя и изменяя функции ОС, оказалось более сильным, нежели интерес в росте размера рынка Unix в целом с помощью поддержания совместимости (и, следовательно, понижения барьера входа для независимых разработчиков программного обеспечения и общей стоимости владения для потребителей).

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

Так как все участники рынка понимают это, никто даже не думает о выполнении маневров, подобных тем, которые фрагментировали собственнический Unix. Вместо этого, дистрибуторы Linux вынуждены конкурировать способами, которые фактически приносят пользу потребителям и всему рынку. То есть они должны конкурировать в обслуживании, поддержке, и делать ставку при проектировании на то, какие средства на самом деле способствуют облегчению установки и использования.

Общая основа исходных текстов также исключает возможность монополизации. Когда пользователи Linux волнуются об этом, название, которое они обычно бормочут — «Red Hat», компания, которая является крупнейшим и наиболее успешным из дистрибуторов (занимая около 90 % рынка в США). Но известно, что в течение нескольких дней после выхода в мае 1999 года долгожданного релиза 6.0 дистрибутива Red Hat, перед тем, как CD-ROM ов Red Hat было выпущено в достаточном количестве, «слепки» выпущенных CD-ROM, скачанные с FTP-сервера Red Hat рекламировались одним книжным издателем и несколькими другими дистрибуторами компакт-дисков, по более низким ценам чем заявляла сама Red Hat.

Red Hat не могла при этом ничего сделать, поскольку ее основатели очень хорошо понимают, что они не производят и не могут владеть ни одним битом в своем изделии; социальные нормы сообщества Linux запрещают это. По аналогии с современным известным наблюдением Джона Гилмора (John Gilmore) о том, что Интернет интерпретирует цензуру как угрозу и прокладывает маршруты в ее обход, можно сказать, что сообщество хакеров, ответственное за Linux интерпретирует попытки контроля как угрозу и прокладывает маршруты вокруг них. Для Red Hat соблазн возразить против клонирования предварительно выпущенного ею новейшего продукта поставил бы под серьезную угрозу ее возможность привлечь в будущем к сотрудничеству членов сообщества разработчиков.

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

 

13. Открытые НИОКР и переизобретение патронажа

Есть еще один способ «вливания» живых денег, которое изменяет мир открытых программ. «Звезды» сообщества все более и более убеждаются, что им могут платить за то, чем они хотят заниматься, вместо того, чтобы разрабатывать открытые программы как хобби, получая доход за счет другой постоянной работы. Корпорации подобные Red Hat, O'Reilly Associates, и VA Linux Systems вкладывают некоторые суммы в частично зависимые от них исследования, нанимая и поддерживая талантливых разработчиков.

Это имеет экономический смысл только в том случае, если издержки на человека при поддержании такой лаборатории можно легко возместить из ожидаемой прибыли, которая позволит быстрее увеличить долю фирмы на рынке. O'Reilly могут позволить себе заплатить основным авторам Perl и Apache, чтобы те выполнили работу для них, потому что это, как ожидается, позволит им продать больше книг про Perl и Apache. VA Linux Systems может финансировать свою лабораторную отрасль, потому что улучшение Linux повышает ценность использования автоматизированных рабочих мест, и серверов, которые она продает. И Red Hat основала «Red Hat Advanced Development Labs» для того, чтобы увеличить стоимость предлагаемого ею дистрибутива Linux и привлечь больше клиентов.

Стратегам от более традиционных секторов промышленности программного обеспечения, взращенных в окружениях, которые расценивают патентованную или защищенную коммерческой тайной интеллектуальную собственность как фамильные драгоценности, это поведение может (несмотря на его эффект увеличивать присутствие на рынке), казаться необъяснимым. Зачем финансировать исследования, которые каждый из ваших конкурентов (по определению) может использовать бесплатно?

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

В то время как очевидный анализ ожидаемой в будущем прибыли необходим в мире трезво мыслящих капиталистов, не сводящих глаз с коэффициента окупаемости инвестиций, это — на самом деле, не самый интересный способ объяснения найма «звезды», поскольку сами фирмы дают менее конкретные объяснения этому. Они скажут Вам, если спросите, что просто делают вещи, правильные с точки зрения сообщества, из которого они вышли. Ваш покорный слуга достаточно хорошо знаком с руководителями всех трех фирм, упомянутых выше, и может засвидетельствовать, что эти заявления не могут быть расценены как вздор. Действительно, я был лично завербован в состав правления VA Linux Systems в конце 1998 года, а поэтому имел возможность объяснить им, что такое «правильные вещи», и обнаружил, что они склонны к этому прислушаться.

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

Работа для того, чтобы снискать престиж, оценивая его как актив, способствующий получению прибыли в будущем, также едва ли является новой. Интересно чрезвычайно широко распространенное мнение о том, что такое поведение этих фирм подразумевает, добровольность их действий. Они демонстративно нанимают высоко оплачиваемого талантливого работника для проекта, который не является прямым источником дохода, даже в течение самых бедных капиталом стадий перед первой продажей акций (IPO). И, по крайней мере, пока, рынок фактически вознаграждает такое поведение.

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

Эти наблюдения закрепляют урок, который мы узнали ранее из различных рассуждений. Отношения между Red Hat /VA/ O'Reilly и их клиентами/разработчиками — нетипичны для производственных фирм. Скорее, они характерны для интересных нетипичных примеров поведения, которые характерны для наукоемких сфер услуг. Посмотрев за пределы промышленности, мы можем увидеть эти образцы в (например) юридических фирмах, области врачебной практики и университетах.

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

 

14. Получение того отсюда

Рыночные механизмы для того, чтобы финансировать (и получать за счет этого прибыль!) развитие открытых программ, все еще быстро развиваются. Бизнес-модели, которые мы рассмотрели в этой работе, вероятно, не будет последними из изобретенных. Инвесторы все еще продумывают последствия переизобретения промышленности программного обеспечения с явным упором на обслуживание, а не закрытую интеллектуальную собственность, и должны будут в течение некоторого времени завершить это.

Эта концептуальная революция будет играть некоторую роль в получении неизбежной прибыли для 5 % промышленности и людей, вкладывающих капитал в продажную стоимость; исторически виды коммерческой деятельности по обслуживанию не являются столь же прибыльными, как и производственные виды деятельности (хотя, как любой врач или адвокат могут вам сказать, на самом деле отдача для практикующих специалистов часто выше). Любой предполагаемой заранее прибыли, однако, будет более чем достаточно с точки зрения общего экономического эффекта и с точки зрения затрат, поскольку потребители программ сберегают огромные средства и получают много пользы от открытых продуктов. (Существует параллель с теми повсеместно наблюдаемыми эффектами, которые возникают при перемещении традиционной голосовой телефонии в Интернет).

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

Другая очень интересная тенденция — начало систематических попыток создать рынки задач, связанные с развитием открытых программ. SourceXchange и CoSource используют слегка различные способы попыток применения модели «обратного аукциона» для финансирования развития программ с открытым кодом.

В целом, тенденции ясны. Мы упоминали перед прогнозом IDC, что доля Linux будет расти быстрее чем всех других операционных систем вместе взятых, до 2003 года. Apache — занимает 61 %-ую рыночную долю на рынке, которая устойчиво повышается. Использование Интернет быстро растет, и обзоры типа «Internet Operating System Counter» показывают, что Linux и другие открытые операционные системы уже составляют большинство на Интернет-хостах и устойчиво отбирают долю у закрытых систем. Потребность в эксплуатировании основанной на открытых программах инфраструктуры Интернета все более и более обусловливает не просто проектирование другого программного обеспечения, а деловые методы и стратегию использования/покупки программного обеспечения каждой корпорацией. Эти тенденции, во всяком случае, вероятно, ускорятся.

 

15. Заключение: жизнь после революции

Что мир программного обеспечения будет напоминать, когда переход к открытым текстам закончится?

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

Эта система измерений хорошо соответствует тому, что люди обычно представляют, когда они говорят о «приложениях» (нисколько не поддаются описанию, слабо описанные или закрытые технические стандарты); «инфраструктуре» (пригодные для продажи услуги, сильные стандарты); и «связующим (middleware) ПО» (частично пригодные, распространенные, но неполные технические стандарты). Примерами представителей этих категорий сегодня, в 1999 году, были бы: текстовый процессор (приложение), стек TCP/IP (инфраструктура), и СУБД («связующая» программа).

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

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

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

«Приложения», с другой стороны, будут иметь в большинстве своем тенденцию оставаться закрытыми. Будут существовать обстоятельства, при которых ценность использования нераскрытого алгоритма или технологии достаточно высока (затраты, связанные с ненадежностью будут достаточно низкими, а риски, связанные с монополией поставщика достаточно терпимыми), что потребители продолжат платить за закрытые программы. Это, наиболее вероятно, останется верным для самостоятельных вертикальных рынков приложений (Вертикальный рынок (Vertical market) — ситуация, при которой рынок конкретного товара ограничен (узок), но большинство потребителей на этом рынке нуждаются в данном товаре (, прим. перев.), где эффекты от совместной разработки слабы. Наш пример с деревообрабатывающей фабрикой выше — один из таких; биометрическое программное обеспечение для идентификации, исходя из свежих сведений 1999 года, кажется наиболее вероятным претендентом на роль другого.

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

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

Приложения имеют тенденцию переходить в категорию «связующего» ПО в той степени, в какой стандартизированные методы развиваются и «сервисы» становятся «предметами потребления». (Базы данных, например, стали «связующим» ПО после появления SQL, отделившего интерфейсы от «движков»). Как только «связующие» службы становятся предметами потребления, они будут в свою очередь иметь тенденцию переходить в открытую инфраструктуру — переход, который мы наблюдаем в области операционных систем прямо сейчас.

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

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

 

16. Библиография и благодарности

1. Собор и базар: , русский перевод: .

2. Заселяя ноосферу: , русский перевод: .

3. De Marco and Lister, Peopleware: Productive Projects and Teams (New York; Dorset House, 1987; ISBN 0-932633-05-6

4. Шон Харгривс (Shawn Hargreaves) написал хороший анализ применимости методов открытого программирования к теории игр; Playing the Open Source Game ().

Несколько обсуждений стимулирования с Дэвидом Д. Фридманом (David D. Friedman) помогли мне усовершеноствовать модель «общин наоборот» применительно к сотрудничеству в области открытых разработок. Я также весьма обязан Маршалу Ван Эльстину (Marshall van Alstyne), который указал на концептуальную важность конкурирующих информационных ресурсов. Рей Онтко (Ray Ontko) из Indiana Group снабжал меня полезной критикой. Очень много людей при встречах, с которыми я беседовал до июня 1999 года, также помогли мне; если Вы — один из них, Вы знаете, за что я Вам благодарен.

Еще одно свидетельство в пользу открытой модели — то, что эта работа была существенно улучшена благодаря обратной связи с помощью электронных писем, которые я получил в течение нескольких дней после ее публикации. Ллойд Вуд (Lloyd Wood) указал на важность открытого программного обеспечения, являющегося «защищенным от будущего» (future-proof), а Дуг Данте (Doug Dante) напомнил мне о деловой модели «открой потом». Вопрос от Адама Мурхауса (Adam Moorhouse) спровоцировал обсуждение исключений, при которых лучше оставить исходный текст закрытым. Лайонел Оливира Гресс t (Lionel Oliviera Gresse) дал мне лучшее название для одной из деловых моделей. Стивен Тернбалл (Stephen Turnbull) обозвал меня глупым из-за небрежной трактовки «эффектов халявщика».

 

17. Приложение: почему закрытие драйверов ведет к убыткам

Изготовители периферийных аппаратных средств ЭВМ (карты Ethernet, контроллеры дисков, видеокарт и т. п.) исторически отказались открывать исходные тексты. Сейчас это положение изменяется в случае с фирмами наподобие Adaptec и Cyclades, начинающими систематически раскрывать спецификации и исходный код драйверов своих плат. Однако, все еще существует сопротивление этому процессу. В этом приложении мы попытаемся опровергнуть несколько неправильных с точки зрения экономики представлений, которые подкрепляют эту тенденцию.

Если вы — производитель аппаратных средств ЭВМ, вы можете бояться, что открытие кода может сделать известной важную информацию о том, как работает ваше оборудование и конкуренты смогут ее скопировать, таким образом получая несправедливое преимущество. Раньше, в эпоху трех — и пятилетних циклов разработки, это было весомым аргументом. Сегодня инженеры ваших конкурентов истратили бы на копирование и понимание копии существенную часть цикла разработки изделия, при этом не используя это время для нововведений или создания особенных функций для собственного устройства. Плагиат — западня, в которую Вы должны желать заманить Ваших конкурентов.

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

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

Даже для сложных устройств наподобие видеокарт, Вы мало что можете сделать, чтобы воспрепятствовать умному программисту, вооруженному дизассемблером. Затраты на такую разработку низки, а юридические барьеры — зыбкие; Linux — международная разработка и есть всегда юрисдикция, в которой дизассемблирование будет законным.

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

Что из этого следует? Сохранение вашего драйвера в тайне сразу же после его выпуска выглядит привлекательным, но, в конечном счете, является плохой стратегией (конечно, если Вы конкурируете с другими продавцами, которые уже открыли код). Но, если Вы должны закрыть код, пропишите его в ПЗУ платы. После этого опубликуйте программный интерфейс к нему. Будьте открытым в максимально возможной степени, для того, чтобы построить свой сектор рынка и продемонстрировать потенциальным клиентам, Вашу веру в способность придумывать новое, и вводить больше новшеств, чем конкуренты.

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

 

18. История изменений

Это — $ Revision: 1.14 $.

Версии, не описанные здесь, имеют незначительные правки или опечатки в номере версии.

20 мая 1999, версия 1.1 — проект.

18 июня 1999, версия 1.2 — не публикуемая версия обзора.

24 июня 1999, версия 1.5 — первая публикация.

24 июня 1999, версия 1.6 — незначительная модернизация; исправление в определении «хакера».

24 июня 1999, версия 1.7 — незначительная модернизация; разъяснение относительно критерия (e).

24 июня 1999, версия 1.9 — «защита от будущего», модель «открой потом», и новый раздел о прибыли за закрытые тексты.

24 июня 1999, версия 1.10 — лучшее название для модели «Бритвы».

25 июня 1999, версия 1.13 — исправляла 13 %-ое требование о доходах Netscape; добавлено лучшее описание «эффектов халявщика», исправлен список закрытых протоколов.

25 июня 1999, версия 1.14 — добавлено описание e-smith, inc.

9 июля 1999, версия 1.15 — новое приложение о драйверах аппаратных средств ЭВМ, и лучшем объяснении соперничающих товаров Рича Морина (Rich Morin).

 

19. От переводчика

Оригинал данного текста находится здесь: http://www.catb.org/~esr/writings/cathedral-bazaar/magic-cauldron/. Перевод текста на русский язык — здесь: http://www.bugtraq.ru/law/articles/cauldron/index.html. Русский перевод разрешается свободно копировать, распространять и размещать в Интернет, для чего Вы можете скачать архивированный его вариант, специально для этого предназначенный: http://www.bugtraq.ru/law/articles/cauldron/keep/zipped.rar.