Эрик Реймонд "Заселяя ноосферу"

     

Ценность смирения

     

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

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

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

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

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

     Мягкость в поведении также применяется в том случае, если кто-то стремится осуществлять поддержку преуспевающего проекта: он должен убедить сообщество, что хорошо в нем разбирается, потому что работа по поддержке в большинстве своем состоит в оценке кода, написанного другими людьми. Кто станет работать для человека, который не в состоянии оценить качество кода, или того, который попытается прибрать к рукам доход в виде репутации от проекта? Потенциальные помощники хотят видеть лидеров проекта, имеющих достаточное количество смирения и способных сказать, когда это объективно необходимо: "Да, это действительно работает лучше чем моя версия, буду использовать ее" - и отдать ресурсы туда, где нужна хорошая репутация.

     Еще одна причина для скромного поведения состоит в том, что в мире открытых исходников вы редко хотите создать впечатление того, что проект "готов". Это могло бы привести к тому, что потенциальный помощник, не будет чувствовать необходимости в своей помощи. Способ усилить рычаги вашего регулирования состоит в том, чтобы быть скромным, говоря о степени готовности программы. Если попробовать похвастаться кодом, и затем сказать "Ладно, это ерунда, что она не делает x, y, и z, она не может быть настолько хороша", патчи для x, y, и z зачастую бывают быстро сделаны.

     Наконец, я лично заметил, что самоуничижительное поведение некоторых ведущих хакеров скрывает под собой реальное (и небезосновательное) опасение относительно становления объектом культа личности. Линус Торвальдс и Ларри Уолл предоставляют явные и многочисленные примеры такого превентивного поведения. Однажды, идя на обед с Ларри Уоллом, я пошутил, "Вы здесь первый хакер - вам и выбирать ресторан." Он явственно вздрогнул. И это справедливо: неудача в отличении общих ценностей от их лидеров разрушила очень много общин, - примеры, о которых он и Линус не могут не знать. С другой стороны, большинство хакеров не отказалось бы заиметь проблему Ларри, если бы могли, но попробуйте заставить их признаться в этом.

     

Общие следствия соревнования репутаций

     

Анализ соревнования репутаций обнаруживает еще некоторые неочевидные последствия. Многие из них вытекают из того факта, что участие в создании успешного проекта более почетно, чем сотрудничество в работе над уже существующим. Также более почетны проекты, единственные в своем роде, в противоположность совершенствованию уже существующих программ, сделанному "за компанию". С другой стороны, программное обеспечение, необходимость которого никто, кроме его автора, не понимает, либо того, в котором никто не нуждается, не может участвовать в соревновании репутаций, поэтому часто легче привлечь к себе внимание, внося вклад в существующий проект нежели заставить окружающих заметить новый. Наконец, намного тяжелее конкурировать с уже успешным проектом, нежели заполнить пустую нишу.

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

     Некоторые очень успешные проекты становятся "убийцами категории": никто не хочет селиться вблизи от них, потому что конкуренция на установленном ими уровне, по мнению хакеров, была бы слишком трудной. Люди, могущие в противном случае основать свои собственные проекты, с которыми было бы покончено, вместо этого пишут расширения для больших проектов, пользующихся успехом. Классический пример "убийцы категории" - GNU Emacs : его версии заполняют экологическую нишу полностью программируемых редакторов настолько полно, что никто даже и не делал попытку действительно различного проекта с начала 1980-ых. Вместо этого люди пишут расширения для Emacs.

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

     Эта тенденция будет иметь в ближайшем будущем интересные последствия. В начале 1998 года Linux был очень похож на убийцу категории "свободных операционных систем " - люди, которые могли бы писать конкурирующие ОС, вместо этого пишут драйверы и расширения для Linux. И большинство узкоспециальных инструментов, которые сообщество когда-либо желало иметь в виде открытых текстов, уже существует. Что осталось?

     Приложения. Думаю, что не ошибусь, если предскажу в качестве подхода 2000 года - все большее и большее смещение усилий по написанию открытого кода на последнюю девственную территорию - программы для не-технарей. Яркий ранний показатель того - разработка GIMP, Photoshop-подобного набора инструментов для обработки изображений, который является первым большим приложением, распространяемым в исходных текстах с легким в использовании графическим пользовательским интерфейсом, кажется, ставшего модным для использовании на коммерческой основе в течение прошедшего десятилетия. Другой показатель - количество той суеты, которая окружает проекты по созданию комплекта прикладных инструментов, наподобие KDE и GNOME.

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

     

