Где взять идею для open-source-проекта и как его продвигать

react-colorful

react-colorful — это лёгкий компонент для выбора цвета для React- и Preact-приложений. Очень небольшая тулза — всего 2,5 КБ, но спрос на неё высокий. Проект вырос из рабочей задачи — как и большинство open-source-решений: они, как правило, возникают, когда ты решаешь какую-то проблему, выясняешь, что качественного готового инструмента для неё пока нет, в итоге делаешь собственный и выкладываешь его под свободной лицензией.

Так вышло и у меня. Когда у нас в resume.io возникла задача дать пользователям возможность перекрашивать свои резюме, мы не смогли найти подходящего колор-пикера: да, был react-color с двумя миллионами загрузок в неделю, и меня, как, наверное, и многих, подкупила его популярность. Однако на деле он вообще не соответствовал современным требованиям к UI-компоненту: очень много весил, тормозил, не работал на телефонах, не был доступным и устанавливал больше десятка других пакетов — правда, выяснил я это, только когда взял его к себе в проект.

Разочаровавшись в существующих решениях, я вдохновился создать react-colorful. Код написал за несколько дней. А вот продвижение оказалось сложной задачей. В работе над open-source-проектами это, наверное, самая сложная часть. Я потратил несколько месяцев — только после этого пакет стал по-настоящему популярным, а разработчики начали использовать его в своих проектах без опасений. Я призвал на помощь коллег, и мы вместе сделали добрую сотню твитов о react-colorful, написали несколько статей и публикаций на Reddit и dev.to, связались с администраторами десятка тематических Telegram-каналов и попросили их рассказать о нашей библиотеке.

Также в работу по продвижению я включаю ещё и процесс поиска и «продажи» своего пакета потенциальным «клиентам»: я искал проекты, которые используют react-color, показывал их авторам цифры и объяснял, что колор-пикер может быть легче, быстрее и лучше во всех смыслах. Если им нравилась идея и они соглашались на миграцию, я заменял react-color на свой react-colorful в их кодовой базе. Таким образом мой пакет получил первые скачивания и начал вызывать доверие у разработчиков.

Всё это — довольно большая и кропотливая работа, она потребовала много сил. Но в итоге время и ресурсы окупились: проект положительно сказался на моей популярности: за последний год меня позвали гостем в несколько известных подкастов, пригласили вести коллективный твиттер jsunderhood и включили в состав программного комитета HolyJS. Вообще, вся эта история довольно поучительная, поэтому я выступил с докладом «Do not choose dependencies blindly, do open source» — рассказал, как запустил свой колор-пикер и почему популярные open-source-проекты часто оказываются не самыми качественными.

По большей части react-colorful я делал своими силами, но плотно советовался с другими ребятами — если ты занимаешься open-source-проектом, полезно иметь open source buddy, то есть коллегу, у которого тоже есть open-source-проекты. У меня такой коллега был, и я часто советовался с ним по разным вопросам: как организовывать API, как лучше оформить документацию. Это было классно, потому что работать в вакууме и двигаться вслепую тяжеловато.

В результате нашей активной работы над продвижением проект заметило много людей и в итоге к нам присоединились другие ребята, которым понравилась философия проекта и которые тоже вносят свой вклад в его развитие. Например, сейчас у меня есть постоянный контрибьютор, студент из США. Он пришёл и переписал весь код на TypeScript — а это достаточно большое изменение, которое серьёзно увеличило стабильность компонента.

colord

Создавая react-colorful, я разобрался в самых разных цветовых пространствах, в методах конвертации из одного пространства в другое и вообще в теории цвета. И в какой-то момент подумал: «А ведь я мог бы сделать не только колор-пикер, но и библиотеку, которая низкоуровнево отвечает за конвертацию и манипуляции с цветами».

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

Сейчас у colord и react-colorful суммарно почти 4 млн скачиваний в неделю (а это довольно много) и они используются в ряде очень известных проектов, таких как Storybook, Grafana, WordPress и cssnano. Так что я могу считать себя немножечко успешным опенсорсером :)

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

Если ты единственный мейнтейнер open-source-проекта, то всегда находишься в некоем вакууме. Например, ты реализовал набор функций, которые тебе нужны по работе, и таким образом покрыл свои юзкейсы, а у других людей может быть свой опыт, задачи, с которыми ты не сталкиваешься. Поэтому они могут предлагать такие идеи, о которых ты даже подумать не мог.

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

Классно то, что обычно они создают issue и спрашивают, нужно это продукту или нет. У меня и в react-colorful, и в colord прилетают подобные issue: «Я видел новый метод проверки разницы между цветами. Давай реализуем». И я отвечаю: «Да, давай». Автор идеи реализует её, создаёт pull request, мы проверяем код — и всё.

Зачем вливаться в Open Source

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

Респект от работодателей. Например, ты делаешь новый open-source-проект с нуля — и получается отличный кейс для портфолио. Но если ты новичок и у тебя пока пустое портфолио, ты можешь написать, что участвовал в существующем популярном open-source-проекте, помог довести до ума документацию и исправил несколько багов. Это тоже плюс при трудоустройстве. Любая работа в Open Source — это похвальное дело, которое положительно скажется на профессиональной оценке.

Прокачка навыков. Участие в Open Source — неважно, в новом или уже существующем проекте — помогает развиваться. Для нового проекта лучше выбирать интересную тему, которую ты не можешь полноценно изучить в рамках рабочих задач. Например, по работе ты создаёшь лендинги, а хочешь разобраться в шифровании. Тогда можно сделать свой открытый проект по шифрованию данных или присоединиться к готовому проекту, посмотреть, как он сделан. Я так прокачался в работе с цветами, хотя по работе мне такие знания не нужны.

Личный бренд. Участие в Open Source влияет на популярность и личный бренд. У меня именно так и вышло: благодаря Open Source я набрал тысячу подписчиков — просто рассказывая про свой проект.

Нетворкинг. Работая над открытыми проектами, можно познакомиться с новыми интересными людьми. Например, в уже существующем проекте легко общаться с другими участниками, вместе решать проблемы. И этими знакомствами потом вполне можно воспользоваться: получить приглашение на конференцию или поучаствовать в каком-то интересном проекте.

Как влиться в проект

Не стоит бояться участия даже в крупных open-source-проектах. Важно понимать, что мейнтейнеры — очень загруженные люди, особенно если их проект пользуется популярностью. На них валятся десятки, а то и сотни разных issue — и всё это приходится разгребать. При этом они пытаются выпускать новые фичи, оформлять документацию. И если мейнтейнер пилит новую фичу, то у него может не остаться времени на исправление мелких багов, обновление или перевод документации на другой язык. А значит, полезным окажется даже новичок: например, можно среди issue, которые есть в проекте, отобрать те, с которыми вам под силу справиться. Или просто найти в репозитории issue с отметкой good-first-issue и попытаться закрыть их.

Если же вы решите что-то улучшить, рекомендую сперва сделать небольшое issue, спросить в нём, стоит ли этим заниматься. Если мейнтейнер одобрит, то вперёд. Иначе есть риск сделать что-то ненужное, что потом не включат в релиз продукта. В итоге можно две недели писать код, а потом выбросить его, потому что, по мнению мейнтейнера, он не соответствует философии проекта.

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