Что происходит, когда в open source проекте уходит лидер

Когда Райан Даль отошёл от Node.js, проект выжил, но на это ушли годы перестройки управления, форк io.js и примирение, прежде чем всё стабилизировалось. Когда Гвидо ван Россум ушёл с поста BDFL («Benevolent Dictator For Life», «доброжелательный пожизненный диктатор»), сообщество несколько месяцев спорило о моделях управления и в итоге остановилось на совете руководителей (steering council). Когда у проекта Deno возникли собственные вопросы о лидерстве, эхо докатилось до каждого разработчика, который поставил на эту среду выполнения.

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

Проблема bus factor

«Bus factor» — сколько человек должен сбить автобус, чтобы проект развалился, — для большинства open source проектов удручающе мал. Исследование 2015 года показало, что более 60% пакетов npm поддерживались одним мейнтейнером. Более свежий анализ критической open source инфраструктуры выявил, что многие проекты с миллионами зависимых от них пользователей ведут один-два человека, часто в качестве неоплачиваемого хобби.

Это не гипотетическая проблема. OpenSSL, библиотека, защищавшая большую часть зашифрованного трафика интернета, в момент обнаружения Heartbleed поддерживалась в основном двумя людьми, которые занимались ею в свободное время. Left-pad, тривиальный npm-пакет из 11 строк, сломал тысячи сборок, когда автор его удалил. Core-js, который скачивали более 25 миллионов раз в неделю, поддерживает один разработчик, публично признававшийся, что едва может позволить себе еду.

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

Модели управления и их компромиссы

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

Модель BDFL

Окончательные решения принимает один человек. Python (Гвидо ван Россум), Linux (Линус Торвальдс), Ruby (Мацу): самые успешные проекты часто имеют сильного технического лидера, чей вкус и суждения формируют проект. Преимущество очевидно: чёткое направление, последовательное видение и быстрые решения. BDFL может сказать «нет» функциям, которые не вписываются, и проект остаётся сфокусированным.

Провал не менее очевиден: BDFL уходит, и никакого плана преемственности нет. Переход Python после ухода Гвидо прошёл неровно, несмотря на десятилетия его работы с сообществом. Проекты с менее вовлечённым сообществом часто просто умирают, когда их BDFL уходит.

Модель фонда

Проекты вроде Apache, Eclipse и Linux Foundation находятся под эгидой некоммерческих фондов с формальными структурами управления: техническими комитетами, выборами коммитеров, процессами принятия решений. Это обеспечивает институциональную преемственность: проект переживает уход отдельных людей, потому что структура сохраняется.

Цена вопроса — бюрократия и политика. Управление в фондах может быть медленным, конфликтным и захваченным корпоративными интересами. Некоторым разработчикам процесс комитетов кажется удушающим на фоне гибкости проекта под руководством BDFL. Худший сценарий: фонд, где управление больше касается организационной политики, чем технических достоинств.

Модель корпоративного спонсора

React (Meta), Go (Google), Rust (изначально Mozilla, сейчас у собственного фонда), TypeScript (Microsoft): многие крупные проекты спонсируются компаниями, которые нанимают ключевых мейнтейнеров. Это решает проблему финансирования: мейнтейнеры получают зарплату, могут работать полный день, а проект выигрывает от корпоративных инженерных ресурсов.

Риск в согласованности интересов. Корпоративные приоритеты меняются. Mozilla уволила команду Rust. Google понижал приоритет и недофинансировал open source проекты, когда бизнес-фокус смещался. Когда стратегические интересы компании расходятся с интересами сообщества, трение неизбежно. Недавняя волна смены лицензий корпоративными спонсорами (Redis, Terraform, Elastic) показывает, насколько хрупкой может быть эта модель.

Когда форки здоровы

Форк, то есть создание конкурирующей копии проекта, часто считают признаком провала. Но в open source это и есть главный предохранительный клапан. Когда лидерство даёт сбой, форки позволяют сообществу продолжать работу, не завися от исходных мейнтейнеров.

Форк Node.js под названием io.js подтолкнул Node к более открытой модели управления и более быстрым релизным циклам. Когда проекты снова слились, Node от этого только выиграл. LibreOffice, отделившийся от OpenOffice.org, спас проект от угасающего интереса Sun/Oracle. MariaDB, сделанная форком MySQL после поглощения Oracle, остаётся управляемой сообществом альтернативой.

Совсем недавно смены лицензий запускали продуктивные форки. Когда Elastic сменила лицензию Elasticsearch, Amazon сделала форк под названием OpenSearch. Когда HashiCorp сменила лицензию Terraform, сообщество сделало форк OpenTofu под эгидой Linux Foundation. Такие форки существуют, потому что право на форк — главный механизм контроля сообщества над лидерством проекта.

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

