Никита Прокопов: «Делайте, что любите, — и люди к вам потянутся»
2026-02-21 22:10 Diff
https://skillbox.ru/media/code/nikita-prokopov-delayte-chto-lyubite-i-lyudi-k-vam-potyanutsya/

#статьи

  • 20 сен 2022
  • 0

Никита Прокопов: «Делайте, что любите, — и люди к вам потянутся»

Популярный open-source-разработчик — о том, как создать проект-бомбу, как его успешно раскрутить и остаться счастливым.

Иллюстрация: freepik / rawpixel.com / Freepik / Дима Руденок для Skillbox Media

Журналист, коммерческий автор и редактор. Пишет про IT, цифровой маркетинг и бизнес.
Сайт: darovska.com.

Clojure-разработчик и автор нескольких open-source-проектов: Fira Code, Alabaster, AnyBar, DataScript и Rum. Автор Telegram-канала «Стой под стрелой».

Меня зовут Никита Прокопов, или tonsky, или даже nikitonsky. Я программист, мне 37 лет, пожил в Новосибирске, Москве, Берлине. Начинал на Java, застал Python, Erlang, OCaml, Perl, Rust, Kotlin, C++, а восемь лет назад увлёкся Clojure. Это функциональный язык с диалектами под JVM и JavaScript. Я автор нескольких open-source-проектов, о которых и хотел бы рассказать.

Самая популярная из моих разработок — специальный программистский шрифт Fira Code.

Идею добавить лигатуры для программистов в моноширинный шрифт я украл у Hasklig. Лигатуры там классные, но сами буквы мне не очень нравились. Тогда я взял Fira Mono, который, по-моему, был гораздо красивее, и сделал с ним то же самое — добавил туда всякие ->, ! = и ++. Ну и убрал любые ассоциации с Haskell, потому что они обычно привлекают неудачу.

Результат выложил на GitHub — и он абсолютно неожиданно для меня, без всяких усилий, начал набирать популярность. Сейчас у Fira Code больше 60 тысяч звёздочек на GitHub. Это совершенно безумное число, больше, чем у Bitcoin, Angular, Webpack, Elasticsearch, Redis — настоящих, сложных проектов. И это точно шрифт номер один по популярности на GitHub.

До сих пор я приятно удивляюсь, когда вижу Fira Code у кого-нибудь на скриншотах, на сайтах или в презентациях. Особенно учитывая, что мне это почти ничего не стоило.

Так выглядит Fira Code
Изображение: личный архив Никиты Прокопова

Чуть больше усилий я приложил к раскрутке DataScript. Это такая in-memory-БД для Clojure и ClojureScript. Она родилась практически из любопытства, когда я понял, как именно сделана другая, более взрослая база данных Datomic от создателя Clojure Рича Хикки. И осознал, что, кажется, могу так же. Зачем, почему, кому это нужно — об этом вначале я вообще не задумывался.

Логотип DataScript
Изображение: личный архив Никиты Прокопова

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

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

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

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

Я считаю, что в каждом новом проекте должна быть хотя бы одна новая мысль. Что-то должно быть не так, как делали до сих пор. Иначе какой смысл за него браться?

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

Это очень «народный» проект. Сейчас есть сделанные мной версии под Sublime Text, VS Code, Idea и множество портов под другие редакторы и терминалы, которые сделали другие люди.

Так выглядит цветовая схема Alabaster
Изображение: личный архив Никиты Прокопова

Похожим образом у меня появилось несколько собственных плагинов для Sublime Text — потому что они нужны были лично мне, для моей рутины. В моём понимании это элементарное обустраивание быта: хочется, чтобы ежедневная работа была максимально комфортной. А кто лучше знает, как мне удобнее, чем я сам?

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

А я поступил наоборот — взял Sublime Text, в котором интеграция с Clojure была одной из худших, и постепенно вывел её на хороший уровень. Мой плагин — Clojure Sublimed — имеет самую педантичную подсветку синтаксиса Clojure и лучшую, на мой взгляд, интеграцию с nREPL в Sublime Text. Хочешь сделать хорошо — сделай сам.

Подсветка синтаксиса в пакете Clojure Sublimed
Изображение: личный архив Никиты Прокопова

Делать open-source-проекты и трудиться на работе одновременно надо очень аккуратно — велик риск выгорания. Но при определённых условиях это вполне возможно.

Мотивация «сделать что-нибудь популярное» плоха, потому что чисто статистически, скорее всего, ничего сверхуспешного вы не сделаете. Конечно, можно (и нужно!) на это надеяться, но вот рассчитывать на это было бы очень наивно. Весь мой опыт наблюдения за миром говорит о том, что предсказать успех практически невозможно.

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

Ну а если что-то выстрелит, это будет приятным бонусом. Главное в open source — очароваться, а не разочароваться.

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

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

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

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

Отрывок из Readme для Fira Code
Скриншот: личный архив Никиты Прокопова

К сожалению, навык объяснять и рассказывать очень недооценён у программистов. Часто встречаются проекты технически очень классные, но разобраться в них очень сложно.

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

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

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

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

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

Так что делайте то, на что хватает сил, и не переживайте по поводу всего остального.

Ничто не фрустрирует меня как пользователя, так сильно, как отсутствие коммуникации. Вот задал я вопрос, создал issue или послал pull request и… тишина. День, неделю, месяц. Год иногда.

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

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

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

Бесплатный курс по Python ➞
Мини-курс для новичков и для опытных кодеров. 4 крутых проекта в портфолио, живое общение со спикером. Кликните и узнайте, чему можно научиться на курсе. Смотреть программу