Даже после того, как вы сделали проект общим, вы и другие основатели, будете частенько хотеть, разрешить трудные вопросы в процессе закрытого обсуждения в своем внутреннем круге. Это особенно верно в начале проекта, когда нужно принять очень много важных решений, и, обычно, мало добровольцев достаточно квалифицированы, чтобы их принять. Все очевидные недостатки обсуждения с помощью публичного листа рассылки будут ясно вырисовываться перед вами: задержка,как неотъемлемая часть разговоров по электронной почте, потребность оставить достаточное количество времени для согласования, споры с наивными добровольцами, которые думают, что понимают все проблемы, но на самом деле не понимают (такие есть в каждом проекте; иногда это лучшие программисты будущего года, иногда они остаются наивными навсегда), кто-то, кто не может понять, почему вы хотите решить только задачу X, в то время как очевидно, что это подмножество большей проблемы Y и так далее. Искушение принять решения за закрытыми дверьми и представить их как faits accomplis (свершившиеся факты) , или, по крайней мере, как прямые рекомендации объединенного и влиятельного большинства, вместо всего этого, будет очень большим.

Не делайте этого

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

Наконец, существует вероятность того, что кто-то из списка сможет сделать ценный вклад в беседу, выступив с идеей, которую вы никогда и не ожидали. Невозможно предсказать, насколько такое событие вероятно; это зависит лишь от сложности кода и требуемой степени специализации. Но если история из жизни может быть дозволена в качестве доказательства, я поставил бы на то, что это более вероятно, чем можно было бы интуитивно ожидать. В проекте Subversion мы (основатели) полагали, что оказались перед большим и сложным набором проблем, о которых мы интенсивно размышляли в течение нескольких месяцев, и мы искренне сомневались, что кто-либо из недавно созданного списка рассылки, способен реально посодействовать в обсуждении. Таким образом, мы выбрали ленивый путь и стали пинать туда-сюда некоторые технические решения в частной переписке, до того момента, когда ответсвенный за проект ^[10]понял куда дует ветер и попросил перенести дискуссию в общий доступ. Прикрыв глаза мы это сделали — и были ошеломлены числом проницательных комментариев и предложений, которые быстро последовали. Во многих случаях люди предлагали решения, которые даже не приходили нам в голову. Оказалось, что в этом списке нашлось некоторое количество очень умных людей; они лишь ждали нужной наживки. Да, в действительности последующие обсуждения заняли больше времени, чем они заняли бы, если бы мы оставили дискуссию закрытой, но они были настолько более производительными, что это стоило дополнительного времени.

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

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

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

С самого начала существования вашего проекта в качестве общедоступного, вы должны поддерживать политику нулевого допуска в отношении грубого или оскорбительного поведения на его форумах. Нулевой допуск не означает технического принуждения как такового. Вам не нужно удалять людей из списка адресатов рассылки, когда они грубят другим подписчикам, или лишать их возможности вносить свой код, потому что они пишут уничижительные комментарии. (В теории Вам, возможно, в конечном счете придется прибегнуть к подобным действиям, но только после того, как любые другие способы не дадут результата— чего не может быть в начале проекта по определению). Нулевой допуск просто означает, что вы никогда не позволяете плохому поведению проскользнуть незамеченным. Например, когда кто-то размещает комментарий технического плана вперемешку с ad hominem высказыванием в адрес какого-то другого разработчика на проекте, ваш ответ обязательно должен быть в первую очередь, направлен на высказывания ad hominem как на отдельную проблему саму по себе, и только затем переходить к технической части.

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

