"Внешние" протоколы, форматы, продукты, на которых строится собственное решение, представляют собой отягощения, как в лицензионном плане, так и в техническом. Если лицензионные отягощения еще можно оценить -- это стоимость лицензионных отчислений за единицу или "огулом" в случае неограниченных поставок, то технические отягощения (освоение API, документации и т.д., временные затраты) оценить довольно сложно.
Практика, например, игровой индустрии и встраиваемых консьюмерских решений показывает, что вместо использования типичных коммерческих библиотек (звук, видео-кодеки, разнообразные движки) за последние года четыре произошел сдвиг в сторону использования открытых стандартов (и свободных библиотек/ПО их поддерживающих) для тех компонент, которые не являются 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, чтобы не расходовать усилия зря.
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, чтобы не расходовать усилия зря.