Волшебный котел
Шрифт:
На самом же деле, из накопленного опыта видно, что события имеют противоположную тенденцию. Широта и объем развития программ с открытыми текстами (судя, например, по количеству обновлений в день на Metalab или постингов в день в freshmeat.net) устойчиво увеличиваются. Ясно, что существующий способ их критики, с использованием модели «Трагедии общин», не в состоянии отразить то, что происходит на самом деле.
Часть решения данной проблемы, конечно, состоит в том, что использование программного обеспечения не уменьшает его ценность. Действительно, широкое распространение используемых программ с открытыми текстами имеет тенденцию увеличивать его ценность, поскольку пользователи
Другая часть решения заключается в том, что предполагаемую рыночную цену за маленькие патчи к общим исходным текстам определить трудно. Предположим, я пишу исправление для раздражающей ошибки, и предполагаю, что много людей, использующих его, могли бы за это заплатить; как мне собрать деньги с них всех? Обычные системы оплаты имеют достаточно высокие накладные расходы, чтобы сделать реальной проблемой микроплатежи, с помощью которых это можно было бы осуществить.
Может быть, более близко к истине то, что эту цену не просто трудно получить, а, в общем случае, трудно даже назначить. Мысленный эксперимент позволяет нам предполагать, что в Интернет появилась теоретически идеальная система микрооплаты — безопасная, универсально доступная, с нулевыми издержками. Теперь скажем, Вы написали, патч из категории «Исправления к ядру Linux: разное». Как Вы узнаете, какую цену запросить? Как потенциальный покупатель, не видя патч, узнает, сколько заплатить за него?
То, что мы имеем, почти походит на изображение в кривом зеркале из «проблемы вычисления» Ф. А. Хайека — требуется сверхсущество, способное оценить функциональную ценность патча, которому доверят, установление соответствующих цен, и которое будет стимулировать торговлю.
К сожалению, у нас серьезная нехватка сверхсуществ, и поэтому Вася Пупкин, написавший патч, поставлен перед двумя выборами: сидеть на нем или подарить обществу «за так». В первом случае он не получает ничего. Во втором случае он может ничего не получить, а может побудить окружающих ко взаимному предоставлению услуг, которые решат некоторые из проблем Васи Пупкина в будущем. Второй выбор, формально альтруистический, фактически является эгоистичным с точки зрения теории игр.
При анализе этого вида сотрудничества, важно обратить внимание что, в то время как существует «проблема халявщиков» (работа может быть сделана в расчете на что-либо, в отсутствие денег или иной материальной компенсации), она не уравновешивается ростом числа конечных пользователей. Сложность и избыток коммуникаций в разработке программы с открытыми текстами почти полностью зависит от числа вовлеченных разработчиков; наличие большего количества конечных пользователей, которые никогда не смотрят на исходники, не дает ничего. Это может увеличить количество глупых вопросов, появляющихся в списках рассылки проекта, что относительно легко предотвращается с помощью списков часто задаваемых вопросов и игнорирования вопрошающих, которые не читали его (и в самом деле, оба этих метода достаточно типичны).
Реальные проблемы халявщиков в области открытого программного обеспечения в большей степени порождены затратами на препирательства при внесении патчей нежели чем-нибудь еще. Потенциальный сотрудник проекта с небольшой долей в культурной игре репутаций (см. [2]), в отсутствии денежной компенсации, может подумать, что-то типа: «Не стоит посылать этот патч, потому что я должен буду просмотреть его, написать ChangeLog, и заполнить сопроводительные документы для FSF…» Поэтому число сотрудников (и, следовательно, успех) проекта в значительной степени обратно пропорционален числу препятствий, которые он заставляет пользователя пройти, чтобы внести в него вклад. Такие затраты могут быть организационными в такой же степени, как и техническими. Вместе они могут объяснить, почему ничем не сдержанная, аморфная Linux-культура привлекла в себя больше затрат совместной энергии чем более сильно организованная и централизованная BSD, и почему значение Фонда свободного программного обеспечения понизилось после того, как возросло значение Linux.
Это все хорошо, поскольку все-таки происходит. Но это — объяснение того, что Вася Пупкин делает со своим патчем после того, как его написал, сделанное пост фактум. Другая половина объяснения, которая нам нужна — экономическое объяснение того, как Вася способен написать патч, вместо того, чтобы совершенствовать программу с закрытыми исходниками, которая, возможно, возвратила бы ему стоимость продажи. Какие деловые модели создают те ниши, в которых развитие открытых программ может процветать?
6. Причины для скрытия исходников
Прежде, чем систематизировать деловые модели, связанные с открытыми текстами, мы должны рассмотреть противоположную модель получения вознаграждения за программу вообще. Что мы защищаем на самом деле, когда мы скрываем исходный текст?
Скажем, Вы нанимаете кого-то, чтобы написать на заказ (допустим) специализированный пакет бухгалтерского учета для вашего бизнеса. Эта проблема не будет решена лучше в том случае, если исходники закрыты, а не открыты; единственный случай, в котором Вы могли бы желать, чтобы они были закрыты — это когда Вы хотите продать пакет другим людям, или исключить его использование конкурентами.
Очевидный ответ: то, что Вы защищаете — это продажная стоимость, но для 95 % программного обеспечения, написанного для внутреннего использования она не имеет значения. Так какая выгода в том, чтобы исходные тексты были закрыты?
Подвергнем этот второй случай (защита преимущества в конкуренции) маленькой экспертизе. Предположим, Вы открыли исходники этого пакета бухгалтерского учета. Он становится популярным и развивается за счет усовершенствований, сделанных сообществом. Теперь ваш конкурент также начинает использовать его. Конкурент получает выгоду, не платя за разработку и вмешивается в ваш бизнес. Это — аргумент против открытия исходников?
Возможно — а возможно, и нет. Реальный вопрос — превышает ли выгода от распространения разработки ваши потери из-за увеличения конкуренции со стороны нахлебников. Множество людей склонны рассуждать плохо о таких действиях, при этом a) игнорируя функциональное совершенствование за счет привлечения большего количества добровольной помощи; b) не рассматривая стоимость разработки как вложение капитала, в соответствии с неверной гипотезой, по которой Вы должны были оплатить затраты на разработку так или иначе, таким образом считая их стоимостью открытия исходных текстов (которое Вы пожелали произвести).
Есть другие причины для закрытия кода, являющиеся полностью иррациональными. Вы могли бы, например, действовать под влиянием заблуждения, что закрытие исходников сделает ваши используемые в бизнесе системы более безопасными против крекеров и злоумышленников. Если так, я рекомендую немедленную терапевтическую беседу с криптографом. Действительно профессиональные параноики лучше знают, что не стоит доверять безопасности программ с закрытыми текстами, поскольку они отучены делать это горьким опытом. Безопасность — часть надежности; не беспокоясь за безопасность, можно доверять только алгоритмам и их реализациям, которые могут подвергнуться экспертизе членов сообщества.