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



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

Предыстория

Если первый материал из этой серии был о том, что я, занимаясь Snowpack, сделал правильно, то эта статья будет посвящена всему тому, что пошло не так.

Мы начинали год, переполненные ожиданиями. Snowpack признан лучшим проектом 2020 года в категории Productivity Booster OS Awards. Наш проект занял высокие места в разделе об инструментах для сборки проектов опроса State of JavaScript 2020 года. Количество его загрузок с 200 тысяч в 2020 году взлетело до 1,3 миллиона в 2021.

Когда делаешь нечто подобное впервые — никогда не сделаешь всё абсолютно правильно. Так было и с моим первым опытом поддержки опенсорсного проекта такого масштаба. Раньше я начинал работу над многими проектами, и репозитории некоторых из них даже пользовались немалой любовью пользователей, но ни один из них не дорастал до такого размера. У нас не было «дорожной карты», рассчитанной на переход проекта к тем размерам, до которых он дорос, и я, как я теперь вижу, наделал множество ошибок.

Я хочу со всей ясностью заявить, что невероятно горжусь этим проектом и теми людьми, которые внесли вклад в его развитие. Snowpack продвинул к новым горизонтам всю индустрию веб-разработки, и это невероятно здорово. Даже если вы никогда не использовали Snowpack напрямую, знайте, что те дела, которые мы начали, стали основой для множества инструментов, относящихся к самым разным сферам веб-разработки. Это, например, Vite, Skypack, JSPM CDN. Речь идёт о поддержке npm-пакетов в ESM-среде и о движении «unbundled web development», о веб-разработке, основанной на использовании отдельных компонентов.

В этом материале я попытаюсь представить руководство для тех, кто однажды окажется в ситуации, похожей на мою.

Урок 1: разрабатывайте версии больших проектов, предназначенные для тестирования проектов в реальных условиях

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

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

Крупные компании могут успешно проводить подобные испытания на своих внутренних проектах, а вот небольшие команды разработчиков, к сожалению, этого не могут. Например, Facebook может тестировать новые версии React или результаты исправления ошибок на кодовой базе, представленной более чем 30000 компонентов. Они могут всё проверить сами, на масштабном проекте, а потом уже выкладывать обновлённый продукт в общий доступ.

Если ваш проект не принадлежит техническому гиганту — это не значит, что вы никак не можете протестировать его в реальных условиях. Если вы где-то работаете — попробуйте испытывать свои разработки внутри компании-работодателя. Рик Харрис часто говорит о том, как использование Svelte в The New York Times оказало положительное влияние на этот фреймворк. В результате — компания, где вы работаете, вполне может стать реальной «интерактивной средой запуска кода» для испытаний новых возможностей, изменений API, и даже целых предрелизных версий проекта.

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

▍Совет тем, кто занимается поддержкой опенсорсных проектов

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

Урок 2: обеспечьте удобства программистам, которые будут пользоваться вашим проектом

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

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


По мере того, как наша аудитория превращалась из группы первых пользователей в более обширную, «мейнстримовую» команду, стало менее вероятным то, что пользователи будут выяснять причины странных ошибок (undefined is not a function — ужас!). Они, при возникновении таких ошибок, попросту оставляли проект и переходили на что-то более знакомое или более стабильное.

Эти рассуждения применимы и к выбору новых возможностей программы. «Бандлинг должен быть необязательным» — это ключевая идея, с самого начала пронизывающая весь Snowpack. Если вы читали первый материал из этой серии, то, возможно, помните, что наши первые пользователи были в восторге от этой идеи. А вот по мере того, как проект рос, оказалось, что новым пользователям она уже нравится далеко не так сильно, как первым. Они, в основном, не понимали, почему им, при использовании Snowpack, нужно самостоятельно реализовывать столь простую возможность.

▍Совет тем, кто занимается поддержкой опенсорсных проектов

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

Урок 3: не ждите, что пользователи будут рассказывать вам абсолютно обо всём

Хочу рассказать о том, как Snowpack почти стал одной из основ SvelteKit.

Дело было так: Рик Харрис выразил восхищение нашим проектом на конференции Svelte Summit и написал об этом в блоге. Мы были на седьмом небе от счастья. Но прямо перед публичным релизом SvelteKit разработчики этого проекта заменили Snowpack на альтернативный инструмент, называемый Vite. Мы узнали об этом слишком поздно. Команду разработчиков SvelteKit что-то в Snowpack не устраивало, а мы даже этого не заметили!

