Это перевод заметки Армина Ронахера (Armin Ronacher) о миграции в опенсорс-сообществах. Повествование ведётся от лица автора оригинала.
Легаси-код — плохая практика, и если вы используете такой код, винить в этом можно только себя. Сообщества, которые работают над опенсорс-проектами, рано или поздно сталкиваются с простой ситуацией: что-то становится старым, и это что-то приходится менять на новое и лучшее. В пользу этого лучшего решения всегда есть стандартные аргументы: мы учились на собственных ошибках, а старое решение было плохим с самого начала, в старом решении плохой код и оно тянет за собой плохие практики. Возможно, последняя версия поддерживает новейший TLS/SSL, а ранние версии небезопасны, поэтому они больше никуда не годятся.
Некоторые сообщества из-за этого страдают. Раз в несколько лет библиотеку или целую экосистему сообщества приходится выбрасывать, а на освободившееся место брать что-то новое. Поддержка старой библиотеки обычно прекращается внезапно. Такое может случиться с экосистемой пакетов, с интерпретатором, с модулями в стандартной библиотеке и так далее. Сложно предугадать, что будет с проектом и сообществом после масштабных изменений. Например, Zope так и не восстановился после раскола на Zope 2 и Zope 3. Perl не справился с разделением на Perl 5 и Perl 6. Оба этих проекта фактически раскололись пополам.
С такой проблемой сталкиваются многие опенсорс-сообщества. Они меняют что-то старое на что-то новое без чёткого плана миграции. Но некоторые сообщества успешно справляются с трудностями и выживают.
Это по большей части работает, так как подход к управлению миграциями со стороны опенсорс-сообщество можно охарактеризовать словом «читинг». За это приходится расплачиваться эмоциями и избыточным стрессом. Люди, которые отказываются от миграции, не страдают в финансовом смысле, так как деньги в опенсорсе обычно не задействованы. Как минимум, пользователи не платят разработчикам опенсорс-продуктов. То есть вы не теряете доходы, если миграция вызывает проблемы у пользователей.
Как минимум, отток некоторых пользователей может принести пользу сообществу, так как те, кто не мигрирует, как правило создают много шума в баг-трекерах. Фактически опенсорс-сообщества управляют такими миграциями с помощью своего авторитета: они поощряют пользователей мигрировать в обновлённые экосистемы. Проекты меряют свою популярность количеством загрузок или звёзд на GitHub, а также других индикаторов-пузомерок. Обычно эти индикаторы прокачанные, и мейнтейнерам проекта сложно своевременно увидеть, что пользователи стали меньше пользоваться продуктом, даже если некоторые пользователи уходят, выражая сильное недовольство.
Хитрость заключается в том, чтобы убедить сообщество, что миграция — стоящее дело. Однако разочарование из-за миграции подрывает доверие пользователей, и они с настороженностью относятся к новым миграциям. Я видел, как GTK мигрировало с версии 1 на версию 2, а затем на версию 3. Это был болезненный процесс. И к тому моменту, когда все приложения использовали одну версию, возникала необходимость в новой миграции.
Поскольку миграция вызывает эмоциональный дискомфорт, сообщества нормально воспринимают хитрости. Хороший пример — миграция на Python 3. Большое количество пользователей языка стимулирует участников сообщества мигрировать на новую версию. Вместе и отца легче бить, а если вы уверены в своей правоте, то трудности раздражают ещё меньше. В случае с Python 3 призывы мигрировать основывались скорее на эмоциях, а не на рациональных аргументах. И хоть многие вещи действительно лучше работают в Python 3, понадобилось много итераций, чтобы не регрессировать в других вещах. Тем не менее появились сайты с «досками позора», на которые попадали библиотеки, которые не переключились на Python 3. Сообщества очень хорошо умеют проталкивать даже сомнительные изменения. Такие способности можно назвать одной из характерных черт сообществ.
Одна из главных причин такого отношения — позиция мейнтейнеров опенсорс-проектов, которую можно выразить цитатой: «Мне не платят за это, и я не хочу тратить усилия на поддержку версии такой-то». На практике это хороший аргумент, потому что это правда. Немногие проекты в опенсорсе настолько большие, чтобы в них выживали (по)сторонние люди. Например, в Python есть форк версии 2.7, который называется Tauthon. Он не может похвастаться большим вниманием разработчиков.
Есть проекты, которые явно управляют миграциями и делают их обязательными. Лидеры забывают, что люди любят сообщества, в которых нет насильственных действий и обязательств. Часто отсутствие обратной совместимости играет на руку большинству в сообществе. Но есть и меньшинство, ради которого стоит стараться. В первую очередь отсутствие обратной совместимости может отталкивать коммерческих пользователей. Это может быть полезно для проекта, так как для многих проектов приоритетными остаются некоммерческие вопросы. А самые успешные опенсорс-проекты сохранят большое количество пользователей, в том числе коммерческих, в любом случае. Однако есть проекты, для которых уменьшение пользовательской базы равнозначно уменьшению инвестиций.
Искренне уверен, что многим опенсорс-проектам было бы проще развиваться, если бы они признали, что насильственная миграция болезненна для всех. Создание новой версии, которая закрывает все открытые issue, может быть фаном для разработчика. Но если разработчик понимает, что ему придётся убеждать всех в важности и необходимости перехода на новую версию, фан от работы может исчезнуть. Я участвовал в создании Python 3. Должен сказать, что эта работа истощила меня и лишила радости от участия в опенсорсе. Не имеет значения, в какой роли вы участвуете в миграции — приятного здесь мало как для разработчика, так и для рядового пользователя.
Правильно организованная миграция — настоящий подарок для разработчиков и пользователей. Есть много проектов, с которых можно брать пример. Пользователю приятно иметь возможность обновиться до последней версии проекта, особенно если обновление не требует усилий и ничего не ломает. Такая ситуация стимулирует меня контрибьютить, так как есть шанс, что я смогу пользоваться продуктом, и всё будет работать.
Важно понимать, что многие проекты вне мира опенсорс не имеют такого пространства для манёвра и не могут позволить себе сломать обратную совместимость. Если вы работаете в окружении, где нужно думать о совместимости сотен систем, миграция становится особенно трудной. И вам приходится принимать непростые решения. Опенсорс-проекты едва ли не первыми стали отказываться от поддержки устаревших стандартов TLS. Они просто заставляли всех пользователей обновлять приложения, и им не приходилось думать о последствиях. Коммерческие проекты не могут позволить себе такую роскошь.
Я написал эту заметку, так как Python-сообщество с 1 января 2020 года прекратило поддержку Python 2. Это значит, что многие полезные инструменты, включая pytest, в свою очередь прекращают поддержку Python 2. Тем не менее только половина пользователей языка перешла на Python 3. Сообщество Pallets, которое поддерживает мои собственные библиотеки, тоже мигрирует на Python 3. Я могу это понять, хоть и не согласен с этим полностью. Я желаю всему сообществу Python только добра. Но надеюсь, что кто-то разберёт завалы, когда всё утихнет, так как из этой ситуации можно извлечь много полезной информации и опыта.
Адаптированный перевод заметки Open Source Migrates With Emotional Distress by Armin Ronacher. Мнение администрации Хекслета может не совпадать с мнением автора оригинальной публикации.
