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

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

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

Своим опытом поведения в таких случаях делится Джордж Данлап — один из лидеров проекта XenProject. В опубликованной на сайте OpenSource.com статье он рассказывает о том, какие методы применялись при решении проблемы безопасности XSA-7, по которой не был достигнут консенсус, причём руководство заранее знало, что именно так и будет.

Создание процедуры на случай разногласий

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

Тем более, что на первых порах работает действительно команда единомышленников, многие из которых лично знакомы друг с другом. Формальности им совершенно ни к чему.

Тем не менее, уже на этом этапе надо начинать готовить процедурные правила принятия решений при отсутствии консенсуса. Можно дать это право какому-нибудь «пожизненному диктатору», совету коммитеров или каким-либо другим чётко очерченным группам, состав которых определяется заранее.

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

Джордж Данлап вспоминает, что проблема XSA-7 была успешно решена именно голосованием коммитеров. В противном случае дискуссия длилась бы вечно.

Использование форума для начала обсуждения

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

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

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

Проведение опроса

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

  • идея ужасна и я буду категорически возражать против неё;
  • идея мне не нравится, но я не будут спорить, если её примут;
  • идея мне нравится, но отстаивать её я не готов;
  • идея великолепна, я буду выступать в её защиту.

Джордж Данлап предлагает интересный приём, который можно использовать при опросе. Следует дать участникам возможность отвечать анонимно, но заранее предупредить их, что указание своего имени увеличит вес мнения.

После завершения опроса «расклад сил» будет более-менее понятен. Причём, не только среди дискуссионно-активной части сообщества.

Определение «центра тяжести» мнения сообщества

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

В любом случае следует предпочитать не «больше за», а «меньше против». Даже вялый компромисс лучше вечного энергичного спора.

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

Формулировка конкретного предложения

Окончательные результаты опроса должны помочь лидерам сформулировать конкретное предложение по обсуждаемому вопросу и направить его в рассылку. Разумеется, уже поддержанное либо «диктатором», либо группой коммитеров.

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