Начало работы Классическая модель того, как начинаются проекты бесплатного программного обеспечения, предоставлена Эриком Раймондом, в теперь уже знаменитой статье о процессах разработки с открытым исходным кодом, озаглавленной Собор и Базар. Он писал:
Любое хорошее программное обеспечение начинается с расцарапывания личного зуда разработчика. (из )
Обратите внимание, на то, что Раймонд не говорил, что проекты с открытым исходным кодом получаются только тогда, когда у кого-нибудь начинается зуд. Скорее он говорил, что хорошее, программное обеспечение получается, когда у программиста есть личный интерес в том, чтобы увидеть задачу решенной; значимость этого для свободного программномого обеспечения в том, что личный зуд, стал самым частым побуждением для начала работы над свободным программным проектом. Большинство свободных проектов все еще начинаются именно так, но сейчас реже, чем в 1997, когда Раймонд написал эти слова. Сегодня у нас есть явление организаций — включая коммерческие корпорации— начинающих большие, централизованно управляемые проекты с открытым исходным кодом, с нуля. Одинокий программист, строча код для решения локальной задачи и потом понимая, что результат работы имеет более широкую применимость, все еще является источником большого количества нового свободного программного обеспечения, но не единственным Тем не менее, точка зрения Раймонда все еще проницательна. Основным условием является то, что производители программного обеспечения напрямую заинтересованы в его успехе, потому что они сами его используют. Если программное обеспечение не делает того, что оно, как предполагается, должно делать, то человек или организация его производящая, будет чувствовать неудовлетворенность своей ежедневной работой. Например, проект OpenAdapter (), который был начат инвестиционным банком Дресднер Клеинуорт Уоссерштеин (Dresdner Kleinwort Wasserstein) как ифраструктура с открытым исходным кодом, предназначенная для интеграции несовместимых финансовых информационных систем, едва ли способен вызвать зуд у любого самостоятельного разработчика. Она вызывает организационный зуд. Но этот зуд возникает непосредственно из опыта организации и ее партнеров,и поэтому если проект будет не в состоянии вылечить его, они об этом узнают. Такое положение дел способствует производству хорошего программного обеспечения, потому что цикл обратной связи идет в нужном направлении. Программа не писалась для того, чтобы быть проданной кому-то другому, так чтобы они могли решить их задачу. Она писалась для того, чтобы решить свою собственную задачу, а затем поделиться со всеми, как будто задача была болезнью, а программное обеспечение было лекарством, чье распространение означает полное истребление эпидемии. Эта глава о том, как представить новый свободный программный проект миру, но многие из его рекомендаций, показались бы знакомыми органам здравоохранения, распространяющим лекарства. Цели очень похожи: вы хотите объяснить, что делает лекарство, отдаете его в руки нужных людей, и убеждаетесь в том, что тот кто его получил, знает как его использовать. Но в случае с программным обеспечением, вы также хотите соблазнить некоторых получателей присоединиться к продолжающейся исследовательской деятельности по улучшению лекарства. Распространение свободного программного обеспечения, это двойная задача. Программное обеспечение должно привлекать пользователей, и привлекать разработчиков. Эти две потребности не обязательно конфликтуют, но они действительно добавляют некоторую сложность к начальному представлению проекта. Какая-то информация полезна для обоих групп, некоторая полезна только для одной или другой. Оба вида информации должны подписаться под принципом расширяемого представления; то есть, степень детализации, представленная на каждом отрезке, должна прямо соответствовать количеству времени и усилий, вложенных читателем. Больше усилий всегда должно быть равно большему вознаграждению. Когда эти два показателя не связаны прочно, люди могут быстро потерять веру и прекратить вкладывать свои силы. Из этого следует вывод о том, что внешний вид имеет значение. Программисты, в частности, часто не склонны в это верить. Их любовь к содержанию, а не к форме является почти профессиональной гордостью.Поэтому не случайно, что так много программистов проявляют неприязнь к работе в отделе продаж или связей с общественностью, а профессиональные дизайнеры часто приходят в ужас от того, что программисты придумывают самостоятельно. Это достойно сожаления, потому что встречаются ситуации, где форма является содержанием, и презентация проекта - одна из них. Например, самое первое, что посетитель узнает о проекте, это то, как выглядит его веб-сайт. Эта информация воспринимается раньше, чем любое информационное содержание сайта будет понято— до того, как будет прочитан любой текст или нажата любая ссылка. Как бы это ни было несправедливо, люди не могут удержать себя от немедленного формирования первого впечатления. Появление сайта указывает на то, позаботитлись ли разработчики об организации внешнего представления проекта. У людей имеются чрезвычайно чувствительные антенны для обнаружения усилий, потраченных на заботу о проекте. Большинство из нас может сказать с первого взгляда, был ли веб-сайт быстро набросан совместными усилиями или серьезно проработан. Это начальная информация, которую выдает ваш проект, и впечатление, которая она создает, по аналогии перенесется на остальную часть проекта. Итак, хотя большая часть этой главы рассказывает о наполнении, с которого должен начинаться ваш проект, помните, что впечатление и ощущение от использования программы тоже важны. Так как веб-сайт проекта должен функционировать для двух разных категорий посетителей — пользователей и разработчиков—особое внимание должно быть уделено ясности и направленности. Хотя здесь не место для общего трактата по веб-дизайну, один принцип достаточно важен,и заслуживает упоминания, особенно когда сайт предназначен для множества (перекрывающихся) групп: люди должны иметь общее представление о том, куда ведет ссылка до того как они нажимают на нее. Например, должно быть очевидно смотря на ссылки на пользовательскую документацию, что они ведут к пользовательской документации, а не, скажем, к документации разработчика. Реализация проекта это, частично, предоставление информации, но также и предоставление удобства. Простое присутствие некоторых стандартных предложений в нужных местах, убеждает пользователей и разработчиков, решающих, хотят ли они принять участие в проекте. Это означает, что проекта есть своя совместная деятельность, что проект предвидел вопросы, которые люди будут задавать и приложил усилия для ответа на них, таким способом, который требует минимального напряжения со стороны спрашивающего. Окружившись этой аурой подготовленности, проект посылает сообщение: "Ваше время не будет потрачено впустую, если вы присоединитесь", которое является именно тем, что люди хотят услышать. Но сначала оглянитесь Прежде чем начинать проект с открытым исходным кодом обратите внимание на одно важное предостережение: Всегда осмотритесь вокруг, чтобы узнать нет ли уже существующего проекта, который делает то, что вы хотите. Существует большая вероятность того, что какую бы задачу вы не хотели решить сейчас, кто-то хотел решить ее до вас. И если они решили ее и выпустили свой код под свободной лицензией, тогда сегодня для вас нет причины снова изобретать колесо. Конечно есть исключчения: если вы хотите начать проекта в учебных целях, то уже существующий код не поможет; или, может быть, проект о котором вы думаете настолько узкоспециален, что вы знаете о нулевой вероятности того, что кто-то еще это делал. Но в общем, нет смысла не поискать и отдача может быть огромной. Если обычные поисковые службы ничего не находят, попробуйте поискать на (сайт новостей о проектах с открытым исходным кодом, подробнее о котором будет сказано позднее), на и в разделе свободных программн Фонда свободного программного обеспечения . Даже если вы не нашли именно то, что искали, вы можете найти что-нибудь настолько близкое, что будет больше смысла присоединиться к этому проекту и добавить функциональности, чем самому начинать с нуля. Начните с того, что у вас уже есть Вы осмотрелись, поняли, что ничего вокруг действительно вам не подходит и решили начать новый проект. И что теперь? Самая трудная часть в запуске проекта свободного программного обеспечения заключается в преобразовании личного взгляда в общественный. Вы или ваша организация можете хорошо представлять, чего вы хотите, но описание вашей цели таким образом, чтобы она была понятна всему миру требует изрядного количества работы. Самое главное, однако—найти время заняться этим. Вы и другие основатели проекта должны решить, что проект действительно должен сделать— то есть, примите решение о его ограничениях, о том, что он не будет делать, так же, как и о том, что он будет делать— и напишите программое заявление. Эта часть обычно не слишком сложна, хотя иногда она может выявить невысказанные предположения и даже разногласия о природе проекта, что прекрасно: лучше решить их сейчас, чем позднее. Следующий шаг—упаковать проект для общественного употребления, и это, в основном, тяжелая работа в чистом виде. Что делает ее такой утомительной, так это то, что главным образом она состоит из организации и описания вещей, которые остальные уже знаютs— "остальные", то есть те, кто уже принимает участие в проекте. Таким образом, для людей, делающих эту работу, нет никакой немедленной отдачи. Они не нуждаются в файле README дающем краткий обзор проекта, ни в документе о дизайне или руководстве пользователя. Они не нуждаются в тщательно организованном дереве кода, соответствующем неофициальным, но широко распространенным стандартам распространения исходных кодов программного обеспечения. Каким бы способом ни был организован исходный код, он прекрасно им подходит, потому что они, в любом случае, уже привыкли к нему, и если код в принципе работает, они знают как его использовать. Для них даже не имеет значения, если фундаментальные архитектурные решения проекта остаются не описанными; с ними они также уже знакомы. Новички, с другой стороны, нуждаются в подобных вещах. К счастью, они не нуждаются во всем сразу. Вам не обязательно предоставлять каждый возможный документ, прежде чем проект станет доступен общественности. В идеальном мире, возможно, каждый новый проект с открытым кодом начинал бы жизнь с исчерпывающим документом о дизайне, полным руководством пользователя (со специальными отметками о запланированных, но еще не реализованных функциях), с красиво и переносимо упакованным кодом, способном выполняться на любой вычислительной платформе, и так далее. В действительности, забота обо всех этих белых пятнах была бы отнимающей недопустимо много времени, и, в любом случае, это такой тип работы, что можно обоснованно надеяться на то, что добровольцы помогут с ней, как только проект пойдет полным ходом. Что, однако, действительно необходимо, это достаточное количество усилий, вложенных во внешний вид, так, чтобы новички преодолели изначальное препятствие неизвестности. Думайте об этом как о первом шаге процесса загрузки, чтобы довести проект до минимальных затрат энергии на запуск. Я слышал, что этот порог называют энергией преодоления препятствий (хакстартом - hacktivation): количество энергии, которое должен потратить новичок, до того, как он начнет получать что-либо от проекта обратно. Чем ниже энергия преодоления препятствий, тем лучше. Ваша первая задача состоит в том, чтобы опустить энергию преодоления препятствий до такого уровня, который бы содействовал привлечению людей. Каждый из следующих подразделов описывает один важный аспект начала нового проекта. Они представлены примерно в том порядке, в котором новый посетитель столкнулся бы с ними, хотя, конечно, порядок в котором вы действительно их выполняете, может быть другим. Вы можете рассматривать их как контрольный перечень. Начиная проект, просто пробегайте список и удостоверьтесь, что каждый пункт проработан, или, по крайней мере, что вас устраивают потенциальные последствия, если вы что-то пропустили. Выберите хорошее название Поставьте себя на место того, кто только что услышал о вашем проекте, возможно, наткнулвшись на него, в поисках программного обеспечения, решающего некоторую задачу. Первое, с чем они столкнутся, это название проекта. Хорошее название автоматически не сделает ваш проект успешным, и плохое название не приговорит его— ну, действительно плохое имя, вероятно сможет это сделать, но мы начнем с предположения о том, что здесь никто активно не пытается провалить свой проект. Однако, плохое имя может замедлить понимание проекта, или потому что люди не отнесутся к нему серьезно, или потому что им будет трудно его запомнить. Хорошее название: Дает какое-то представление о том, что проект делает, или, хотя бы, четко указывает, с чем он связан, таким образом, что если кто-либо знает название и знает, что делает проект, имя очень легко вспоминается. Легко запоминается. Никуда не денешься от того факта, что английский стал языком интернета по умолчанию: "просто запомнить" означает "просто для того, кто может читать по английски, чтобы запомнить". Названия, которые являются игрой слов, зависящей от произношения носителя языка, например, будут непонятны многим читателям, для которых английский не является родным. Если игра слов особенно хороша и незабываема, она, может быть, все еще стоит того; только имейте в виду, что многие люди, видя название, не услышат его в своей голове так же, как услышит его носитель языка. Не такое же, как название какого-либо другого проекта, и не нарушает никакие торговые марки. Это просто хорошие манеры, так же как и хороший юридический ход. Вы же не хотите устроить путаницу в определениях. Достаточно сложно следить следить за всем, что уже доступно в сети и без того, чтобы разные вещи имели одно и тоже название. Ссылки, упомянутые ранее в полезны для полезны для нахождения проектов, уже имеющих то имя, о котором вы думали. Свободный поиск торговых марок доступен на и . Если возможно, доступно как доменное имя в .com, .net, и .org доменах вержнего уровня. Вам нужно выбрать один, вероятнее .org, и сделать его официальным сайтом проекта; два других должны перенаправлять туда и должны просто препятствовать тому, чтобы посторонние лица создавали путанницу с именами вокруг проекта. Даже если вы хотите держать проект на другом сайте (см. ), вы все еще можете зарегистрировать определенные домены для проекта и перенаправлять с них на сайт проекта. Это очень помогает пользователям иметь простой для запоминания URL-адрес. Разработайте четкое программное заявление Как только они нашли веб-сайт проекта, следующей вещью, которую будут искать люди, станет краткое описание, программное заявление, и таким образом они смогут решить (в течение 30 секунд), интересно ли им узнать о проекте подробнее. Заявление должно быть обязательно располагаться на главной странице, предпочтительно сразу под названием проекта. Программное заявление должно быть конкректным, устанавливающим четкие границы, и, прежде всего, коротким. Вот пример одного хорошего, от :
Для создания, в сообществе, лидирующего международного программного пакета для офиса, который будет работать на всех распространенных платформах и предоставлять доступ ко всем функциям и данным при помощи API (Application Programming Interface - интерфейс прикладного программирования), основанном на открытых компонентах и формате файлов, основанном на XML.
Всего в нескольких словах они указали на ключевые точки, широко основываясь на предыдущих знаниях читателя. Говоря "в сообществе", они указывают, что никакая корпорация не будет руководить разработкой; "международный" означает, что программное обеспечение позволит людям работать на разных языках и с различнимы региональными настройками; "все распространенные платформы" означает, что оно будет пренесено на Unix, Macintosh и Windows. Остальное говорит о том, что открытые интерфейсы и легко понимаемые форматы файлов являются важной частью намеченной цели. Они не выходят и не говорят прямо, что пытаются стать свободной альтернативой Microsoft Office, но многие люди, вероятно смогут прочитать это между строк. Хотя это программное заявление кажется слишком общим на первый взгляд, в действительности оно четко очерчивает круг задач: слова "пакет для офиса" означает предельно конкретную вещь для тех, кто хорошо знаком с подобным программным обеспечением. Опять, предполагаемые предыдущие знания читателя (в данном случае, вероятно, из MS Office) используются для сохранения краткости программного заявления. Природа программного заявления зависит частично от того, кто его пишет а не только от программного обеспечения, которое оно описывает. Например, для OpenOffice.org есть смысл использовать слова "в сообществе", потому что проект был начат, и все еще в значительной степени спонсируется компанией Sun Microsystems. Включая эти слова Sun указывает на свое внимание к тревогам о том, что она могла бы попытаться руководить процессом разработки. При обращении с подобными вещами, простая демонстрация понимания возможного возникновения проблемы, ведет по пути полного ухода от нее. С другой стороны, проекты, которые не спонсируются одной единственной корпорацией вероятно, не нуждаются в таком указании; в конце концов, разработка сообществом — норма, и таким образом, обычно не бывает никакой причины указывать на это, как на часть программного заявления. Подтвердите Что Проект Свободный Те, кто остается заинтересованными после прочтения программного заявленя, потом зохотят посмотреть подробнее, возможно некоторую документацию пользователя или разработчика, и в конечном счете, захотят что-нибудь скачать. Но, до всего этого, они должны быть уверенны, что это открытый исходный код. Главная страница должна однозначно ясно указывать на то, что это проект с открытым исходным кодом. Это может показаться очевидным, но вы были бы удивлены, насколько много проектов забывают это сделать. Я видел вебсайты проектов свободного программного обеспечения, где главная страница не только не говорила, под какой именно конкретной свободной лицензией распространяется программное обеспечение, но и вообще не указывала напрямую, что это свободное программное обеспечение. Иногда, решающий бит информации отправлялся в изгнание на страницу Загрузки, или на страницу для Разработчиков, или в любое другое место, которое требует лишнего щелчка мыши, чтобы до него добраться. В крайних случаях лицензия вообщен не была указана нигде на сайте — единственный способ найти ее состоял в том, чтобы загрузить программное обеспечение и посмотреть внутри. Не совершайте такой ошибки. Подобное упущение может привести к потере многих потенциальных разработчиков и пользователей. Укажите наверху, сразу под программным заявлением, что проект является "свободным программным обеспечением" или "программным обеспечением с открытым исходным кодом", и предоставьте точную лицензию. Быстрое руководство по выбору лицензии дается в далее в этой главе, а возможные проблемы с лицензиями подробно обсуждаются в . В этот момент наш гипотетический посетитель определил, вероятно в течение минуты или меньше, что он заинтересован потратить, скажем, еще по крайней мере пять минут, исследуя этот проект. Следующие разделы описывают, что он должен увидеть в эти пять минут. Функциональные возможности и Список требований Там должен быть краткий список функций, которые поддерживает программное обеспечение (если что-то еще не закончено, вы можете включить это в список, но поместить "запланировано" или "в разработке" рядом с ними), и тип вычислительной среды, требуеющейся для работы программного обеспечения. Подумайте о списке функций/требований как о чем-то, что вы предоставили кому-нибудь, попросившему краткое описание программного обеспечения. Это, часто, всего лишь логическое развитие программного заявления. Например, программное заявление могло бы сказать:
Создать полнотекстовый индексатор и поисковый механизм с богатым API, для использования программистами, предоставляющими службы поиска по большим коллекциям текстовых файлов.
Список функциональных возможностей и требований давал бы подробные объяснения, проясняя область применения, описанную в программном заявлении:
Функциональные возможности: Поиск в простом тексте, HTML и XML Поиск слова и предложения (запланировано) Нечеткое совпадение (запланировано) Инкрементное обновление индексов (запланировано) Индексирование удаленных веб-сайтов Требования: Python 2.2 или выше Достаточное дисковое пространство для хранения индексов (примерно в два раза больше изначального объема данных)
Обладая этой информацией, читатели могут быстро почувствовать, есть ли у этого программного обеспечения перспектива поработать у них, и могут рассмотреть возможность тоже поучавствовать в качестве разработчиков. Текущее состояние разработки Люди всегда хотят знать, как живет проект. Для новых проектов, они хотят знать разницу между обещанием и реальной действительностью. Для зрелых проектов, они хотят знать, как активно он поддерживается, как часто выпускаются новые версии, насколько быстро реагирует на сообщения об ошибках и т.д. Чтобы ответить на эти вопросы, вы должны предоставить страницу текущего состояния разработки, перечисляя краткосрочные цели проекта и его нужды (например, проект может искать разработчиков со специфическими знаниями). Страница может также предоставить хронологию предыдущих версий со списками функциональных особенностей, и, таким образом, посетители смогут понять, что значит для проекта "развитие" и как быстро он развивается согласно своему собственному определению. Не бойтесь выглядеть неготовым и не поддавайтесь искушению раздуть текущее состояние. Все знают, что программное обеспечение развивается постепенно; нет ничего постыдного в том, чтобы сказать "Это - альфа-версия программного обеспечения, содержащая известные ошибки. Оно выполняется, и работает, по крайней мере, время от времени, но используйте его на ваш собственный риск." Такое заявление не будет отпугивать тот тип разработчиков,которые нужны вам на этой стадии. Что касается пользователей, одна из самых плохих вещей, которые может сделать проект - это привлекть пользователей прежде, чем программное обеспечение для них будет готово. Очень трудно отделаться от приобретенной когда-то репутации неустойчивого или нестабильного проекта. Консерватизм окупается в долгосрочной перспективе; для программного обеспечения всегда лучше быть более стабильным, чем ожидает пользователь, чем менее, и приятные неожиданности способствуют лучшим отзывам. Альфа и Бета Термин alpha обычно означает первую выпущенную версию, с помощью которой пользователи могут выполнить реальную работу и у которой есть все заявленная функциональность, но и известные ошибки. Основной задачей альфа-версии программного обеспечения является получение отзывов, что бы разработчики узнали, над чем еще нужно поработать. Следующий этап, бета-версия, означает, что все серьезные ошибки в программном обеспечении исправлены, но не достаточно протестированы, чтобы удовлетворить условиям выпуска окончательной версии. Целью бета-версии программного обеспечения является или стать окончательной версией, при условии что ошибок не найдено, или предоставить программистам детальные отзывы, с тем, чтобы они быстро доработали программу до финальной версии. Загрузки Программное обеспечение должен быть доступно для загрузки в виде исходного кода в стандартных форматах. Когда проект только начинается, двоичные (исполняемые) файлы не являются необходимыми, кроме случаев, когда у программного обеспечения существуют настолько сложные требования к компиляции или зависимости, что просто заставить его заработать потребовало бы значительных усилий для большинства людей. (Но если дело обстоит именно так, то проекту в любом случае будет очень нелегко привлечь разработчиков!) Механизм распространения должен быть настолько же удобным, стандартным, и нетрудоемким насколько это возможно. Если бы вы пытались вылечить болезнь, то вы не распространяли бы лекарство таким образом, который требовал бы применения нестандартного размера шприца. Точно так же и программное обеспечение должно соответствовать стандартным методам сборки и установки; чем больше оно отклоняется от стандартов, тем больше потенциальные пользователи и разработчики будут сдаваться и уходить в замешательстве. Это кажется очевидным, но многие проекты не потрудились стандартизировать свои операции по установке почти до окончания игры, говоря самим себе, что они могут это сделать в любое время: "Мы уладим все это когда код будет близок к завершению." Чего они не понимают, так это того, что откладывая скучную работу по доведению до ума процедур сборки и установки, они фактически увеличивают время на завершение кода— потому что они отпугивают разработчиков, которые, в ином случае,дополнили бы код. Но самое коварство заключается в том, что они не знают , что они теряют всех этих разработчиков, потому что этот процесс - накопление непримечательных событий: кто-то посещает веб-сайт, загружает программное обеспечение, пытается его собрать, терпит неудачу, сдается и уходит. Узнает ли кто-нибудь когда-нибудь, что это случилось, кроме самого этого человека? Никто работающий над проектом не поймет, что чей-то интерес и добрая воля были тихо растрачены. Скучная работа, хорошо оправдывающая себя, всегда должна быть выполнена на ранней стадии, а значительное понижение понятийного барьера при помощи хорошей подготовки пакетов очень хорошо себя оправдывает. Когда вы выпускаете пакет, доступный для скачивания, жизненно важно присвоить уникальный номер версиии этому выпуску, чтобы люди могли сравнить два любых пакета и узнать какой из них заменяет другой. Подробное обсуждение нумерования версий можно найти в , а подробности стандартизации процессов сборки и установки в , оба в . Контроль версий и доступ к системе учета ошибок. Скачивание исходных пакетов прекрасно подходит для тех, кто хочет просто установить и использовать программное обеспечение, но этого недостаточно для тех, кто хочет его отладить или добавить новые возможности. Ночные версии кода могут помочь, но они все еще не являются достаточно разделенными на модули для бурно развивающегося сообщества разработчиков. Людям нужен доступ к последним версиям кода в реальном времени, и средством обеспечения такого доступа является использование системы управления версиями. Наличие анонимно доступных исходных кодов с контролируемыми версиями, это указание— и пользователям и разработчикам— на то, что проект позаботился о том, чтобы дать людям все что им нужно для учестия в проекте. Если вы не можете предложить систему управления версиями сразу же, то сделайте пометку, указывающую на то, что вы намерены вскоре ее настроить. Инфраструктура управления версиями подробно обсуждается в в . Тоже самое каксается и проектной системы отслеживания ошибок. Важность системы отслеживания ошибок заключается не только в ее полезности для разработчиков, но и в том, что она значит для тех, кто наблюдает за проектом. Для многих людей, доступная база данных об ошибках является лучшим показателем того, что к проекту можно относиться серьезно. Более того, чем большее количество ошибок содержится в базе данных, тем лучше выглядит проект. Это может показаться парадоксальным, но вспомните, что количество зарегистрированных ошибок зависит от трех факторов: абсолютного числа ошибок, содержащихся в программном обеспечении, числа пользователей, работающих с программным обеспечением и удобства, с которым эти пользователи могут регистрировать эти ошибки. Из этих трех факторов два последних более значимы, чем первый. Любое программное обеспечение достаточного объема и сложности, содержит в высшей степени случайное число ошибок, ожидающих, чтобы их нашли. Настоящий вопрос в том, насколько хорошо проект регистрирует и выставляет приоритеты этим ошибкам? Проект с большой и хорошо поддерживаемой базой данных об ошибках (это значит, что реакция на ошибки своевременна, дублирующиеся ошибки сведены к одной и т.д.), таким образом, производит лучшее впечатление, чем проект совсем без базы данных об ошибках и с почти пустой базой данных. Конечно, если ваш проект только начинается, то база данных об ошибках будет содержать очень мало ошибок, и вы мало что можете с этим поделать. Но если страница статуса подчеркивает молодость проекта, и если люди, смотрящие на базу данных об ошибках, могут увидеть, что большинство записей было сделано недавно, они смогут на этом основании экстраполировать, что у проекта уже есть соответсвующая норма записей, и они не будут чрезмерно встревожены малым абсолютным количеством зарегистрированных ошибок. Заметьте, что системы учета ошибок используются для слежения не только за ошибками в программном обеспечении, но и для заявок на расширение функциональных возможностей, изменений в документации, ожидающих реализации заданий и многого другого. Подробности работы с системой учета ошибок описаны в в , так что здесь я не буду рассматривать ее здесь. С точки зрения представления проекта важно просто иметь систему слежения за ошибками и убедиться в том, что факт ее наличия отражен на главной странице проекта. Каналы связи Посетители обычно хотят знать, как добраться до людей, связанных с проектом. Предоставьте адреса списков рассылки, дискуссионных групп, и каналов IRC, и любых других форумов, где можно добраться до других людей, связанных с этим программным обеспечением. Поясните, что вы и другие авторы проекта подписаны на эти списки рассылки, таким образом, чтобы люди видели, что есть обратной связи, которая дойдет до разработчиков. Ваше присутствие в списках не подразумевает стремления ответить на все вопросы или реализовать все заявки на расширение функциональных возможностей. В конечном счете, большинство пользователей в любом случае никогда не присоединится к форумам, но они будут спокойны, зная, что они могут, если когда-нибудь им это понадобится. На ранних стадиях проекта, нет никакой необходимости иметь отдельные форумы для пользователей и разработчиков. Гораздо лучше сделать так, чтобы все люди, связанные с программным обеспечением разговаривали вместе, в одной "комнате". Среди тех, кто с ранних стадий принимает участия в проекте, различия между разработчиком и пользователем часто расплывчато, до тех пор, пока не настанет время их различать; соотношение разработчиков к пользователям обычно намного выше на ранних стадиях проекта, чем на поздних. Пока вы не можете быть уверены, что каждый заинтересовавшийся продуктом на ранней стадии - программист, который хочет залезть внутрь программы, вы можете предположить, что они по крайней мере интересуются последующими обсуждениями хода разработки и пониманием направлений развития проекта. Так как эта глава только о том, как начать проект, то достаточно сказать, что эти форумы для общения должны существовать. Позже, в в , мы рассмотрим где и как устанавливать такие форумы, случаи, в которых они могут нуждаться в модерировании и другом обслуживании, и как отделить форумы для разработчиков от форумов для пользователей, когда придет время, избежав создания непреодолимой пропасти. Руководство разработчика Если кто-то рассматривает возможность поучавствовать в проекте, он будет искать руководство разработчика. Руководство разработчика является не столько техническим, сколько социальным: оно объясняет, как разработчики взаимодействуют с друг другом и с пользователями, и,в конечном счете, как все делать. Эта тема подробно рассматривается в в , но основнымми элементами руководства разработчика являются: указатели на форумы для взаимодействия с другими разработчиками инструкции о том, как сообщать об ошибках и присылать исправления некоторые советы по тому, как обычно ведется разработка — является ли проект добровольным диктаторством, демократией, или чем-нибудь другим Между прочим, "диктатура" не несет никакого отрицательного смыслового оттенка. Это совершенно нормально работать в режиме тирании, где у одного определенного разработчика есть право вето на любые изменения. Много успешных проектов работают в таком режиме. Важная вещь - то, что проект идет этим путем и говорит об этом. Тирания, стремящаяся казаться демократией, отпугнет людей; тирания, которая говорит, что это - тирания, будет чувствовать себя прекрасно, пока тиран компетентен и ему доверяют. Смотрите как пример очень досконального руководства разработчика или как более свободного руководства, которое больше сосредоточено на направлении и духе участия, и меньше на технических тонкостях. Проблема предоставления программисту введения в программный проект отдельно обсуждается в далее в жтой главе. Документация Документация жизненно необходима. Должно быть хоть что-нибудь, что можно прочитать, даже если оно является элементарным и неполным. Это попадает прямо в категорию "тяжелая работа", упомянутую ранее, и часто является первой областью, в которой погибают новые проекты с открытым кодом. Выработка программного заявления и списока функций, выбор лицензии, обобщение статуса разработки — все это относительно небольшие задачи, которые могут быть окончательно завершены, и к которым нет нужды возвращаться, завершив их один раз. Документация, с другой стороны, в действительности никогда не может быть закончена, что может являетьс одной из причин того, что люди иногда насовсем откладывают эту задачу. Самая коварная вещь, это то, что польза документации для тех, кто ее пишет, обратно пропорциональна пользе для тех, кто будет ее читать. Самая важная документация для начинающих пользователей - это основы: как быстро установить программу, краткий обзор того, как она работает, возможно, некоторое руководство по выполнению основных операций. Все это как раз является теми вещами, которые авторы документации знают слишком хорошо— настолько хорошо, что для них может быть сложно увидеть эти вещи с точки зрения читателя, и обстоятельно объяснить те шаги, которые (для авторов) кажутся настолько очевидными, что не достойны даже упоминания. Нет никакого волшебного решения этой проблемы. Кто-то просто должен сесть и написать текст, а затем следовать ему, как типичный новый пользователь, чтобы проверить его качество. Используйте простой, легкий в редактировании формат, такой как HTML, простой текст, Texinfo, или какой-то вариант XML— что-нибудь, что удобно для легковесных, быстрых, моментальных исправлений. Это нужно не только для того, чтобы исключить любые лишние трудности, которые могли бы препятствовать первоначальным авторам вносить последующие изменения, но также и для тех, кто присоединяется к проекту позже и хочет работать над документацией. Один способ гарантировать наличие начальной документации по основным моментам, это заранее ограничить область ее применения. Таким образом, ее написание, по крайней мере, не будет видеться как бесконечная задача. Хорошее эмпирическое правило заключается в том, что она должна соответствовать следующим минимальным требованиям: Четко объясните читателям какой уровень технических знаний от них ожидается. Ясно и точно опишите как установить программну, и где-нибудь в начале документа, укажите пользователю, как выполнить своего рода диагностический тест или простую операцию, чтобы убедиться, что они все настроили правильно. Документация по запуску в некоторой степени является более важной, чем документация по использованию. Чем больше усилий кто-нибудь затратил на установку и начало работы с программой, тем настойчивей он будет выяснять, как работают более сложные функциональные возможности, которые задокументированны не так хорошо. Когда люди отказываются, от программы, они отказываются на ранних этапах; поэтому, самые ранние стадии, такие как установка, больше всего нуждаются в поддержке. Предоставьте в стиле обучающей методики пример того, как выполнить одну частоиспользуемую операцию. Очевидно, что множество примеров для множества задач было бы еще лучше, но если время ограниченно, выберите одну задачу и тщательно пройдитесь по ней. Как только кто-нибудь увидит, что программа может быть использованна для одного действия, они начнут изучать, что еще она может делать сама по себе—и, если вам повезет, станут дополнять документацию сами. Что приводит нас к следующему пункту... Пометьте те области, где документация, как вы знаете, незакончена. Показывая читателям, что вы беспокоитесь о ее неточностях, вы приравниваете себя к их точке зрения. Ваше сопереживание убеждает их, что они не столкнуться с сопротивлением, убеждая проект в важности какого-либо аспекта. Эти пометки не должны представлять обещания заполнить недостающие части к какой-то указанной дате — вполне законно считать их открытыми запросами о помощи к добровольцам. Последний пункт, на самом деле, имеет более широкое значение, и может быть применен ко всему проекту, а не только к документации. Точный учет известных недостатков, это норма в мире открытого исходного кода. Вам не нужно преувеличивать недостатки проекта, просто указать на них, тщательно и беспристрастно, когда этого требует контекст (или в документации, или в базе данных об ошибках, или в обсуждении в списке рассылки). Никто не будет рассматривать это ни как пораженческое настроение со стороны проекта, ни как стремление, решить проблему к определенной дате, если только проект явно не заявит о подобной цели. Так как каждый, кто использует программное обеспечение, сам по себе обнаружит неточности, для них намного лучше быть психологически подготовленными— тогда будет похоже на то, что проект обладает точным знанием того, как он себя чувствует. Ведение FAQ FAQ (документ "Часто задаваемые вопросы") может быть одной из лучших инвестиций, которую осуществляет проект, в терминах обратной отдачи при обучении. Часто задаваемые вопросы очень точно настроены на те вопросы, которые фактически задают пользователи и разработчики — в противоположность вопросам, которые как вы ожидали они зададут — и поэтому, хорошо поддерживаемый FAQ предназначен давать тем, кто его читает, именно то, что они ищут. FAQ часто является самым первым местом, куда заглядывает пользователи, когда они сталкиваются с проблемой, часто даже предпочитая его официальному руководству, и, вероятно, это то документ в вашем проекте, на который вероятнее всего есть ссылки с других сайтов. К сожалению, вы не можете создать FAQ с самого начала проекта. Хорошие FAQ не пишутся, они вырастают. Они по определению являются документами реагирующими, развивающимися со временем, в ответ на каждодневное использование людьми программного обеспечения. Из-зи того, что невозможно точно предвидеть вопросы, которые люди будут задавать, невозможно сесть и написать полезный FAQ с нуля. Таким образом, не растрачивайте впустую свое время, пытаясь это сделать. Вы можете, однако, найти полезным, создать почти пустой шаблон FAQ, так, чтобы у людей было очевидное место, куда добавлять вопросы и ответы, после того как проект заработает. На этой стадии, самым важным свойством является не полнота, а соответствие: если к FAQ легко что-то добавить, люди будут добавлять. (Правильная поддержка FAQ является нетривиальной и интригующей задачей, и подробнее обсуждается в в .) Доступность документации Документация должна быть доступна в двух местах: в интернете (напрямую с сайта), и в загружаемом пакете программного обеспечения (см. в ). Она должна быть в интернете в виде просматриваемого списка, потому что люди часто читают документацию до того как скачивают программу первый раз, рассматривая ее, как подсказку, чтобы решить стоит ли ее загружать вообще. Но она также должна сопровождать программу, по принципу того, что загружаемый пакет должен предоставлять (т.е. делать локально доступным) все что нужно человеку для использования пакета. Для документации в интернете, убедитесь, что присутствует ссылка, которая ведет к полной документации на одной HTML странице (сделайте пометку "единая" или "все-в-одном" или "одна большая страница" рядом со ссылкой, чтобы люди знали, что загрузка может занять некоторое время). Это полезно, потому что люди часто хотят поискать определенное слово или фразу по всей документации. В общем, они уже знают, что они ищут; они просто не помнят в какой секции это оно находится. Для таких людей, не ничего более разочаровывающего, чем увидеть одну HTML страницу для оглавления, затем другую для вступления, затем другую для для инструкций по установке и т.д. Когда страницы разбиты таким образом, функция поиска в их браузере бесполезна. Стиль раздельных страниц полезен для тех, кто знает, какая секция им нужна или тем, кто хочет прочитать последовательно всю документацию от начала до конца. Но это не самый распространенный способ, которым используют документацию. Гораздо чаще, кто-либо, знакомый с основами программы возвращается, чтобы поискать отпределенное слово или фразу. Отказать им в предоставлении единого, доступного для поиска документа, сделает их жизнь только тяжелее. Документация разработчика Документация разработчика пишется для того, чтобы помочь программистам понять код, и чтобы они могли исправлять и расширять его. Она несколько отличается от руководства разработчика, обсуждавшегося ранее, которое более социальное, чем техническое. Руководство разработчика говорит программистам, как взаимодействовать друг с другом; документация разработчика говорит как взаимодействовать с самим кодом. Оба вида документов часто складываются вместе в один документ для удобства (как, например, в указанном ранее), но это не обязательно. Хотя документация разработчика может быть очень полезной, нет никакой причины задерживать выпуск продукта, чтобы ее доделать. До тех пор, пока изначальные авторы документации могут (и хотят) отвечать на вопросы о коде, этого достаточно для начала. Фактически, необходимость отвечать на те же самые вопросы снова и снова является самой частой причиной для написания документации. Но даже до того, как она написана, определенным участникам проекта удается пробираться через код. Сила, заставляющая людей тратить время, изучая основы кода, это то, что код делает для них что-то полезное. Если у людей есть такая вера, они найдут время чтобы разобраться; если у них этой веры нет, никакое количество документации для разработчика их не привлечет и не удержит. Таким образом, если у вас есть время, чтобы написать документацию только для одной целевой аудитории, напишите ее для пользователей. Вся пользовательская документация - в действительности - также является и документацией разработчика; любой программист, который собирается работать над определенной частью программы, должен знать с и то, как его использовать. Позже, когда вы увидите, что программисты задают одни и те же вопросы снова и снова, выделите время, чтобы написать отдельную документацию специально для них. Некоторые проекты используют wiki как начальную документацию, или даже как основную документацию. По моему опыту, в действительности это работает только если wiki активно редактируется несколькими людьми, которые договорились, как документация должна быть организована и какой "голос" должен у нее быть. Смотрите в подробнее. Примеры выходных данных и снимки экранов Если проект включает в себя графический интерфейс пользователя или если он выдает графические или любые другие видимые данные, разместите несколько примеров на сайте проекта. В случае интерфейса, это снимки экрана; для выходных данных это могут быть снимки экрана или просто файлы. Все они работают на человеческое желание получения немедленного вознаграждения: единственный снимок экрана может быть более убедителен, чем множество абзацев описания и болтовни в листе рассылки, потому что снимок экрана является неопровержимым доказательством того, что программа работает. В ней может быть много ошибок, ее может быть трудно установить, она може быть не полностью документирована, но снимки экрана все еще являются доказательством того, что если кто-либо приложит достаточно усилий, то он сможет заставить ее работать. Снимки экрана Так как снимки экрана могут вас обескуражить, пока вы на самом деле не сделаете несколько штук, вот основные советы, как их делать. Используя Gimp (), откройте File->Acquire->Screenshot, выберите Single Window или Whole Screen, затем щелкните OK. Теперь, следующий щелчок мыши сделает снимок окна или экрана, по которому вы щелкнули в виде картинки в Gimp. Обрежте и измените размер картинки по необходимости, используя инструкции в . Существует множество других вещей, которые вы можете разместить на сайте проекта, если у вас есть время, или если по той или иной причине они являются достаточно существенными: страница новостей, страница хронологии проекта, страница ссылок по теме, возможность поиска по сайту, ссылка для добровольных пожертвований, и т.д. Ничего из этого не является необходимым в самом начале, но помните об этом для будущего. Постоянный хостинг Существует несколько сайтов, которые предоставляют бесплатный хостинг и инфраструктуру для проектов с открытым кодом: место для сайта, система контроля версий, система учета ошибок, место для загрузки файлов, чат, регулярные резервные копии, и т.д. Детали изменяются от сайта к сайту, но самый основной набор услуг предлагаются на всех. При использовании одного из этих сайтов вы бесплатно получаете довольно многое; то, что вы отдаете - как очевидно - это всесторонний контроль пользователя. Службы хостинга решает, какое программное обеспечение размещено на сайте и может управлять или, по крайней мере, влиять на внешний вид и наполнение веб-страниц проекта. Смотрите в где более детально обсуждаутся преимущества и недостатки постоянного хостинга и приводится список сайтов, которые его предлагают. Выбор лицензии и ее применение Этот раздел задуман как очень общее, очень поверхностное руководство по выбору лицензии. Прочитайте для детального понимания законной силы различных лицензий, и того, как выбранная вами лицензия может затронуть возможности людей совместить ваше программное обеспечение с другими свободными программами. Существует огромное множество лицензий на свободное программное обеспечение на ваш выбор. Большинство из них нет необходимости здесь рассматривать, так как они написаны для удовлетворения определенных юридических нужд некоторых корпораций или людей, и будут неподходящими для вашего проекта. Мы ограничимся только самыми частоиспользуемыми лицензиями; в большинстве случаев вы захотите выбрать одну из них. Лицензии "Делай что угодно" Если вы спокойно относитесь к тому, что код вашего проекта потенциально будет использован в проприетарном программном обеспечении, тогда используйте лицензию семействаMIT/X. Она самая простая из нескольких минималистических лицензий, которая делает чуть больше, чем просто утверждает номинальное авторское право (в действительности не запрещая копирования) и указывает на то, что код поставляется без гарантии. Смотрите для более подробной информации. GPL Если вы не хотите, чтобы ваш код был использован в проприетарных программах, используйте Открытую лицензию GNU. (). Открытая лицензия (GPL), возможно, является самой признанной в мире свободной лицензией на программы. Это само по себе большое преимущество, так как многие потенциальные пользователи и участники будут с ней знакомы, и, таким образом, не будут тратить дополнительное время на чтение и понимание вашей лицензии. Смотрите в для подробного описания. Если пользователи работают с вашим кодом в первую очередь через сеть—то есть программа является частью сетевой службы — тогда рассмотрите возможность использования GNU Affero GPLвместо GNU. Смотрите в для подробного описания. Как применять лицензию к вашему программному обеспечению Как только вы выбрали лицензию, вы должны заявить об этом на главной странице сайта проекта. Здень не нужно приводить полный текст лицензии; дайте только название лицензии и привяжите к нему ссылку на полный текст лицензии на другой странице. Это укажет людям на то, под каким типом лицензии вы намерены выпустить программное обеспечение, но этого не достаточно для соблюдения законных прав. Для этого, сама программа должна содержать лицензию. Обычным способом это сделать является помещение полного текста лицензии в файл с названием COPYING (или LICENSE), и наличие маленькой метки в начале каждого файла исходного кода, указывающей на дату, владельца прав и лицензию, и информирующего, где найти полный текст лицензии. Существует множество вариантов этого шаблона, так что здесь мы рассмотрим только один пример. Открытая лицензия GNU предписывает поместить следующую метку в начале каждого файла исходного кода: Copyright (C) <год> <имя автора> This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program. If not, see <http://www.gnu.org/licenses/> Здесь специально не указывается, что копия лицензии, которую вы получили вместе с программой находится в файле COPYING, но обычно ее помещают именно туда. (Вы можете изменить приведенную выше метку, чтобы прямо указать на это.) Этот шаблон, также предоставляет географический адрес, по которому можно запросить копию лицензии. Другой часто используемый способ заключается в размещении на веб-странице ссылки на лицензию. Решите сами и ссылайтесь на то место, которое вы считаете самым надежным хранилищем копии лицензии, и которое может находиться на сайте вашего проекта. В общем, метка, которую вы помещаете в каждый файл с исходным кодом, не обязательно должна выглядеть точно также как указанная выше, пока она начинается с той же информации об обладателе авторского права и даты, указывает имя лицензии и четко определяет, где можно увидеть полную лицензию. Задавая тон Пока мы описали одноразовые задачи, которые вы решаете во время подготовки проекта: выбор лицензии, размещение начального вебсайта, и т.д. Но самые важные аспекты начинания нового проекта являются динамическими. Выбор адреса списка рассылки прост; обеспечение того, что разговоры в листе рассылки остаются в границах темы и продуктивны является совсем другим вопросом. Если проект становится открытым после нескольких лет закрытой, внутренней разработки, его процессы разработки изменятся и вам будет нужно подготовить уже существующих разработчиков к этому изменению. Первые шаги — самые сложные, потому что еще не определены предварительные условия и ожидаемое в будущем поведение. Стабильность внутри проекта создается не с помощью формальных соглашений, а с помощью принятой всеми и трудноопределимой коллективной мудрости, которая формируется со временем. Часто встречаются и записанные правила, но они являются, в сущности, дистилляцией нематериальных, неизменно присутствующих соглашений, которые направляют проект на самом деле. Записанные правила не столько определяют культуру проекта, сколько описывают ее, и даже описывают только приблизительно. Существует несколько причин того, что работа строится именно так. Рост и высокая текучесть кадров не столь разрушительны для накопления поведенческих норм, как можно было бы подумать. Пока изменения не происходят слишком быстро, для вновь прибывших есть время узнать, как все сделано, и после того, как они узнают, они сами будут помогать укреплению этого стиля. Посмотрите, как детские песни переживают столетия. И сегодня есть дети, напевающие примерно те же самые рифмы, что и дети сотни лет назад, даже при том, что сейчас нет в живых ни одного ребенка, жившего тогда. Младшие дети слышат песни, спетые старшими, и когда они становятся старшими, они в свою очередь, споют их перед другими младшими. Конечно, дети не участвуют в сознательной программе по передаче, но причина, по которой песни выживают, тем не менее, в том, что они передаются регулярно и многократно. Временные рамки проектов свободного программного обеспечения не могут быть измерены столетиями (мы еще об этом не знаем), но движущие силы передачи во многом аналогичны. Степень текучести кадров, однако, выше и должна быть компенсирована за счет более активных и тщательно спланированных усилий по передаче. Это усилие поддерживается тем фактом, что, обычно, люди склонны к ожиданию и поиску социальных норм. Так уж устроены люди. В любой группе, объединенной общим делом, люди, присоединяющиеся к ней, инстинктивно ищут модели поведения, которые сделают их частью группы. Целью создания прецедентов в ранний период является установление этих "внутри-групповых" моделей поведения, которые будут полезны для проекта; установленные однажды, они будут в значительной степени жить сами по себе. Далее следует несколько конкретных примеров того, что вы можете сделать, чтобы создать хорошие прецеденты. Они не представляют собой исчерпывающий список, это просто иллюстрация мысли о том, что установление духа сотрудничества на ранней стадии чрезвычайно помогает проекту. Физически, каждый разработчик может работать в комнате сам по себе в одиночестве, но вы можете многое сделать, чтобы дать им почувствовать, будто все они работают вместе в одной комнате. Чем больше они будут себя так чувствовать, тем больше времени они захотят посвятить проекту. Я выбрал именно эти примеры, потому что они всплыли на проекте Subversion (), в котором я учавствовал и который наблюдал с самого начала. Но они верны не только для Subversion; подобные ситуации возникнут на большинстве открытых проектов, и они должны быть рассмотрены как возможность встать с той ноги. Избегайте закрытых обсуждений Даже после того, как вы сделали проект общим, вы и другие основатели, будете частенько хотеть, разрешить трудные вопросы в процессе закрытого обсуждения в своем внутреннем круге. Это особенно верно в начале проекта, когда нужно принять очень много важных решений, и, обычно, мало добровольцев достаточно квалифицированы, чтобы их принять. Все очевидные недостатки обсуждения с помощью публичного листа рассылки будут ясно вырисовываться перед вами: задержка,как неотъемлемая часть разговоров по электронной почте, потребность оставить достаточное количество времени для согласования, споры с наивными добровольцами, которые думают, что понимают все проблемы, но на самом деле не понимают (такие есть в каждом проекте; иногда это лучшие программисты будущего года, иногда они остаются наивными навсегда), кто-то, кто не может понять, почему вы хотите решить только задачу X, в то время как очевидно, что это подмножество большей проблемы Y и так далее. Искушение принять решения за закрытыми дверьми и представить их как faits accomplis (свершившиеся факты) , или, по крайней мере, как прямые рекомендации объединенного и влиятельного большинства, вместо всего этого, будет очень большим. Не делайте этого Какими медленными и тягостными ни были публичные обсуждения, они почти всегда предпочтительнее в конечном итоге. Принятие важных решений частным образом похоже на распыление репеллента от участников на вашем проекте. Никакой серьезный доброволец не захотел бы долгое время слоняться поблизости в окружении, где тайный совет принимает все важные решения. Кроме того, у общественного обсуждения есть благотворные побочные эффекты, которые распространятся далеко за рамки любого эфемерного технического вопроса, который был спорным моментом: Обсуждение поможет познакомить с системой и обучить новых разработчиков. Вы никогда не знаете, сколько глаз следит за беседой; даже если большая часть людей не принимают непосредственного участия, многие могут просто следить, собирая информацию о программе. Обсуждение научит вас искусству объяснения технических вопросов людям, не так хорошо разбирающимся в программе, как вы. Этот навык требует тренировки, а вы не сможете тренироваться, разговаривая с людьми, которые уже знают то, что знаете вы. Дискуссия и ее результаты будут всегда доступны в публичных архивах, позволяя в последующих обсуждениях не ходить по своим собсвенным следам. Смотрите в . Наконец, существует вероятность того, что кто-то из списка сможет сделать ценный вклад в беседу, выступив с идеей, которую вы никогда и не ожидали. Невозможно предсказать, насколько такое событие вероятно; это зависит лишь от сложности кода и требуемой степени специализации. Но если история из жизни может быть дозволена в качестве доказательства, я поставил бы на то, что это более вероятно, чем можно было бы интуитивно ожидать. В проекте Subversion мы (основатели) полагали, что оказались перед большим и сложным набором проблем, о которых мы интенсивно размышляли в течение нескольких месяцев, и мы искренне сомневались, что кто-либо из недавно созданного списка рассылки, способен реально посодействовать в обсуждении. Таким образом, мы выбрали ленивый путь и стали пинать туда-сюда некоторые технические решения в частной переписке, до того момента, когда ответсвенный за проект Мы еще не дошли до раздела о доверии, но чтобы показать на практике то, что я буду в дальнейшем проповедовать: имя ответсвенного было Брайен Бехлендорф, и именно он указал на общую значимость нахождения всех обсуждений в общем доступе, если только не возникнет особой нужды в частном разговоре.понял куда дует ветер и попросил перенести дискуссию в общий доступ. Прикрыв глаза мы это сделали — и были ошеломлены числом проницательных комментариев и предложений, которые быстро последовали. Во многих случаях люди предлагали решения, которые даже не приходили нам в голову. Оказалось, что в этом списке нашлось некоторое количество очень умных людей; они лишь ждали нужной наживки. Да, в действительности последующие обсуждения заняли больше времени, чем они заняли бы, если бы мы оставили дискуссию закрытой, но они были настолько более производительными, что это стоило дополнительного времени. Не углубляясь в обобщения, на которые можно махнуть рукой, типа "группа всегда умнее индивида" (все мы встречали достаточно групп, чтобы знать лучше), нужно признать, что есть определенные виды деятельности, в которых группы оказываются на высоте. Основательная экспертная оценка кода является одной из них; высказывание большого количества идей в короткое время - другой. Качество идей, естественно, зависит от качества думающего, взявшегося за них, но вы не узнаете, что за мыслители находятся рядом, до тех пор пока не стимулируете их сложной задачей. Естественно, есть некоторые вопросы, которые должны обсуждаться конфиденциально; на протяжении этой книги мы увидим такие примеры. Но основополагающим принципом всегда должно быть:Если нет причин для того, чтобы вопрос обсуждался в частном порядке, он должен обсуждаться открыто. Чтобы поставить дело именно так, необходимо над этим работать. Недостаточно просто проверять, что все Ваши собственные письма идут в общий список рассылки. Вам также нужно перенести в этот список рассылки разговоры других людей, для которых конфиденциальность является излишней. Если кто-то пытается начать закрытое обсуждение, и нет никакой причины для его закрытости, то именно вы ответственны за немедленное открытие соответствующего мета-обсуждение. Даже не комментируйте начальную тему, пока вы или успешно не направили разговор в общесвенно доступное русло, или не пришли к выводу, что конфиденциальность действительно была необходима. Если вы последовательно будете поступать именно так, то люди уловят смысл довольно быстро и начнут использовать общественные форумы по умолчанию. Пресекайте грубость на корню С самого начала существования вашего проекта в качестве общедоступного, вы должны поддерживать политику нулевого допуска в отношении грубого или оскорбительного поведения на его форумах. Нулевой допуск не означает технического принуждения как такового. Вам не нужно удалять людей из списка адресатов рассылки, когда они грубят другим подписчикам, или лишать их возможности вносить свой код, потому что они пишут уничижительные комментарии. (В теории Вам, возможно, в конечном счете придется прибегнуть к подобным действиям, но только после того, как любые другие способы не дадут результата— чего не может быть в начале проекта по определению). Нулевой допуск просто означает, что вы никогда не позволяете плохому поведению проскользнуть незамеченным. Например, когда кто-то размещает комментарий технического плана вперемешку с ad hominem высказыванием в адрес какого-то другого разработчика на проекте, ваш ответ обязательно должен быть в первую очередь, направлен на высказывания ad hominem как на отдельную проблему саму по себе, и только затем переходить к технической части. К сожалению очень легко, и это слишком типично, что конструктивные обсуждения скатываются в перебранки. В электронной почте люди говорят то, что они никогда не сказали бы лицом к лицу. Темы дискуссий только усиливают этот эффект: в технических вопросах люди часто подразумевают, что есть один единственный правильный ответ на большинство вопросов, и несоответствие этому ответу может быть объяснено лишь незнанием или глупостью. От определения чьего-то технического решения как глупого, недалеко и до определения как глупого и самого человека. Фактически, в большинстве случаев, сложно определить, в какой момент технические споры уходят в сторону и начинается нападение на личность, что и есть та причина, по которой решительные ответы или наказания не являются хорошей мыслью. Вместо этого, когда Вы думаете, что видите, как это происходит, пошлите сообщение, которое подчеркивает важность сохранения дружественного тона в обсуждении, не обвиняя никого в том, что он преднамеренно язвит. Подобные сообщения "Хороших Полицейских" в действительности имеют неудачную тенденцию звучать как речь воспитателя детского сада, читающего классу лекции о хорошем поведении:
Сначала,пожалуйста, давайте откажемся от (возможных) комментариев связанных с личностью; например, называть разаработанную Джеем архитектуру слоя безопасности "наивной и не отвечающей основным принципам компьютерной безопасности". Это может быть справедливо или нет, но в любом случае, такое обсуждение невозвомжно. Джей предложил свое решение по доброй воле. Если у него есть недостатки, укажите на них и мы их исправим или спроектируем новую архитектуру. Я уверен что Мей не хотел оскорбить лично Джея, но высказывание было неудачным, а мы пытаемся вести здесь конструктивный диалог. Теперь, собственно о предложении. Я думаю Мэй был прав говоря, что...
Как бы искусственно не звучали такие ответыв, они дают заметный результат. Если Вы последовательно искореняете плохое поведение, но не требуете извинений или осознания ошибки от виновной стороны, то вы оставляете людям возможность остыть и показать их лучшую сторону, ведя себя более прилично в следующий раз—и они сделают именно так. Один из секретов успешности таких действий—никогда не делать это дополнительное обсуждение основной темой. Оно должно всегда быть несколько в стороне, вроде краткого предисловия к основной части вашего ответа. Укажите мимоходом, что "мы здесь так не делаем", но затем переходите к настоящему существу вопроса, так, чтобы вы дали людям конкретную тему, на которую надо ответить. Если кто-то возражает, что они не заслуживали вашего упрека, просто отказывайтесь быть вовлеченными в спор на эту тему. Также не отвечайте (если вы думаете, что они только спускают пар и не требуют ответа), или скажите, что вы сожалеете о том, что, наверное, слишком остро реагировали и что трудно различить нюансы в электронной почте, а затем возвращайтесь к основной теме. Никогда, никогда не настаивайте на признании кем-то вины, перед сообществом или перед самим собой, в том, что они вели себя неправильно. Если они по собственной воле захотят принести извинения, это великолепно, но требование такого признания только вызовет негодование. Основная задача заключается в установлении правил хорошего тона в качестве "внутригруппового" поведения. Это поможет проекту, так как разработчики могут уйти из проекта (даже из проектов, которые им нравятся и которые они хотят поддержать) из-за язвительных писем. Вы можете даже не узнать о том, что они ушли; кто-то может просто следить за рассылкой, видеть что для участия в проекте нужно быть достаточно толстокожим, и принять решение вообще не связываться с этим проектом. Поддерживать доброжелательность на форуме—это стратегия для длительного выживания и ее легко придерживаться, пока проект все еще достаточно мал. Как только это станет частью проектной культуры, вам больне не нужно будет оставаться единственным человеком, поддерживающим ее. Она будет соблюдаться всеми. Практикуйте Открытое Рецензирование Кода Одним из лучших способов развития продуктивного сообщества разработчиков является поощрение того, что бы люди смотрели на код друг друга. Для того, чтобы это проиходило эффективно, необходима некоторая техническая инфраструктура—в частности уведомления о внесении изменений должны быть включены; подробнее в . Эффект уведомлений об изменениях в том, что каждый раз, когда кто-нибудь вносит изменения в исходный код, отсылается письмо, показывающее сообщение, заносимое в журнал, и список отличий данной версии от предыдущей (см. , в ). Рецензирование кода это просмотр уведомлений о внесении изменений после их поступления, с целью поиска ошибок и возможных улучшений.Именно так обычно и происходит рецензирование кода в проектах с открытым исходным кодом любого размера. В более организованных проектах, "рецензирование кода" так же может означать несколько человек, сидящих вместе и просматривающих распечатки исходного кода в поисках конкретных проблем или шаблонов. Рецензирование кода служит нескольким целям одновременно. Это самый очевидный пример экспертной оценки в мире открытого ПО, что напрямую помогает поддерживать качество программного обеспечения. Каждая ошибка, которая содержится в программе, попадает туда, будучи добавленной и не выявленной; однако, чем больше глаз следит за добавлениями, тем меньше ошибок будет в конечном продукте. Но рецензирование кода служит и косвенной цели: оно доказывает людям, что то что они делаю имеет значение, так как очевидно, что никто не будет тратить время на проверку внесенных изменений, если его не заботит их эффект. Люди стараются изо всех сил, когда они знают, что другие люди потратят время на оценку их работы. Рецензия должна быть открытой. Даже в тех случаях, когда я сидел физически в одной комнате с разработчиками, и один из нас вносил изменения, мы заботились о том, чтобы не обсуждать код разговаривая в комнате, а вместо этого отправить его в список рассылки для разработчиков. От того факта, что люди видят рецензии, выигрывают все. Люди читают комментарии и иногда находят в них неточности, и даже если не находят, сам факт все время напоминает им, что рецензирование это ожидаемое, обычное действие, как мытье посуды или стрижка газона. В проекте 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. explores techniques for mixing paid and unpaid developers successfully, and discusses the necessity of legal diligence when opening up a private code base that may contain software written or "owned" by other parties. Announcing Once the project is presentable—not perfect, just presentable—you're ready to announce it to the world. This is actually a very simple process: go to , click on Submit in the top navigation bar, and fill out a form announcing your new project. Freshmeat is the place everyone watches for new project announcements. You only have to catch a few eyes there for news of your project to spread by word of mouth. If you know of mailing lists or newsgroups where an announcement of your project would be on-topic and of interest, then post there, but be careful to make exactly one post per forum, and to direct people to your project's own forums for follow-up discussion (by setting the Reply-to header). The posts should be short and get right to the point: To: discuss@lists.example.org Subject: [ANN] Scanley full-text indexer project Reply-to: dev@scanley.org This is a one-time post to announce the creation of the Scanley project, an open source full-text indexer and search engine with a rich API, for use by programmers in providing search services for large collections of text files. Scanley is now running code, is under active development, and is looking for both developers and testers. Home page: http://www.scanley.org/ Features: - Searches plain text, HTML, and XML - Word or phrase searching - (planned) Fuzzy matching - (planned) Incremental updating of indexes - (planned) Indexing of remote web sites Requirements: - Python 2.2 or higher - Enough disk space to hold the indexes (approximately 2x original data size) For more information, please come to scanley.org. Thank you, -J. Random (See in for advice on announcing further releases and other project events.) There is an ongoing debate in the free software world about whether it is necessary to begin with running code, or whether a project can benefit from being opened even during the design/discussion stage. I used to think starting with running code was the most important factor, that it was what separated successful projects from toys, and that serious developers would only be attracted to software that did something concrete already. This turned out not to be the case. In the Subversion project, we started with a design document, a core of interested and well-connected developers, a lot of fanfare, and no running code at all. To my complete surprise, the project acquired active participants right from the beginning, and by the time we did have something running, there were quite a few volunteer developers already deeply involved. Subversion is not the only example; the Mozilla project was also launched without running code, and is now a successful and popular web browser. In the face of such evidence, I have to back away from the assertion that running code is absolutely necessary for launching a project. Running code is still the best foundation for success, and a good rule of thumb would be to wait until you have it before announcing your project. However, there may be circumstances where announcing earlier makes sense. I do think that at least a well-developed design document, or else some sort of code framework, is necessary—of course it may be revised based on public feedback, but there has to be something concrete, something more tangible than just good intentions, for people to sink their teeth into. Whenever you announce, don't expect a horde of volunteers to join the project immediately afterward. Usually, the result of announcing is that you get a few casual inquiries, a few more people join your mailing lists, and aside from that, everything continues pretty much as before. But over time, you will notice a gradual increase in participation from both new code contributors and users. Announcement is merely the planting of a seed. It can take a long time for the news to spread. If the project consistently rewards those who get involved, the news will spread, though, because people want to share when they've found something good. If all goes well, the dynamics of exponential communications networks will slowly transform the project into a complex community, where you don't necessarily know everyone's name and can no longer follow every single conversation. The next chapters are about working in that environment.