Я слушаю аудиокниги с 2014 года. За это время я перепробовал много разных сервисов: и с моделью “по подписке”, и те, что продают каждую конкретную книгу.
Ни один из сервисов меня не устраивал полностью, поэтому однажды я собрал всю свою коллекцию купленных книг и перенёс их на домашний сервер, где развернул Audiobookshelf.
У него был и есть потрясающе красивый неофициальный iOS-клиент, которым я пользовался какое-то время. Осенью 2024 года Google наконец показала Pixel 9 и я решил, что пора попробовать Android
С большим сожалением я обнаружил, что мне сложно использовать официальное мобильное приложение для Audiobookshelf, других тогда не было, а возвращаться к популярным стриминговым площадкам мне не хотелось.
Так родилась идея написать Lissen — красивый, минималистичный и удобный клиент для Audiobookshelf.
Сегодня я расскажу про разработку, релиз и опыт использования приложения, которое я писал для себя.
Идея приложения
Оригинальный клиент Audiobookshelf поддерживал каталогизацию, закладки, несколько типов контента, но при этом им было сложно пользоваться из-за перегруженных экранов и неинтуитивной для Android-приложения вёрстки.
В моей версии, основной идеей должен был стать чистый интерфейс, а не обилие фич. Я отрезал всё, что считал лишним, и в итоге сформулировал требования:
- Приложение поддерживает только аудиокниги и не поддерживает никаких других типов контента.
- У приложения интерфейс настолько чистый, что его не заметно при повседневном использовании.
- Приложение сразу должно поддерживать офлайн-кеширование книг, чтобы им можно было пользоваться без интернета.
- В приложении нет рекламы или платных функций, код будет доступен под какой-то максимально свободной лицензией.
Также я очень хотел сократ��ть количество переходов, которые должен сделать пользователь для того, чтобы начать слушать книжку.
Меня откровенно бесил UI подобных приложений, где из каталога я попадал сначала на экран с описанием книги, и только потом переходил к плееру. Это работало для магазина аудиокниг, но в случае с собственным сервером я уже заранее выбрал книги, которые хочу слушать.
После пары дней проектирования на салфетках два основных экрана приложения начали выглядеть приблизительно так:
Получается, что для успешного первого релиза приложение должно покрывать конкретный кейс, который больше всего мне был нужен:
Я хочу подключиться к серверу и начать слушать аудиокнижку с того места, на котором остановился, а если требуется — скачать файлы книги оффлайн и продолжить без интернета.
Технологический стек
Такой объём разработки показался мне более-менее реальным, и я начал выяснять, как вообще в 2024 году пишут подобные штуки.
Спустя пару часов общения с нейронками я начал понимать, какие технологии буду использовать:
- Для воспроизведения аудио по сети Google рекомендует использовать Media3.
- UI Android-экранов тот же Google предлагает строить с помощью Jetpack Compose вместо устаревших XML-файликов с разметкой.
- Для хранения метаданных о книгах и поддержки оффлайна лучше всего подойдёт Room, под капотом которого лежит понятный SQLite с поддержкой запросов.
- Работу с сетью я реализую на Retrofit, потому что просто к нему привык в предыдущих своих мобильных приложениях. И вообще я консерватор.
То есть мой клиент Audiobookshelf — это более-менее стандартный медиаплеер с возможностью обращаться к файлам по уже существующему API и складывать их в локальный кеш вместе с метаданными, чтобы использовать приложение без сети.
Это казалось несложным, и я решил, что за полтора-два месяца смогу выдать что-то пригодное для повседневного использования, занимаясь приложением после основной работы, где я бэкендер и пишу свои серверные штуки.
Архитектура приложения
Когда я анализировал похожие приложения для других платформ, я видел, что многие из них поддерживают не только Audiobookshelf. Большая часть приложений, такие как Plappa и ShelfPlayer, давали возможность подключаться ещё и к Jellyfin или Emby, или воспроизводить локальные файлы, сохранённые в памяти телефона.
В тот момент я пользовался Audiobookshelf несколько месяцев, и у меня все ещё не было уверенности, что это надолго. Поэтому свой клиент я хотел спроектировать так, чтобы в случае чего расширение на новые источники контента не стало большой проблемой.
В мире серверных приложений существует стандартный для таких дел подход. Обычно описывают агностичную структуру данных, с которой будет работать большая часть приложения, а взаимодействие с внешним API реализовывают как конкретную имплементацию общего интер��ейса.
При таком дизайне появляется возможность добавлять источники данных, не меняя ничего в основном коде приложения — при условии, что очередная апишка немного похожа на предыдущую
Я решил, что этот модульный подход приложения мне подходит, и скоро у меня была готова интеграция, кое-как прикрученная к UI приложения, чтобы было на чём её тестировать.
Проблемы модульности
Основное ограничение такого подхода — принципиальная изолированность каналов. Не только большая часть приложения ничего не знает об источниках данных, но и сами они ничего не знают друг о друге.
Я столкнулся с последствиями этой изолированности, когда попытался реализовать оффлайн-воспроизведение кешированных книг в виде отдельного независимого канала данных.
Если пользователь начинал слушать книжку в оффлайне, а затем подключался к серверу и перезапускал воспроизведение, важно было перейти к последнему месту — и не важно, что там помнит сервер.
Или если пользователь переключался между книгами, когда не был подключён к серверу, а затем вернулся в онлайн, в блоке с недавно прослушанными книгами требовалось сохранить историю навигации, чтобы не было ощущения, будто книги теряются.
В итоге я отказался от идеи поддерживать оффлайн как отдельный канал и выбрал более простую реализацию, которая использует оффлайн-кеш как дополнительный источник данных независимо от выбранного канала.
Второй проблемой при интеграции клиента с Audiobookshelf API стала сложная структура ответа.
Я ожидал, что книга состоит из файлов, которые воспроизводятся по ссылке. Оказалось, что у книги, кроме файлов, существует ещё и набор эпизодов, которые должны использоваться пользователем для навигации.
Я понимаю задумку разработчиков API: это способ дать пользователю возможность произвольно нарезать книжку на главы, никак не взаимодействуя с самим медиаконтентом. Это логично и удобно, но осознание пришло слишком поздно и стоило мне двух вечеров исправлений.
Я использовал для воспроизведения Media3, киллер-фича которого заключалась в возможности просто засунуть в него всю очередь воспроизведения и больше не думать о связности элементов. Фреймворк сам реализует и перемотку, и догрузку контента из сети, так что мне нужно было только правильно отображать воспроизводимый элемент, вытаскивая его порядковый номер прямо из медиаплеера.
После открытия эпизодов я понял, что это не работает. Если Media3 ожидает, что для воспроизведения в него запихивают очередь из файлов, а для навигации мне нужно отображать эпизоды, значит, придётся как-то связать их друг с другом — причём в уже почти готовом приложении.
Сначала я хотел построить что-то вроде списка файлов, которые относятся к одному эпизоду, чтобы обеспечить нормальную навигацию, но быстро пришёл к тому, что файлы и эпизоды могут располагаться как угодно относительно друг друга и не связаны ничем, кроме общего контейнера.
Тогда я перешёл к подходу, при котором вся навигация работает по абсолютному смещению. То есть, если пользователь прослушал 5 файлов и находится в середине шестого, то приложение в состоянии посчитать общий оффсет от начала и определить позицию, и отобразить нужный эпизод.
И наоборот — если пользователь переходит в другое место книги, приложение просто начинает воспроизводить её с определённого смещения от начала, рассчитывая нужную позицию в очереди плеера.
Это существенно упростило мне большую часть работы с навигацией, но потребовало значительно переписать часть приложения, которая отвечала за воспроизведение, и перетестировать поведение заново.
Первая версия приложения
Я зафиксировал минимальный набор функционала, который должен был быть доступен сразу: воспроизведение книг, синхронизация прогресса прослушивания и какой-никакой оффлайн для работы приложения без интернета.
Поскольку я не мобильный, а серверный разработчик, я мог быстро закодить сложную интеграцию с серверным API, организовать хранение и удержание сессии для синхронизации позиции в медиафайле и всякое такое.
При этом я не имел ни малейшего представления, как в 2024 году правильно организовать MVVM Android-приложения, какие части системного фреймворка использовать и чем мне уберечь мои экраны от убийства об операционку.
Большую часть этого сервисного кода я написал вместе с нейросетками. OpenAI как раз к тому времени выкатил свою новенькую O1, которая заменила мне StackOverflow и гугление ответов на мои глупые вопросы.
В итоге структура кода приложения мало отличалась от той, которую рекомендует Google в своих гайдах. Jetpack-компоненты взаимодействовали с вьюмодельками, которые обращались к репозиториям, а те — делали запросы к выбранному медиаканалу через Retrofit. Всё как в большинстве стриминговых приложений, с той лишь разницей, что адрес сервера нужно было сохранить отдельно.
На кодирование запланированного функционала действительно ушло полтора месяца. Я не брал на работе отпуск, чтобы сосредоточиться на сайд-проекте, но дома не занимался ничем, кроме разработки. С десяти до шести меня ждали рабочие проекты, с шести до одиннадцати — приложение для аудиокниг.
В какой-то момент я смог сказать, что приложение стало напоминать нечто рабочее.
Такой режим, правда, меня изрядно вымотал. Мне повезло, что последние строчки кода я дописал как раз к началу угасания энтузиазма.
Иконка приложения
Сверстать экраны приложения так, чтобы оно выглядело чисто и лаконично, мне помогли гайды от Гугла, нейросети и похожие приложения от других авторов. Сложнее было придумать, как назвать клиент и нарисовать для него какую-нибудь иконку — причём хотелось связать их общей идеей, которая помогла бы сделать приложение узнаваемым.
Отрисовка иконки заняла у меня чуть ли не половину времени от всей разработки. Приложение ассоциировалось с уютом и комфортом, и я хотел сначала нарисовать кота в наушниках, но так и не придумал к нему достойную идею.
Тогда я поговорил с нейросеткой о том, чем можно заменить кота, и машина, перемножив пару сотен матриц, оригинально предложила мне лису. Практически сразу я понял, что могу назвать приложение Lissen. Смотрите сами:
- Романо- и германоязычная аудитория увидит схожесть со словом Listen и свяжет это с аудиокнижками или хотя бы просто с “аудио”.
- Славяноязычные пользователи, скорее всего, заметят какую-никакую связь части названия с рыжей лисьей мордой.
Я быстро поискал в сети наличие приложений и сервисов с таким названием, не нашёл ничего крупного и следующие два дня перебирал разные варианты нейрокартинок, чтобы найти подходящий.
Наконец, я получил более-менее приличную картинку и попросил девушку поправить артефакты нейронки. Затем последовала несложная векторизация изображения и адаптация под требования современного дизайна:
Теперь у приложения было всё, что нужно: более-менее стабильно работающий минимальный набор фич, название с милой картинкой и огромное желание выкатить это в продакшн.
Пререлиз
Я решил отложить публикацию приложения в сторы и сначала попробовать найти лояльное сообщество пользователей, с которым смогу собрать какой-никакой фидбек с минимальными шансами провала.
Пара часов поисков привели меня на Reddit, в профильный саб, где пользователи часто обсуждали проблемы официального мобильного приложения.
25 октября я написал в нём пост, где оставил ссылку на APK-файл на GitHub и предложил попробовать альтернативный клиент.
Большая часть ночи прошла в ответах, а к утру ста��о понятно, что Lissen не просто вежливо приняли.
Очевидно было, что приложение нашло свою целевую аудиторию из технически подкованных пользователей.
Мне оставляли дельные комментарии, отсыпали звёздочки на GitHub, задавали вопросы, на которые у меня не было ответа, и обещали попробовать приложение на ближайших выходных.
При этом часть пользователей не смогла подключиться к своему серверу. Некоторые писали, что приложение хорошее, но им критически не хватает какого-то функционала. Кто-то сказал, что будет ждать релиза на Google Play и вот тогда уже оценит клиент.
Всё это привело меня к трём важным выводам:
- Я написал что-то полезное, и это можно развивать в надежде получить больше пользователей.
- Никакой поддержки альтернативных серверов вроде Emby приложению не требуется. Вместо этого лучше сосредоточиться на типах контента, которые Audiobookshelf поддерживает, а моё приложение — ещё нет.
- Мне срочно нужно поддержать тёмную тему.
Детские проблемы
Когда выходные закончились и радость от успешного релиза начала сходить на нет, пришло время разобрать фидбек типа “всё очень круто, но ничего не работает”. Обнаружились три основных проблемы:
Часть пользователей не использовала SSL для доступа к своим домашним серверам, подключалась по IP-адресу. Android-приложения по умолчанию запрещают такие подключения, и требовалось явно разрешить это, чтобы дать таким пользователям рабочее приложение.
Первая версия приложения поддерживала только аудиокниги. Это было моё осознанное решение, чтобы поскорее выпустить первый релиз, но я забыл ограничить типы библиотек, которые доступны для выбора. В итоге пользователи могли запросить неподдерживаемый контент — и приложение падало с грохотом.
Поддержку эпизодов я писал в последний момент и не успел внимательно её оттестировать. Иногда навигация приложения не справлялась, и пользователя выбрасывало в другую часть книги при попытке вернуться на 10 секунд назад.
Все эти баги, к счастью, оказалось несложно поправить за пару дней. При этом после каждого фикса я благодарил пользователей за комментарии, а те не забывали отвечать, что всё заработало.
ACRA
Быстро я пришёл к выводу, что на общении с людьми далеко не уедешь. Мне нужно было интегрироваться с каким-нибудь креш-трекером, чтобы знать больше хотя бы о падениях.
Lissen был и остаётся полностью свободным, поэтому тянуть в приложение Google-аналитику, которая собирает в том числе нужные мне стектрейсы, не хотелось. Очередной диалог с нейронкой привёл меня к ACRA — небольшой библиотечке, которая может репортить креши на отдельный бэкенд.
У меня крутилась арендованная ещё в седой древности виртуалка, поэтому поднять там ещё один джарник с бэкендом и настроить новое доменное имя оказалось несложно.
Спустя несколько дней у меня был список частых причин падения. Как оказалось, самая частая из них — нестабильность самого Media3, которая починилась значительно позже, с обновлением платформы Android.
Скриншотов тех самых багов у меня не осталось, поэтому придется показывать что есть
В остальном приложение как будто бы работало, и я смог сосредоточиться на запросах пользователей.
Github Issues
Общение с ними я поддерживал всё на том же Reddit, плавно переводя их на GitHub проекта, чтобы в результате общения оставались какие-то артефакты и можно было построить нормальный релизный цикл.
При этом я решил, что относительно просьб и предложений я займу следующую позицию:
- Я автор, и я владею видением по развитию приложения. Только я решаю, какие запросы окажутся выполненными, а какие не соответствуют генеральной линии и будут отброшены.
- Хотелось бы, чтобы пользователи рассказывали о проблемах и опыте использования больше и чаще, чем предлагали готовые решения.
- Отказы — это нормально. Если пользователь говорит, что я глух к просьбам и не делаю того, чего он просит — часто он хочет какое-то другое приложение, а не Lissen.
Это суровая модель поведения, но в итоге она позволила мне удержать Lissen от скатывания в bloatware и искать решения проблем вместе с пользователями.
Одним из частых запросов, с которым я встречался, была просьба добавить таймер автовыключения. Как оказалось, многие люди засыпают под аудиокниги и хотят, чтобы воспроизведение автоматически прекращалось после какого-то времени или в конце главы.
Сам я никогда таким не пользовался, а поэтому как должен выглядеть таймер — не знал. К счастью, в других приложениях было несложно найти хороший вариант реализации, и меня позабавило, что как минимум в трёх популярных стримингах эта фича выглядит и работает абсолютно одинаково. Видимо, я не один такой.
Другим популярным запросом стали подкасты.
Реализовать их поддержку оказалось просто: я ожидал, что многие пользователи захотят поддержку этого типа контента. Поэтому заранее знал, реализую их как отдельный медиа-канал на механизме, который позволял бы приложению интегрироваться с другими серверами типа Plex и Emby.
Это оказалось хорошим решением ещё и потому, что API Audiobookshelf для книг очень сильно отличается от API для подкастов, и проще было рассматривать их как два независимых источника контента, чем пробовать найти что-то общее.
Большой проблемой здесь стало скачивание выпусков в оффлайн-хранилище устройства. Моя наивная реализация, позволявшая скачать аудиокнигу целиком, не годилась для подкастов, которые могли вестись годами и состоять из тысяч часов выпусков.
Я очень хотел отдать релиз как можно скорее, а хорошее решение требовало времени, поэтому я временно запретил скачивать подкасты вообще, пообещав вернуться к вопросу позже.
Я считал, что делаю эту фичу для других пользователей, как и таймер, но пока тестировал интеграцию в разработке — втянулся и теперь постоянно слушаю какие-то выпуски по дороге и в поездах.
Магазины приложений
Примерно к этому моменту я решил, что приложение достаточно зрелое, чтобы распространять его не только через посты на Reddit и свой гитхаб, но и через разные аппсторы.
До этого у меня уже был опыт публикации приложения в Google Play в 2016, но с тех пор многое изменилось.
Во-первых, магазинов приложений стало больше. Если раньше был только Google Play, с которым не было особых проблем, то к 2024 году появилось достаточно популярных альтернатив.
Во-вторых, сам Google сильно закрутил гайки разработчикам и вместо ненавязчивой постмодерации приложений по запросу перешёл на предварительную проверку загружаемого пакета.
Рассудив, что с Гуглом у меня обязательно будут проблемы, я решил, что заодно опубликую Lissen в тех альтернативных магазинах приложений, которые это позволят.
Первым в этом списке стал F-Droid. Это стор свободных приложений, который смог очень хорошо организовать процесс добавления новых пакетов. Я сделал мерж-реквест в репозиторий с метаданными, прошёл ревью, немного поругавшись с мейнтейнерами, и стал ожидать. Через пару дней приложение стало возможно установить из каталога, а обновлялось оно самостоятельно, используя механизм релизов гитхаба.
К сожалению, никаких данных о количестве установок магазин не даёт, поэтому я до сих пор не знаю, насколько это популярный способ для распространения Lissen, и считаю его резервным каналом доставки обновлений.
Вторым в очереди магазинов стал RuStore. Я не ожидал от площадки больших охватов, а просто хотел поддержать стор своей активностью.
С ним у меня всё прошло хорошо: модератор попросил поднять какой-нибудь демо-сервер Audiobookshelf, чтобы у него была возможность проверить функции приложения, немного потрогал основной функ��ионал и пропустил приложение.
Как я и ожидал, большой популярности это приложению не принесло: на 30 марта 2025 года приложение из RuStore установило 108 человек, поэтому я поддерживаю актуальность Lissen там скорее на всякий случай.
Также я пытался опубликовать приложение в AppGallery, но быстро свернул лавочку. Для размещения пакета магазин требовал добавить в зависимости библиотеку с телеметрией, что либо выводило Lissen из категории свободного ПО, либо требовало от меня поддерживать отдельную версию.
И, наконец, Google Play, который, как мне показалось, сейчас ориентирован скорее на корпоративных разработчиков и большие студии, чем на инди и опенсорс.
Первая попытка пройти премодерацию закончилась тем, что у меня попросили предоставить демо-сервер — как и в случае с RuStore.
Второй отказ я получил потому, что модератор вместо https://demo.lissenapp.org пытался подключиться к ...listenapp.org/, который, конечно же, был недоступен.
И третий отказ последовал после того, как модератору не понравилось упоминание оффлайн-прослушивания в описании. Я до сих пор не знаю, нашёл ли он кнопку с облачком и стрелочкой, но после того как я убрал строчку из описания — приложение наконец-то стало доступно в Google Play спустя три недели попыток.
Я был настойчив в своём желании добиться от Google принятия моего приложения, потому что понимал, что при всех его проблемах Google Play — это для многих единственный способ получить приложение на своём телефоне. Забегая вперёд, на сегодняшний день этот канал принёс мне почти 2000 установок и более 800 активных устройств.
Локализация
Согласно той же статистике от Google Play, Lissen был популярен прежде всего в США, Британии, Австралии и Канаде. Это англоговорящие страны, поэтому меня устраивало наличие локализации приложения только на русский и английский, а планов поддерживать другие языки не было.
Такие планы нашлись зато у моих пользователей. В середине декабря пользователь с ником thehijacker завёл мне на гитхаб issue с просьбой позволить ему добавить в приложение поддержку его родного словенского языка.
Так Lissen обзавёлся собственной страничкой Weblate, интегрированной с git-проектом, и, спустя пару дней, получил локализацию на словенский язык:
Эта идея многим пришлась по душе: спустя несколько месяцев приложение поддерживает уже 11 языков, включая такую экзотику как тамильский и китайский.
Мне же остается только не забывать включать контрибьюторов в список авторов и собирать новые версии приложения, каждый раз радуясь их активности в проекте.
Редизайн
Пользователи активно просили исправления старых багов и поддержки новой функциональности, поэтому несколько месяцев подряд Lissen обрастал фичами.
Я добавил возможность просматривать больше метаданных книги, чем планировал изначально, поддержал настройку скорости воспроизведения и поддержал поиск по каталогу книг.
Релизный цикл был короток, и у меня часто не хватало времени продумать, как очередная фича будет выглядеть в контексте всего приложения. Часто я вообще брал первое UI/UX-решение, казавшееся мне разумным, и в итоге Lissen начал терять ту чистоту интерфейса, ради которой создавался.
Я взял паузу в разработке нового функционала и попробовал пересобрать макеты приложения так, чтобы они начали состоять из одинаковых блоков. В несколько итераций я пришёл к состоянию, при котором в приложении остался минимальный набор компонентов.
Например, вот так изменилась страница настроек приложения
Это решило сразу две проблемы:
Во-первых, у пользователя появилось право ожидать от одинаковых элементов одинакового поведения.
Во-вторых, я получил возможность переиспользовать готовые блоки для новых фич.
Это не стало полноценной дизайн-системой, но всё же в мерж-реквестах с исправлениями от контрибьюторов я стал замечать, что UI-компоненты переиспользовались правильно, как будто сами собой, без моих замечаний на ревью.
Идентификация личности
Я создал свой аккаунт разработчика Google Play для того, чтобы опубликовать там свою курсовую в 2016 году. После этого, он большую часть времени не использовался, а все новые политики Google каким-то образом обходили меня стороной.
Из-за этого я ожидал проблем с работой приложения в Google Play, и рано или поздно они должны были проявиться.
В конце декабря 2024 года Google прислал мне письмо с просьбой подтвердить личность как разработчика, угрожая в случае отказа удалить мои приложения и заблокировать учётку.
Я попробовал прислать им фотографии моего паспорта и сканы банковских выписок, в каждой из которых были указаны одни и те же имя и адрес.
По разным причинам Google раз за разом отвергал эти документы, и спустя неделю попыток я решил, что с меня хватит, и улетел отмечать новогодние праздники в Сеул.
Я собирался попробовать ещё раз прислать им тот же набор документов и надеялся, что волшебная шляпа бюрократии случайным образом окажется ко мне более снисходительной.
В случае, если и в этот раз мои документы были бы отвергнуты по любой причине, я собирался прикрутить к приложению простенькую модалку, где объяснил бы ситуацию и просил бы пользователей переустановить приложение из F-Droid, чтобы получать свежие обновления. Это сократило бы охват, но всё равно выглядело бы лучше, чем просто пропавшее без особых причин приложение из Google Play без указаний, где его теперь искать.
К счастью, очередная банковская выписка попала на стол к модератору в нужный момент, и этот план не пригодился. Но я до сих пор держу его в голове на случай новых проблем.
Донаты
Я не планировал монетизировать приложение, о чём много раз писал и на гитхабе, и на Reddit. Тем не менее, отказываться от добровольных пожертвований не стал и после третьей по счёту просьбы добавил такую возможность.
Поскольку основная аудитория Lissen на тот момент состояла из американцев, британцев и канадцев, я зарегистрировал аккаунт на Stripe и завёл страничку на ko-fi, добавив ссылку на неё на страничку с настройками приложения.
За всё время существования этой странички я получил 20 пожертвований на разные суммы — и этого хватило, чтобы на несколько лет окупить работу демо-сервера, необходимого для модерации приложения в RuStore и Google Play.
Я не собираюсь зарабатывать на Lissen, но тонкий ручеёк донатов каждый раз поднимает мою мотивацию уделять время этому проекту. Донаты — это скорее источник дофамина, чем способ заработка, так что я рад любым пожертвованиям, но никогда не буду на них настаивать.
Lissen сегодня
К 30 марта 2025 года Lissen превратился из попытки наскоро заменить официальный клиент Audiobookshelf в полноценное самостоятельное приложение, локализованное на 10 языков и с более чем тысячей пользователей.
Приложение доступно для скачивания в крупных сторах, а на страничке клиентов для Audiobookshelf есть упоминание Lissen.
Я очень рад, что могу выпускать и поддерживать полезное приложение, и ещё больше рад, что потратил это время не зря. За полгода существования приложения я переслушал достаточно книг и подкастов, чтобы считать затею успешной.
Про свободное ПО
Lissen — не первый мой опенсорсный сайд-проект, и, наблюдая за тем, как он и все остальные мои приложения, телеграм-боты и сайты в интернете развиваются, живут и умирают, я могу собрать несколько общих черт для каждого из них:
— Для опенсорса очень важно комьюнити, и многое зависит от первого впечатления. С Lissen мне повезло сразу найти лояльное и дружелюбное сообщество, что дало мне возможность довести приложение до пригодного к использованию состояния. Другие проекты, которым повезло меньше, как правило, умирали, так и не получив приличной известности.
— Очень важно внимательно работать с потоком заявок от пользователей, но при этом оставаться твёрдым и последовательным в отстаивании концепции проекта. Не нужно пытаться угодить всем. Всегда будет часть пользователей, которые искали какой-то другой продукт, но по ошибке нашли твой и теперь пытаются подогнать его под свои ожидания.
— Бесплатное ПО требует такой же, если не большей, чем коммерческая разработка, вовлечённости в работу. По сути своей, решение “не брать денег за продукт” принадлежит авторам, но не даёт никаких скидок от ожиданий пользователя.
— Большие корпорации, которые чинят проблемы маленьким инди-проектам, редко делают это со зла или от умысла. Большая часть неприятных ситуаций происходит из-за огромного размера компаний типа Google или Amazon и неумения их работать с не-корпоратами. С этим нужно просто смириться и чаще трогать траву.
Если что-то можно отрезать от первых версий приложения, чтобы поскорее отдать это в использование, — в большинстве случаев стоит это сделать. Потому что в случае с сайд-проектами энтузиазм разработчика — самый быстрорасходуемый ресурс. Если он закончится до того, как у проекта появится поддержка комьюнити, есть риск вообще ничего не выпустить.
Разумеется, Lissen — это опенсорсный продукт, который останется бесплатным и свободным для всех, кто желает им пользоваться. Я благодарен авторам локализаций, модераторам Weblate и пользователям, которые донатят, присылают мерж-реквесты с правками, предлагают клёвые идеи и участвуют в их обсуждении.
Я продолжу работать над проектом до тех пор, пока к нему сохраняется интерес и позволяют мои возможности, а после, надеюсь, у него появятся другие ментейнеры.
