Читать онлайн «Волшебный котел». Страница 1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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