Если речь идёт о маленьких проектах, то их авторы обычно поддерживают достаточно сильную связь с их пользователями. Но по мере роста аудитории связь с пользователями ослабевает. Я так привык к тому, что пользователи сообщают мне о том, что их не устраивает, что даже не подумал о том, чтобы самому чем-то таким поинтересоваться. Я не увидел тех сложностей, с которыми команда Svelte сталкивалась ежедневно, получив их отзыв лишь тогда, когда было уже слишком поздно менять чьё-то мнение о Snowpack.

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

▍Совет тем, кто занимается поддержкой опенсорсных проектов

Не ждите, когда пользователи скажут вам о том, что что-то идёт не так. Старайтесь действовать на опережение в делах сбора отзывов пользователей и исправления того, что им не нравится.

Урок 4: будьте последовательны

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

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

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

Как бы там ни было, я и сам всё ещё над этим работаю.

▍Совет тем, кто занимается поддержкой опенсорсных проектов

Будьте последовательны. Не заставляйте тех, кто делает вклад в ваш проект, бесконечно ожидать результатов код-ревью или комментариев об их PR.

Урок 5: не пропадайте, пользуйтесь Discord (серьёзно!)

Я уже это сказал, но это так важно, что я повторюсь: пользуйтесь Discord. Создайте сервер сообщества сразу же после того, как у вас появятся первые пользователи. Если у вас уже есть Slack-сообщество — подумайте о переходе на Discord. Серьёзно. Это — гораздо лучше.

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

Общение в Discord хорошо ещё и тем, что оно может подвигнуть вас на эксперименты. Кто-то советует хорошего бота (интеграцию с чем-либо) для вашего Discord-сервера? Попробуйте! Попросите помощи в проведении процесса интеграции, в настройке бота, да можете даже попросить научить вас тому, как работает Discord. Если ваша кодовая база далека от идеала — Discord может оказаться отличным полигоном, где можно взаимодействовать с сообществом (и даже учиться чему-то новому).

▍Совет тем, кто занимается поддержкой опенсорсных проектов

Используйте Discord. Будьте последовательны и регулярно бывайте там, где пользователи ожидают вас видеть. Используйте интересные возможности платформы (эмодзи, боты, стикеры и прочее подобное).

Урок 6: не стремитесь всё сделать самостоятельно

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

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

Несмотря на то, что за годы занятий опенсорсом я принял множество вкладов в мои проекты, я, работая над Snowpack, попал в эту ловушку. Часть меня хотела заниматься проектом исключительно самостоятельно и не хотела, чтобы мне в работе над ним кто-то серьёзно помогал. В этот период я сделал кое-что заметное, но мне приходилось работать в большой спешке. Пострадало качество кода. Я не делал код-ревью, так как мне казалось, что времени на это у меня нет. А потом, когда я устраивал себе отдых, отдых этот затягивался, а в проекте в это время царила тишина.

Бывали ли вы когда-нибудь настолько выгоревшими на работе, что у вас даже не было сил это осознать? Да, это тяжело.

▍Совет тем, кто занимается поддержкой опенсорсных проектов

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

Итоги: что ждёт Snowpack?

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

Досадные ошибки имеют свойство преследовать нас. Я уже начал применять собственные советы в нашем новейшем проекте, который называется Astro. Мы уже организовали активное Discord-общение, создали здоровую модель управления проектом, надёжную среду для тестирования кода. Мы уделяем основное внимание стабильности кода и сообществу, состоящему из тех замечательных людей, которые помогают нам поддерживать проект.

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

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

Но, в то же время, Vite (альтернатива Snowpack, используемая в SvelteKit) сейчас на высоте. К чести разработчиков этого проекта хочу сказать, что они многое сделали по-настоящему хорошо. Правда, хорошо и то, что Vite и Snowpack очень похожи, один инструмент можно легко заменить другим. Даже в будущем релизе Astro мы планируем попробовать переключиться со Snowpack на Vite.

Может, настало то время, когда пора дать Snowpack постепенно исчезнуть. Мы задали сообществу вопрос о том, хочет ли кто-нибудь заняться поддержкой проекта в долгосрочной перспективе. Но приём в команду нового контрибьютора требует времени, которого, кажется, найти мы не можем. В общем, у нас тут получается что-то вроде «Уловки-22».

Ещё у нас есть идея вернуться к истокам, и, так сказать, позволить этой истории закончиться там же, где она и началась. Установщик пакетов, который так понравился нашим первым пользователям, всё ещё живёт в виде отдельного пакета. Аудитория такого проекта будет небольшой. Может, занятие им даже принесёт положительные эмоции.

Но, что бы ни случилось, я знаю о том, что мы будем продолжать учиться и продолжать развиваться.

Спасибо, что дочитали до этого места! Подписывайтесь на меня в Твиттере. А на тот случай, если вы не читали первую статью — вот вам ссылка на неё.

Что вы посоветовали бы тому, кто хочет создать собственный опенсорсный проект?