Так выглядела Ubuntu Touch, когда проект анонсировали 2 января 2013 года. Изображение: Canonical
Теперь, когда телефонов и планшетов Ubuntu больше нет, я бы хотел поделиться мыслями, почему проект провалился и какие уроки из этого можно извлечь.
Чтобы резюмировать моё участие в проекте: я использовал Ubuntu Touch на Nexus 7 постоянно и периодически с момента его анонса в 2013 году и до декабря 2014 года, начал работать над приложениями Click в декабре 2014-го, начал писать статью из 15-ти частей “Hacking Ubuntu Touch” об устройстве системы в январе 2015-го, был инсайдером по программе Ubuntu Phone Insider, получил Meizu MX4 от Canonical, организовал конкурс для разработчиков приложений UbuContest и был его спонсором, работал над баг-репортами и приложениями примерно до апреля 2016 года, а затем продал или переделал все мои оставшиеся устройства в середине 2016-го. Так что думаю, что могу поделиться какими-то мыслями о проекте, его проблемах и о том, где мы могли сработать лучше.
Пожалуйста, обратите внимание, что эта статья не затрагивает проект UBPorts, который продолжает работать на операционной системе телефонов, Unity 8 и другие компоненты.
1. Он не попал в прибыльную нишу
Ubuntu для ПК, ноутбуков и серверов сделал это относительно легко. Почти все эти устройства позволяют вам установить любую операционную систему, которая умеет работать с аппаратным обеспечением, так что когда Ubuntu появилась в 2004 году, её крупнейший конкурент (Microsoft) был очень уязвим. У Windows была плохая репутация, высокая цена и эта система по-свински пожирала ресурсы, так что Ubuntu оставалось всего лишь быть менее раздражающей, дешевле, легче в установке и лучше работать на более старых компьютерах. И это в точности что она сделала. У Windows и сейчас сохранилась плохая репутация, теперь даже она шпионит за пользователями, и она по-прежнему довольно дорога. Так что Ubuntu Desktop не нужно было тогда и не нужно сейчас делать многое, чтобы сохранить и увеличить аудиторию пользователей.
На серверном рынке Windows, Red Hat и особенно SUSE воспринимались как слишком консервативные решения, слишком неповоротливые и опять же слишком дорогие. Подписка Red Hat Enterprise стоит несколько сотен долларов в год, и эта подписка даже необязательно включает в себя живую человеческую поддержку. Быстроразвивающаяся, менее дорогая альтернатива с некоторой поддержкой от индустрии и гигантским количеством пакетов в репозиториях должна была заинтересовать многих, особенно для облачных решений. То, что Ubuntu выбрали образцовой операционной системой для OpenStack, тоже во многом помогло.
Но с мобильными устройствами всё иначе. Вы не можете просто прошить любую операционную систему на своём телефоне или планшете. Каждое устройство поставляется с кастомным, специально подготовленным билдом Android. Когда Ubuntu объявила о выходе на мобильный рынок в 2013 году, ни Android, ни iOS не были уязвимы, в отличие от ситуации на десктопном рынке. Люди призывали к созданию третьей альтернативы не потому что Android и iOS имели плохую репутацию или какие-то ограничения, или неудобны в использовании, а потому что они (справедливо) опасались монополии Google. Так что нападение на Android и iOS оказалось не таким простым, как на Microsoft и Red Hat на десктопном и серверном рынках.
Я помню, кто-то из Canonical говорил, что проекту нужно захватить около 1% мобильного рынка, чтобы поддерживать себя. В то время это означало продажу около 11 млн телефонов Ubuntu и пару миллионов планшетов ежегодно. Если бы вы умудрились зарабатывать хотя бы один доллар/евро на ПО и сервисах для каждого устройства, то легко оплатили бы труд более сотни разработчиков, это много денег, если правильно их использовать. В компании Jolla, которая разрабатывает Sailfish OS, было около 120 сотрудников в какой-то момент, я думаю, но там были отделы маркетинга и поддержки, которые у Canonical уже имелись в наличии. Но продажа 11 млн телефонов и пары миллионов планшетов в годы была очень амбициозной целью, учитывая, что количество пользователей Ubuntu Desktop находилось где-то в районе 20-30 млн.
- Возможность № 1 добиться одного процента. Быть настолько лучше конкурентов, что вы становитесь стандартом и уже даже не беспокоитесь о каком-то одном проценте. Думаю, мы все знали, что такое невозможно, особенно это стало ясно после того, как все важные сервисы (WhatsApp, Google, Twitter, Instagram и др.) даже не позволяли клонировать их приложения для запуска на устройствах Ubuntu. Canonical не сделала свой собственный клиент Telegram, когда первые коммерческие телефоны Ubuntu вышли на рынок, там вообще не было никакого мессенджера. И это в 2015 году, когда все обмениваются текстовыми сообщениями постоянно. Никто не хотел платить те же деньги за телефон Ubuntu, если он не может делать те же вещи, что и такая же модель под Android, даже если его позиционируют как «устройство для разработчика».
- Возможность № 2 добиться одного процента. Позиционироваться в ниши с глубокими карманами. Canonical слишком сконцентрировалась в нише «Конвергенция», которая не была интересна большому количеству людей, в то же время она игнорировала всех хакеров, мейкеров и людей, которые наелись слежкой со стороны Microsoft, Google и АНБ. Немногие были готовы платить премиальную цену за телефон, который может превратиться в тормознутый ноутбук при подключении к внешнему дисплею, но зато многие были готовы платить премиальную цену за Blackphone.
2. Неудобство для пользователя и искажённые приоритеты
Хочу быть честным: после получения первых нескольких обновлений over-the-air (OTA) я спросил себя: «Будут ли bq и Meizu, а особенно их пользователи мириться с этим?» Телефоны тормозили, их нужно было регулярно перезагружать. Meizu MX4 перегревался. Индикатор батареи часто показывал ложные данные. Мобильные данные работали ненадёжно, (национальный) роуминг часто вообще не работал. Сервис определения местоположения был очень ненадёжен. Телефон не всегда подавал сигнал при входящем звонке или вы не могли сделать исходящий вызов, потому что UI спрятал кнопки. На будильник нельзя было положиться. Bluetooth поддерживал только аудиоустройства, а позже устройства ввода, но никакой передачи файлов даже в базовом виде. WiFi не мог подключиться к сетям WPA Enterprise вплоть до пятого обновления OTA-5. Мне кажется, в какой-то момент аудиоплееер даже начал удалять файлы в процессе их индексации. И так далее.
Список вещей, которые должны были работать, но не работали, очень длинный. Что ещё хуже, несколько раз баги возвращались через несколько обновлений OTA, как регрессия. Во время существования проекта для телефонов/планшетов количество сообщений о багах на Launchpad взлетело так, как я никогда прежде не видел.
Искоренение всех этих багов не являлось главным приоритетом, а разработчики тратили основную часть времени на поддержку большего количества железа (Meizu Pro 5, bq Aquaris 10) и на обеспечение конвергенции. До последнего дня существования проекта пользователи, с которыми я разговаривал, не были довольны устройством. Только те, кто пользовался самым базовым функционалом, как мой отец, у которого даже не была включена функция передачи данных и он делал один звонок в два дня, были довольны, потому что устройство работало днями без подзарядки. Впрочем, купить смартфон за 150 евро, а затем не использовать функции, которые делают его «смарт», не имеет особого смысла.
Как должна была выглядеть конвергенция. Изображение: Canonical
Я понимаю, что не хватало разработчиков, чтобы исправить всё и сразу, но вместо выбора, сделать хороший телефон ИЛИ хороший планшет с конвергенцией, мы получили устройства, которые в реальности ничего не могли сделать как следует. Весь проект постоянно сопровождал эдакий ореол «Это устройства для разработчиков, необязательно исправлять всё быстро, мы выиграем на длинной дистанции» — пока менеджмент не осознал очевидные вещи, что всё это довольно дорого и слишком много времени уже потеряно. Вот тогда они начали сокращать убытки, перевели всех ключевых разработчиков в Snappy в районе октября 2016 года, позволили телефонам и планшетам умереть тихой смертью и несколько месяцев ничего не говорили публике.
Да, и я думаю, что дизайнеры слишком долго держались за идею Scopes. Особенно с учётом того, что никто на самом деле не мог понять, как использовать эти Scopes на десктопе.
3. Устройства было сложно раздобыть и они устаревали
Я думаю, мы все можем согласиться, что реально раздобыть устройство было слишком трудно. Я купил свой первый Nexus 7 в магазине, а Nexus 4 на eBay, но когда проект действительно вышел на серьёзные обороты, эти устройства уже устарели, их стало труднее достать, а вскоре для них перестали выходить официальные билды образов. Устройства bq хотя бы продавались по всей Европе, но чаще всего на странице стояла пометка “out of stock”. Раздобыть MX4 было практически невозможно для всякого, кто не участвовал в программе Ubuntu Phone Insiders. Если людям из США даже и удавалось получить его, то он не подключался к мобильным сетям на полной скорости.
Большую часть 2015 и 2016 годов, если разработчики приложений хотели получить официально поддерживаемое устройство, чтобы тестировать свои приложения, я не знал, что рекомендовать.
С другой стороны, то устройство, которое большинство ждали — исключительно высокопроизводительный Ubuntu Edge — оказалось другим. Устройства bq были дешёвыми, с маленьким объёмом встроенной памяти и только с поддержкой 3G. В MX4 был большой экран, высокая скорость и 4G, но больше ничего, даже отсутствовал разъём для карт SD. Выход HDMI, необходимый для конвергенции, отсутствовал на всех официальных телефонах, а Miracast/Aethercast не был равноценной заменой. Многие думали, что Ubuntu раскроет полный потенциал их железа, например, FM-радио на Aquaris E4.5/E5, но такого не было даже в планах, а без исходников драйверов под Android было практически невозможно добавить такую фичу.
Многие также ожидали, что их телефоны Ubuntu будут изначально более безопасными, чем Android, потому что здесь open source и частые обновления. Очевидно, это было не так, драйверы Android и софт для мобильного передатчика по-прежнему оставались проприетарными и небезопасными, и при этом с полным доступом к железу. Немногие это осознавали.
4. Коммуникации и маркетинг были скорее хаотическими, а иногда вводили в заблуждение
Я тратил огромное количество времени каждый день, пытаясь поспеть за разработкой, но обычно даже я не знал, что появится в следующем OTA, а что уберут. Списки почтовой рассылки, IRC, каналы Telegram, Launchpad, официальные веб-сайты, приватные разговоры между разработчиками, спринты, Ubuntu Online Summit — это было слишком. И это даже не упоминая все секретные разговоры в Canonical, когда они хотели сохранить новость в тайне, чтобы гарантировать максимальное освещение в СМИ в момент анонса.
Поскольку многие сотрудники Canonical работают из дома и в разных часовых поясах, для меня ситуация становилась только хуже. Помню, как пытался помочь с багами «Когда я нажимаю кнопку включения питания, телефон просыпается только через секунду» и «Обманный индикатор аккумулятора». Единственным надёжным местом был Launchpad, так что люди рассчитывали на него. Но иногда намного эффективнее просто поговорить с человеком минуту, прежде чем вы действительно опубликуете что-то ценное к баг-репорту, или просто чтобы решить, с какой стороны подходить к проблеме.
Человек, работающий над исходниками ядра, мог быть где-то в Азии. Сотрудник, который отвечает за все Q&A, мог быть где-то в США. Я был в Европе. Наше рабочее время в реальности не особенно пересекалось. Так что в некоторые дни мне приходилось разговаривать с парнем из Азии в 8:00 утра, пока он не ушёл с работы, а потом с человеком из США в полдень или ночью, когда там только начинается рабочий день.
Рекламируемые функции bq Aquaris E4.5 Ubuntu Edition. Заметьте отсутствие слов «конвергенция», HDMI, FM-радио и многих других вещей, которые люди ожидали, но маркетинг им этого не дал. Изображение: bq
Должен сказать, что я многое узнал от отдела маркетинга, особенно относительно «ожиданий и реальности». Например, многие предполагали как нечто само собой разумеющееся, что Aquaris E4.5/E5 и MX4 получат функцию конвергенции с более поздним обновлением OTA, но ни производители, ни Canonical не обещали это при продаже устройств. До самого момента отмены проекта большинство людей про себя предполагали, что смогут запускать те же приложения, что и на десктопе (Firefox, SIP-клиенты и др.) и управлять приложениями при помощи apt-get, и вот здесь маркетинг стал просто вводить в заблуждение. Было слишком много акцентов на том, что «это та же самая Ubuntu», хотя на самом деле это не так. Не могу припомнить, как часто мне приходилось объяснять случайным людям на различных каналах поддержки, что Firefox не запустится, а apt-get всё сломает. Часто люди очень удивлялись, узнав, что Ubuntu для мобильных настолько отличается.
5. Слишком много акцента на технических фичах, которые не нужны ни пользователям, ни разработчикам приложений
У меня такое чувство, что анонс новой и независимой мобильной операционной системы стал хорошей причиной для архитекторов сказать: «Да, давайте сделаем это, но давайте сделаем это Правильным Способом, и будем лучше остальных». Ubuntu должна была не просто предоставить графический интерфейс пользователя, но такой интерфейс, который будет работать на всех устройствах и в любых форм-факторах. Она не просто изолирует приложения друг от друга, как делает ядро Linux и Android, а реализует полноценную песочницу с защитой данных и приватности. Она магически сделает так, что работающие приложения не будут расходовать заряд батареи. И так далее. Что бы другие не сделали с технической стороны, Ubuntu должна сделать лучше и более элегантным способом.
Не всё это для меня имело смысл. Выпуск Unity 8 был необходим, потому что Unity 7 зависела от Compiz и не очень хорошо подходила для работы на множестве форм-факторов с поворотными дисплеями и т. д. Но единственным делом для Mir была замена X.Org и SurfaceFlinger, так что Unity 8 могла использовать единый API на десктопах и мобильных устройствах. Я не эксперт по графическим технологиям и API, но мне кажется, что хотя бы с точки зрения «у нас не хватает рабочих рук» разработка полностью нового графического сервера, который никто больше не хочет использовать и который не добавляет ничего особенного по сравнению с существующими альтернативами, — это то, чего следовало избегать любой ценой. Особенно если пользователь никогда не увидит разницу. Ubuntu Touch спокойно использовала Android SurfaceFlinger до конца 2013 года.
По-моему, то же самое относится к модели изоляции и жизненному циклу. Если вы усложняете дизайн, чтобы может быть сэкономить немножко энергии аккумулятора, и эта сложность ведёт к большой дополнительной работе по реализации системных сервисов, но эти сервисы никогда так и не будут реализованы, потому что ваша группа разработки слишком мала, то вряд ли ваши пользователи и разработчики приложений похвалят вас за то, что устройства работают чуть дольше. Скорее они будут бесконечно жаловаться на отсутствующие вещи. Вот почему баг-репорт «Закончить реализацию высокоприоритетных фоновых сервисов» разогрелся до 240 градусов — прошло три года с момента анонса проекта, но практически ничего не было сделано в этом отношении.
Ещё один хороший пример — запланированный фреймворк для сообщений. Вы должны были получить одно системное приложение для всех типов сообщений, будь то Jabber/XMPP, SMS, Telegram или WhatsApp, а сторонние сервисы могли выпускать плагины для своих протоколов. Этот фреймворк был одной из основных причин, почему приложениям запрещали работать в фоновом режиме. Так что вы не могли просто сделать отдельный XMPP-клиент, который бы получал сообщения в фоне. Но фреймворк для сообщений, к которому вы должны были выпустить плагин, задерживался и в итоге так никогда и не вышел. Даже клиент Telegram не мог работать в фоне, он мог показывать только всплывающие сообщения, потому что Canonical убедила разработчиков Telegram изменить их серверный код (!) для поддержки сервиса Ubuntu Push Notification.
Некоторые ключевые разработчики в Canonical действительно думали, что Ubuntu настолько важна, что все сервис-провайдеры изменят свои серверные коды для поддержки Ubuntu Push Notification, и это решит проблему. Никто кроме Telegram даже не задумался об этом.
(Кстати, я по-пренему думаю, что модель жизненного цикла не привела бы к заметной экономии батареи. Если подумать, то в ней всегда будет расходоваться такое же, а часто и большее количество циклов CPU).
6. Жизнь разработчиков приложений была слишком сложной
Современная мобильная ОС — это больше, чем ОС. Это экосистема. И вот здесь Ubuntu провалилась сильнее всего.
Ubuntu для мобильных устройств оказалась фундаментально несовместима с любым окружением для исполнения программ, какое существовало до него. Она не могла запускать приложения Android, Windows, X11 или iOS. Вы не могли просто перекомпилировать приложения Android, Windows, X11 или iOS. Графическая система, системные сервисы, песочница, набор базовых библиотек — всё было другим. Она даже полностью отличалась от Ubuntu Desktop. Можете целыми днями говорить, что «Это та же самая Ubuntu», но если я даже не могу протестировать свои приложения на десктопе, потому что там не запускается Mir, то это не та же самая Ubuntu и мне нужно разрабатывать для двух разных платформ.
Canonical пришла и сделала целый SDK, Integrated Development Environment на базе Qt Creator, плюс среду кросс-компиляции, плюс полностью новый набор компонентов Ubuntu QML. Я действительно не хочу никого здесь обидеть, но помимо неиспользования существующего кода, то, как всё это было сделано, оказалось крайне запутанным и стало разочарованием для разработчиков приложений. Ничего не работало, всё изменялось и ломалось постоянно. Иногда SDK был сломан неделями. Появились схемы версионирования, но ваше приложение всё равно не работало.
В какой-то момент мне пришлось пересобирать и обновлять моё приложение glmark2 в каталоге, потому что вышел OTA с обновлёнными клиентскими библиотеками Mir, хотя ОС заявляла тот же уровень совместимости, что и раньше. Затем стало ясно, что схема версионирования просто гарантирует, что официальный метод написания приложения гарантированно работает, но официальный метод — это просто QML и HTML5. Программа glmark2 взаимодействовала напрямую с Mir, как и многие другие (например, игры с использованием SDL). Приложения в каталоге могли просто прекратить работать, если не проверять и обновлять их после каждого OTA. Вы по-прежнему можете запускать старые Android-приложения на современном Android-смартфоне, но вот приложение Click с прошлого года может прекратить работу после следующего OTA, если вы не отслеживаете его постоянно. Я помню яркую дискуссию в IRC в конце 2015 года, во время которой несколько разработчиков Canonical были озадачены этим фактом и спрашивали у сотрудников группы SDK, как, по их мнению, разработчикам приложений работать в таких условиях.
Рендеринг bq Aquaris E4.5 с игрой Panda Love, одним из моих приложений в Click Store
Я начинал как разработчик приложений. Что бы я ни хотел сделать, начинать приходилось практически с нуля. Сделать GUI? Поддерживался только QML с компонентами Ubuntu QML, а QML не назовёшь устоявшейся экосистемой с большим количеством существующего кода и хорошим инструментарием. Просто использовать одну из существующих библиотек UI? Они все предназначены для работы с X11 или, может быть, Wayland, и прошло немало времени, пока SDL и прочие получили бэкенды для Mir. Коммуникации с железом и системными сервисами? Из-за песочницы было трудно обращаться напрямую к специализированным сервисам Ubuntu через D-Bus, к большинству «стандартных» процессов вроде NetworkManager нельзя было обращаться изнутри песочницы. Скачать что-нибудь в фоновом режиме? Для этого нужно обращаться к специальному менеджеру скачиваний Ubuntu. Получить уведомления о событиях за пределами телефона? Только если интегрируете всё с сервисом Ubuntu Push Notification.
Вот почему мне пришлось начинать работу с самой базовой системы. Тогда в январе 2015-го я хотел сделать сканеры WiFi и Bluetooth, но всех необходимых API и системных сервисов просто ещё не существовало. Многие из отсутствующих API и системных сервисов так никогда и не появились.
Всё это делало платформу крайне непривлекательной для большинства сторонних разработчиков. Они не видели, как могут окупиться их инвестиции в создание ещё одной версии приложения с нуля, особенно с учётом маленькой пользовательской базы. Я не помню ни одного приложения, которое в Click Store закачал бы его «оригинальный» разработчик. Даже клиент Telegram разработала сама Canonical.
Так что многие из нас создавали простенькие веб-приложения или клонировали существующие приложения. И немедленно столкнулись с проблемой, что многие приложения полагаются на некий вид несвободного онлайнового сервиса с очень невыгодными условиями использования. Лично я разработал BD Navigator, клон Deutsche Bahn Navigator. Я провёл обратную разработку их клиент-серверного протокола до той точки, где мог копировать практически всё, кроме покупки настоящего билета на поезд, но они встроили небольшой фрагмент криптографии, а использование краденых криптографических ключей в Германии незаконно. Я спросил разрешения у Deutsche Bahn, они отказали. В конце концов всё приложение целиком деградировало до уровня величественного веб-контейнера с закладками на их мобильные веб-страницы.
Точно то же самое справедливо для WhatsApp, Twitter, Instagram, Google Plus, Google Drive и других. Мы можем скопировать много чего, но сервис-провайдеры не разрешают нам делать это. Говорят, что WhatsApp запросил семизначную сумму просто за доступ к их API, а не за разработку полноценного клиента. Instagram настолько закрыл свои API, что даже встроенный Instagram Scope пришлось удалить. У Google для многих сервисов нет публичного API.
(Также небольшое количество нердов open source никогда бы не смогли поддерживать актуальную коллекцию клонов для всех популярных приложений. Это просто не масштабируется).
7. Она не была такой открытой и не пользовалась такой общественной поддержкой, как предполагалось
Теперь я понимаю, что это заявление может быть противоречивым, и если вы не согласны, пожалуйста, имейте в виду, что это исключительно мои ощущения. Может быть, я в меньшинстве. Понятия не имею.
Ubuntu для мобильных устройств должна была стать такой же открытой, как «нормальная» Ubuntu, но этого не произошло.
- Исходный код всего, что мы разрабатывали, был где-то распределён по неизвестному количеству проектов Launchpad.
- Исходники ядра на GitHub часто были устаревшими.
- Код всех проприетарных драйверов Android и другого софта был доступен только сотрудникам Canonical.
- У Canonical и её коммерческих партнёров имелась полностью приватная зона Launchpad с приватными баг-репортами. Довольно часто в публичных баг-репортах встречались ссылки на приватные страницы, так что у вас была только половина информации.
- Большую часть информации о будущих устройствах сообщество получало с помощью поиска случайных утечек информации, по большей мере на paste.ubuntu.com.
- Узнав о будущей фиче, мы часто обнаруживали, что соответствующий проект Launchpad открыт неделями или месяцами ранее под кодовым названием или что разработчики Canonical месяцами работают над ним в приватных репозиториях. Например, так было с Aethercast.
- Не будучи сотрудником Canonical, вам было трудно понять, над чем идёт работа, что запланировано и где вы можете помочь.
- Если вы нашли, где помочь, то очень трудно установить контакт с разработчиками Canonical. У них рабочий день как минимум восемь часов, но у вас нет восьми часов свободного времени, а ваше свободное время часто не совпадает с их рабочим графиком.
- У меня никогда не возникало ощущение, что пожелания пользователей и более широкого сообщества имеет какое-то влияние на список будущих фич или на то, что войдёт в следующий OTA. Во многих случаях баг-репорты Launchpad и запросы функций с наибольшей поддержкой задерживались дольше остальных.
FAQ
Вот некоторые вопросы, которые мне иногда задают.
Сколько устройств вы купили для разработки?
Думаю, что купил два новых Nexus 7, два использованных Nexus 4, три новых bq Aquaris E4.5 и два дешёвых китайских телефона Mediatek (для реверс-инжиниринга) специально для работы с Ubuntu. Также у меня был MX4 от Canonical. Думаю, я потратил где-то больше тысячи евро на семь телефонов и два планшета.
Вы когда-нибудь оценивали затраченное время?
Да. После всех расчётов у меня вышло шесть человеко-месяцев за полуторалетний период или объём работы, аналогичный тому, если бы Canonical наняла меня на 30% ставки.
Вы жалеете, что потратили столько времени и усилий?
Нет
Когда вы впервые начали сомневаться, что всё получится?
Если не ошибаюсь, это было в районе Рождества 2015 года. Большая шумиха вроде как закончилась, и стало ясно, что мы никогда не получим полноценные приложения WhatsApp, Twitter и другие, а для многих владельцев телефонов планируется не так уже много «реально» важной функциональности. Шла работа над конвергенцией для планшета, но немногим удалось заполучить bq Aquaris M10.
Помните, что я начал работать над базовой операционной системой только потому, что не мог создать половину приложений, какие хотел. После года работы не был закончен ни один API или системный сервис, необходимый мне, и мы всё ещё спорили с некоторыми системными архитекторами о необходимости всех этих вещей в принципе. Когда ваши разработчики приложений говорят, что вам нужно нечто для создания классных приложений, просто дайте им то, с чем вы как архитектор можете ужиться в обозримом будущем. Оно необязательно должно быть идеальным, но разработчики приложений нужны вам больше, чем вы им.
Вы ушли в середине 2016-го, задолго до закрытия проекта. Почему?
С одной стороны, разработка ПО стала меньше интересовать меня. Сейчас я бóльшую часть времени путешествую по миру, фотографирую, делаю плохие карточные игры, плохие комиксы и плохие игры.
С другой стороны, я больше не чувствовал, что работа над проектом приносит мне радость. Иногда я думал «Я делаю недостаточно, это моя вина», просидев над устройством восемь часов подряд. Не такие чувства должны быть у человека, который работает над проектом в свободное время ради удовольствия.
Автор: m1rko
