На прошедшей в Остине конференции OSCON (Open Source Convention) с докладом, посвящённом специфике крупномасштабных открытых разработок, выступила Джесси Фрезелье, принимавшая ключевое участие в проектах Docker, Kubernetes и Golang. Таким образом, она очень хорошо знакома с проблемой и её рекомендации заслуживают самого пристального внимания.
«Звёздный инженер» Джесси Фрезелье известна не только своим техническим вкладом в наиболее востребованные открытые программы, но и принципиальной жизненной позицией. В частности, в прошлом году она покинула проект Docker из-за дискриминации по половому признаку.
В своём выступлении она поделилась с участниками конференции некоторыми рекомендациями, основанными на богатом личном опыте. Советы эксперта можно разбить на несколько групп.
Советы по привлечению и удержанию участников
Фрезелье считает, что важную роль в привлечении новых участников играет организация трекера проекта. В частности, маркировка некоторых вопросов, которые могут заинтересовать новичков и помогут им быстрее интегрироваться в команду.
Особое внимание следует уделять открытости проекта, причём не только в технической области. В частности, если разработка началась внутри компании, то наверняка ей предшествовала какая-то внутренняя дискуссия, материалы которых должны быть доступны всем.
Разумеется дело тут не только в открытости ради открытости. Участники проекта должны быть в курсе динамики принятия тех или иных решений. В противном случае неизбежны возвраты к тому, что уже давно обсуждалось, причём с теми же самыми аргументами. Подобные бессмысленные затраты времени явно не идут на пользу проекту.
К тому же рано или поздно ветеранам надоест объяснять новичкам одно и то же. Недавно подключившимся к проекту участникам такое поведение может показаться пренебрежительным, и они утратят интерес к разработке.
Обязательно следует определить условия для участников, которые планируют заниматься не программированием, а документацией, дизайном или популяризацией решения. Их роль не менее важна и они также нуждаются в стимулировании.
Не каждый новый участник становится постоянным членом команды. Процесс перехода следует продумать и в некотором смысле формализовать. Добровольные помощники не должны сомневаться в собственном статусе — он должен быть очевиден.
Время участников следует уважать. К сожалению, про это правило лидеры проектов забывают слишком часто. Они считают, что очевидное им автоматически является очевидным всем. Разумеется это не так — следует максимально избавить добровольных помощников от всевозможных «накладных расходов».
Из этого следует, что все внутренние для проекта процессы следует определить заранее. Например, если какой-либо новый участник желает стать мантейнером, он должен иметь возможность понять, каким образом это достигается.
Советы по воспитанию мантейнеров
Очевидно, что мантейнеры играют ключевую роль в каждом проекте. Поэтому их формированию следует уделять особое внимание. По сути, лидер должен принять некую политику, направленную на поддержку именно таких участников.
Прежде всего, в проекте должны быть приняты критерии, которым должен соответствовать мантейнер. Причём не расплывчатые, а максимально конкретные и понятные даже новичку.
Лидерам важно понимать, что открытых проектов много и конкуренция за участников высока. Если амбициозному новичку что-то непонятно с самого начала, то вероятнее всего он найдёт другую разработку, а не будет тратить время на изучение организационных вопросов.
Мантейнер — это серьёзная нагрузка и большая ответственность. Чтобы участники брали это на себя, в проекте должна быть предусмотрена система поощрений. Если есть такая возможность, то не только моральных, но и материальных.
Поскольку крупные проекты так или иначе связаны с коммерческими компаниями, то последнее особенно важно. Наивно считать, что все участники будут альтруистами — многие хотят получать за свою работу деньги и это совершенно нормально.
В частности, потенциальный мантейнер должен иметь какие-то перспективы перехода из добровольных помощников в штат заинтересованной корпорации. Очевидно, что бизнесу это тоже выгодно — фактически он получает уже полностью подготовленного сотрудника, на практике доказавшего свою компетентность и квалификацию.
В крупных проектах невозможно сосредоточить весь контроль в одних руках. Это должна быть распределённая и довольно сложная система управления, которую следует создать.
Управление проектом имеет решающее значение. Проблема заключается в том, что чем проект крупнее, тем сложнее реализовать выполнение сугубо административных функций, а специфика Open Source не позволяет использовать некоторые корпоративные принципы, основанные на строгой иерархии и материальной заинтересованности.
Фрезелье призывает уделять вопросу управления проектом особое внимание. Именно он может стать тем самым слабым звеном, которое заметно снизит эффективность совместной работы.
Советы по работе с уязвимостями
Уязвимостей в крупном ПО избежать нельзя. Это относится как к продуктам больших компаний, так и к открытым разработкам.
Фрезелье считает, что прежде всего процесс нахождения и устранения уязвимостей следует сделать максимально открытым. В хорошем результате заинтересованы все участники разработки, поэтому они постоянно должны быть в курсе дела.
Злоумышленники и так знают про ошибки в ПО значительно больше, чем хотелось бы. Тестеры и разработчики должны знать как минимум не меньше. К тому же не исключено, что таким образом получится привлечь в команду людей, балансирующих на грани — много квалифицированных программистов занимаются поиском уязвимостей «просто так», они ещё не знают, в какую сторону направить свои силы: к добру или злу.
Возможно некоторых из них ещё не поздно перетянуть на «сторону света». Достаточно наглядно показать, что хакерские навыки востребованы обществом и работа над полезным проектом в составе хорошей команды значительно интересней.
Отдельный вопрос — информирование пользователей. Руководители проекта должны быть уверены, что все они знают, как и когда необходимо обновлять ПО, чтобы чувствовать себя в относительной безопасности. Отсюда особую важность приобретают участники, занятые не написанием кода, а популяризацией и технической поддержкой.
В любом проекте необходима группа технических писателей, которая будет оперативно и в понятной форме доводить до пользователей важную информацию. В противном случае усилия даже очень квалифицированных разработчиков будут сведены на нет обычной неосведомлённостью большинства заинтересованных лиц.
Открытость не должна иметь исключений. Даже если кто-то просит «придержать» информацию до какой-то важной конференции, на компромисс идти не стоит.
Если в процессе работы с уязвимостями происходит какой-то даже незначительный сбой, то это должно стать поводом для серьёзного расследования. Безопасность — слишком важная составляющая проекта, относится к ней легкомысленно недопустимо.
Советы по работе с компаниями
«Just for fun» — это прекрасно. Но значительно лучше, если энтузиазм подпитывается деньгами от коммерческих компаний. Практически все крупные открытые проекты работают именно по такому принципу.
Одна из главных задач лидера открытого проекта — найти баланс между корпоративными потребностями и интересом сообщества. Если получится достичь разумного компромисса, то это решит большинство возможных проблем.
Прежде всего следует убедить руководство компаний рассматривать сообщество в качестве кадрового резерва. Сделать это, кстати, несложно — речь идёт о людях, о профессиональных качествах которых можно судить не только по резюме.
С другой стороны, участники проекта должны понимать, что их добровольная работа сама по себе ничего не гарантирует. Приём на постоянную работу надо ещё заслужить. Open Source — это новые возможности, но не более того.
Отдельная тема — авторские права на патчи. Все участники должны быть уверены, что вклады принадлежат им, а не финансирующим деятельность сообщества компаниям. Это принципиальный момент, который крайне важен для разработчиков.