Как бы искусственно не звучали такие ответыв, они дают заметный результат. Если Вы последовательно искореняете плохое поведение, но не требуете извинений или осознания ошибки от виновной стороны, то вы оставляете людям возможность остыть и показать их лучшую сторону, ведя себя более прилично в следующий раз—и они сделают именно так. Один из секретов успешности таких действий—никогда не делать это дополнительное обсуждение основной темой. Оно должно всегда быть несколько в стороне, вроде краткого предисловия к основной части вашего ответа. Укажите мимоходом, что "мы здесь так не делаем", но затем переходите к настоящему существу вопроса, так, чтобы вы дали людям конкретную тему, на которую надо ответить. Если кто-то возражает, что они не заслуживали вашего упрека, просто отказывайтесь быть вовлеченными в спор на эту тему. Также не отвечайте (если вы думаете, что они только спускают пар и не требуют ответа), или скажите, что вы сожалеете о том, что, наверное, слишком остро реагировали и что трудно различить нюансы в электронной почте, а затем возвращайтесь к основной теме. Никогда, никогда не настаивайте на признании кем-то вины, перед сообществом или перед самим собой, в том, что они вели себя неправильно. Если они по собственной воле захотят принести извинения, это великолепно, но требование такого признания только вызовет негодование.

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

Одним из лучших способов развития продуктивного сообщества разработчиков является поощрение того, что бы люди смотрели на код друг друга. Для того, чтобы это проиходило эффективно, необходима некоторая техническая инфраструктура—в частности уведомления о внесении изменений должны быть включены; подробнее в «Commit emails». Эффект уведомлений об изменениях в том, что каждый раз, когда кто-нибудь вносит изменения в исходный код, отсылается письмо, показывающее сообщение, заносимое в журнал, и список отличий данной версии от предыдущей (см. diff, в «Version Control Vocabulary»). Рецензирование кода это просмотр уведомлений о внесении изменений после их поступления, с целью поиска ошибок и возможных улучшений.^[11]

Рецензирование кода служит нескольким целям одновременно. Это самый очевидный пример экспертной оценки в мире открытого ПО, что напрямую помогает поддерживать качество программного обеспечения. Каждая ошибка, которая содержится в программе, попадает туда, будучи добавленной и не выявленной; однако, чем больше глаз следит за добавлениями, тем меньше ошибок будет в конечном продукте. Но рецензирование кода служит и косвенной цели: оно доказывает людям, что то что они делаю имеет значение, так как очевидно, что никто не будет тратить время на проверку внесенных изменений, если его не заботит их эффект. Люди стараются изо всех сил, когда они знают, что другие люди потратят время на оценку их работы.

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

В проекте Subversion, мы поначалу не занимались регулярным рецензированием кода. Не было гарантии того, что каждое изменение было бы просмотрено, хотя, кто-нибудь мог иногда просмотреть изменения, если был особенно заинтересован в данном разделе кода. Проскальзывали такие ошибки, которые могли бы и должны были быть пойманы. Разработчик по имени Грег Стейн, который знал о значимости рецензирования кода из прошлого опыта, решил, что он станет примером для подражания, рецензируя каждую строчку каждого изменения которое вносилось в хранилище кода. Каждое изменение, которое вносил кто угодно, вскоре стало сопровождаться письмом от Грега в список рассылки для разработчиков, в котором разбирались изменения, анализировались возможные проблемы и иногда хвалились хорошие куски кода. И сразу же он стал находить ошибки и неоптимальные приемы кодирования, которые, в ином случае, проскользнули бы совсем незамеченными. Он подчеркнуто никогда не жаловался на то, что являлся единственным человеком, просматривающим каждое изменение, даже если это занимало приличную часть его времени, но он пел хвалу рецензированию кода каждый раз, когда предоставлялась такая возможность. Довольно скоро другие люди, включая меня, тоже начали регулярно рецензировать изменения. Что нами двигало? Не то, что Грег умышленно нас стыдил. Но он доказал, что рецензирование кода было полезной тратой времени, и что человек может принести столько же пользы проекту путем рецензирования изменений, вносимых другими, сколько и путем написания нового кода. Как только он это продемонстрировал, рецензирование стало ожидаемым действием, до такой степени, что любое изменение, которое не вызывало какой-либо реакции, заставляло автора волноваться и даже спрашивать в списке рассылки, смог ли уже кто-нибудь его оценить. Позже, Грег получил работу, которая уже не оставляла ему много времени на Subversion, и ему пришлось прекратить регулярные рецензии. Но к тому времени эта привычка настолько укоренилась во всех нас, что казалось, будто так и было с незапамятных времен.

