Содержание
Чаще всего люди малознакомые с открытым ПО задают вопросы: Как оно устроено? Что заставляет проект развиваться? Кто принимает решения? Мне не нравятся банальные ответы типа меритократии, духа сотрудничества, самодокументированного кода и т.п. Вопрос, на самом деле, не так прост. Меритократия, сотрудничество, поддержка кода входят в ответ, но они ничего не говорят о том, как проект живет ежедневной жизнью, как решаются конфликтные ситуации.
В этой главе я попробую показать те вещи, на которых базируются все успешные проекты. Успешные, не только с точки зрения качества исполнения, но и с точки зрения здорового рабочего состояния и живучести. Рабочее состояние—это деятельность по внедрению нового кода и новых разработчиков в проект, а также по реагированию на поступающие отчеты об ошибках. Живучесть—это способность проекта жить своей жизнью независимо от конкретного участника или спонсора. Посмотрите на это как на вероятность того, что проект продолжит свое существование, в случае если все основатели из него уйдут. Добиться успеха с технически совершенным продуктом легко, но без надежной команды разработчиков и установления основ социального взаимодействия проект может не справится с ростом, который принесет успех, или с уходом харизматичных личностей.
Существует несколько путей достижения успеха. Один подразумевает ведение формальных управляющих процедур, с помощью которых разрешаются споры, принимаются (и иногда исключаются) разработчики, планируются новые функции проекта, и так далее. Другой полагается на менее формализованную структуру сознательного самоограничения, и создает тем самым атмосферу честности, которая и становится де факто формой управления. Оба подхода приводят к тому, что у участников возникает чувство организационной стабильности, подкрепляемое понятными всем привычками и процедурами. Эти особенности гораздо более важны для самоорганизующихся систем, чем для систем с централизованным управлением, потому что для самоорганизующихся систем справедливо высказывание о том, что ложка дегтя портит бочку меда, по крайней мере на какое-то время.
Важный компонент, который заставляет разработчиков держаться вместе и находить консенсус при необходимости,—это право на отделение, право любого человека взять копию исходного кода и использовать её, чтобы начать конкурирующий проект (форк). Парадокс заключается в том, что сама возможность появления форка обладает большим влиянием на развитие проекта открытого ПО, чем конкурирующие форки, число которых обычно мало. Форк невыгоден всем (причины описаны в разделе Глава 8, Managing Volunteers: «Forks»), и чем сильнее становится угроза разделения проекта, тем больше решимости найти компромисс появляется у участников проекта.
Форте, или скорее возможность их появления, приводят к тому, что в мире открытого ПО нет диктаторов. Возможно, это заявление покажется странным, потому что люди часто говорят о "диктаторах" или "тиранах" в проектах открытого ПО. Но эта тирания особая, она отличается от того, что принято понимать под этим словом. Представьте короля, чьи вассалы могут скопировать королевство целиком, переехать в копию и править там как захотят. Не будет ли такой король править по другому, в отличие от короля, чьи слуги привязаны к нему навсегда?
Вот почему даже проекты формально не являющиеся демократиями проявляют черты демократии, когда дело доходит до принятия важных решений. Право на создание копии предполагает право на отделение, а оно предполагает консенсус. Может случиться, что все хотят подчиниться одному лидеру (самый известный пример — Линус Торвальдс и разработка ядра Linux), но это происходит, потому что люди захотели это сделать, не со зла и без презрения. У диктатора нет никакой супер-власти над проектом. Все свободные лицензии подразумевают, что ни одна сторона не обладает большей властью чем другая при выборе как использовать или изменять код. Если диктатор внезапно начнёт принимать плохие решения, последует возмущение, за которым рано или поздно последует протест и отделение. Конечно, дело редко заходит так далеко, потому что диктатор старается не допускать плохих решений.
То что право на отделение ограничивает власть, которую может получить один человек в проекте, вовсе не значит, что все проекты управляются одинаково. Вы не захотите, чтобы каждое решение превращалось в поиск людей, которые хотят сделать форк. От этого все быстро устанут, и это отнимает много энергии, которую можно было бы направить на полезную работу. В следующих разделах мы внимательно изучим разные способы, с помощью которых можно упростить процесс принятия решений. Два примера, которые мы рассмотрим, немного идеализированы, огромное число проектов лежит в плоскости между ними.
Модель великодушного диктатора собственно и означает великодушного диктатора: окончательное решение принимает один человек, который как ожидается примет его правильно, поскольку обладает нужными личными качествами и опытом.
Хотя мы обычно и употребляем термин "великодушный диктатор" (или ВД), лучше думать об этой роли как о "арбитре одобренном сообществом" или "судье". В общем, великодушные диктаторы, не принимают всех решений, и даже большей их части. Крайне маловероятно, что один человек обладает настолько широкими знаниями, чтобы постоянно принимать правильные решения во всех областях проекта. Даже если это будет так, хорошие разработчики не останутся в проекте, если не получат достаточно влияния на вектор развития проекта. Поэтому великодушные диктаторы обычно не диктаторствуют много. Вместо этого они позволяют случатся событиям и вырабатываться решениям в дискуссиях и посредством эксперимента. Они и сами участвуют в дискуссиях, как обычные разработчики, доверяя людям которые разбираются в предметной области. Они топают ногой и говорят "Будет так!" только если дискуссия зашла в тупик и большая часть группы хочет, чтобы кто-нибудь принял решение, дабы не тормозить разработку. Нежелание править с помощью указов присуще практически всем успешным великодушным диктаторам. Это одна из причин, по которой они все еще занимают эту роль.
Чтобы быть великодушным диктатором надо обладать рядом качеств. Во-первых, нужна тщательно настроенная точность восприятия собственной значимости в проекте, которая рождает самоограничение. На ранних стадиях обсуждения, ВД должен ограничивать себя и не высказывать суждений и решений таким образом, чтобы другие участники приняли их как приказ и отчаялись спорить. Нельзя ограничивать свободу высказывать мысли, пусть и глупые. ВД и сам будет время от времени говорить глупости. Таким образом, диктатору нужно мужество признавать свои ошибки, хотя это качество необходимо любому хорошему разработчику, особенно если он остается в проекте надолго. Разница лишь в том, что диктатор может позволить себе ошибаться не заботясь о своем кредите доверия. Разработчики с меньшим опытом могут не чувствовать себя столь уверенно в отношении ошибок, поэтому ВД должен очень аккуратно критиковать и спорить с ними, понимая какой вес имеют его слова и в техническом и в психологическом аспекте.
ВД не обязательно должен быть самым технически подкованным участником проекта. У него должно быть достаточно навыков, чтобы работать с кодом самому, понимать изменения вносимые в код и комментировать их, но это всё, что нужно. Роль ВД невозможно получить и удержаться на ней только за счет талантов или потрясающих навыков программирования. Важен на самом деле опыт и чувство архитектуры, не обязательно даже обладать способностью проектировать хорошую архитектуру под заданные условия, но отличать хорошую от плохой необходимо.
Обычно роль великодушного диктатора выполняет основатель проекта, но связь тут скорее корреляционная чем причинно-следственная. Тот набор качеств, который необходим для старта проекта (технические знания, способность общаться и убеждать людей, и т.д.) совпадает с набором качеств необходимых ВД. И, конечно же, основатель проекта считается другими более важной персоной. Только этого может быть достаточно для того, чтобы великодушный диктатор появился самым простым способом.
Помните, что право на отделение есть у каждого. ВД сам может сделать форк так же просто как и другие. Некоторые диктаторы делают их иногда, если они чувствуют что их видение проекта отличается от видения большинства разработчиков. На возможность отделения не влияют права доступа диктатора к серверам. Люди иногда говорят о контроле над сервером как будто обладание им дарует абсолютную власть над проектом, на самом деле это не важно. Возможность добавлять или удалять права доступа на изменения на одном сервере касается только копии проекта на этом сервере. Длительное пренебрежение этим принципом со стороны диктатора или кого-либо еще приведет к тому, что разработка переместится на другой сервер.
Будет ли в вашем проекте роль диктатора или вы выберете менее централизованную модель управления, зависит от людей, способных занять роль диктатора. Как правило, если все сразу понимают, кто должен стать ВД, то он им становится. Но если такой очевидной кандидатуры нет, то в проекте лучше использовать децентрализованную модель принятия решений, которая описана в следующем разделе.