Чаще всего люди малознакомые с открытым ПО задают вопросы: Как оно устроено? Что заставляет проект развиваться? Кто принимает решения? Мне не нравятся банальные ответы типа меритократии, духа сотрудничества, самодокументированного кода и т.п. Вопрос, на самом деле, не так прост. Меритократия, сотрудничество, поддержка кода входят в ответ, но они ничего не говорят о том, как проект живет ежедневной жизнью, как решаются конфликтные ситуации. В этой главе я попробую показать те вещи, на которых базируются все успешные проекты. Успешные, не только с точки зрения качества исполнения, но и с точки зрения здорового рабочего состояния и живучести. Рабочее состояние—это деятельность по внедрению нового кода и новых разработчиков в проект, а также по реагированию на поступающие отчеты об ошибках. Живучесть—это способность проекта жить своей жизнью независимо от конкретного участника или спонсора. Посмотрите на это как на вероятность того, что проект продолжит свое существование, в случае если все основатели из него уйдут. Добиться успеха с технически совершенным продуктом легко, но без надежной команды разработчиков и установления основ социального взаимодействия проект может не справится с ростом, который принесет успех, или с уходом харизматичных личностей. Существует несколько путей достижения успеха. Один подразумевает ведение формальных управляющих процедур, с помощью которых разрешаются споры, принимаются (и иногда исключаются) разработчики, планируются новые функции проекта, и так далее. Другой полагается на менее формализованную структуру сознательного самоограничения, и создает тем самым атмосферу честности, которая и становится де факто формой управления. Оба подхода приводят к тому, что у участников возникает чувство организационной стабильности, подкрепляемое понятными всем привычками и процедурами. Эти особенности гораздо более важны для самоорганизующихся систем, чем для систем с централизованным управлением, потому что для самоорганизующихся систем справедливо высказывание о том, что ложка дегтя портит бочку меда, по крайней мере на какое-то время. Важный компонент, который заставляет разработчиков держаться вместе и находить консенсус при необходимости,—это право на отделение, право любого человека взять копию исходного кода и использовать её, чтобы начать конкурирующий проект (форк). Парадокс заключается в том, что сама возможность появления форка обладает большим влиянием на развитие проекта открытого ПО, чем конкурирующие форки, число которых обычно мало. Форк невыгоден всем (причины описаны в разделе : ), и чем сильнее становится угроза разделения проекта, тем больше решимости найти компромисс появляется у участников проекта. Форте, или скорее возможность их появления, приводят к тому, что в мире открытого ПО нет диктаторов. Возможно, это заявление покажется странным, потому что люди часто говорят о "диктаторах" или "тиранах" в проектах открытого ПО. Но эта тирания особая, она отличается от того, что принято понимать под этим словом. Представьте короля, чьи вассалы могут скопировать королевство целиком, переехать в копию и править там как захотят. Не будет ли такой король править по другому, в отличие от короля, чьи слуги привязаны к нему навсегда? Вот почему даже проекты формально не являющиеся демократиями проявляют черты демократии, когда дело доходит до принятия важных решений. Право на создание копии предполагает право на отделение, а оно предполагает консенсус. Может случиться, что все хотят подчиниться одному лидеру (самый известный пример — Линус Торвальдс и разработка ядра Linux), но это происходит, потому что люди захотели это сделать, не со зла и без презрения. У диктатора нет никакой супер-власти над проектом. Все свободные лицензии подразумевают, что ни одна сторона не обладает большей властью чем другая при выборе как использовать или изменять код. Если диктатор внезапно начнёт принимать плохие решения, последует возмущение, за которым рано или поздно последует протест и отделение. Конечно, дело редко заходит так далеко, потому что диктатор старается не допускать плохих решений. То что право на отделение ограничивает власть, которую может получить один человек в проекте, вовсе не значит, что все проекты управляются одинаково. Вы не захотите, чтобы каждое решение превращалось в поиск людей, которые хотят сделать форк. От этого все быстро устанут, и это отнимает много энергии, которую можно было бы направить на полезную работу. В следующих разделах мы внимательно изучим разные способы, с помощью которых можно упростить процесс принятия решений. Два примера, которые мы рассмотрим, немного идеализированы, огромное число проектов лежит в плоскости между ними. Модель великодушного диктатора собственно и означает великодушного диктатора: окончательное решение принимает один человек, который как ожидается примет его правильно, поскольку обладает нужными личными качествами и опытом. Хотя мы обычно и употребляем термин "великодушный диктатор" (или ВД), лучше думать об этой роли как о "арбитре одобренном сообществом" или "судье". В общем, великодушные диктаторы, не принимают всех решений, и даже большей их части. Крайне маловероятно, что один человек обладает настолько широкими знаниями, чтобы постоянно принимать правильные решения во всех областях проекта. Даже если это будет так, хорошие разработчики не останутся в проекте, если не получат достаточно влияния на вектор развития проекта. Поэтому великодушные диктаторы обычно не диктаторствуют много. Вместо этого они позволяют случатся событиям и вырабатываться решениям в дискуссиях и посредством эксперимента. Они и сами участвуют в дискуссиях, как обычные разработчики, доверяя людям которые разбираются в предметной области. Они топают ногой и говорят "Будет так!" только если дискуссия зашла в тупик и большая часть группы хочет, чтобы кто-нибудь принял решение, дабы не тормозить разработку. Нежелание править с помощью указов присуще практически всем успешным великодушным диктаторам. Это одна из причин, по которой они все еще занимают эту роль. Чтобы быть великодушным диктатором надо обладать рядом качеств. Во-первых, нужна тщательно настроенная точность восприятия собственной значимости в проекте, которая рождает самоограничение. На ранних стадиях обсуждения, ВД должен ограничивать себя и не высказывать суждений и решений таким образом, чтобы другие участники приняли их как приказ и отчаялись спорить. Нельзя ограничивать свободу высказывать мысли, пусть и глупые. ВД и сам будет время от времени говорить глупости. Таким образом, диктатору нужно мужество признавать свои ошибки, хотя это качество необходимо любому хорошему разработчику, особенно если он остается в проекте надолго. Разница лишь в том, что диктатор может позволить себе ошибаться не заботясь о своем кредите доверия. Разработчики с меньшим опытом могут не чувствовать себя столь уверенно в отношении ошибок, поэтому ВД должен очень аккуратно критиковать и спорить с ними, понимая какой вес имеют его слова и в техническом и в психологическом аспекте. ВД не обязательно должен быть самым технически подкованным участником проекта. У него должно быть достаточно навыков, чтобы работать с кодом самому, понимать изменения вносимые в код и комментировать их, но это всё, что нужно. Роль ВД невозможно получить и удержаться на ней только за счет талантов или потрясающих навыков программирования. Важен на самом деле опыт и чувство архитектуры, не обязательно даже обладать способностью проектировать хорошую архитектуру под заданные условия, но отличать хорошую от плохой необходимо. Обычно роль великодушного диктатора выполняет основатель проекта, но связь тут скорее корреляционная чем причинно-следственная. Тот набор качеств, который необходим для старта проекта (технические знания, способность общаться и убеждать людей, и т.д.) совпадает с набором качеств необходимых ВД. И, конечно же, основатель проекта считается другими более важной персоной. Только этого может быть достаточно для того, чтобы великодушный диктатор появился самым простым способом. Помните, что право на отделение есть у каждого. ВД сам может сделать форк так же просто как и другие. Некоторые диктаторы делают их иногда, если они чувствуют что их видение проекта отличается от видения большинства разработчиков. На возможность отделения не влияют права доступа диктатора к серверам. Люди иногда говорят о контроле над сервером как будто обладание им дарует абсолютную власть над проектом, на самом деле это не важно. Возможность добавлять или удалять права доступа на изменения на одном сервере касается только копии проекта на этом сервере. Длительное пренебрежение этим принципом со стороны диктатора или кого-либо еще приведет к тому, что разработка переместится на другой сервер. Будет ли в вашем проекте роль диктатора или вы выберете менее централизованную модель управления, зависит от людей, способных занять роль диктатора. Как правило, если все сразу понимают, кто должен стать ВД, то он им становится. Но если такой очевидной кандидатуры нет, то в проекте лучше использовать децентрализованную модель принятия решений, которая описана в следующем разделе. По мере взросления проекты отказываются от модели великодушного диктатора в угоду более открытых демократических систем. Это не всегда происходит из-за разочарования в диктаторе. Просто управление на основе группового решения более "эволюционно стабильно", если говорить языком биологов. В тот момент когда диктатор уходит со сцены или пробует применять процесс принятия решения зависящий от большего числа участников, наступает возможность перехода проекта к новой недиктаторской модели и принять конституцию, как будто переход уже совершен. Сообщество может не воспользоваться этой возможностью в первый раз, или во второй, но рано или поздно оно ей воспользуется, и воспользовавшись вряд ли уже возвратится назад. Здравый смысл дает ответ на вопрос, почему это так. Если группа людей числом N решает наделить одного человека особой властью, это значит, что N людей решило пожертвовать своим влиянием в угоду одному. Людям обычно не нравится так делать. Даже если они так сделают, то диктатура все равно будет условной. Группа наделила человека властью, и очевидно, группа может его низложить. Таким образом, если проект перешел от предводительства одного харизматичного лидера к более формализованной системе групповых решений, он редко возвращается к прежней модели. Работа таких систем отличается в мелочах, но есть два признака по которым они схожи: во-первых, решение в группе принимается достижением консенсуса, во-вторых, существует определенный механизм голосования, который применяется если консенсус недостижим. Консенсус— всего лишь решение которое всех устраивает. Это определение вполне однозначно: группа достигла консенсуса по определенному вопросу, если кто-то высказал предположение о том, что консенсус достигнут, и никто не высказался против. Естественно, человек заявляющий о консенсусе четко выразить в чем он заключается, и какие действия будут предприняты (если это не очевидно) после его принятия. Большая часть разговоров в проекте идет о технических вопросах, таких как пути исправления ошибок, добавление нового функционала, глубина документирования интерфейсов, и т.п. Управление на основе консенсуса замечательно работает в этом случае, потому что бесшовно интегрируется в техническую дискуссию. К концу обсуждения группа как правило достигает соглашения о том, какие действия предпринять. Кто-то обычно пишет сообщение, подводящее итог обсуждению и содержащее предложенное решение, которое и является по сути предложением о консенсусе. После этого у несогласного человека все еще есть возможность возразить и сказать: "Подождите, я не согласен. Мы должны еще подумать над этим". Для небольших, не вызывающих споров решения, предложение о консенсусе очевидно. Например, если разработчик добавляет патч исправляющий ошибку, само исправление и есть предложение о консенсусе: "Я полагаю, что все мы соглашаемся с тем, что эта ошибка требует исправления, и предложенное исправление её решает". Естественно, разработчики так не говорят. Они просто добавляют исправление, и другие участники проекта не декларируют свое согласие, потому что молчание и есть согласие. Если кто-то вносит исправление, и на практике не возникает консенсус, то начинается дискуссия, как будто исправление и не вносилось. Мы поговорим о причинах этого в следующем разделе. То, что исходный код проекта содержится в системе контроля версий, позволяет легко отменять решения. Чаще всего их приходится отменять из-за того, что кто-то ошибочно предположил, что его изменения обрадуют всех, а на самом деле после внесения изменений разгорелась дискуссия. Разговор обычно начинается с обязательных извинений за то, что возражения не были высказаны в ходе дискуссии до внесения изменений. Извинения не приносятся, если дискуссии не было. В любом случае нет причин различать обсуждение до и после внесения изменений. Любое изменение можно отменить, по крайней мере до того как от него появятся зависимости (скажем, новый код который перестанет работать если убрать изменение). Система контроля версий смягчает последствия быстрых или поспешных решений. Это, в свою очередь, дает людям возможность оценивать необходимость обсуждения до внесения изменений самостоятельно. Также это позволяет не делать процесс выработки консенсуса формальным. В большинстве проектов он достигается естественным образом. Небольшие изменения вносятся либо совсем без обсуждения, либо с минимальным обсуждением и последующим молчаливым согласием. Перед внесением более значительных изменений, особенно если они могут дестабилизировать большие участки кода, следует подождать два-три дня прежде чем считать консенсус состоявшимся. Идея заключается в том, что никто не должен остаться за бортом, особенно по причине того, что не проверяет почту достаточно часто. Таким образом, если человек знает, что нужно сделать, он должен сделать это. Это относится не только к изменению кода ПО, но и к обновлению сайта, внесению изменений в документацию, и другим вещам, которые не должны вызывать бурного обсуждения. Как правило, будет не очень много случаев, в которых понадобится отменять изменения. C ними можно справляться по мере возникновения. Конечно, не стоит поощрять своеволие. Есть психологическая разница между решением принятым после обсуждения и решением, которое уже вступило в силу, даже если его можно отменить. Люди чувствуют что движущая сила связана с действием, и будут меньше сопротивляться уже принятому решению, чем принятию решения, которое только обсуждается. Если разработчик пользуется этим и вносит потенциально спорные изменения слишком быстро, другие участники могут и должны возразить ему, а также должны заставить его следовать более строгим стандартам пока он не научится. Часть дискуссий неизбежно не будет заканчиваться консенсусом. Когда другие средства достижения компромисса исчерпают себя, голосуйте. Но набор возможных исходов должен быть определен перед голосованием. И здесь, снова, природа технической дискуссии замечательно проявляет себя и сливается с процедурой принятия решения. Зачастую вопросы, которые выносятся на голосование касаются сложных, многогранных вещей. В это случае, один или два человека обычно берут на себе роль посредника, они периодически публикуют краткие результаты дискуссии и отслеживают ключевые точки по которые соглашаются (или не соглашаются) стороны. Эти сообщения помогают другим участникам быстро оценивать достигнутый прогресс и напоминают о проблемах, которые еще предстоит решить. Эти же сообщения послужат прототипами бюллетеней, если потребуется голосование. Если посредники справились со своей работой, они могут провести достоверное голосование в случае необходимости и использовать собранную информацию для бюллетеней. Посредники могут участвовать в обсуждении. Они не обязаны устраняться от дискуссии, если они могут понять и адекватно представлять взгляды других участников, и не позволяют своим взглядам влиять на нейтралитет при исполнении роли посредника. Обычно содержание бюллетеня не вызывает споров. Ко времени проведения голосования споры как правило сводятся к узкому кругу четко обозначенных вопросов. Иногда разработчик может не согласится с тем, как вопросы представлены в бюллетене. Иногда его доводы разумны, например если важный вопрос был оставлен за бортом, или описан недостаточно точно. Но в других случаях разработчик может попросту оттягивать неизбежное, зная что выбор скорее всего будет не в его пользу. Смотрите как противостоять такому поведению в разделе :. Remember to specify the voting system, as there are many different kinds, and people might make wrong assumptions about which procedure is being used. A good choice in most cases is approval voting, whereby each voter can vote for as many of the choices on the ballot as he likes. Approval voting is simple to explain and to count, and unlike some other methods, it only involves one round of voting. See for more details about approval voting and other voting systems, but try to avoid getting into a long debate about which voting system to use (because, of course, you will then find yourself in a debate about which voting system to use to decide the voting system!). One reason approval voting is a good choice is that it's very hard for anyone to object to—it's about as fair as a voting system can be. Finally, conduct votes in public. There is no need for secrecy or anonymity in a vote on matters that have been debated publicly anyway. Have each participant post her votes to the project mailing list, so that any observer can tally and check the results for herself, and so that everything is recorded in the archives. The hardest thing about voting is determining when to do it. In general, taking a vote should be very rare—a last resort for when all other options have failed. Don't think of voting as a great way to resolve debates. It isn't. It ends discussion, and thereby ends creative thinking about the problem. As long as discussion continues, there is the possibility that someone will come up with a new solution everyone likes. This happens surprisingly often: a lively debate can produce a new way of thinking about the problem, and lead to a proposal that eventually satisfies everyone. Even when no new proposal arises, it's still usually better to broker a compromise than to hold a vote. After a compromise, everyone is a little bit unhappy, whereas after a vote, some people are unhappy while others are happy. From a political standpoint, the former situation is preferable: at least each person can feel he extracted a price for his unhappiness. He may be dissatisfied, but so is everyone else. Voting's main advantage is that it finally settles a question so everyone can move on. But it settles it by a head count, instead of by rational dialogue leading everyone to the same conclusion. The more experienced people are with open source projects, the less eager I find them to be to settle questions by vote. Instead they will try to explore previously unconsidered solutions, or compromise more severely than they'd originally planned. Various techniques are available to prevent a premature vote. The most obvious is simply to say "I don't think we're ready for a vote yet," and explain why not. Another is to ask for an informal (non-binding) show of hands. If the response clearly tends toward one side or another, this will make some people suddenly more willing to compromise, obviating the need for a formal vote. But the most effective way is simply to offer a new solution, or a new viewpoint on an old suggestion, so that people re-engage with the issues instead of merely repeating the same arguments. In certain rare cases, everyone may agree that all the compromise solutions are worse than any of the non-compromise ones. When that happens, voting is less objectionable, both because it is more likely to lead to a superior solution and because people will not be overly unhappy no matter how it turns out. Even then, the vote should not be rushed. The discussion leading up to a vote is what educates the electorate, so stopping that discussion early can lower the quality of the result. (Note that this advice to be reluctant to call votes does not apply to the change-inclusion voting described in in . There, voting is more of a communications mechanism, a means of registering one's involvement in the change review process so that everyone can tell how much review a given change has received.) Having a voting system raises the question of electorate: who gets to vote? This has the potential to be a sensitive issue, because it forces the project to officially recognize some people as being more involved, or as having better judgement, than others. The best solution is to simply take an existing distinction, commit access, and attach voting privileges to it. In projects that offer both full and partial commit access, the question of whether partial committers can vote largely depends on the process by which partial commit access is granted. If the project hands it out liberally, for example as a way of maintaining many third-party contributed tools in the repository, then it should be made clear that partial commit access is really just about committing, not voting. The reverse implication naturally holds as well: since full committers will have voting privileges, they must be chosen not only as programmers, but as members of the electorate. If someone shows disruptive or obstructionist tendencies on the mailing list, the group should be very cautious about making him a committer, even if the person is technically skilled. The voting system itself should be used to choose new committers, both full and partial. But here is one of the rare instances where secrecy is appropriate. You can't have votes about potential committers posted to a public mailing list, because the candidate's feelings (and reputation) could be hurt. Instead, the usual way is that an existing committer posts to a private mailing list consisting only of the other committers, proposing that someone be granted commit access. The other committers speak their minds freely, knowing the discussion is private. Often there will be no disagreement, and therefore no vote necessary. After waiting a few days to make sure every committer has had a chance to respond, the proposer mails the candidate and offers him commit access. If there is disagreement, discussion ensues as for any other question, possibly resulting in a vote. For this process to be open and frank, the mere fact that the discussion is taking place at all should be secret. If the person under consideration knew it was going on, and then were never offered commit access, he could conclude that he had lost the vote, and would likely feel hurt. Of course, if someone explicitly asks for commit access, then there is no choice but to consider the proposal and explicitly accept or reject him. If the latter, then it should be done as politely as possible, with a clear explanation: "We liked your patches, but haven't seen enough of them yet," or "We appreciate all your patches, but they required considerable adjustments before they could be applied, so we don't feel comfortable giving you commit access yet. We hope that this will change over time, though." Remember, what you're saying could come as a blow, depending on the person's level of confidence. Try to see it from their point of view as you write the mail. Because adding a new committer is more consequential than most other one-time decisions, some projects have special requirements for the vote. For example, they may require that the proposal receive at least n positive votes and no negative votes, or that a supermajority vote in favor. The exact parameters are not important; the main idea is to get the group to be careful about adding new committers. Similar, or even stricter, special requirements can apply to votes to remove a committer, though hopefully that will never be necessary. See in for more on the non-voting aspects of adding and removing committers. For certain kinds of votes, it may be useful to expand the electorate. For example, if the developers simply can't figure out whether a given interface choice matches the way people actually use the software, one solution is to ask to all the subscribers of the project's mailing lists to vote. These are really polls rather than votes, but the developers may choose to treat the result as binding. As with any poll, be sure to make it clear to the participants that there's a write-in option: if someone thinks of a better option not offered in the poll questions, her response may turn out to be the most important result of the poll. Some projects allow a special kind of vote known as a veto. A veto is a way for a developer to put a halt to a hasty or ill-considered change, at least long enough for everyone to discuss it more. Think of a veto as somewhere between a very strong objection and a filibuster. Its exact meaning varies from one project to another. Some projects make it very difficult to override a veto; others allow them to be overridden by regular majority vote, perhaps after an enforced delay for more discussion. Any veto should be accompanied by a thorough explanation; a veto without such an explanation should be considered invalid on arrival. With vetoes comes the problem of veto abuse. Sometimes developers are too eager to raise the stakes by casting a veto, when really all that was called for was more discussion. You can prevent veto abuse by being very reluctant to use vetoes yourself, and by gently calling it out when someone else uses her veto too often. If necessary, you can also remind the group that vetoes are binding for only as long as the group agrees they are—after all, if a clear majority of developers wants X, then X is going to happen one way or another. Either the vetoing developer will back down, or the group will decide to weaken the meaning of a veto. You may see people write "-1" to express a veto. This usage comes from the Apache Software Foundation, which has a highly structured voting and veto process, described at . The Apache standards have spread to other projects, and you will see their conventions used to varying degrees in a lot of places in the open source world. Technically, "-1" does not always indicate a formal veto even according to the Apache standards, but informally it is usually taken to mean a veto, or at least a very strong objection. Like votes, vetoes can apply retroactively. It's not okay to object to a veto on the grounds that the change in question has already been committed, or the action taken (unless it's something irrevocable, like putting out a press release). On the other hand, a veto that arrives weeks or months late isn't likely to be taken very seriously, nor should it be. At some point, the number of conventions and agreements floating around in your project may become so great that you need to record it somewhere. In order to give such a document legitimacy, make it clear that it is based on mailing list discussions and on agreements already in effect. As you compose it, refer to the relevant threads in the mailing list archives, and whenever there's a point you're not sure about, ask again. The document should not contain any surprises: it is not the source of the agreements, it is merely a description of them. Of course, if it is successful, people will start citing it as a source of authority in itself, but that just means it reflects the overall will of the group accurately. This is the document alluded to in in . Naturally, when the project is very young, you will have to lay down guidelines without the benefit of a long project history to draw on. But as the development community matures, you can adjust the language to reflect the way things actually turn out. Don't try to be comprehensive. No document can capture everything people need to know about participating in a project. Many of the conventions a project evolves remain forever unspoken, never mentioned explicitly, yet adhered to by all. Other things are simply too obvious to be mentioned, and would only distract from important but non-obvious material. For example, there's no point writing guidelines like "Be polite and respectful to others on the mailing lists, and don't start flame wars," or "Write clean, readable bug-free code." Of course these things are desirable, but since there's no conceivable universe in which they might not be desirable, they are not worth mentioning. If people are being rude on the mailing list, or writing buggy code, they're not going to stop just because the project guidelines said to. Such situations need to be dealt with as they arise, not by blanket admonitions to be good. On the other hand, if the project has specific guidelines about how to write good code, such as rules about documenting every API in a certain format, then those guidelines should be written down as completely as possible. A good way to determine what to include is to base the document on the questions that newcomers ask most often, and on the complaints experienced developers make most often. This doesn't necessarily mean it should turn into a FAQ sheet—it probably needs a more coherent narrative structure than FAQs can offer. But it should follow the same reality-based principle of addressing the issues that actually arise, rather than those you anticipate might arise. If the project is a benevolent dictatorship, or has officers endowed with special powers (president, chair, whatever), then the document is also a good opportunity to codify succession procedures. Sometimes this can be as simple as naming specific people as replacements in case the BD suddenly leaves the project for any reason. Generally, if there is a BD, only the BD can get away with naming a successor. If there are elected officers, then the nomination and election procedure that was used to choose them in the first place should be described in the document. If there was no procedure originally, then get consensus on a procedure on the mailing lists before writing about it. People can sometimes be touchy about hierarchical structures, so the subject needs to be approached with sensitivity. Perhaps the most important thing is to make it clear that the rules can be reconsidered. If the conventions described in the document start to hamper the project, remind everyone that it is supposed to be a living reflection of the group's intentions, not a source of frustration and blockage. If someone makes a habit of inappropriately asking for rules to be reconsidered every time the rules get in her way, you don't always need to debate it with her—sometimes silence is the best tactic. If other people agree with the complaints, they'll chime in, and it will be obvious that something needs to change. If no one else agrees, then the person won't get much response, and the rules will stay as they are. Two good examples of project guidelines are the Subversion Community Guide, at , and the Apache Software Foundation governance documents, at and . The ASF is really a collection of software projects, legally organized as a nonprofit corporation, so its documents tend to describe governance procedures more than development conventions. They're still worth reading, though, because they represent the accumulated experience of a lot of open source projects.