информационная безопасность
без паники и всерьез
 подробно о проекте
Rambler's Top100Все любят медАтака на Internet
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Microsoft обещает радикально усилить... 
 Ядро Linux избавляется от российских... 
 20 лет Ubuntu 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / закон / статьи
ЗАКОН
главная
обозрение
статьи
форум
рассылка
free soft





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


     

Конфликт и решение конфликта

     

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

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

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

     Эти правила вообще удовлетворительны при решении большинства проектных споров. Когда они для этого непригодны, обычно применяется указание лидера проекта. Споры, которые проходят сквозь оба этих фильтра, редки.

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

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

     

Механизмы роста культурного уровня и связь с наукой

     

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

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

     Много норм преподаются на примере. Можно упомянуть один очень простой случай: есть правило о том, что каждый дистрибутив программного обеспечения должен иметь файл по имени README или READ.ME, содержащий первоочередные инструкции для ознакомления. Это соглашение прочно установилось, по крайней мере, с начала 1980-ых, но до сих пор оно никогда не записывалось. Оно выводится из наблюдения за многими дистрибутивами.

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

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

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


           

    • Определенные мистерии подобны паролю. В качестве одного из примеров: существует телеконференция Usenet под названием alt.sysadmin.recovery, которая явно имеет секрет, вы не можете в нее писать, не зная его, при этом знание рассматривается в качестве свидетельства того, что вы готовы в нее писать. Постоянные подписчики имеют сильное табу на раскрытие этой тайны.
    •      

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

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

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

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

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

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

     Очевидные параллели с хакерской "культурой даров", как я ее охарактеризовал, в большом количестве имеются в науке. Как только исследователь достигает должности профессора, ему нет необходимости волноваться о проблемах выживания. Действительно, понятие профессорской степени может, вероятно, быть прослежено назад к более ранней культуре даров, в которой "естествоиспытателями" были прежде всего богатые господа, имеющие в своем распоряжении время, которое можно посвятить исследованиям. В отсутствии забот о выживании улучшение репутации становится целью, достижение которой поощряет распространение новых идей и исследований через журналы и другие СМИ. Это имеет объективный функциональный смысл потому, что научные исследования, подобно культуре хакеров, полагаются преимущественно на идею о "стоянии на плечах гигантов", и отсутствии необходимости открывать многократно основные принципы.

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

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

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

     

Заключение: от обычаев к обычному праву

     

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

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

     Мы нашли близкую и логичную аналогию обычаям хакеров в теории землевладения из англо-американской традиции общего права. Исторически [ 8 ], европейские племенные культуры, которые изобрели эту традицию, улучшали свою систему разрешения споров, двигаясь от системы невнятных, полуосознанных обычаев к созданию явно закрепленного, общепринятого закона, запоминаемого племенными мудрецами - и, в конечном итоге, записанного.

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

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

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

     

Вопросы для дальнейшего исследования

     

В культуре (и у меня лично) слабо понимается причина успеха больших проектов, которые не следуют модели "доброго диктатора". Большинство таких проектов терпит неудачу. Немногие становятся успешными и ценными для сообщества ( Perl, Apache, KDE ). Никто на самом деле не понимает, где находится различие. Определенный резон есть в том, что каждый такой проект - sui generis[ 9] и выживает или гибнет в зависимости от динамики отношений в группе и от отдельных ее членов, но верно ли это, или существуют воспроизводимые стратегии, которым группа может следовать?

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





Rambler's Top100
Рейтинг@Mail.ru



назад «     » вперед

  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach