В этом материале я хочу рассказать о пяти вещах, которые я узнал, доведя Snowpack от исходного коммита до почти 20000 звёзд на GitHub и до более чем миллиона загрузок.
Этот материал предназначен для всех, кто интересуется опенсорсным программным обеспечением. То, что я вынес из своего опыта, и то, о чём я тут расскажу, адресовано всем, кто заинтересован в запуске собственного опенсорсного проекта, или в том, чтобы сделать вклад в существующий проект.
Мой рассказ состоит из двух частей. В этом первом материале я уделяю основное внимание тому, чему научился, создавая Snowpack с нуля и находя наших первых пользователей. Во второй части я расскажу о том, как выглядит поддержка популярного растущего опенсорсного проекта.
Предыстория
Пару лет назад я начал работу над экспериментальным JavaScript-проектом под кодовым названием Pika. Его талисманом была симпатичная синяя мышка, в этом проекте царила позитивная атмосфера, которая способствовала объединению в его рамках множества более мелких экспериментальных проектов. Общая цель этого проекта лучше всего может быть выражена так: «ES-модули — это замечательная новая технология. Давайте решать с её помощью больше различных задач».
Первый год работы над проектом Pika, возможно, был самым продуктивным годом в моей жизни. Я создал @pika/pack (инструмент для работы над npm-пакетами, рассчитанный на авторов таких пакетов), Pika CI (GitHub-экшн, который позволяет применять команды npm install или даже import() к любому PR на GitHub), неудачный браузерный редактор кода. Я создал и JavaScript-CDN нового поколения, которая, в итоге, превратилась в Skypack.
Среди прочих моих разработок сильнее всего выделялся проект @pika/web. Он позволяет устанавливать любой npm-пакет так, чтобы его можно было бы запускать непосредственно в браузере, не используя при этом бандлер (например — react -> /react.js). Этот проект, вероятно, известен вам под его новым именем (Snowpack).
Ниже я расскажу о пяти вещах, которые я узнал, когда работал над проектом Snowpack, развивал его, двигался от первого коммита до официального релиза версии 1.0 и находил его первых пользователей.
Урок 1: начните с поиска решения какой-то собственной проблемы
В самом начале проект Snowpack представлял собой инструмент для преобразования любого npm-пакета в отдельный JavaScript-файл, код которого можно запустить в браузере. Звучит скучновато. Правда? Нет, не правда!
Этот маленький, незамысловатый инструмент открывал совершенно новый подход к веб-разработке, который сейчас называют «Unbundled Web Development». В результате в распоряжении программистов оказались такие возможности, как мгновенная перезагрузка ресурсов и практически мгновенный запуск проекта в ходе разработки. Работа с ресурсами при этом не замедляется даже тогда, когда число файлов, входящих в проект, доходит до 1000 или даже до более чем 10000. Это ни в какое сравнение не идёт с более традиционными окружениями разработки, где используется бандлинг ресурсов, где всё ещё нормальным считается время запуска и перезагрузки проекта, исчисляемое несколькими секундами.
Исходная идея Snowpack возникла из простого, личного чувства неудовлетворённости, которое я испытывал на работе. Я трудился в команде разработки проекта Polymer, в Google. Там я участвовал в создании альтернативных инструментов сборки для (теперь уже мёртвой) спецификации HTML Imports. Сам инструмент получился весьма приятным, но он не очень хорошо работал с npm, а пользовались им буквально несколько человек.
Я в итоге ушёл из команды разработчиков Polymer, но проблема, которая меня беспокоила, никуда не делась. Почему бандлеры, вроде Webpack, стали единственным инструментом, позволяющим использовать npm-пакеты в браузерах? Что-то должно решить проблемы загрузки npm-пакетов и их запуска в браузере, но должно ли это «что-то» предусматривать бандлинг всего сайта? Snowpack был моей попыткой выяснить то, есть ли альтернативный способ работы с npm-пакетами в браузере.
▍Совет тем, кто занимается поддержкой опенсорсных проектов
Положите в основу своей разработки решение собственных проблем. Если вас что-то не устраивает — велика вероятность, что то же самое не нравится и другим разработчикам. Заведите себе привычку всё подвергать сомнению.
Урок 2: действуйте быстро, не увеличивайте размеры проекта
Когда вы работаете над новым проектом, вы редко когда знаете о том, какой именно код окажется важным в долгосрочной перспективе, и о том, какой код, в итоге, нужно будет удалить. Я, за время работы программистом, выбросил достаточные объёмы кода для того, чтобы понять, что иногда быстрое, сумбурное написание кода имеет определённую ценность. Если вы начинаете работу над новым проектом, некоторый беспорядок в его коде — это совершенно нормально.
Внутри Snowpack практически все сложные задачи решал Rollup. Snowpack был, на самом деле, всего лишь обёрткой для Rollup, которая занималась бандлингом отдельных npm-пакетов, а не всего сайта. Понимание того, что внутри Snowpack можно задействовать Rollup, сэкономило мне недели (а то и месяцы) рабочего времени.
Если говорить честно, то Snowpack, большую часть своей жизни, представлял собой всего лишь один единственный файл index.js.
Для того чтобы придерживаться избранного курса, я сосредоточился на единственной возможности: «Дай мне имя пакета, а я преобразую его в ES-модуль». Для большинства веб-разработчиков такая возможность, правда, оказалась бы слишком низкоуровневой. Честно говоря, Snowpack не привлёк значительной аудитории до тех пор, пока мы, в его версии 2.0, не добавили в проект встроенный сервер разработки и команду для сборки проекта. Но, даже без сервера, то, что Snowpack 1.0 был узкоспециализированным инструментом, оказалось интересным для определённого класса веб-разработчиков, совсем не пользующихся дополнительными инструментами или пользующимися ими в ограниченных масштабах.
Я рекомендую вам проверить свою идею и подготовить рабочую демо-версию проекта, сделав это как можно быстрее. На практике это означает выполнение следующих четырёх рекомендаций:
- Используйте существующие инструменты! Создайте форк похожего опенсорсного проекта или используйте внутри своего проекта существующий инструмент в том случае, если это поможет вам выиграть время.
- Пишите неаккуратный код! На самых ранних стадиях развития проекта вы, вероятно, не будете точно знать о том, что именно вы создаёте. Преждевременный рефакторинг кода иногда может быть хуже, чем полное отсутствие рефакторинга. Поэтому постарайтесь как можно дольше поддерживать гибкость своего кода.
- Придерживайтесь чётких ориентиров! Не надо оснащать проект недоделанными, едва работающими возможностями. Вместо этого сосредоточьтесь на очень хорошем решении одной задачи.
- Не пишите тесты! Сначала убедитесь в том, что создаёте что-то полезное, а потом уже тратьте свободное время на написание тестов. Нет ничего хуже, чем писать тесты для чего-то такого, чем в итоге никто не будет пользоваться.
Я знаю, что некоторые из моих советов выглядят неоднозначно и спорно. «Нет тестов??? Ересь!». Всё, что я могу сказать в защиту своего мнения, заключается в том, что этот подход хорошо сработал на нескольких моих популярных проектах, а так же — на бесчисленном количестве проектов, которые так и не стали популярными и ушли в небытие.
Очевидный минус рекомендации о том, что действовать надо быстро, заключается в том, что она невыполнима в долгосрочной перспективе. Быстрота действий означает и накопление технического долга, который когда-то неизбежно придётся платить, но, правда, лишь в том случае, если проект станет успешным. Как только наберётся некоторое количество пользователей, которым нравится то, что вы делаете, вам следует сдвинуть приоритеты в сторону стабильности, рефакторинга, тестирования кода. Подробнее об этом я расскажу в следующем материале.
Выплата технического долга может оказаться тяжёлой и утомительной работой. Но тут есть и положительный момент: если ваш проект никогда не «взлетит» — значит вы можете принимать поздравления! Вы не тратили время на тестирование чего-то такого, что никому не нужно.
▍Совет тем, кто занимается поддержкой опенсорсных проектов
Пишите неопрятный код, придерживайтесь чётких ориентиров, откладывайте дела, не являющиеся абсолютно необходимыми, до тех пор, пока вы не будете уверены в том, что работаете над чем-то реально полезным.
Урок 3: оперативно исправляйте ошибки
Вы только что получили свой первый баг-репорт. Ужас! Кто-то попробовал вашу разработку, а в ней что-то оказалось неисправным. Но самое важное тут то, что ваш проект кого-то настолько заинтересовал, что он сообщил вам об ошибке.
Одной из самых правильных линий поведения при работе над новым опенсорсных проектом является следующая: исправляйте ошибки сразу же после того, как к вам поступают отчёты о них. Сделать исправление ошибок самой приоритетной задачей в проекте, который уже дорос до изрядного размера, довольно сложно. Поэтому, пока можете, наслаждайтесь свободой и возможностью очень быстро реагировать на обращения пользователей.
Себастьян Маккензи (создатель Babel, Yarn, и, теперь, Rome) хорошо выразил вышеозвученную мысль:
Одна из причин успеха Babel заключается в том, как быстро и оперативно я мог исправлять ошибки и выпускать новые версии. Я стремился регулярно выпускать новые релизы в течение считанных минут после получения баг-репортов. Это было невероятно важно в ранние дни развития проекта, когда ещё мало кто им пользовался. Возможность быстро решать проблемы, мешающие пользователям работать, часто могла вдохновить их на использование Babel, несмотря даже на то, что при работе с ним они столкнулись с ошибкой.
▍Совет тем, кто занимается поддержкой опенсорсных проектов
Ваши первые пользователи — это самое важное. Сделайте исправление ошибок, о которых они сообщают, самой главной своей задачей, отодвинув всё остальное на второй план.
Урок 4: уделите внимание хорошему сторителлингу
Возникает такое ощущение, что программисты всегда брезгуют вопросами, связанными с маркетингом. Но ничего не поделаешь — тому, кто хочет, чтобы люди пользовались его разработками, нужно людям об этих разработках рассказать. Даже когда речь идёт о вирусном маркетинге, о «сарафанном радио», когда нечто становится популярным, как кажется, естественным образом, за этим обычно стоят вполне конкретные действия заинтересованных лиц.
Для начала достаточно поделиться сведениями о проекте с друзьями или коллегами и поинтересоваться их мнением о нём. И если ваш проект, в первый же день, не попадёт на первую полосу Hacker News — это совершенно нормально. В этот момент вам нужна лишь обратная связь и, возможно, ваши первые пользователи.
Когда вы готовы к тому, чтобы рассказать о проекте более широкой аудитории, сделать это можно несколькими способами. Один из популярных подходов заключается в том, чтобы рассказывать свою историю постепенно, в небольших, красиво оформленных публикациях. Именно так Себастьян Маккензи разжигал интерес аудитории к Rome, начав почти за 2 года до выхода проекта. Марк Далглейш тоже сделал большое дело, продвигая таким же образом в Twitter vanilla-extract.
Ещё можно проявить креативность и сделать что-то совершенно необычное. Бен Холмс отрывается по полной, записывая видео о своём новом проекте Slinkity перед маркерной доской.
Если говорить о Snowpack, то я решил рассказать нашу историю в одной большой публикации. Её подготовка заняла немало времени, но это дало нам пространство для обстоятельного раскрытия причин существования проекта. Я подумал, что нам нужна эмоциональная связь с нашей главной целью, которая заключалась в изменении подхода к веб-разработке. И даже хотя речь идёт всего лишь об одной публикации, она подняла большой шум, а после того, как она вышла, ещё довольно долго на неё ссылались и делились ей в соцсетях.
▍Совет тем, кто занимается поддержкой опенсорсных проектов
Продвигайте свой проект. Найдите такой стиль сторителлинга, который подходит вам и вашему проекту.
Урок 5: игнорируйте ненавистников, прислушивайтесь к пользователям
Если рассказ о вашем проекте когда-нибудь попадёт на Hacker News — ждите, что кому-то он очень не понравится.
Если вам будет сопутствовать удача — вы сможете увидеть разницу между невежественной и конструктивной критикой. Игнорируйте выпады невежд (ненавистников), а вот к конструктивной критике, по возможности, прислушайтесь. Если видно, что кто-то уделил время хотя бы тому, чтобы, с добрыми намерениями, понять ваш проект, в его отзыве обычно можно найти что-то ценное. Вам надо научиться узнавать такие отзывы.
Обычно конструктивная критика появляется тогда, когда очевидно то, что некто попытался понять смысл того, что вы сделали, но ещё не вполне разобрался в некоторых важнейших моментах проекта. Легко назвать такого человека тупицей и пойти дальше, но помните о том, что именно вы отвечаете за то, чтобы понятно рассказать другим о своей работе. Если кто-то не понял смысла того, что вы делаете, это обычно значит, что вы могли бы улучшить файл README своего проекта, или его документацию, или как-то поработать над сторителлингом.
▍Совет тем, кто занимается поддержкой опенсорсных проектов
Ненавистники, как говорится, всегда будут ненавидеть. Поэтому просто не обращайте на них внимания. Научитесь узнавать отзывы, написанные доброжелательными людьми и содержащие конструктивную критику.
Главный вывод: поддерживайте своих первых пользователей
Если вы начинаете работу над новым опенсорсным проектом — вам стоит постараться сделать так, чтобы ваши первые 10 пользователей испытывали бы от проекта исключительно положительные эмоции. Всё то, о чём мы говорили выше, в сущности, сводится к тому, чтобы так или иначе найти и поддержать этих первых пользователей. Если вы поведёте себя с ними правильно — это значит, что вы уже создали что-то, в чём есть какой-то смысл.
И если вам кажется, что для того, чтобы сделать всё то, о чём мы говорили, понадобится слишком много времени и сил, помните о том, что в сфере опенсорса нет правил. Предполагается, что всё, что связано с опенсорсом, должно быть позитивным и интересным. И если вы разрабатываете что-то исключительно для себя или для небольшой аудитории — вы вполне можете не принимать к сведению большинство тех советов, которыми я с вами поделился.
Есть ли у вас собственные опенсорсные проекты?
Комментариев нет:
Отправить комментарий