Спираль выгорания

Большинство кризисов лидерства в open source начинаются не с драматичного ухода. Они начинаются с выгорания: медленной эрозии сил и энтузиазма мейнтейнера под грузом задач, pull request'ов, запросов функций и требовательных пользователей.

Динамика предсказуема. Мейнтейнер создаёт полезную штуку. Приходят пользователи. С ними приходят баг-репорты, запросы функций, вопросы и претензии. Мейнтейнер, чувствуя ответственность, пытается ответить на всё. Объём превышает его возможности. Он начинает бояться уведомлений. Отвечает медленнее, потом короче, потом вообще перестаёт. В конце концов он исчезает, и проект входит в период зомби-поддержки: технически живой, практически брошенный.

Выгорание мейнтейнера в open source — не личная слабость. Это структурная проблема: проекты генерируют безграничный спрос на время и внимание конечного числа людей, и встроенного механизма управления этим спросом нет.

Некоторые мейнтейнеры нашли способы справиться: строгие границы по времени ответа, передача сортировки задач членам сообщества, оплачиваемая поддержка через GitHub Sponsors или Open Collective, а также спокойное отношение к медленным ответам. Но для этого нужно сознательно противостоять давлению быть доступным постоянно, а это идёт вразрез с культурой многих open source сообществ.

Как выглядит здоровая передача лидерства

Несколько проектов справились со сменой лидерства хорошо, и у них есть общие черты.

Распределённые знания, а не только распределённый код. «Племенное знание» проекта — почему были приняты те или иные решения, какие альтернативы рассматривались, каковы принципы дизайна — документируется, а не хранится в голове одного человека. Для этого служат Architecture Decision Records (ADR) и подробные RFC.
Несколько людей с доступом к коммитам и правом на релиз. Если выпустить релиз может только один человек, он становится единственной точкой отказа. У здоровых проектов есть как минимум 3-5 человек, которые могут независимо выпускать новые версии.
Явные документы об управлении. Как принимаются решения? Кто за что отвечает? Как добавляются новые мейнтейнеры? Проекты, которые отвечают на эти вопросы до кризиса, справляются с преемственностью лучше тех, что импровизируют.
Постепенные переходы, а не внезапные уходы. Лучшие переходы происходят, когда уходящий лидер сознательно сокращает участие на протяжении месяцев, наставляет преемников и явно передаёт полномочия. Резкий уход, даже из благих побуждений, создаёт вакуум.
Финансовая устойчивость. Проекты с надёжным финансированием (через фонды, корпоративных спонсоров или сбор средств сообществом) лучше переживают смены, потому что новых мейнтейнеров можно оплачивать за время. Предложить кому-то унаследовать неоплачиваемую работу на полный день — трудная задача.

Что стоит делать пользователям и компаниям

Если ваш бизнес зависит от open source программного обеспечения, а он зависит, вы заинтересованы в здоровье проектов, от которых зависите. Несколько практических шагов:

Проверьте bus factor своих зависимостей. Посмотрите на критические open source проекты в вашем стеке. Сколько у них активных мейнтейнеров? Когда был последний релиз? Насколько быстро устраняются уязвимости безопасности? Проект с одним мейнтейнером и шестимесячной уязвимостью в безопасности — риск, о котором вам стоит знать.
Финансируйте то, что используете. Если проект критичен для вашего бизнеса, поддержите его финансово. Для этого есть GitHub Sponsors, Open Collective и Tidelift. Стоимость финансирования мейнтейнера ничтожна по сравнению с ценой ситуации, когда критическая зависимость остаётся без поддержки.
Вносите вклад в upstream. Исправления багов, улучшения документации, сортировка задач — всё это снижает нагрузку на мейнтейнера и помогает команде лучше знать кодовую базу. Если проекту понадобятся новые мейнтейнеры, вы будете готовы подхватить работу.
Имейте план Б. Для критических зависимостей заранее продумайте, что делать, если проект заброшен. Сможете ли вы сделать форк и поддерживать его? Есть ли альтернатива, на которую можно мигрировать? Ответы на эти вопросы нужно искать до того, как они понадобятся.

Управление в open source — не самая гламурная работа. Она не порождает заголовков и звёзд на GitHub. Но разница между проектом, который переживает уход основателя, и проектом, который не переживает, почти всегда в управлении: в скучной, структурной работе по документированию решений, распределению полномочий и планированию преемственности. Живут те проекты, которые строят институты, а не только software.