[Перевод] Что действительно случилось с Vista
См. также: «Что действительно случилось с Vista: инсайдерская ретроспектива»
Я обычно пищу о вещах, которыми непосредственно занимался — или писал код, или управлял проектом. В этой статье я выбрал другой подход, чтобы написать о своём взгляде на глубинные причины фиаско Windows Vista (кодовое название Longhorn). Хотя это случилось более десяти лет назад, то был ключевой период по переходу на мобильные устройства — и те события вызвали долговременные последствия внутри Microsoft. Я нашёл, что многие попытки описать проблемы Microsoft, особенно в связи с переходом на мобильную платформу, неубедительны и не совпадают с моим пониманием того, что случилось. Статья в Vanity Fair «Потерянное десятилетие Microsoft» описывает бюрократическую гниль и подковёрную борьбу («жизнь… стала непрерывно жестокой») или культурную гниль из-за негативных последствий системы оценки рейтинга конкурентных стеков. Последующая статья в The Atlantic описывает ситуацию как классическую «дилемму инноватора».
Думаю, что ситуацию можно изложить иначе — с лучшей привязкой к конкретным фактам о проектах и истинными мотивами ключевых сторон. Это не попытка написать альтернативную историю — я понятия не имею, что бы случилось, не будь сделаны те ошибки. Но они определённо не помогли Microsoft пройти через этот переломный момент в компьютерной индустрии.
Это и не журналистское расследование — я не проводил большой серии интервью с ключевыми участниками событий. Здесь моё личное мнение на основании того, что я видел в то время и что узнал потом. Хотя в то время я работал в подразделении Office, мне приходилось тесно сотрудничать со многими коллегами из подразделения Windows, так что я хорошо осведомлён о процессах, которые происходили там.
Прошу прощения за большой размер статьи. Вот краткое изложение:
- Microsoft неверно оценила ключевые тенденции в развитии аппаратного обеспечения. В частности, резкий разворот в 2003 году в тенденции быстрого повышения частоты однопоточного процессора с соответствующими улучшениями других ключевых элементов ПК. Vista планировалась и создавалась для оборудования, которого не существовало. Это было плохо для десктопов, хуже для ноутбуков и ужасно для мобильных устройств.
- Ставка на C# и управляемый код была плохо обоснована и плохо реализована. Ответственность за этот конкретный провал можно напрямую возложить на Билла Гейтса и его бесплодные попытки создать священный Грааль из универсального хранилища с универсальной инфраструктурой приложений. У этого провала оказались особенно долгосрочные последствия.
- Управление проектами в подразделении Windows оставалось на катастрофическом уровне на протяжении всей его истории, в том числе были проекты, так и не доведённые до конца. Vista оказалась катастрофой, но стала просто кульминацией ряда почти катастрофических сценариев в ключевой миссии исполнения сложных проектов.
Поскольку это очень важно для данной истории, хочу начать с маленького примера о структуре индустрии и создании ценностных качеств.
Любое устройство состоит из аппаратного обеспечения, операционной системы (ОС) и приложений. На самом базовом уровне ОС управляет и выставляет аппаратные ресурсы таким образом, что приложения могут совместно использовать их. ОС предоставляет также программные интерфейсы (API), позволяющие разным типам оборудования подключаться к устройству, и API, предоставляющие приложениям доступ к этому оборудованию, а также системные сервисы ОС. Хотя на базовом уровне ОС предоставляет только аппаратные ресурсы, на практике «ОС» включает в себя много других высокоуровневых функций, в том числе графический пользовательский интерфейс, сложное управление для отображения и редактирования форматированного текста или внедрения HTML, высокоуровневую сетевую поддержку, управление файлами, механизмы для обмена данными и функциональностью между приложениями и даже целые приложения вроде браузера, почтового клиента, работы с фотографиями и камерами. История ОС, особенно в потребительском мире, предусматривает включение в себя всё больше и больше высокоуровневых сервисов, которые или напрямую предоставляются пользователям, или выставляются как API для приложений.
Это развитие высокоуровневой функциональности обусловлено благотворным циклом и многосторонними сетевыми эффектами, присущими бизнесу ОС. Всё большее и большее количество пользователей ОС привлекают больше разработчиков. Больше разработчиков создают больше приложений, что делает ОС более привлекательной для пользователей. Это приводит к циклу, когда ещё больше пользователей ведёт к ещё большему росту количества разработчиков. Предоставляемые API операционной системы — вот что делает бизнес-стратегию настолько успешной и стабильной для победителей этого состязания. Миллионы разработчиков в целом тратят огромные усилия на программирование системных API и сервисов за собой. Чем сильнее какое-то приложение зависит от сложных API, предоставляемых определённой ОС, тем сложнее перенести это приложение на какую-то другую ОС. Значит, даже если конкурент сумеет повторить ключевую функциональность другой ОС, он всё равно не получит эти приложения. Единственному поставщику ОС совершенно невозможно продублировать усилия, затраченные миллионами разработчиков.
С такой динамикой существует много усиливающих друг друга причин для поставщика добавлять в свою ОС всё более сложную функциональность и API, которую упрощают разработчикам доступ к этой функциональности. Сложная функциональность должна привлечь разработчиков, а с помощью простых API они смогут быстро создать лучшие приложения. Эти лучшие приложения сразу входят в благотворный цикл привлечения большего количества пользователей. Классическим примером было то, когда Windows стала первой ОС, где разрешили встраивать HTML-документы непосредственно в приложения. Что критически важно, после использования этой функциональности становилось сложнее перенести приложение на другую ОС.
Если посмотреть на Windows, iOS и Android, то все они используют ту же стратегию, хотя у Microsoft, Apple и Google разные способы монетизации. Microsoft классически берёт оплату за лицензию на каждом устройстве. Её платят OEM-сборщики, которые продают устройства с Windows. Это горизонтальная бизнес-стратегия с большим количеством OEM, каждый из которых платит Microsoft за каждое собранное и проданное устройство. Apple монетизируется через производство и прямые продажи устройств. Google зависит от постпродажной монетизации, в основном, через поиск. На самом деле страх, что Apple и Microsoft заберут мобильный рынок поиска (и мобильные сервисы в целом) — это главная причина инвестиций Google в Android. Microsoft также переходит на прямую монетизацию от продажи устройств (через линейку Surface), а также на постпродажную монетизацию (через Bing и платные подписки вроде Office 365).
Ещё одна важная часть, которую нужно здесь учитывать, — это сторонний связующий софт (middleware) вроде Java и Adobe Flash. В каком-то смысле он не отличается от высокоуровневых сервисов ОС, кроме того, что создаётся и предоставляется сторонней компанией. У провайдеров ОС и разработчиков связующего софта отношения из смеси любви и ненависти. В том отношении, что middleware позволяет разработчикам быстрее создавать отличные приложения для их платформы, это любовь. Часть «ненависти» управляется несколькими движущими силами. Определённые типы связующего ПО специально решают задачу создания приложений, которые работают на разных платформах. Middleware вроде Java и Flash распространяется под девизом «напиши однажды, запускай везде». Приложения, построенные на таком middleware, напрямую не зависят от API в ОС — и поэтому могут работать на любой платформе, где существует это связующее ПО. Оно осуществляет преобразование своих API в нативные API операционной системы. (Заметьте, что современные читатели могут представлять Java или как серверную инфраструктуру для веб-сайтов, или как предпочтительный язык для разработки Android-приложений. Я же имею в виду первопричины его создания как языка для браузерных приложений по требованию. В таком качестве он рассматривался во времена, когда планировалась Vista).
Кроссплатформенное связующее ПО разрушает сетевые эффекты, которые создаются в результате привязки приложений к определённой ОС через эксклюзивные API, специфические для этой ОС. Приложения, построенные на таком связующем ПО, также склонны использовать «наименьшую общую функциональность» всех ОС и не так быстро перенимают новые возможности, которые появляются в ОС. Некоторые виды функциональности ОС создают свои собственные внутренние сетевые эффекты, при которых чем больше приложений используют эту функциональность — тем лучше работают все приложения. Классическим примером является форматированный копипаст; чем больше приложений поддерживают копирование и вставку форматированного контента между собой, тем более ценной является ОС для каждого пользователя. Если сторонний провайдер связующего ПО блокирует эту динамику, то со временем он блокирует возможность устойчивой дифференциации ОС.
Браузер как платформа доставки приложений — вероятно, самый стабильный пример связующего ПО, которое нарушает динамику системных API. Если посмотреть на 35 лет компьютерной истории, то в какие-то моменты появлялись и другие подходы, но все они провалились по причинам, в которые мы здесь не будем углубляться. Для нашей истории критически важным является то, что 20 лет назад было не так очевидно, во что всё выльется. Страх middleware и нарушения стабильной дифференциации API были главными факторами во времена Vista.
Давайте разберёмся в истории Windows и проблемах в реализации этого проекта.
Я собираюсь провести тяжёлую работу по обобщению итогов, но думаю, что мы не потеряем суть. Обычно у каждого релиза Windows имелась главная тема и примерный срок. Например, Windows 95 должна была обновить пользовательские Windows на 32 бита, установить современную файловую систему, новый UI и стандартные сетевые средства (включая браузер). Кроме основных тем, отдельные разработчики и группы самостоятельно определяли ключевые функции в своей области — и начинали разработку. Продукт в разработке получался нестабильный, поскольку в течение долгого времени новые функции ещё не могли стабильно работать друг с другом. В определённый момент разработчики принимали решение, что достаточно хорошо развили функционал — и начинали работать над стабильностью и готовиться к выпуску. Исторически разработчики Windows обычно сильно просрочивали планируемую дату выпуска (Windows 95 изначально называлась Windows 93), а важная планируемая функциональность или отбрасывалась, или значительно урезалась по сравнению с первоначальными планами. Этап подготовки к выпуску часто превращался в «марш смерти», когда баги исправлялись поздними вечерами и на выходных — и постоянно сдвигались дедлайны. Хочу заметить, что ключевым отличием между Windows и Office было то, что после Office 97 команда Office устанавливала дату выпуска следующей версии — и обычно соблюдала сроки. Это позволяло добиться широкой координации с минимальными накладными расходами.
Процесс сильно отличался от современных практик разработки. Независимо от того, пришла идея отдельной функции сверху вниз как часть более широкого ви́дения или снизу вверх от отдельных разработчиков и групп, но современные практики обычно предусматривают непрерывный контроль качества и очень частые релизы для пользователей. Сервисы могут обновляться в продакшне несколько раз в день, а новый клиентский код выходит еженедельно или ежемесячно (обновление клиента дорого обходится как провайдеру, так и пользователям, что затрудняет слишком частые обновления). Это требует, чтобы основная архитектурная и инженерная инфраструктура надёжно работала в больших сложных системах, таких как Windows или Office. Этот процесс не всегда делает проще значительные прорывы в сложной функциональности, но кардинально увеличивает гибкость групп разработки и их способность реагировать на внешние события и реалии. Он также даёт гораздо более честную оценку реального текущего прогресса. Возможно, стоит написать отдельную статью, как подразделение Office осуществило переход на эти практики современной разработки, но достаточно сказать, что подразделение Windows в то время даже близко к ним не приблизилось.
Windows XP стала масштабным релизом, которая тоже соответствовала упомянутому печальному шаблону. Она объединяла бизнес- и пользовательскую платформы на надёжном ядре Windows NT с дружественным пользователю интерфейсом. Сложно было добиться совместимости со всеми приложениями, созданными для платформы Windows, но это было ключевым фактором для перехода на единую бизнес- и пользовательскую платформу. К сожалению, в Windows XP нашли 0day-уязвимость, которая попала в заголовки новостей прямо в день публичного релиза. Эта и другие катастрофы в области информационной безопасности заставили Microsoft кардинально модернизировать ПО и пересмотреть практики разработки в области безопасности — и в конечном итоге выпустить безразмерный сервис-пак для Windows XP, в создании которого приняла участие большая часть подразделения Windows. Вдобавок, ключевые группы по разработке системного ядра Windows (группы Core) работали над 64-битной версией, что оcобенно важно для объединения клиентских и серверных установок Windows (в то время Windows отставала от других корпоративных платформ вроде Sun Solaris в области 64-битных вычислений). Это было критически важно, поскольку Windows конкурировала (и успешно) в сфере более крупных корпоративных серверов.
Хотя крупные отделы подразделения Windows концентрировались на названных инициативах, не меньшая по размеру организация занималась созданием следующего поколения Windows поверх «управляемой» платформы C#. Здесь нужно немного объяснить подоплёку.
С самых первых дней браузер начал развиваться как платформа доставки приложений. Пресловутая цитата Марка Андриссена «Netscape скоро оставит от Windows только плохо отлаженный набор драйверов устройств» датируется 1995-м годом. Это привело к реализации стратегии «поддержать и надстроить» (embrace and extend), которая доставила Microsoft столько неприятностей в связи с антимонопольным расследованием. Microsoft создала и развивала собственный браузер и механизм внедрения проприетарного кода ActiveX. В то время появилась Java как альтернативная стратегия доставки приложений. Разработчики могли использовать Java, высокоуровневый язык со своим собственным богатым набором API, где код автоматически скачивался и запускался в браузере. Java рекламировалась как технология «напиши однажды, запускай везде», что явно попадало в спектр реакции «ненависти» по отношению к связующему ПО. Неожиданно Microsoft подписала лицензионное соглашение с Sun относительно Java, но потом на компанию подали в суд, когда Microsoft расширила Java для прямого доступа к нативным интерфейсам Windows API (что нарушало принцип «запускай везде», но давало разработчикам Java доступ к более богатому и растущему набору API на платформе). Microsoft договорилась о сделке по иску о Java и в конечном итоге решила пойти по собственному пути с языком программирования C#. Это решение оказалось катастрофическим по многим причинам. (Замечу, что C# сам по себе представляет собой отличный образец технологии — катастрофа была в стратегии).
C# — это «управляемый» язык. Главным образом это означает, что разработчикам не нужно управлять выделением и освобождением памяти «вручную». Язык и среда выполнения используют сборку мусора для автоматического освобождения любого участка памяти, который больше не используется. Важно, что среда выполнения также предотвращала типы ошибок в памяти, из-за которых в то время появлялись многие уязвимости в безопасности. В то время, а в реальности в течение всего последующего десятилетия, продолжались страстные рассуждения о влиянии автоматического управления памятью на производительность программирования и безопасность. Я не буду пересказывать здесь те споры. Достаточно сказать, что самая успешная современная операционная система iOS решила не играть в эти игры (Android продаётся в большем количестве, но iOS получает львиную долю прибыли). Управляемым окружениям присущ перерасход ресурсов по сравнению с неуправляемыми окружениями, так что им требуется больше памяти для работы. Большинство окружений, которые используют преимущества производительности управляемого кода, стараются осторожно ограничить его использование только там, где это имеет наибольший смысл, а не слепо использовать везде подряд.
Если программисты впервые столкнулись с окружениями такого типа (а это почти 100% разработчиков проекта Windows в то время), то они несерьёзно относятся к использованию памяти. Но как бы не управлялась память, автоматически или вручную, она представляет собой ресурс, и несерьёзное отношение к ресурсу ведёт к раздутому коду, которому для работы требуется больше памяти. На самом деле даже «высокая продуктивность» (генерация большого количества кода) не всегда главный критерий успешности проекта («если бы у меня было больше времени, я бы написал письмо короче»). В то время использование большего количества ресурсов являлось частью системы ценностей, поскольку так усиливалось значение толстого клиента для вычислительных возможностей системы (по сравнению с «тонким клиентом» вроде простого приложения, работающего через веб-страницу). При создании обновления Longhorn разработчики Windows хвастали бы тем, сколько новых API они написали.
Частью ставки на C# также была ставка на богатую библиотеку основных классов и создание новой клиентской технологии как набора библиотек классов поверх этой базы. Базовая библиотека предоставляла простые типы вроде строк и массивов, а также более сложные структуры данных и сервисы вроде списков и таблиц хэширования. Смысл в том, что это должно обеспечить единообразие для всего Windows API. Win32 поначалу были относительно небольшими единообразными API, но за последнее десятилетие сильно раздулись усилиями такого большого количества групп, которые добавляли в набор API без какой-либо единой последовательной концепции. Новая библиотека рассматривалась как возможность вернуть всё на круги своя.
Тот факт, что ни одна другая операционная система не выбрала такой путь, рассматривался как своего рода «большая ставка», что являлось фундаментальной частью системы ценностей во внутренней культуре Microsoft. К сожалению, кроме проблем с использованием раздутых ресурсов, существовали фундаментальные вызовы с использованием новой технологии в операционной системе (особенно с тем, как обрабатывать сбои ресурсов в критических частях ОС, как независимо обновлять приложения, управляемую среду выполнения и ОС и как сделать, чтобы различные части ОС развивались независимо друг от друга), которые не решили или не полностью понимали в то время. Не существовало буквально никакой стратегии миграции для существующих приложений, построенных поверх неуправляемых Win32. Несмотря на это, огромные армии разработчиков развернули строительство поверх этой нестабильной платформы. Над чем они работали?
В этом месте имеет смысл подключить к рассказу Билла Гейтса.
Вся история Microsoft с момента основания компании посвящена превосходству софта над железом. Программное обеспечение является повсеместным товаром, а ценность именно в программах. Если посмотреть на устойчивую прибыль экосистемы ПК, то такой взгляд действительно кажется точным. Определённо он точен с точки зрения взаимоотношений OEM и Microsoft. Компания Intel получала львиную часть прибыли среди производителей всего компьютерного оборудования. В то же время динамика всей компьютерной экосистемы поддерживалась бесконечным экспоненциальным ростом производительности железа под действием закона Мура и других экспоненциальных трендов. Программное обеспечение словило волну, поскольку именно оно получало основную экономическую выгоду от финального продукта. Помните, что фундаментальная ключевая роль ОС — это предоставлять аппаратные ресурсы для добросовестного использования приложениями.
Переплетённые роли железа и софта иногда затрудняют оценку распределения стоимости. На самом деле анализ рынка смартфонов помогает внести ясность. Когда инженеры RIM (производитель доминирующего телефона Blackberry) посмотрели демонстрацию оригинального iPhone, их первая реакция была: «Это невозможно»! Невозможно сконструировать полноэкраннный легковесный телефон с тач-интерфейсом и такой производительностью, чтобы аккумулятора хватало на достаточно долгое время. Но в реальности такое оказалось возможным. Последние десять лет рынок двигали вперёд непрерывные аппаратные инновации (лучшие экраны, более быстрая связь, более производительные процессоры, больше памяти, лучшая камера, новые сенсоры, более ёмкие батареи, уменьшение веса, мгновенное включение) опосредованно через программное обеспечение ОС.
Когда iOS открылась для сторонних приложений, поразительным оказалось то, как аккуратно ОС контролировала поведение приложений, чтобы сохранить общую производительность устройства. От стандартов и обязательного рассмотрения в курируемом каталоге приложений Apple до продуманной изоляции приложений в песочнице, от первоначального ограничения на одну задачу без фоновых процессов до жёстких ограничений на отклик приложения и обработку аудио и видео с аппаратным ускорением и низким энергопотреблением, а также множество других техник, направленных на сбережений драгоценной энергии батареи — очень многие инновации iOS фундаментально относились к ключевой функции ОС по управлению аккуратным экспонированием аппаратных ресурсов приложениям.
Трудно не заметить огромную разницу с подходом, который исповедовали разработчики подразделения Windows с выпуском Vista. Роль аппаратных инноваций заключалась в том, чтобы сделать возможными программные инновации, а не в том, чтобы софт олицетворял инновации железа.
Когда начался проект Longhorn, три крупные группы начали масштабную работу по переосмыслению клиентского программного стека поверх управляемой платформы C#. Группа WinFS должна была создать новый слой универсального хранилища для приложений. Вместо простой иерархической подборки файлов и директорий файловая система работала под управлением полнофункционального реляционного движка. Это должно было не только облегчить создание новых мощных приложений, но их данные не запирались бы в непрозрачных файлах, а становились доступными для других приложений и реляционных таблиц, которые можно смешивать и сравнивать в новых ещё более функциональных приложениях. Это примеры внутренних сетевых эффектов, благодаря которым создаются мощные рвы против конкурентов. Информация также открывалась новому файловому менеджеру для простого поиска и сложных запросов. Так должны были наконец-то реализоваться идеи универсального хранилища Cairo, которое забросили и не сумели внедрить в Windows 95.
Группа Avalon (позже Windows Presentation Foundation) должна была переосмыслить уровень представления поверх мощных графических процессоров. Уровень представления концентрировался на создании универсального холста, где пользовательский интерфейс и контент насыщенных приложений незаметно смешивались между собой, так что результат частично представлял собой документ, а частично — пользовательский интерфейс, всё под управлением мощных графических процессоров, способных обрабатывать 3D-игры.
Третья группа писала код, который вышел как Windows Communication Foundations (WCF) для создания сетевых функций. Это критический компонент практически любого современного приложения.
Сочетание насыщенного хранилища и насыщенного представления было чашей Грааля для Билла. Построенные на стабильной управляемой инфраструктуре C# эти компоненты сделали бы возможным создание новых классов мощных приложений, которые разработчики могли бы быстро и эффективно конструировать. Насыщенная инфраструктура и защитный ров API обеспечили бы ОС благоприятный цикл с положительной обратной связью ещё на одно десятилетие.
Так что пошло не так? Если одним словом, то всё.
Некоторые проблемы объясняются провалами в исполнении краткосрочных задач, а другие были долговременными стратегическими ошибками.
Когда группа Core выступила с проектом повышения безопасности и 64-битной Windows, она провела переоценку статуса всего проекта Longhorn. Разработчики написали огромный объём кода. К сожалению, когда вы строите сложную систему и работаете без чётких ограничений и дедлайнов, правильное ментальное состояние команды, которая генерирует много кода, не соответствует ментальному состоянию тех, кто строит железную дорогу через всю страну и уже завершил её на 90%. Их скорее можно сравнить с теми, кто вырыл невероятно глубокую яму, а теперь думает, как выбраться обратно и закопать её. Команда только справилась с пониманием всех последствий попытки доставки функций ОС поверх этой управляемой инфраструктуры. Они осознали, что у них тонна работы, чтобы просто сделать реальностью базовые предпосылки. Кроме всего этого, ни один из основных компонентов не доведён до стадии готовности. Они также начали понимать ограничения производительности при внедрении основных новых подсистем в существующий код. Проекты WinFS и Avalon на заменяли существующей инфраструктуру ОС, а ложились поверх неё. Так что существенные расходы вычислительных ресурсов просто добавлялись сверху.
Как объясняется в статье Wall Street Journal от 2005 года, Олчин принял решение вынести эти основные компоненты из релиза, продолжая их разработку. В результате после трёх лет продуктового цикла работу над ними приходилось начинать фактически с нуля. Все эти управляемые функции нужно было исключить из основного состава ОС и поставлять отдельно. Их исключение явно было правильным решением, но исключение обеих подсистем выявило и вызвало проблемы, которые затем сохранятся в течение десятилетия.
Ставка на C# и управляемый код включала в себя стратегию, которая сокращала вложения в неуправляемые слои Win32. Я помню долгие совещания с попытками уговорить представителей подразделения Windows сделать относительно небольшие коммиты в текстовые и графические функции, необходимые для Office. Исключение из релиза этих компонентов C# сделало ещё более очевидным, что Windows ещё несколько лет останется без ключевых управляющих элементов пользовательского интерфейса для разработчиков (таких как Office) в своём основном Win32 API.
Также катастрофические последствия имело то, что ставка на Avalon сопровождалась массивным сокращением работы над IE. Группу IE сократили, переведя часть сотрудников в проект Avalon, а IE оставили на жизнеобеспечении с невозможностью решить кучу проблем в безопасности, число коих постоянно множилось. Долгосрочное ви́дение заключалось в том, что HTML станет древней технологией, а те приложения, на которые нацелены наши конкуренты с помощью браузера и HTML, станут работать поверх новой инфраструктуры Avalon.
Это стало гигантской стратегической ошибкой, которая открыла дверь для распространения Firefox, а затем и браузера Chrome от Google. Хотя невозможно сказать, предотвратили бы такой исход вложения в IE, но определённо не стало бы хуже. Прекращение вложений также подорвало команду IE и оставило их неподготовленными и с нехваткой персонала перед лицом продолжающейся быстрой эволюции веб-технологий, что разрушило репутацию IE среди веб-разработчиков. Факт совершённой ошибки немедленно стал очевиден для всех в компании: здесь не требовалось быть особым провидцем. Office и другие подразделения в компании активно вкладывались в веб и HTML. Не существовало никакого реального способа, как эти инструменты могут перейти на Avalon, а уж тем более вся индустрия. На самом деле команда Avalon так никогда и не описала этот реальный способ: должно было случиться нечто волшебное — и вдруг все начинают писать приложения Avalon вместо HTML. Это было настолько же абсурдно, насколько и бессовестно. Сразу после того как мы «выиграли» войну браузеров и наблюдали поглощение Netscape корпорацией AOL, мы кардинально снижаем дальнейшее развитие технологий на этих открытых стандартах. Только с началом проекта Windows 7 восстановили персонал группы IE и возобновили активные инвестиции в IE и стандартные веб-технологии.
С Avalon связаны и другие последовавшие проблемы.
Модель Avalon основывалась на концепции Билла, чтобы обеспечить универсальный холст, среду выполнения для приложений. Как я объяснял в статье «Дырявая на уровне архитектуры», одна из главных проблем для разработчиков фреймворков вроде Avalon — как открыть функции на разных уровнях так, чтобы приложения могли привязаться к ним на соответствующем функциональном уровне и не нести лишних затрат производительности. Если открыть функциональность только на самом высоком уровне, то вся работа по сути будет недоступна для более сложных приложений (таких как приложения Office), которым нужна привязка на более нижних уровнях. Потребовалось ещё 10 лет до выпуска Windows 10, прежде чем решили эти проблемы на уровне архитектуры.
Avalon также сделал ставку на энергоёмкие графические карты. Мобильная графическая модель, хотя использовала некоторые такие же элементы, в основном фокусировалась на достижении плавной анимации за счёт предварительно отрисованных текстур или слоёв с их зуммированием, панорамированием и смешиванием. Количество слоёв аккуратно ограничивается, чтобы мобильный графический процессор показывал большую частоту кадров, необходимую для плавной анимации и взаимодействия с пользователем, потребляя при этом немного энергии. Графическая модель Avalon эффективно двигалась в противоположном направлении.
Проблемы с WinFS в каком-то смысле оказались даже более фундаментальными, чем с Avalon. В то время как Avalon поставлялся отдельно, а некоторые ключевые концепции использовались как основа для компонентов UI в Windows 8 и 10, проект WinFS полностью прекратили.
Изначально предполагалось, что WinFS станет файловой системой. Невероятно сложной задачей представлялось заменить старую файловую систему на полностью новую реализацию, которая несёт в себе некоторую важную новую функциональность, — и в то же время сохранить видимую неизменность для огромного массива существующего программного обеспечения. Особенно с учётом того, что основные разработчики базовых подсистем Windows тогда занимались другими задачами (безопасность и 64-битная версия). Так что WinFS создавалась как сторонний компонент, который предоставит дополнительную функциональность для поиска и насыщенных запросов. Эта конструкция означала, что WinFS будет нести значительные дополнительные затраты на производительность с меньшим количеством возможностей для сквозной оптимизации. Как и для любой новой функции, эти затраты должны сочетаться с её преимуществами. Но в тот момент WinFS действительно предоставляла только поиск, который был «просто функцией», а не изменением парадигмы, как предполагал Билл. В Microsoft уже имелся движок десктопного поиска, который потреблял гораздо меньше ресурсов, чем WinFS. Более того, осуществление такого переворота в экосистеме для локального поиска ПК, когда бóльшая часть информации мигрировала с ПК в облако, говорило о крупном непонимании современных тенденций из-за этих неустанных попыток сосредоточить инновации на насыщенном клиенте.
На более глубинном уровне ви́дение Билла экосистемы приложений, которые хранят всё у себя и делятся своими данными в этом реляционном хранилище, прямо противоречит тому, как приложения строят свои модели данных. В то время как некоторые настольные приложения (и почти все внутренние приложения для IT) используют реляционные хранилища для своей внутренней модели данных, они не хотят предоставлять эти модели данных для неконтролируемого чтения и записи другими приложениями. Я объяснил некоторые из фундаментальных причин в вышеупомянутой статье «Дырявая на уровне архитектуры». Были (и есть) множество других вариантов для приложений, которые хотят использовать реляционное хранилище. И конечно, долговременная тенденция заключалась в том, что все эти данные перемещаются в облако, а не запираются в хранилище локального ПК.
Решение продолжать инвестиции в этот управляемый стек и вынести его из релиза ОС повлечёт долговременные последствия и после выпуска Vista. Руководство смирилось с реальностью, что он не станет частью релиза, но продолжало рассматривать эти технологии в качестве основных звеньев клиентской инновации. Когда Синофски реорганизовал структуру подразделения Windows для продуктового цикла Windows 7, он вынёс все проекты управляемого кода из подразделения Windows в подразделение разработки (DevDiv), выстроив их наряду с другими командами DevDiv, которые занимались созданием управляемых компиляторов, сред выполнения, базовых библиотек и сред разработки. Позже он вступит в борьбу за то, что считать основной средой выполнения Windows в процессе продуктового цикла Windows 8, но сейчас эффективно отложил борьбу, вытеснив эти команды и не создавая альтернативных проектов внутри организации Windows. Это повлекло долгосрочные последствия. Проекты продолжали потреблять внутренние инвестиции и ресурсы. Общественность продолжала думать, что за управляемыми средами выполнения — будущее Windows. Образовалась территория «выжженной земли», когда не производилось никаких значимых инвестиций за пределами управляемых областей (и, следовательно, полностью отсутствовали инвестиции для Office и других крупных неуправляемых приложений). Кроме того, команды по разработке управляемого кода теперь даже не думали о серьёзных вложениях, связанных с новыми инновациями аппаратного обеспечения, а только о построении полностью независимого связующего слоя. Эти управляемы
