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

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

Самая распространённая и большая ошибка, которую совершают компании — это уход с головой в свободные и открытые проекты, и связанные с этим нереалистичные ожидания. Крис Грамс (Chris Grams) однажды описал привлечение сообщества к разработке как «модель Тома Сойера» — это когда компании ожидают, что кто-то другой сделает за них их работу. Важно не попасть в эту ловушку.

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

Модель присоединения компании к сообществу.

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

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

Часто сообщества документируют свои нормы поведения — многие проекты, включая ядро Linux и проект Gnome, имеют свои собственные правила поведения, кодексы, политики, отражённые в их списках рассылки и в других источниках. Для большинства сообществ они могут быть кратко сформулированы так: «Плыть по течению, не раскачивая лодку».

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

Модель взращивания сообщества.

Второй сценарий — взращивание сообщества. Если компания решила выпустить ПО под свободной лицензией, её первым решением будет вопрос о том, будет-ли проект позиционироваться исключительно как проект сообщества или нет, и до какой степени это будет проект сообщества?

Саймон Филипс (Simon Philips) писал о различных типах сообществ, которые могут вырасти вокруг СПО. Он описывал сообщества разработчиков программного кода, непрофильных разработчиков, разработчиков, работающих над дополнениями, интеграторов, распространяющих и настраивающих ПО, но не обязательно изменяющих его, и, наконец, пользователей ПО. Каждое из этих сообществ имеет разные потребности и требует различного подхода.

Если компания хочет взрастить сообщество вокруг своего проекта, есть несколько практических советов, которым необходимо следовать:

• Управление: если компания установит правило, согласно которому она будет единолично решать, какой код будет добавлен в ядро продукта, то она потеряет многие преимущества открытых проектов.
• Барьеры при входе в сообщество: барьеры, которые необходимо преодолеть участникам могут быть разными: использование необычных инструментов разработки, требующих использования запутанных процессов генерации отчётов об ошибках, пожеланий или отправки патчей, или навязывание различных соглашений о передаче имущественных прав, которые должен подписать участник, прежде чем внести свой вклад.
• Инструменты разработки и инфраструктура: компании необходимо убедиться, что она предоставляет пользователям удобные возможности распространения своих работ и общения друг с другом — будь то через специальные модули, или через систему управления версиями (GIT, Bazaar). Вклад в проект компании должен рассматриваться как важный социальный опыт каждого члена сообщества.
• Процессы в сообществе: компания должна создать простую экосистему — никто не хочет быть гражданином второго сорта. Нужно документировать процессы получения доступа к ключевым ресурсам, таким как права модератора, принятие кода в основную ветку или доступ редактора к сайту проекта.
• Соответствующий бюджет: выделение ресурсов — создание сообщества занимает много времени и усилий, а это означает значительные инвестиции, в первую очередь инвестиции в человеческие ресурсы. Наличие одного парня, ответственного за работу с сообществом и команды из 10 разработчиков за стенами компании — не решит всех проблем. Если зарождающееся сообщество почувствует пренебрежение собой, оно просто исчезнет.

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

Некоторые типичные ситуации, которых стоит избегать:

1. Командование и управление. Сообщество — это партнёрство. Компании используются для контроля за продуктами, над которыми они работают. Попытка передать управление над проектом в руки растущего сообщества, если компания захочет увеличить количество разработчиков, приведёт к «радушному» ответу от людей, которые не хотят быть гражданами второго сорта. Кроме того, взаимодействие с сообществом проекта, в котором компания не в состоянии контролировать принятие решений, является сложной задачей. Необходимо обменять контроль на влияние на людей.
2. Отстранение от сообщества. Когда команда компании работает слишком много в частном порядке, созданное ей сообщество может не принять мотивы компании и её приоритеты. Работая через списки рассылки или иные формы публичного обмена информацией, компания позволяет людям вне компании быть наравне с ней по скорости работы и понимать суть проекта.
3. Долгие дискуссии. Слишком долгое обсуждение незначительных решений. Когда в компании начинают чувствовать, что сообщество тянет её вниз, ей нужно знать, когда необходимо переходить от слов к делу.
4. Чёрная дыра. Заманчиво нанять разработчиков, которые уже заработали себе хорошую репутацию и навыки в проектах, построенных компанией. Но нужно остерегаться приёма на работу разработчиков из числа активных членов сообщества. Это может ухудшить сообщество. В компании должны убедиться, что работа в сообществе является частью должностной инструкции.
5. Необходимо остерегаться чрезмерного вклада одних разработчиков в ущерб возможностей других. Нужно внести ясность — что компания будет делать при разработке, а что не будет.