ROS Blog A perspective: managed developers beyond Microsoft

Материал из Русский WINE
Перейти к: навигация, поиск

Перспектива: Разработчики вне экосистемы Microsoft

Оригинал статьи - http://www.reactos.org/node/638

Дата публикации оригинальной статьи - 12.05.2013

Автор оригинальной статьи - Цзылян Гуо


В своей прошлой статье я немного затронул тему того, что "зацикленность" Microsoft на Metro/Modern и собственном цифровом магазине приложений привела к практически полному игнорированию ими значительной части сообщества разработчиков приложений. К моему удивлению эта статья привлекла пристальное внимание многих людей, кто-то был согласен с ней, кто-то нет. Дискуссия разгорелась ещё сильнее, когда люди начали обсуждать то, сколько проблем принесла (или не принесла) Microsoft разработчикам своим довольно странным ходом. Однако я решил не закапываться глубоко в дебри этой темы, поскольку предыдущая статья и так непомерно разрослась и стала уже слишком большой. Дальше я хотел бы немного поговорить о последствиях этого шага для разработчиков и вновь постараться поставить точку в этом вопросе. В конечном счёте, всем людям, так или иначе получившим "пинка" от Microsoft, нужно выбрать, что же делать дальше. Однако этот выбор зависит от того, насколько плотно они использовали технологию Microsoft, от которой та впоследствии отказалась, а также от причины, по которой она от неё отказалась.

Что касается разработчиков Silverlight, то тут не так уж всё и плохо. Microsoft заверяет, что Silverlight в его текущей форме будет без проблем функционировать на всех ОС от Microsoft в ближайшие десять лет, и опасность того, что в ближайшее время неожиданно перестанут работать все бизнес-приложения, написанные с использованием этой технологии, практически отсутствует. Нечто похожее уже имело место ранее и происходило с приложениями эпохи до-.NET Visual Basic, а также с приложениями, написанными с использованием Microsoft Foundation Classes. Даже сегодня некоторыми крупными компаниями всё ещё разрабатываются и используются для внутренних нужд приложения на VB6 и MFC, по большей части от того, что их переписывание с использованием какой-либо новой технологии обернётся большими затратами, и это не смотря на тот факт, что VB6 содержится большое количество архитектурных недостатков, и что многие приложения на VB6 устроены куда сложнее, чем то, на что среда их выполнения вообще рассчитана. Эти приложения зачастую даже расширяются и дополняются, что для приложений MFC более простительно, чем для VB6, с учётом того, что Microsoft выпустила обновления MFC чтобы облегчить разработчикам приложений работу с некоторыми новыми функциями своих операционных систем. Однако, до тех пор, пока компании рассматривают IT как пустую трату денег, они вряд ли станут выделять ресурсы на миграцию со своих устаревших систем, в долгосрочной перспективе лишь увеличивая стоимость этого перехода путём игнорирования самого факта существования проблемы и тем самым, возможно, в будущем обрекают себя на крайне неудобное положение перед своими клиентами. Что же касается разработчиков Silverlight, позиция Microsoft, сейчас кажущаяся лишь краткосрочным неудобством, в будущем может обернуться проблемами с поддержкой приложений, использующих эту технологию, из-за отсутствия обновлений программного инструментария для разработчиков, особенно учитывая то, что около года назад проект Mono прекратил разработку Moonlight, а других альтернатив просто нет.

Разработчикам XNA одновременно и повезло, и не очень. У Silverlight имеется большое число корпоративных пользователей, вкладывающих немалые средства в эту технологию, поэтому Microsoft не может просто так прекратить её поддержку, не затронув их интересов. У XNA такой весомой поддержки нет, поэтому Microsoft не задумываясь отказалась от неё в Windows 8. Однако сделав это, Microsoft дала разработчикам проекта Mono прекрасную возможность перехватить этих разработчиков. Проект Mono анонсировал создание своего собственного фреймворка для написания игр (MonoGame), основная цель которого состоит в обеспечении совместимости с API XNA. Для разработчиков это означает, что после замены всего нескольких строк в исходном коде остальная часть уже готовой программы без проблем заработает в новой среде. Такой уровень совместимости несомненно порадует разработчиков, поскольку им не придётся изучать новый фреймворк и они смогут продолжить создавать игры, применяя все полученные ранее знания. В то же самое время, Mono обещает обеспечить для MonoGame кроссплатформенную поддержку, что означает, что игры, поддержка платформ в которых ранее ограничивалась лишь Windows или XBox, теперь могут быть запущены как на Windows, так и на Android, iOS, Linux, и Mac OS X. Популярность C# как языка для создания игр, не обошла стороной многих других. Движок Unity при работе использует Mono, это же касается и Sony Playstation Mobile SDK. Microsoft создала экосистему разработчиков игр на .NET, сделав XNA действительно комфортным и на удивление мощным фреймворком. В итоге, забросив поддержку разработчиков XNA, Microsoft тем самым снабдила все другие ОС множеством разработчиков игр, а это именно то, в чём исторически заключается слабая сторона Linux и OS X. В футболе это называют игрой в свои ворота.

В процессе обсуждения моей предыдущей статьи одни люди сделали вывод, что использование ими технологий .NET сделало их программы кроссплатформенными, другие использовали мою статью как аргумент в пользу того, что опираться на технологии Microsoft было полным безрассудством. Что касается кроссплатформенности, то по большей части это действительно так, но не стоит упускать из виду, какая именно группа разработчиков больше всего пострадала от действий Microsoft. Многие подумали, что я посочувствовал разработчикам, однако в действительности я лишь имел ввиду, что Microsoft своими действиями лишь наносит вред самой себе. Сами разработчики не так уж и сильно пострадали от потери Silverlight и XNA, а у разработчиков .NET уже есть альтернатива экосистеме Microsoft на случай, если те опять решат сделать какой-либо неприемлемый ход. Microsoft своими попытками затолкать всех разработчиков в свой магазин приложений нанесла наибольший вред лишь самой себе, создала в своей экосистеме пробелы, которых не было раньше, отняла у людей инструменты, на которые они полагались и которыми они пользовались уже много лет, и практически ничего не дала взамен. Похоже, что в Microsoft надеялись на то, что разработчики бросятся использовать предоставленные ими новые инструменты и наполнят приложениями их цифровой магазин. Вместо этого нашлись те, кто начал заполнять эти пробелы, тем самым позволяя разработчикам полностью отказаться от экосистемы Microsoft, а также исключая необходимость переходить на работу с Metro/Modern, что в итоге практически полностью нейтрализует весь отрицательный эффект от действий Microsoft. Это стало возможным лишь по той причине, что проект Mono был уже достаточно развит, чтобы заполнить образовавшиеся пробелы в экосистеме. Стоит также отметить, что это стало довольно интересным прецедентом для многих других проектов. Так что Microsoft нанесла своими действиями вред не кому-то из сторонних разработчиков, а исключительно самой себе. Извлечёт ли Microsoft из всего этого правильный урок нам ещё предстоит увидеть, однако похоже, что их руководство особой гибкостью не отличается, чего стоит лишь их недавний безумный порыв попытаться привлечь всеобщее внимание к их магазину приложений.

Переводы блогов
MonsteraБезопасное программированиеИнтеллектуальная собственность: Идеология vs ПрактичностьИнтеллектуальная собственность: ОсновыОб ОС для настольных компьютеров...Перспектива: Microsoft и игрыПерспектива: Разработчики вне экосистемы MicrosoftПерспектива: Разработчики и MicrosoftСценарии использования ReactOSЦена прогресса