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

Проблема настолько серьёзна, что основатель LinuxQuestions.org Джереми Гарсия решил публично ответить на письмо читателя, который сообщает, что один интересный ему проект, размещённый на GitHub и опубликованный на условиях GPL v3, фактически остался без программистов. Это случилось после того, как инициатор проекта остыл к своей идее.

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

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

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

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

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

Главное правило — что автору очевидно, то остальным непонятно. Люди, как правило, очень неохотно принимают участие в том, в чём не видят никакого смысла.

Поэтому с самого начала следует чётко определить следующее:

· что именно предлагается сделать;

· кому это может быть нужно;

· чем это отличается от аналогичных решений;

· когда и где это должно быть использовано.

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

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

Второй важный момент — инструкция для участников (на GitHub этот файл традиционно называется CONTRIBUTING.md). В ней должно быть максимально подробно изложены правила клонирования и написания кода, все принятые в проекте стандарты и любая другая информация, которая может быть полезна разработчику.

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

Говорят, что самое трудное — начать. С этим, безусловно, следует считаться. Инициатор проекта обязательно должен позаботиться о том, чтобы потенциальные участники могли стартовать максимально быстро.

Не стоит уповать на багтрекер, на котором перечислены все ошибки, требующие исправления. Значительно лучше отдельно выделить несколько небольших задач, решение которых не требует глубокого знания кода всего приложения. Этим решаются сразу две проблемы. Новые участники сразу приступают к работе и интегрируются в коллектив постепенно. А если они по каким-то причинам решат сразу покинуть проект, то ущерб от этого будет минимален, поскольку они не успеют внести заметные изменения в основные модули.

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

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

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

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

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

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