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

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

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

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

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

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

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

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

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

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

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