Собственность в ноосфере и борьба за территорию

     

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

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

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

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

     Этот поведенческий анализ сначала кажется очень абстрактным и трудным для соотнесения с фактическим поведением хакеров. Но он может привести к некоторым важным заключениям. Одно из них - объяснение популярности веб-сайтов, и в особенности того, почему проекты с открытыми текстами, имеющие веб-сайты кажутся более "реальными" и солидными, нежели проекты без них.

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

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

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

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

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

     

Причины конфликта

     

В конфликтах, связанных с открытыми программами, мы можем выделить четыре главных проблемы:

     

• Кто должен принимать обязательные для выполнения решения о проекте?

     

• Кто и за что получает похвалы или критику?

     

• Как предотвратить дублирование усилий и воспрепятствовать "стихийным" версиям усложнить отслеживание ошибок?

     

• Что такое, грубо говоря, "дело правое"?

     Однако, если мы вглядимся пристальнее, проблема "правого дела" имеет тенденцию исчезать. Причем - для любого подобного вопроса, независимо от того, есть объективный способ решить, что будет принято всеми сторонами или нет. Если способ есть, игра заканчивается тем, что побеждает дружба. Если нет, проблема сводится к тому, "кто решает ".

     Соответственно, три проблемы, которые теория решения конфликтов должна решить в работе над проеком - (A): кто сдает карты при решении проектных вопросов, (B): как решить, какие сотрудники вознаграждаются, и чем, и (C): как предотвратить ветвление проектной группы и продукта на несколько групп.

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

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

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

     

Структура проекта и собственность

 

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

     Самый простой нетривиальный случай - когда проект имеет много лиц, совместно осуществляющих поддержку и работающих при единственном "добром диктаторе", владельце проекта. Традиция одобряет этот способ для групповых проектов; видно, что она работает в случае проектов такого размера, как ядро Linux или Emacs, и решает проблему того, "кто решает" способом, который не намного хуже чем любой другой.

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

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

     Рассматривая логическую схему этого процесса, мы видим, что "добрый диктатор" фактически не имеет неограниченной власти над проектом. Хотя он имеет право принимать обязательные решения, в действительности он торгует долями от репутации в обмен на работу других. Аналогия с издольщиной [ 7 ] на ферме почти непреодолима, за исключением того, что имя помощника остается в списке благодарностей и продолжает "работать" до некоторого предела даже после того, как этот помощник прекратил свою деятельность.

     Поскольку к проектам великодушного диктатора присоединяется больше участников, они имеют тенденцию разделяться работников двух видов: обычных и членов команды разработчиков. Типичный путь к становлению членом команды разработчиков - возложение на себя ответственности за значимую подсистему проекта. Другой - принятие на себя роли "его высочества спеца", после описания и исправления множества ошибок. Этим или другими способами разработчики компании становятся и остаются вкладчиками, которые делают существенные и продолжающиеся инвестиции времени в проект.

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

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

     Некоторые очень большие проекты полностью отказываются от модели "доброго диктатора". Один из способов сделать это - превратить разработчиков в собрание с голосованием (как с Apache ). Другой - "переход диктатуры", при котором контроль иногда передают от одного члена команды к другому в пределах круга главных разработчиков компании (так организовали свою работу разработчики Perl).

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