Что отличает удачную идею для пет-проекта от неудачной

Многие программисты поддерживают так называемые pet-projects, или проекты для души. То есть, нечто, чему уделяется свободное время, и что как правило не приносит денег. Для кого-то это просто интересный способ провести время, вместо сериалов и YouTube. Кто-то таким образом развивается профессионально и/или изучает новые технологии. В целом, мотивация здесь может быть самой разной.

На протяжении лет я начинал и забрасывал множество пет-проектов. Одним из них является данный блог. По состоянию на сегодняшний день, это самый живучий из моих проектов. В качестве других примеров можно привести серию самодельных радиолюбительских трансиверов. Трансиверы получались переменного качества, но с каждым новым экземпляром я лучше понимал, как надо, а как не надо их делать. Больше всего я доволен трансиверами HBR/MK2 и AYN/4B.

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

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

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

Проект должен иметь реалистичный объем работ. Реалистичный – не значит маленький. Это значит, тот объем, который вы реалистично способны выполнить. Я реалистично могу написать змейку для советского ретро-компьютера. Это простая игра, где нет музыки, а ассеты могут быть нарисованы попиксельно в Gimp. Однако я вряд ли смогу написать более-менее серьезную трехмерную игру. Просто я не умею создавать трехмерные модели, музыку и звуковые эффекты, интересные сюжеты, писать диалоги, считать игровой баланс, ничего не знаю о дизайне уровней, и так далее. Такие игры разрабатываются не в одиночку, а командами. Максимум я могу создать трехмерную демку. Может быть, если уделить этому N лет, то смогу написать простенький движок. Но не полноценную игру. Трезво оценивайте свои силы.

Если проект крупный, то необходимо иметь хотя бы приблизительный план работ, а.к.а. roadmap. Суть здесь не столько в самом плане, сколько в возможности декомпозиции большой задачи на более мелкие. Например, я решил делать трансивер с «мозгами» на STM32 и Si5351 в качестве VFO. Мне понадобится драйвер Si5351 для STM32. Я ищу в интернете, и понимаю, что такого драйвера не существует. Значит, первым делом мне предстоит написать свой драйвер. Быть может, до трансивера дело и не дойдет, но драйвер сам по себе является неплохим пет-проектом.

Перед началом проекта будет не лишним проверить, как много существует аналогичных проектов. Например, мне было бы интересно написать программу, реализующую алгоритмы цифровой обработки сигналов. Такие алгоритмы применяются в SDR-трансиверах. Однако существует уже много открытых SDR-трансиверов – mcHF и его форки, Волк, Маламут, T41-EP, Brass, и другие.

Сомневаюсь, что мой SDR выйдет лучше существующих. Да и рабочий самодельный трансивер у меня уже есть. Он не является SDR, но в чем-то может соревноваться даже с SDR промышленного производства. А последние по крайней мере не уступают самодельным. Кроме того, мне хотелось бы не только вечно паять трансиверы, но и использовать их по назначению. Поэтому алгоритмы ЦОС, пожалуй, я применю в каких-то других задачах. Однако если вам лично интересно заниматься SDR, то мое мнение по данному вопросу, ровно как и чье-либо еще, не должно вас волновать.

По опыту, лучше всего получаются проекты, которые вы же потом и будете использовать. Так данный блог – это записная книжка, к которой я сам часто обращаюсь. Самодельный трансивер – это аппарат, который имеет удобный лично для меня интерфейс. К тому же, он полностью открытый, а значит, ремонтопригодный. Аналогично, не так давно опубликованный Wireless Explorer – это удобный лично для меня графический сканер Wi-Fi сетей.

Технически, пет-проекту не обязательно быть open-source. Однако открытость имеет важное преимущество. С открытым проектом может ознакомиться любой желающий. А значит, автор может получить обратную связь. Обратная связь – это новые идеи и знания, а также исправление мелких дефектов, которые могли быть упущены. Иногда на базе открытых проектов создаются новые открытые проекты, которые в чем-то превосходят оригинальный.

Но у этой медали есть и обратная сторона. Если проект станет популярным, то к вам начнут приходить люди и чего-то хотеть. Так мой драйвер OLED-экранчиков для STM32 за восемь лет существования собрал более 1000 звездочек на GitHub. Мне достаточно часто приходят issues с вопросами и пожеланиями, а также pull requests. Если я принимаю pull request, то его неплохо бы проверить на реальном железе. Если не принимаю, то неплохо бы объяснить автору причину. На это я трачу свое свободное время, которого у меня не то, чтобы было в избытке.

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

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

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

А по каким критериям вы выбираете идеи для пет-проектов?