Волшебный котел

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.