![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
К вопросу о ресурсах
Отчет об исполнении решений суда по антимопомольным делам США vs Microsoft, который был опубликован позавчера, содержит и вот такую характеристику расходов, которые несет Microsoft:
Надо сказать, что это только для исполнения решения суда о программе MCPP (результат антимонопольного разбирательства в США). По программе WSPP (результат антимонопольного разбирательства в ЕС) такой отчет пока недоступен, но врядли будет преувеличением сказать, что общее число сотрудников, привлеченных для публичного или доступного за небольшую сумму документирования программных интерфейсов между Windows сервером и клиентом, сопоставимо с размерами серьезной IT-компании в России. Даже если усреднить расходы на сотрудника где-то в районе $100К USD в год (не зарплаты, а полные расходы на содержание сотрудника), то это будет порядка $75 MUSD в год. Серьезный бюджет.
Можно ли было его избежать? Возможно, но врядли целиком -- ведь даже учитывая, что подобные вложения в разработку и поддержание в актуальном состоянии документации в 40000 страниц были бы распределены по годам, ежегодные расходы все равно составляли бы около десятка миллионов долларов. Практика последних двух месяцев, за которые я имею возможность участвовать в работе программы WSPP как контрактор PFIF (стать им может любой разработчик свободного ПО, которому требуется доступ к протоколам, включенным в WSPP), показывает, что многие документы неполны. В них отсутствуют описания некоторых полей, форматов представления структур (например, строковое представление бинарных описателей объектов в запросах в AD), зависимостей между компонентами клиент-серверных связей (например, версия клиента проверяется разными программами и на основании проверки выполняются разные операции -- запрос в AD или обращение по MS RPC, а точный перечень зависимостей не указан и не понятно, как версию кодировать). Конечно, это неудивительно, учитывая объемы и сроки, да и Microsoft не очень-то и сопротивляется: пока все запросы на восполнение пробелов отрабатываются достаточно корректно и полно.
С моей точки зрения та цена (финансовая и отвлечением ресурсов), которую сейчас Microsoft платит за антимонопольное поведение, должна послужить хорошим уроком всем, кто считает, что при создании сложных вычислительных систем можно игнорировать окружающую действительность. Ни одна компания или проект по разработке ПО не живет в вакууме, работы практически во всех случаях строятся на использовании и итеративном улучшении существовавших ранее подходов, протоколов и кода. Так что делать вид, что ты изолирован, уникален, а больше ничего вокруг не существует, обойдется себе дороже. В этом смысле открытые стандарты и протоколы служат не только полезную службу потребителям, гарантируя им возможность конкуренции среди производителей, но и являются эффективным способом экономии собственных расходов в компаниях в долгосрочной перспективе. Созидающим компаниям в IT-отрасли действительно нельзя работать, руководствуясь краткосрочными приоритетами.
Over 750 Microsoft employees and contingent staff are involved in work on the MCPP
technical documentation. Given the substantial overlap between the MCPP and the European
Work Group Server Protocol Program, all of these individuals devote their efforts to work that
relates to both programs or that is exclusive to the MCPP.
Of these, approximately 320 product team engineers and program managers are actively
involved in the creation and review of the technical content of the documentation. There are
over 25 full-time employees and over 50 contingent staff working as technical writers, editors,
and production technicians. Additionally, as the protocol testing effort continues, approximately
40 full-time employees and approximately 360 contingent and vendor staff work as software test
designers, test engineers, and test architects. Significant attention to and involvement in the
technical documentation and the MCPP extend through all levels of the Microsoft organization
and draw upon the resources of numerous product engineering, business, technical, and legal groups, as well as company management.
Надо сказать, что это только для исполнения решения суда о программе MCPP (результат антимонопольного разбирательства в США). По программе WSPP (результат антимонопольного разбирательства в ЕС) такой отчет пока недоступен, но врядли будет преувеличением сказать, что общее число сотрудников, привлеченных для публичного или доступного за небольшую сумму документирования программных интерфейсов между Windows сервером и клиентом, сопоставимо с размерами серьезной IT-компании в России. Даже если усреднить расходы на сотрудника где-то в районе $100К USD в год (не зарплаты, а полные расходы на содержание сотрудника), то это будет порядка $75 MUSD в год. Серьезный бюджет.
Можно ли было его избежать? Возможно, но врядли целиком -- ведь даже учитывая, что подобные вложения в разработку и поддержание в актуальном состоянии документации в 40000 страниц были бы распределены по годам, ежегодные расходы все равно составляли бы около десятка миллионов долларов. Практика последних двух месяцев, за которые я имею возможность участвовать в работе программы WSPP как контрактор PFIF (стать им может любой разработчик свободного ПО, которому требуется доступ к протоколам, включенным в WSPP), показывает, что многие документы неполны. В них отсутствуют описания некоторых полей, форматов представления структур (например, строковое представление бинарных описателей объектов в запросах в AD), зависимостей между компонентами клиент-серверных связей (например, версия клиента проверяется разными программами и на основании проверки выполняются разные операции -- запрос в AD или обращение по MS RPC, а точный перечень зависимостей не указан и не понятно, как версию кодировать). Конечно, это неудивительно, учитывая объемы и сроки, да и Microsoft не очень-то и сопротивляется: пока все запросы на восполнение пробелов отрабатываются достаточно корректно и полно.
С моей точки зрения та цена (финансовая и отвлечением ресурсов), которую сейчас Microsoft платит за антимонопольное поведение, должна послужить хорошим уроком всем, кто считает, что при создании сложных вычислительных систем можно игнорировать окружающую действительность. Ни одна компания или проект по разработке ПО не живет в вакууме, работы практически во всех случаях строятся на использовании и итеративном улучшении существовавших ранее подходов, протоколов и кода. Так что делать вид, что ты изолирован, уникален, а больше ничего вокруг не существует, обойдется себе дороже. В этом смысле открытые стандарты и протоколы служат не только полезную службу потребителям, гарантируя им возможность конкуренции среди производителей, но и являются эффективным способом экономии собственных расходов в компаниях в долгосрочной перспективе. Созидающим компаниям в IT-отрасли действительно нельзя работать, руководствуясь краткосрочными приоритетами.
интересные данные
P.S. я где-то через месяц снова займусь бинарными форматами, так что скорее всего будет очередная пачка замечаний :-)
Re: интересные данные
Re: интересные данные
no subject
no subject
Я уже который раз вижу, что народ просто не умеет пользоваться доступным публично материалом для обоснований, это да. И аргументируют это еще тем, что "они не знали". Задачи, значит, космической важности, решать знают как, а найти информацию не знают как. :-)))
no subject
потому что на вопрос где взять на это время начальство уже не находило что ответить ;)
no subject
no subject
но есть надежда что осенью сядем писать новую версию движка, и документацию удастся включить в план.
no subject
no subject
# [MS-RDPBCGR]: Remote Desktop Protocol: Basic Connectivity and Graphics Remoting Specification
# [MS-RDPEA]: Remote Desktop Protocol: Audio Output Virtual Channel Extension
# [MS-RDPECLIP]: Remote Desktop Protocol: Clipboard Virtual Channel Extension
# [MS-RDPEDYC]: Remote Desktop Protocol: Dynamic Channel Virtual Channel Extension
# [MS-RDPEFS]: Remote Desktop Protocol: File System Virtual Channel Extension
# [MS-RDPEGDI]: Remote Desktop Protocol: Graphics Device Interface (GDI) Acceleration Extensions
# [MS-RDPELE]: Remote Desktop Protocol: Licensing Extension
# [MS-RDPEMC]: Remote Desktop Protocol: Multiparty Virtual Channel Extension
# [MS-RDPEPC]: Remote Desktop Protocol: Print Virtual Channel Extension
# [MS-RDPEPNP]: Remote Desktop Protocol: Plug and Play Devices Virtual Channel Extension
# [MS-RDPEPS]: Remote Desktop Protocol:Session Selection Extension
# [MS-RDPERP]: Remote Desktop Protocol: Remote Programs Virtual Channel Extension
# [MS-RDPESC]: Remote Desktop Protocol: Smart Card Virtual Channel Extension
# [MS-RDPESP]: Remote Desktop Protocol: Serial Port Virtual Channel Extension
# [MS-RDPEXPS]: Remote Desktop Protocol: XML Paper Specification (XPS) Print Virtual Channel Extension
Понятно, что там нужно смотреть на лицензии, патенты и проч. Но это уже все есть. Если доказать, что RDP входит в список протоколов, необходимых для реализации Workgroup servers, то можно формально запросить включение этого комплекта протоколов из MCPP в WSPP (по идее, почти все должно быть включено, но есть некоторые нюансы).
no subject
Дороже, но "потом": если ты уже монополист, то можешь себе позволить это "дорого". Если же ты только что открылся, то первая задача – закрепиться, и доп. расходы на всякую "побочную" деятельность вроде документирования вряд ли помогают этому, а открытие протоколов сразу – фактически является помощью конкурентам в выдавливании тебя.
Поэтому как достоверно измерить это "дороже"? Абсолютные цифры вряд ли являются хорошим показателем, а как рассматривать с учетом всей окружающей ситуации – непонятно.
no subject
Практика, например, игровой индустрии и встраиваемых консьюмерских решений показывает, что вместо использования типичных коммерческих библиотек (звук, видео-кодеки, разнообразные движки) за последние года четыре произошел сдвиг в сторону использования открытых стандартов (и свободных библиотек/ПО их поддерживающих) для тех компонент, которые не являются core expertise для компаний. То есть, вместо отчислений за mp3/aac/wmv многие переходят на Ogg Vorbis/Theora (чаще всего их достаточно), вместо закрытых CHM на HTML/PDF, вместо специализированных языков в движках -- на открытые python, lua и прочие scheme. То же самое касается и протоколов -- мало кому надо что-то новое выдумывать, абсолютное большинство новых "протоколов" -- это вариации, на транспортном или логическом уровнях, поверх существующих, особенно если речь идет о сетевом ПО, которое имеет интерфейс с пользователем и своим же серверным компонентом. Тут, как правило, в дело идут примитивные web-services поверх HTTP/HTTPS/XMPP.
Это практика, с нуля выстраивать уже никто не собирается, потому что как раз на этом терять свое время и ресурсы бессмысленно, нужно же "закрепиться".
Что касается разработки абсолютно новых протоколов, то таких очень мало и их поставщики обычно заинтересованы в активном внедрении и широком распространении. Если протоколы направлены на утилизацию тех или иных аппаратных средств, то именно аппаратные компоненты будут преимущественным образом генерировать доход. Показательный случай -- Infiniband, где разработчики железа из разных групп были вынуждены сначала объединить усилия на аппаратном уровне (работы по Future I/O и ngio превратились в Inifiniband), а потом из-за отсутствия логического стандарта и вовсе забросить личные разработки драйверов и объединиться в OpenFabric Alliance. Желание унификации со стороны производителей было таково, что даже соединительные кабели CX4, которые используют в Infiniband, были выбраны в качестве соединительных кабелей в Serial Attached SCSI, чтобы не расходовать усилия зря.