Эту тему в сообществе Open Source обсуждают редко. Намного приятней писать о расширении числа участников, увеличение вкладов и тому подобных вещах. Однако реальность такова, что разработчики порой уходят из проектов. А иногда такой поступок означает если не фактическое закрытие проекта, то возникновение у него множества непростых проблем.
Разработчик Гарет Гринвей два года назад принял непростое для себя решение и оставил открытый проект, которому посвятил 14 лет своей жизни. А совсем недавно он опубликовал на сайте OpenSource.com статью, в которой анализирует эту проблему и пытается предложить меры, позволяющие защитить весь проект от подобных решений отдельных участников.
Он общался с людьми, которые уходили из открытых проектов и интересовался причинами такого поступка. Оказалось, что их очень непросто систематизировать: у кого-то происходят изменения в личной жизни, кто-то начинает испытывать нехватку времени... Если участие в проекте было как-то связано с работой, то перемены в компании могут вынудить людей принять подобное решение.
Поскольку большинство открытых проектов не имеют HR-поддержки, причиной ухода может быть личная обида на лидеров или основателей. Зачастую именно эта причина приводит к появлению различных ответвлений или форков, которые могут привлечь других участников, что приводит к ослаблению первоначальной команды.
При увольнении с предприятия сотрудник часто берёт на себя обязательство не переманивать на новое место своих бывших сослуживцев. Но в открытых проектах такое невозможно — добровольные участники не подписывают никаких соглашений и совершенно свободны в своих поступках, поскольку иное противоречит самой сущности Open Source.
Сообщество традиционно свободно от формальных процедур. При уходе из проекта не надо уведомлять остальных участников за две недели. Так как у участника нет каких-то строгих планов, даже после фактического прекращения работы он ещё долго будет считаться частью сообщества.
Открытым проектам зачастую свойственна определённая организация безалаберность. Гринвей пишет, что большинство людей, с которыми он общался, рассказывали ему, что не понимали своей реальной значимости в процессе совместной работы — никто не сообщал им, что они фактически занимают лидерские позиции.
Случалось и обратное — некоторые участники, опираясь на свои субъективные ощущения, были уверены, что когда они уйдут из проекта, то за ними последует много людей. Часто они были разочарованы, поскольку их точку зрения не обязательно разделяли другие.
Тем не менее большинство людей, по тем или иным причинам покидающих проект, не испытывают к нему каких-либо негативных чувств и не хотят создавать ему проблем. Но они не знают, как это сделать. В-основном потому, что сами не представляют, к каким последствиям приведёт их уход.
Что будет с финансируемой коммерческой компанией проектом, когда его основатель утратит к нему интерес? Даже если бизнес готов сохранить прежние отношения, с кем ему надо контактировать? Это непростые вопросы, на которые часто нет никакого ответа.
Гринвей спрашивал у руководителей нескольких открытых проектов о том, что они будут делать, если уйдёт ключевой участник. Большинство ответило, что не знают, потому что с ними этого пока не случалось. А столкнувшиеся с такой ситуацией начали реагировать только после того, как проблемы уже возникли.
Что может сделать руководитель проекта? Прежде всего сделать процесс совместной работы документированным и прозрачным. Участники должны получать регулярные оповещения о присоединившихся к проекту и покинувших его.
Вот три подсказки Гринвея, которыми могут пользоваться руководители проектов. По его мнению, они помогут избежать наиболее серьёзных проблем, возникающих из-за организационной неразберихи.
Во-первых, руководителю необходимо позаботиться об обеспечении активов всего проекта, а не его отдельных участников. Например, всегда знать, кто именно имеет доступ к важной информации (логины, пароли и т. д.).
Во-вторых, оценить значение «фактора автобуса» для своего проекта. Если потеря одного участника будет для проекта критичным, то следует пересмотреть всю структуру сообщества.
В-третьих, если проект не управляется никаким органом, то этот недостаток следует устранить. Можно воспользоваться услугами Software Freedom Conservancy, а можно создать собственную организацию, провести выборы совета. Он будет регулярно проводить заседания (очные или дистанционные), решения которых должны быть задокументированы и доведены до сведения всех участников.
