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

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

Что такое сообщество и зачем его строить Open Source проекту?
Сообщества — группы отдельных лиц, разделяющих общие интересы. И закрытые и открытые проекты имеют свои сообщества пользователей, большая часть которых относительно пассивна, ести говорить об их взаимодействии с остальными участниками сообщества. С другой стороны, любой тип сообщества может включать в себя участников, которые решат принять более активное участие, например, отправляя отчёты об ошибках, помогая другим пользователям, занимаясь написанием документации или пропагандой.
Наиболее активные участники должны быть вознаграждены за их усилия. Microsoft, к примеру, награждает тех из пользовательского сообщества, кто помогает людям строить большую часть технологии Microsoft посредством программы MVP (Most Valued Professional). В сообществах Open Source, активные участники ожидают вознаграждения в виде разширения доступа к проекту и увеличения контроля над ним.

Хотя закрытые проекты и несут некоторые выгоды сообществу, существует чёткое ограничение видов добровольного участия в проекте для сообщества. В силу того, что код не открыт для изучения, категорически не существует пути для пользователей в самом деле развивать продукт, решать проблемы, разрабатывать новые функции и вносить программный код в основной проект. Однако наоборот дела обстоят с такими возможностями у сообществ Open Source. Там возможен поток информации в виде кода и документации от любого участника сообщества в центр, хотя и в модерируемом виде. И что более важно, при любой возникшей проблеме существует большое количество глаз, которые обратят на неё внимание и объеденят мозговые усилия всего сообщества. В проектах с закрытым кодом максимальное число людей, следящих за данной проблемой всегда ограничено общим числом нанятых разработчиков.

Типичные пути сообществ Open Source
При своём рождении, сообщества Open Source могут быть чрезвычайно маленькими, иногда состоящими из одного-двух разработчиков и почти без пользователей. В зависимости от типа проекта, такое может продолжаться на протяжении какого-то времени, может быть даже лет, в качестве «инкубационного периода», в течение которого изначальная команда работает над получением чего-нибудь, работающего «из коробки». Эрик Реймонд (Eric Raymond) в книге «Собор и Базар» замечает, что необходимое пред-условие успеха — наличие 'чего-нибудь работающего и поддающегося тестированию, с чем можно поиграть'. Стоит заметить, что 'работающий' не означает великолепный или даже готовый. 'Выпуски рано и часто' — известная мантра Open Source разработки, не лишена смысла, так как подобное поведение проекта может помочь получить ранние отклики и увеличить надёжность проекта. По этой причине сообщества не должны бояться выкладывать материал раньше. Благодаря ранним выпускам можно получить значительные преимущества, предоставив ожидания и управляя проектом чётко и верно.

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

Открытие проекта таким образом может добавить совсем новый набор проблем. Карл Фогел (Karl Fogel) в «Производстве Open Source программ», замечает: «Открытие означает приведение кода в понятную форму для прибывших извне, настройку сайта разработчиков, списка рассылки, и чаще всего первое написание документации. Всё это представляется большим объёмом работ. И конечно, если появится кто-то из заинтересовавшихся разработчиков, придётся отвечать на их вопросы в течение какого-то времени до того, как от них появится какая-то польза.» Однако дополнительные усилия хотя бы частично перекрываются наличием готовых инструментов совместной работы типа Google Code или Sourceforge. И в дополнение: открытие проекта не обязательно значит потерю управления. Многие проекты в рание периоды работают как «великодушная диктатура» с одним человеком, ответственным за разработку большей части функций и анализ написанного кода.

Великодушные диктаторы не обязаны обладать выдающимися техническими навыками, но, по Фогелу, они будут должны «уметь различить хороший дизайн». Фогел идёт дальше и отмечает, что основная ответственность диктатора в том, чтобы убедиться: участники верят, что они «вместе могут больше, чем по одному». Разработчики останутся только если лидер проекта сможет сделать проект местом, куда они захотят возвращаться. Это означает вознаграждать работу, делегируя тем, кто этого заслужил и тем, кто этого хочет, более отвественные участки работы. Управление проектами Open Source было описано как активное, неформальное и незаметное. Успешные великодушные диктаторы должны ещё и «говорить тихо». Все это требует общечеловеческих навыков, и, как предполагает Реймонд, «небольшого умения очаровывать людей».

Прозрачное управление на подводных камнях
В зоне ответственности лидеров сообщества находится уверенность в том, что условия остаются пригодными для использования потенциала Open Source. Она не приходит сама по себе и должна аккуратно управляться.

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

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

Позволить уйти
Чтобы считаться достаточно здоровыми, сообщества Open Source должны быть способны пережить потерю нтереса их изначального основателя к ним. Если они сильно полагаются на диктатора, они рискуют разбиться на части и пропасть, когда их лидер сменит сферу интересов или уйдёт на покой.

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

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

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

источник