Поделиться
Интероперабельность ПО: кто и зачем борется с ней?
Интероперабельность – ключ к нормальной работе компьютерных программ. Однако на практике поставщики ПО частенько не обеспечивают возможность полноценного обмена данными со своими решениями.Человеку для полноценного существования необходимо общение. Компьютерным программам для полноценной работы необходим обмен данными. Проблемы с социализацией чреваты психологическими осложнениями для человека. Проблемы с обменом данных чреваты потерей функциональности для программы.
Интероперабельность – ключ к нормальной работе компьютерных программ
Социализация – ключ к гармоничному существованию человеческой личности. Интероперабельность – ключ к нормальной работе компьютерных программ. В идеальном мире информационных технологий проблем с интероперабельностью нет. Программы беспрепятственно обмениваются данными, следуя общепринятым конвенциям (форматы файлов, протоколы, структуры данных и т.д.).
ЕГАИС
Впервые запущенная в 2005 году, система контроля за производством и реализацией алкоголя ЕГАИС надолго останется хрестоматийным примером решением, в котором нарушено максимальное количество правил интероперабельности. Используемые в первых версиях ЕГАИС интерфейсы обмена данных с большой вероятностью даже не были специфицированы. В связи с этим, создание аналогичного ПО для реализации функций ЕГАИС было в принципе невозможно. (Но даже если бы такое ПО было разработано, пользоваться им было бы невозможно, поскольку оно не прошло бы обязательной сертификации.) Первые версии ЕГАИС не предусматривали возможности взаимодействия с другим ПО, вынуждая всех пользователей вести двойной учет: отдельно в стандартной учетной системе и отдельно в ЕГАИС. Наконец, безальтернативное использование ЕГАИС было закреплено на законодательном уровне – вмешательство государства привело к катастрофе, которая в принципе не могла возникнуть в условиях рынка.
В реальном мире проблемы с интероперабельностью встречаются повсеместно по двум причинам: плохая работа программистов и нежелание поставщиков ПО обеспечить возможность полноценного обмена данными со своими программами.
Низкая культура разработки, которая приводит к появлению неинтероперабельного ПО, будет оставаться проблемой, поскольку в мире существуют некомпетентные разработчики. Но говорить о ней отдельно нет надобности. Достаточно ограничить свой выбор надежными поставщиками, которые не позволяют себе использовать труд некомпетентных программистов, и эта проблема отпадет сама собой.
Проблема становится гораздо сложнее, когда в основе отсутствия интероперабельности лежат коммерческие интересы. В этом случае поставщик прекрасно осведомлен о том, как сделать свое программное обеспечение интероперабельным, но сознательно этого не делает. Хуже того, поставщик сознательно создает препятствия для совместимости.
Когда несовместимость выгодна
Идеальный конкурентный рынок порождает только интероперабельные программы. Чем c большим числом систем способна взаимодействовать некоторая программа, тем прочнее ее конкурентные позиции. Напротив, несовместимость часто является следствием неконкурентного развития рынка. Не чувствуя реальной угрозы со стороны конкурентов, доминирующий поставщик начинает увеличивать собственные прибыли, мешая конкурентам создавать совместимые продукты.
Почему техническое превосходство не всегда приводит к победе на рынке?
Есть принципиальная разница между формирующимся и уже сформировавшимся рынком. В первом случае побеждает тот поставщик, который предлагает продукт с наиболее выгодными характеристиками. Во втором случае разработать перспективный продукт мало – нужно еще преодолеть действие так называемого "сетевого эффекта" (network effect). Суть его заключается в том, что стоимость продукта возрастает по мере роста числа пользователей. Например, никому не нужен сверхсовременный мобильный телефон, с которого нельзя дозвониться пользователям обычной мобильной связи – подавляющее большинство покупателей предпочтут менее совершенное в технологическом плане, но более практическое решение. Любой поставщик, стремящийся изменить статус-кво на рынке, вынужден разрабатывать стратегию борьбы с сетевым эффектом. В случае программного обеспечения эта борьба тем легче, чем выше уровень интероперабельности ПО.
Существует три основных способа обеспечения совместимости. Первый – спецификация или стандарт, в которых с достаточной подробностью описаны используемые в программе интерфейсы обмена данными. Второй – открытая эталонная реализация, которую разработчики совместимого ПО могут брать за образец при создании аналогичных программ. Наконец, наиболее затратный способ – обратный инжиниринг (reverse engineering), когда разработчики совместимого ПО вынуждены действовать наощупь, добиваясь совместимости методом проб и ошибок.
Общепринятым является первый способ, т.е. разработка ПО на основании спецификации. Эталонная реализация может быть полезным дополнением к опубликованной спецификации, хотя сама по себе редко бывает достаточна. Что касается реверс-инжиниринга, то, не говоря о чрезвычайно высокой затратности этого способа, он практически никогда не позволяет добиться полностью удовлетворительной совместимости, особенно при разработке сложных программ. Однако в отдельных случаях этот метод дает впечатляющие результаты: в частности, именно так была реализована совместимость с форматами данных Microsoft Office в офисном пакете OpenOffice.org.
Идеология одна – бизнес разный
Было бы наивно объяснять различия в поведении участников софтверного рынка разницей их идеологии. Основополагающие несоответствия кроются в их бизнес-моделях. При этом прослеживается любопытная особенность: компании поддерживают беспрепятственную интероперабельность в тех областях, которые не связаны непосредственно с их основным источником прибыли, в то время как в области своих непосредственных коммерческих интересов они ведут себя гораздо более ревниво.
Например, Microsoft либерально относится к производителям аппаратного обеспечения под Windows и программного над Windows. В то же время, действия компании в области обеспечения совместимости Windows с другими ОС намного менее однозначны. Так, в 1993 году отсутствие со стороны Microsoft достаточной информации для обеспечения интероперабельности с ее операционными системами послужило поводом для инициирования антимонопольного разбирательства в Европе со стороны Novell. Десять лет спустя Еврокомиссия признала обоснованность таких претензий, обязав Microsoft опубликовать необходимые сведения.
Apple, которая поставляет не только ПО, но и оборудование, совершенно не заинтересована в том, чтобы Mac OS X можно было запустить на любом компьютере. Более того, когда новые "маки" перешли на процессоры Intel, и для этого появилась техническая возможность, компания прибегла к печально известному закону DMCA и фактически убила в зародыше рынок дешевых компьютеров для запуска Mac OS X. Однако Apple не может не стремиться к интероперабельности в области межсистемной совместимости – иначе ее компьютеры не смогут работать в сетях Windows, а также в области технологий, используемых для разработки приложений под Mac OS X , и операционная система попросту останется без приложений.
Таким образом, каждый крупный поставщик рынка ИТ имеет свою область "предпочтительного доминирования", за пределами которой он искренне отстаивает принципы свободы рынка и интероперабельности. В общей картине несколько выделяются лишь Open Source-компании, которые "из принципа" отстаивают принцип интероперабельности даже в сфере своих непосредственных коммерческих интересов, однако сравнивать их с традиционными крупными ИТ-компаниями не имеет смысла. Open Source – это принципиально другой подход к бизнесу, и объемы прибыли поставщиков ПО с открытым кодом в принципе не могут приблизиться к объемам прибыли традиционных компаний.
Игра в царя горы
Для доминирующего поставщика естественно стремление к тому, чтобы конкуренты не имели доступа к спецификациям и эталонным реализациям и прибегали к дорогостоящему и ненадежному обратному инжинирингу, тем более что законодательство западных стран накладывает на обратный инжиниринг чрезвычайно жесткие ограничения .
Существует целый арсенал средств, позволяющих создать препятствия для конкурентов. Во-первых, поставщик может не публиковать сведения об используемых форматах данных и протоколах обмена, либо сознательно публиковать их лишь в частичном виде, не позволяя конкурентам добиться полной совместимости. Например, такова была политика Macromedia и далее Adobe в отношении формата Flash. Даже после открытия спецификаций в рамках проекта Open Screen Project в 2008 году часть спецификаций ключевых компонентов остается закрытой (отсутствует спецификация видео-кодека, используемого в Flash, права на который не принадлежат Adobe).
Во-вторых, поставщик может формально следовать одному из принятых в отрасли стандартов, однако при этом сознательно включать в свои программы дополнительные функции, не предусмотренные им. В этой ситуации конкурентам придется разрабатывать программы, которые неизбежно будут обладать ограниченной интероперабельностью. Такова пресловутая тактика embrace, extend and extinguish (воспринять, расширить и уничтожить). В 90-е годы прошлого века она применялась Microsoft при создании собственной реализации языка Java, лишь ограниченно совместимой с реализацией от Sun Microsystems.
Короткая ссылка