Начинайте рецензирование с самого первого изменения. С помощью просмотра изменений проще всего поймать такие типы ошибок как уязвимости системы безопасности, утечка памяти, недостатоность комментариев или документации API, ошибки завышения или занижения на единицу (off-by-one), несовпадение порядка вызывающего/вызываемого и другие ошибки, которые требуют минимум окружающего контекста для их выявления. Однако, даже широкомасштабные проблемы, такие как неспособность выделить повторяющиеся шаблоны в отдельное место, становятся заметными, после того, как кто-нибудь начинает регулярно рецензировать изменения, потому что память о прошлых различиях дополняет информацию о текущих.

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

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

Попробуйте вообразить, как эта ситуация выглядит для них: раньше все решения относительно кода и дизайна принимались группой программистов, которые знали программу более или менее одинаково хорошо, которые испытывали одинаковое давление со стороны одного и того же менеджемента, и которые знали сильные и слабые стороны каждого из них. А теперь вы просите отдать их код на внимательное изучение случайным людям, которые будут строить свои суждения основываясь только на коде, без учета того, что даление со стороны бизнеса могло диктовать принятие некоторых решений. Эти незнакомцы будут задавать много вопросов, вопросов, которые подталкивают нынешних разработчиков к осознанию того, что документация, над которой они так тяжело работали, все еще не отвечает требованиям (и это неизбежно). И, что хуже всего, вновь прибывшие представляются как непонятные, безликие существа. Если один из ваших разработчиков уже чувствует неуверенность в своих знаниях, представьте, как она обострится, когда новички укажут на дыры в коде, который он написал, и даже хуже, сделают это в присутствии его коллег. И это неизбежно, если только ваша команда не является командой великолепных кодировщиков;в действительности же, поначалу такое случается со всеми. Все происходит не потому, что они плохие программисты; просто любая программа, превышающая определенный размер, содержит ошибки, и экспертная оценка выявит некоторые из этих ошибок (см. «Практикуйте Открытое Рецензирование Кода»ранее в этой главе). В то же время, сам новоприбывшие поначалу не будут часто служить объектом оценки, так как они не могут добавлять код, пока не познакомятся с проектом получше. Для ваших разработчиков это может видиться как поток критики, который идет к ним, но никогда не исходит от них. Таким образом, есть опасность возникновения среди старой гвардии образа мышления, характерного для загнанного в угол человека.

The best way to prevent this is to warn everyone about what's coming, explain it, tell them that the initial discomfort is perfectly normal, and reassure them that it's going to get better. Some of these warnings should take place privately, before the project is opened. But you may also find it helpful to remind people on the public lists that this is a new way of development for the project, and that it will take some time to adjust. The very best thing you can do is lead by example. If you don't see your developers answering enough newbie questions, then just telling them to answer more isn't going to help. They may not have a good sense of what warrants a response and what doesn't yet, or it could be that they don't have a feel for how to prioritize coding work against the new burden of external communications. The way to get them to participate is to participate yourself. Be on the public mailing lists, and make sure to answer some questions there. When you don't have the expertise to field a question, then visibly hand it off to a developer who does—and watch to make sure he follows up with an answer, or at least a response. It will naturally be tempting for the longtime developers to lapse into private discussions, since that's what they're used to. Make sure you're subscribed to the internal mailing lists on which this might happen, so you can ask that such discussions be moved to the public lists right away.

There are other, longer-term concerns with opening up formerly closed projects. Глава 5, Money explores techniques for mixing paid and unpaid developers successfully, and Глава 9, Licenses, Copyrights, and Patents discusses the necessity of legal diligence when opening up a private code base that may contain software written or "owned" by other parties.