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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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