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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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