Стандарт, еще стандарт

Автор: Илья Щуров Voyager

Занимаясь тематикой свободного ПО уже несколько лет, я успел привыкнуть к некоторым простым и очевидным вещам. Например, к тому, что открытые стандарты для интерфейсов и форматов - это не только хорошо, но и очень важно. Причем важно для всех. Ну, скажем, любая блондинка из анекдота должна испытывать неописуемые нравственные страдания, пересылая своей знакомой файл в проприетарном формате DOC - а вдруг у той не окажется MS Windows или MS Office и она не сможет его прочитать или отредактировать? И уж конечно, я полагал, что за противостоянием "ODF vs. OOXML" следит все прогрессивное человечество.

Тем неожиданнее было обнаружить, что идея темы, посвященной стандартизации офисных форматов, встретила определенное сопротивление. "А кого это вообще волнует - какие там форматы файлов разработчики используют?" - спрашивал Володя Гуриев. Ответ на этот вопрос был мне столь очевиден, что я не нашел слов, чтобы его выразить. Пришлось писать статью.

Впрочем, вопрос действительно не очень простой. С чего бы это вокруг в общем-то технической процедуры стандартизации разгорелись страсти, достойные по накалу даже не мексиканских мыльных опер, а остросюжетных сериалов? Имеют ли какое-то значение стандарты в жизни "простого пользователя", если он зачастую не знает об их существовании? Каковы общие принципы развития информационных технологий - и как мы можем на них повлиять, чтобы извлечь из них максимальную пользу? Какова роль государственного управления в этих процессах?

Чтобы попытаться если не ответить, то хотя бы поместить в правильный контекст все эти и многие другие вопросы, нам придется поговорить о стандартах вообще, слегка погрузиться в историю, вспомнить браузерные войны и проанализировать события, происходящие буквально на наших глазах.

Вообще говоря, единого определения "открытого стандарта" не существует - разные источники приводят немного разные формулировки, и зачастую обсуждаются разные степени или аспекты "открытости". Тем не менее можно выделить основные свойства, которым должен удовлетворять "открытый стандарт". Спецификации стандарта должны быть доступны для ознакомления и использования - бесплатно или за некоторую фиксированную цену. Любой разработчик без какой-либо дискриминации должен иметь возможность реализовать стандарт. Стандарт не должен требовать лицензионных или патентных отчислений для своей реализации (отсутствие роялти). Еще одно важное требование: принятие стандарта и его новых версий должно происходить путем обсуждения и поиска консенсуса, по понятным и прозрачным правилам, чтобы любая заинтересованная сторона имела возможность повлиять на его развитие.

То, каким образом стандарт разрабатывается и поддерживается, является критически важным. Даже если одна компания опубликует спецификации какой-то технологии и даже если эта технология достаточно популярна, чтобы на нее ориентировались другие разработчики, спецификация не станет стандартом до тех пор, пока к процессу ее разработки не обеспечен равный доступ всех заинтересованных лиц. Например, если с выпуском новой версии некоторого ПО меняется и завязанная на него спецификация, производители конкурирующих продуктов, которые хотят поддерживать совместимость с этим ПО, оказываются в положении догоняющих, а "владелец" спецификации имеет преимущество.

В связи с этим разработкой стандартов в большинстве случаев занимаются отраслевые консорциумы (такие как IETF, W3C, OASIS, Ecma и т. д.) по своим внутренним правилам, а окончательное утверждение многих международных стандартов происходит в ISO (International Organization for Standartization).

Разные объекты как материального, так и информационного миров должны уметь взаимодействовать друг с другом, а для этого обладать "общим языком" в том или ином виде. Гайки должны накручиваться на болты, вагоны - не сходить с рельс, сотовые телефоны - уметь связываться с базовыми станциями. Это очевидно. Для всего этого должны быть разработаны и соблюдаться стандарты - договоренности между производителями о том, какими должны быть вагоны, гайки и сотовые телефоны и как они должны "общаться" с другими объектами.

Но новые технологии редко начинаются со стандарта. Чтобы что-то стандартизовать, это "что-то" нужно сначала сделать (хоть в каком-то виде). До тех пор, пока не изобретены болты и гайки, вряд ли кому-то придет в голову договариваться о том, какого они должны быть размера и с каким шагом должна идти резьба.

А когда новая технология появилась хотя бы в общих чертах, у многих производителей возникает вполне естественное желание "срубить бабла" - или, говоря по-научному, быстро захватить рынок. И это желание ничего знать не хочет ни о какой "пользе для индустрии". Если кому-то это удается и технология (в его реализации) получает массовое распространение - она и становится "стандартной" без всякой оглядки на других участников рынка. Получается то, что иногда называют "стандартом де-факто". Обычно подобные стандарты появляются вместе с монополиями, их обслуживающими.

Процесс подобного захвата рынка тесно связан с так называемыми сетевыми эффектами, когда ценность некоторого продукта или технологии возрастает вместе с количеством людей, которые ею пользуются. Часто упоминаемый "закон Меткалфа" гласит: ценность любой сети растет как квадрат числа узлов (пользователей) в ней. При этом каждый участник рыночной борьбы заинтересован в том, чтобы противодействовать совместимости с продуктами конкурентов (то есть объединению сетей)[Я писал об этих сетевых эффектах в "13 комнате" в прошлом номере.]. Это приводит к появлению сильных положительных обратных связей в сложной динамической системе под названием "рынок" - и делает ее неустойчивой в условиях существования нескольких несовместимых конкурирующих решений. Единственное устойчивое состояние подобной системы, к которому она неминуемо стремится, - весь рынок захвачен одним производителем-монополистом. Ценность сети, порожденной продуктом монополиста, достигает (локального!) максимума, а отсутствие совместимости блокирует появленияе конкурентов. Особенностью рынка программного обеспечения является возможность длительное время противодействовать совместимости благодаря закрытости исходных кодов программ и использованию закрытых (проприетарных) форматов и протоколов, которые легко менять (монополисту) и трудно анализировать (его конкурентам). Проблему еще больше усугубляет возможность использования патентов для борьбы с совместимостью.

Для индустрии такая ситуация является крайне нежелательной (как и любая другая монополизация), но рынок зачастую не может самостоятельно из нее выйти. Чтобы это произошло, требуются существенные изменения "правил игры".

Одну "войну стандартов", имевшую если не разрушительные, то по крайней мере весьма неприятные последствия для каждого из нас, многие наши читатели со стажем должны помнить. Речь идет о противостоянии Microsoft и Netscape в середине 90-х годов на зарождавшемся в тот момент рынке браузеров. Причем ситуация тех лет во многом схожа с нынешней, хотя, конечно, есть и существенные отличия.

Браузерная война тоже велась вокруг формата документов - им был HTML (вместе со связанными технологиями, такими как JavaScript и CSS). Но, в отличие от уже устоявшихся офисных приложений сегодня, веб в то время был очень молодой технологией, и каждый разработчик считал своим долгом добавить в нее какую-нибудь "инновацию", которая помогла бы захватить рынок. Попытки стандартизации, по сути, проваливались: даже когда явные спецификации HTML были утверждены консорциумом W3C, разработчики с обеих сторон с удовольствием добавляли к ним нестандартные расширения, поддерживаемые только одним браузером, да и соблюдать написанное явно не торопились. Стандарты отставали от реальности, на разговоры и оглядку на спецификации времени не было. Целью этой гонки были не столько конечные пользователи, сколько веб-разработчики, плодящие многочисленные сайты с кнопками "Best viewed with…".

Microsoft выиграла ту битву (не без помощи "тяжелой артиллерии" в виде подконтрольной операционной системы), и на некоторое время Microsoft Internet Explorer захватил рынок полностью. Даже в Mac OS он был стандартным браузером с 1997 по 2003 год в соответствии с соглашением между Microsoft и Apple. HTML "от Microsoft" стал тем самым пресловутым стандартом де-факто, на который одно время ориентировалось большинство веб-разработчиков. Более того: было написано огромное количество корпоративных клиент-серверных систем, использовавших различные особенности MSIE для реализации клиентской части и тем самым привязывавших пользователей к платформе Microsoft.

Развитие MSIE фактически прекратилось, но альтернативные браузеры остались и продолжали развиваться. Кроссплатформные Opera и Mozilla, а также Safari, превосходившие по своим возможностям MSIE, стали медленно откусывать свой небольшой, но все-таки заметный кусок пирога, - и со временем веб-разработчики стали понимать, что ориентация только на MSIE может навредить их бизнес-интересам. Vendor lock-in перестал работать как задумано. С этого момента погоня за "инновациями" середины девяностых и игнорирование "писаных" стандартов неприятно аукнулась всей индустрии: веб-разработчики были вынуждены писать несколько версий своего кода для разных браузеров. Аукнулось оно и Microsoft: когда соответствие стандартам стало одной из приоритетных целей, MSIE из лидера превратился в аутсайдера.

И еще один важный факт: оказалось, что реализовать даже сравнительно несложные спецификации HTML+CSS, мягко говоря, непросто. Например, лишь в 2006 году тест Acid2 был пройден браузером под Windows (им стала далеко не мейнстримная Opera, а прохождение этого теста MSIE нам только обещают в грядущей восьмой версии). Конечно, гораздо проще взять какой-то продукт и объявить его реализацию "стандартной". И понятно, что разработчик ПО, на основе которого стандарт пишется, получает существенное преимущество перед своими конкурентами…

Пожалуй, сейчас никто точно не скажет, почему именно Microsoft Office стал стандартом де-факто на столь долгие годы. Энди Апдегрув (Andy Updegrove), член совета директоров ANSI, юрист и эксперт по стандартам (в частности, консультирующий консорциум OASIS и автор сайта consortiuminfo.org), в своей электронной книге "ODF vs. OOXML: War of the Words" (в стадии написания) приводит подробный (хоть и неоднозначный) анализ ситуации, сложившейся вокруг офисных продуктов в начале 80-х годов. В целом этот анализ вписывается в вышеприведенный сценарий развития сетей.

В то время Microsoft была лишь небольшой софтверной компанией, а мир PC постепенно захватывали текстовые процессоры WordStar и (позже) WordPerfect, а также знаменитый пакет Lotus 1-2-3, включавший одну из первых систем электронных таблиц (впрочем, самой первой все-таки была VisiCalc). Общая картина тогда сильно отличалась от сегодняшней: было несколько сравнительно распространенных операционных систем, а действительно важных прикладных программ - по пальцам пересчитать, и разработчик ОС попадал в зависимость от сторонних производителей софта - таких как Lotus. Например, желая выпустить новую версию ОС, разработчик должен был убедиться, что другие вендоры захотят портировать на нее свои приложения - в противном случае рыночная ценность такой системы равнялась бы нулю.

Microsoft смогла выхватить рынок офисных приложений, а заодно существенно укрепить свое положение на динамичном в то время рынке ОС благодаря довольно тонкой игре. "Компания Lotus (наряду с другими вендорами) поверила заявлениям Microsoft о том, что последняя будет поддерживать OS/2 - операционную систему, которую она продвигала вместе с IBM. Основываясь на приеме, который позднее получит название "Microsoft’s head fake" (мне не удалось найти адекватный перевод - И.Щ.), Lotus потратила много ресурсов на портирование 1-2-3 на OS/2, прежде чем обратила внимание на набирающую силы MS Windows. Когда Microsoft прекратила поддержку OS/2 и выпустила новую, существенно улучшенную версию Windows вместе с уже готовым для нее Excel, Lotus осталась на месяцы позади", - пишет Апдегрув. При этом Microsoft рисковала продажами Windows, зато получала независимость от Lotus. В дальнейшем, продавая операционную систему вместе с офисными приложениями, Microsoft смогла вести достаточно агрессивную ценовую войну с конкурентами (в первую очередь с Apple), не имевшими в своем активе полного комплекта.

Вскоре стали проявляться сетевые эффекты, о которых шла речь выше. Способы работы с документами изменились: люди начинали обмениваться файлами (сначала на дискетах, затем по компьютерным сетям), а не бумажными распечатками, и вопрос совместимости форматов впервые встал перед покупателями ПО. О необходимости стандартизации тогда вряд ли кто-то мог подумать (учитывая молодость и динамичность индустрии, стандартизация могла быть даже вредна), поэтому бизнес-пользователи были вынуждены прибегнуть к совместимости "через приложение". Таким приложением стал Microsoft Office. Тогда же возникла необходимость конвертировать документы из одного формата в другой - и естественно, что Microsoft сделала многое, дабы обеспечить импорт "чужих" форматов файлов в "свои" - но не наоборот. Ловушка захлопнулась.

Разработка стандарта ISO состоит из шести этапов - начиная с определения необходимости международного стандарта ("Proposal stage") и заканчивая утверждением и публикацией. Помимо ISO, разработкой стандартов занимаются отраслевые консорциумы. Наиболее уважаемые консорциумы (к ним относятся и OASIS с Ecma, упоминающиеся в статье), являющиеся партнерами ISO, имеют возможность подавать разработанные ими стандарты сразу на пятый этап (утверждение стандарта) - что и называется процедурой Fast Track.

Стратегия замыкания клиентов на одном поставщике ("vendor lock-in"), эксплуатирующая сетевой эффект и в разное время используемая разными компаниями, на самом деле не всегда приводит к ожидаемому результату. Использование сверхпопулярного плеера iPod в жесткой связке с магазином iTunes Music Store благодаря средствам DRM привело к существенному увеличению популярности последнего - но в то же время наличие такого vendor lock-in могло отпугнуть многих потенциальных покупателей iPod’ов и - в случае меньшей лояльности пользователей к продукции фирмы Apple - привести к краху всей затеи (см. также врезку "Еще не отгремели пушки").

Закрытые форматы файлов могли быть восприняты как неизбежная реальность в конце 80-х, они могли быть конкурентным преимуществом в середине 90-х, они могли быть не очень приятным приемом конкурентной борьбы в конце 90-х. Но сейчас ситуация меняется, и закрытость все в большей степени является недостатком, а не преимуществом - для самой Microsoft.

Аналитики из Burton Group в своем отчете "What’s up, .DOC?" выделяют несколько рыночных требований, которые невозможно удовлетворить, используя закрытые бинарные форматы. В их число входят: возможность динамической сборки документов из разных источников, повторное использование контента, в том числе автоматическая обработка запросов и извлечение данных, инспекция и автоматическая "очистка" документов (например, удаление истории правки при публикации). В том же отчете (а равно и в других источниках) как один из существенных факторов изменения IT-ландшафта отмечается переход к модели "Software as a Service" (SaaS), о котором так долго говорили больше… простите, ИТ-журналисты и который вот уже совсем скоро вроде бы наконец должен свершиться окончательно, привнеся новых игроков и новые модели работы.

Документ в текстовом процессоре или электронная таблица все больше отдаляются от своих "бумажных" предков - как по внутренним свойствам, так и по сценариям использования. Они становятся "умнее". Частично возможности автоматической обработки офисных файлов, выходящие за рамки самих офисных пакетов, существовали давно - например, в случае MS Office можно было использовать OLE Automation для получения доступа к функциям пакета из внешнего приложения или же написать соответствующий код с помощью макросов VBA. Однако эти возможности довольно ресурсоемки и платформнозависимы (с чем соглашаются в Microsoft) - и это уже перестает удовлетворять многих разработчиков.

Использование форматов с доступными спецификациями, пригодных для автоматической обработки сторонними приложениями, кажется довольно заманчивым решением. Технологическая основа таких форматов - популярный ныне XML, позволяющий сохранять древовидные структуры данных любой сложности в виде простого текстового файла, разметка которого сравнительно неплохо обрабатывается компьютерами и может читаться людьми (в отличие от бинарных форматов). Однако это лишь маленький шаг на пути к открытым стандартам. Использование XML, в общем-то, не является ни необходимым, ни достаточным условием для обеспечения открытости и интероперабельности - если спецификация формата остается "собственностью" компании-вендора и может свободно меняться вместе с выходом новой версии ПО. Такая стратегия кажется естественной для компании-монополиста - и Microsoft ее использовала в разных областях своей деятельности. Тем не менее в ситуации с офисными форматами компания решила пойти дальше. Почему?

На всякое явление можно посмотреть как на волю определенных сил и как на естественное развитие событий. В связи с этим, мне кажется, всегда лучше обращать внимание на факты.

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

Второй факт - OpenXML - это файловый формат, который уже поддержан производителями информационных систем, в том числе и благодаря качественной спецификации стандарта. Вот несколько примеров приложений (более полный список можно найти на www.openxmlcommunity.org/applications.aspx):

- Три самых распространенных в мире офисных пакета: Microsoft Office (начиная с 2000), Corel Perfect Office и Apple iWork.

- OpenOffice.org в версии от Novell.

Мобильные платформы Apple iPhone, Office Mobile, www.quickoffice.com.

Даже IBM, затратившая беспрецедентные усилия на кампанию против Open XML, поддерживает его в таких продуктах, как LotusQuickr, Websphere Portal, DB2 Content Manager v8.4 и DB2 9 pureXML.

И, конечно, интернет-игроки тоже поддержали новый стандарт. Поиск Google прекрасно демонстрирует OpenXML-документы в виде HTML-страниц, с ними также умеет работать сервис ThinkFree.com.

Мне кажется, уже можно сказать, что формат OpenXML востребован рынком, и главным образом благодаря тем принципам, которые Ecma International заложила в основу этого стандарта. Среди них - полнота и однозначность спецификации (она же упрощает реализацию), возможность конвертации из старых форматов Microsoft, Corel и др. и управления долговременным хранением (да, в мире накоплено много документов, и предлагать формат, не гарантирующий однозначного преобразования, - слишком "смелое решение"), самоописываемая стандартными средствами расширяемость, отсутствие требований, исключающих применение того или иного стандарта, ориентация на оптимизацию производительности, учет национальных требований (мы же не хотим ради нового формата документов менять свои законы). Недоговоренность по этим принципам пока не позволила достичь единства с OASIS, который разработал ODF. Но я думаю, что голос пользователей будет услышан всеми, и верю, что эти форматы будут постепенно сближаться.

Владимир Габриель,

руководитель экспертной группы, Microsoft

Одна из основных забот государства в условиях смешанной экономики - борьба с недобросовестной конкуренцией и монополиями, и деятельность антимонопольных служб нельзя недооценивать. (В качестве свежего примера можно привести недавнее постановление Еврокомиссии, из-за которого Microsoft пришлось передать проекту Samba критически важную для интероперабельности документацию.) Однако, помимо прямого регулирования, государство имеет возможность и косвенно влиять на рынок, будучи крупнейшим заказчиком - в том числе и в сфере информационных технологий.

В качестве заказчика государство имеет свои особенности. Если в частном секторе любой участник рынка волен выбирать инструменты для работы самостоятельно, государство (по идее) должно быть лишено такой свободы. Если частная компания не хочет использовать принятые в индустрии решения по каким-либо причинам (например, юридическая фирма станет запрашивать и отправлять документы в формате LaTeX вместо MS Word), то она имеет на это право, поскольку партнеры или клиенты всегда могут сказать "спасибо, мы пойдем в другое место". Гражданин не может произнести подобную фразу по отношению к своему государству, и государству приходится это учитывать - и тем больше, чем "более электронным" оно становится.

Логично, что, общаясь с гражданином по цифровым каналам, государство не имеет права навязывать ему какое-либо конкретное ПО или платформу - даже если это ПО является "стандартом де-факто". Если 99% граждан моей страны используют какой-то продукт, это не значит, что и я обязан использовать тот же продукт (особенно если нехорошие люди из забугорной компании хотят за него моих кровных денег). Независимо от того, какой софт я предпочитаю использовать, государство должно иметь возможность "понимать" меня, а я - "понимать" государство. В крайнем случае, если устраивающего меня софта не существует, я должен иметь техническую возможность написать его самостоятельно. По сути, это следствие требования равенства всех граждан перед законом. Также различные подразделения государства (министерства, ведомства, агентства и т. д.) должны иметь возможность взаимодействовать друг с другом. Естественный путь к этому - ввести требования обязательности поддержки открытых стандартов теми программами (и, шире, информационными системами), которые используются в государственном управлении.

Есть и другие причины, по которым именно государство заинтересовано в использовании открытых стандартов на информационные технологии. В первую очередь, как правило, отмечают необходимость долговременного хранения документов - что практически невозможно, если архивы хранятся в проприетарном формате с закрытыми спецификациями. Никто не гарантирует, что через семьдесят лет будет существовать ПО, способное прочитать эти файлы. Наличие четкой "человекочитаемой" спецификации формата позволяет надеяться, что и через семьдесят, и через сто, и через двести лет найдется инженер, способный реализовать соответствующее приложение на существующих в тот момент системах.

Зависимость от одного поставщика, который может перестать поддерживать формат или просто исчезнуть с лица Земли, является крайне опасной.

Эти и другие аргументы заставляют государственные структуры многих стран разрабатывать специальные наборы требований к информационным технологиям, которые могут использоваться в публичном секторе. Одно из таких требований - предпочтительное использование международных стандартов - в частности, принятых в ISO.

IBM участвует в разработке многих стандартов, в том числе и для электронных документов. Работа над стандартизацией формата ODF началась более пяти лет назад, а после того, как он стал стандартом ISO, мы поддержали этот стандарт как имеющий широкое применение в отрасли и большую пользовательскую базу своим вступлением в OpenOffice.org 10 сентября 2007 года. На сегодняшний день это единственный открытый, совместимый, не являющийся собственностью какой-либо компании и стандартизованный формат для офисных приложений. Для пользователя это означает постоянный доступ к документам, независимо от того, с помощью какого приложения они были созданы. ODF гарантирует сохранность документа даже в том случае, если программа, в которой он создавался, больше не существует.

IBM разрабатывает технологии и продукты, такие как Lotus Symphony, под ODF и является членом сообщества OpenOffice.org. Первоначальный вклад IBM - исходный код разработок, выполненых в рамках нашего продукта Lotus Notes, например, улучшение доступности приложений. Мы планируем дальнейшее совершенствование как функциональности, так и кода OpenOffice.org. Помимо работы с сообществом над свободным ПО для офиса, мы также будем использовать технологии, разрабатываемые в рамках OpenOffice.org, в наших продуктах.

Мы поддерживаем ODF, потому что видим в этом формате открытость, совместимость и возможность выбора для клиента, что является критически важным для IT-отрасли в целом, так как позволяет клиентам легко переключаться с использования одного приложения на другое, если они используют общий формат, - это те законы, по которым работает рынок, и то, как развиваются инновации. Инновации по-настоящему активизируются после того, как изобретение становится недорогим, стандартизованным и начинает широко использоваться. Чем больше людей его используют, тем больше рождается творческих идей по применению этого изобретения и тем больше вероятность открытия новых методов его применения. Инновациям требуются открытые стандарты.

Марат Гуриев,

директор государственных программ IBM EE/A

Когда администрация штата Массачусетс в конце 2005 года, после двадцати месяцев обсуждений, приняла решение начиная с 2007 использовать для хранения своих документов стандартизированные форматы, единственным кандидатом на эту роль был Open Document Format (ODF), лишь некоторое время назад утвержденный консорциумом OASIS (и еще не поданный на утверждение в ISO)[Для хранения и публикации документов, не предназначенных для изменения, был выбран PDF, что оказалось довольно спорным и критикуемым решением, поскольку о его стандартизации речи тогда не шло.]. В Microsoft поняли, что у них возникли проблемы - компания не планировала поддержку ODF в своих продуктах. Казалось, что это звездный час для таких конкурентов Microsoft, как Sun и IBM (а также Adobe и Corel), сделавших немало для разработки и продвижения ODF. Появился реальный шанс пошатнуть монополию Microsoft.

На пример Массачусетса стали обращать внимание власти других штатов и государств, и со временем копилка лагеря ODF пополнилась множеством пресс-релизов о планах тех или иных госструктур по переходу на этот формат.

Однако в дальнейшем стало ясно, что ситуация не столь радужна, как казалось. Microsoft упорно отказывалась поддерживать ODF в своих продуктах "нативно", но перестать использовать MS Office было не так-то просто, и дело здесь не только в форматах. Многие информационные системы оказались завязаны на продукцию Microsoft и эксплуатировали ее специфические возможности (в частности, VBA). Сохранить эти системы и одновременно перейти на ODF было невозможно (доступных сторонних решений по работе с ODF из MS Office тогда не было), и в результате стоимость миграции оказалась заоблачной.

Вокруг проекта по переходу на ODF возникла нездоровая атмосфера. Главного идеолога миграции Питера Куинна (Peter Quinn), ответственного за IT в администрации Массачусетса, обвиняли в недостаточно проработанной оценке стоимости проекта, в предоставлении неоправданных преференций бизнес-моделям, ориентированным на открытый код, игнорировании нужд различных групп пользователей, которым требовалось использовать MS Office (в частности, из соображений accessibility) и прочих смертных грехах. В начале 2006-го, за год до планируемого перехода, Питер Куинн был вынужден подать в отставку. Тем не менее новый главный CIO Массачусетса Луис Гутиэррес (Louis Gutierrez) заявил, что штат остается верен курсу на открытые стандарты - но не планирует мигрировать с MS Office, а будет использовать уже появившиеся к тому времени плагины для работы с ODF[Впоследствии в штате Массачусетс был разрешен и формат MS OOXML, когда он стал стандартом Ecma, - о чем будет рассказано ниже].

"На сей раз пронесло", - вероятно, подумали в Microsoft.

Один из распространенных пунктов технической критики OOXML: согласно календарным формулам, приведенным в спецификациях формата электронных таблиц, 1900 год получается високосным, что неверно. По словам представителей Microsoft, впервые этот "баг" появился в Lotus 1-2-3 - в те давние времена процессорное время было дорого и упрощение формул за счет таких незначительных погрешностей только приветствовалось. Однако, ради соблюдения обратной совместимости, до сего момента этот "баг" умышленно повторялся в большинстве реализаций электронных таблиц. Исправить его в спецификации OOXML - раз плюнуть, но когда "технари" от Microsoft заикнулись об этом на заседании технического комитета Ecma, им быстро "заткнули рот" представители крупного бизнеса, опасавшиеся проблем с уже накопленным массивом данных. Тем не менее, ссылаясь на критику, поступившую из ISO, Ecma предлагает все-таки внести необходимые изменения - и, быть может, исправить досадное недоразумение.

Впрочем, Массачусетс не был "первым звоночком" для редмондского гиганта. Еще в мае 2004-го комитет по техническому взаимодействию между администрациями Евросоюза (Telematics between Administrations Committee, TAC) выпустил несколько важных рекомендаций, связанных с форматами документов. Изучив положение дел в отрасли (в тот момент были опубликованы как промежуточные спецификации готовящегося стандарта ODF, так и XML-формата WordML от Microsoft - части будущего OOXML), Еврокомиссия предложила Microsoft "взять на себя обязательства по публикации и предоставлению недискриминирующего доступа к будущим версиям спецификаций формата WordML", а также "внести свои XML-форматы в какую-либо международную стандартизирующую организацию по своему выбору".

Microsoft сделала выбор спустя полтора года: в ноябре 2005-го было принято решение стандартизировать XML-формат, используемый в разрабатываемом Office 2007, силами организации Ecma International. Спустя еще год Ecma утвердила окончательный текст стандарта, получившего название ECMA-376 "Office Open XML", и приняла решение о его передаче в ISO для окончательного утверждения по ускоренной процедуре (Fast Track). Казалось, что Microsoft находится в двух шагах от обретения "собственного" (то есть уже практически реализованного в Office 2007) стандарта ISO.

Нетрудно было догадаться, что подобный шаг софтверного гиганта мало кем будет встречен на ура. Но вряд ли кто-то мог знать, что вокруг OOXML развернется битва не на жизнь, а на смерть.

Критика посыпалась со всех сторон. Первый и естественный вопрос вообще не касался технического устройства формата: зачем нужен второй стандарт ISO на формат офисных документов, если один уже есть (ODF был стандартизован в ISO практически в тот же момент, когда люди из Ecma подали свою заявку)? Критики указывали на то, что это противоречит целям ISO, а необходимость поддерживать два стандарта существенно увеличивает нагрузку на индустрию. Почему Microsoft не поддерживает уже принятый ODF? Почему бы не объединить OOXML и ODF?

В Microsoft приводили развернутые аргументы в пользу того, что OOXML и ODF имеют принципиально разные цели и задачи (например, расходятся в вопросе об обратной совместимости), поэтому нельзя говорить, что они задают взаимозаменяемые стандарты (а значит, никаких противоречий с целями ISO нет), и объединить их, сохраняя различные подходы к архитекутре - невозможно. "К тому же было бы нечестно делать ODF единственным международным стандартом лишь по той причине, что его сторонники успели первыми со стандартизацией в ISO", - говорит менеджер по стратегии платформ Microsoft Владислав Шершульский.

Другая форма критики касалась технических недочетов в спецификациях. При обсуждении и анализе 6 тысяч страниц описания стандарта в ходе процедуры Fast Track было высказано больше 3 тысяч замечаний (правда, оценить, сколько из них уникальны, а сколько повторяются, пока невозможно). Претензии были самые разные: нестандартный формат представления времени (не позволяющий работать с датами до 1900 года); использование (в целях пресловутой обратной совместимости) тегов типа SpaceLikeWord95, описанных в терминах поведения приложений предыдущих поколений; возможность использования пользовательской семантической разметки документов с помощью custom-тегов (открывающее, по мнению критиков, простор для создания проприетарных расширений формата) и многое, многое другое. В Microsoft и Ecma на критику реагировали и отвечали, критики отвечали на ответы… Обмен любезностями продолжался. Активные действия тоже.

Европейская организация FFII (Foundation for a Free Information Infrastructure, Фонд свободной информационной инфраструктуры) открыла сайт NoOOXML.org, на котором приводились самые "громкие" аргументы против OOXML и собирались подписи под петицией соответствующего содержания. Некоторые "подписанты" впоследствии стали получать письма от организатора NoOOXML Бенджамина Хенриона (Benjamin Henrion), призывающие организовать массовые обращения в местные стандартизирующие организации (представляющие страну в ISO) с требованием голосовать "против, с комментариями" (No with comments). Список "комментариев" прилагался.

В ходе первого голосования, завершившегося в сентябре 2007, в стандартизации OOXML было отказано: голосов "за" явно не хватило, а "против" было слишком много. Однако этот результат не означал "нет" - он означал "не сейчас". Согласно процедуре, Ecma давалось время для того, чтобы учесть комментарии и подготовить свои предложения по их разрешению. В конце февраля в Женеве на пять дней соберется конференция (Ballot Resolution Meeting, BRM), на которой будут приняты решения о внесении изменений в проект стандарта. После чего состоится повторное голосование о стандартизации OOXML. Оно-то и будет окончательным. А пока - битва продолжается.

Мы хотим единого открытого стандарта XML-формата офисных документов, свободного от возможности нестандартизованных вставок, любых видов патентных ограничений и со свободной реализацией. На основе этих принципов можно сотрудничать и с инженерами Microsoft.

Алексей Новодворский, заместитель генерального директора ALT Linux

Картина сражения выглядит очень по-разному - в зависимости от того, откуда смотреть. С точки зрения противников Microsoft, все очень просто: нехорошие люди из стана софтверного монополиста хотят пропихнуть сырой, невероятно сложный и (якобы) эффективно проприетарный формат как международный открытый стандарт и продолжать пользоваться своим доминирующим положением на рынке, пока конкуренты будут пытаться реализовать 6 тысяч страниц спецификаций (что, по мнению критиков, вообще невозможно сделать вне платформы Windows). Как только и если это случится, компания вряд ли станет строго соблюдать свои же спецификации, а скорее всего - разработает проприетарные расширения, которые будут снова нарушать интероперабельность с продуктами конкурентов. В это время все честные люди планеты встали единым фронтом, чтобы не допустить такого развития событий и отстоять честь уже принятого стандарта ODF.

С точки зрения Microsoft и ее сторонников, все совсем наоборот. Хорошие люди из организации Ecma International собрались (помимо Microsoft в заседаниях технического комитета участвовало множество компаний - Apple, Novell и даже The Gnome Foundation) и сделали прекрасный формат офисных документов, обеспечивающий замечательную обратную совместимость со старыми версиями MS Office (а также офисных пакетов других разработчиков), широкие возможности для корректной расширяемости (те самые пользовательские XML-теги) и поддерживающий другие функции, имеющиеся в Office 2007, которые разработчики ODF не горят желанием реализовать. Всем будет лучше, если этот формат, который лидер рынка безусловно будет поддерживать и в дальнейшем, станет стандартом ISO. Однако нехорошие люди из компании IBM в своих корыстных интересах развернули массивную кампанию и даже мобилизовали наиболее активных и неконструктивных участников FOSS-движения, чтобы не допустить стандартизации OOXML и тем самым продолжать наслаждаться эксклюзивным положением ODF как единственного "правильного" стандарта (который IBM поддерживает, например, в недавно выпущенном пакете Lotus Symphony) - и вытеснить Microsoft самым неконкурентным способом.

Есть и третья точка зрения на проблему, сформулированная в конце XVI века Вильямом Шекспиром: "Пади чума на оба ваши дома". Именно ее я слышал, разговаривая со специалистами из лагеря свободного софта, реально занимающимися офисным ПО: между двумя форматами есть технический паритет (где-то выигрывает один, где-то другой), а ожесточенное противостояние в деле стандартизации OOXML ("возня стандартов" - по выражению Анатолия Якушина, известного в России участника OpenOffice.org) - это не то, чем нужно заниматься индустрии. Несмотря на в целом негативное отношение к наличию двух стандартов ISO, нужно отвлечься от тонкостей процесса стандартизации и противостояния и задуматься над вопросом, поставленным в начале статьи: "А зачем?". Каковы реальные, видимые сегодня - а не теоретические - преимущества стандартизованных XML-форматов в случае офисных документов? Где те самые инновационные приложения и сервисы, которые будут использовать возможности что ODF, что OOXML? Их пока нет - и это одинаково касается и Microsoft, и ее конкурентов.

Появятся ли эти приложения? Несомненно. Для какого формата этот процесс пойдет активнее? Анатолий Якушин считает ODF более перспективной платформой по довольно банальным причинам: сравнительная простота спецификаций (722 страницы ODF 1.0 против 6 тысяч страниц текущего драфта OOXML), использование уже принятых стандартов там, где это возможно (например, SVG для представления векторной графики, MathML для представления формул), а самое главное - наличие свободных и открытых имплементаций формата - в частности, создаваемого в рамках проекта OpenOffice.org набора инструментов ODF Toolkit. Подобные инструменты для OOXML еще только предстоит написать (и эта работа ведется - не без поддержки Microsoft, - но может занять много времени).

Вполне вероятно, что именно эти соображения, а не мартовское голосование в ISO, и уж точно не акции NoOOXML, определят судьбу противоборствующих форматов и поддерживающих их компаний, а заодно - пути развития рынка офисных приложений на ближайшее и даже отдаленное будущее.

История, изложенная выше, не окончена, и в том, что уже произошло, многие моменты допускают неоднозначную трактовку, сильно зависящую от "кочки зрения". Особенно хорошо это можно проследить, анализируя блоги участников дискуссии о стандартах - по каждую из сторон баррикад есть свои любимые факты, любимые документы, любимые отчеты и любимая логика изложения. Однако есть некоторые факты, которые стали очевидными, и некоторые вопросы, которые остро встали в ходе этого противостояния.

Во-первых, индустрия выбирается из vendor lock-in, связанного с офисными форматами. Совсем недавно Microsoft объявила, что опубликует спецификации своих старых бинарных форматов (ранее их можно было получить, только вступив в переписку с компанией) - это уже бесполезное оружие в современном мире.

Переход к стандартизации означает, что "гонка за фичами" в форматах офисных документов завершена. Независимо от результатов голосования в ISO, OOXML уже является международным стандартом (Ecma), на который могут влиять (в той или иной степени) различные игроки - и чтобы внести в него изменения, сначала требуется достигнуть консенсуса и лишь потом выпускать поддерживающий эти изменения продукт.

Во-вторых, начинает осознаваться значение открытых стандартов в ИТ - особенно в государственном управлении. Вряд ли переход будет быстрым и скачкообразным (скажем, в широко обсуждаемом отчете Gartner, подготовленном по заказу Еврокомиссии и посвященном интероперабельности в общеевропейском e-Government, большое внимание уделяется вопросам обратной совместимости, на которую так любит упирать Microsoft), но он идет на наших глазах - и он необратим.

Из важности стандартов следует важность процедуры их разработки и утверждения. Достаточно ли они эффективны, честны и открыты для современного динамичного мира? Что нужно сделать, дабы исключить "возню", возникшую вокруг ODF и OOXML, или по крайней мере упростить разрешение подобных конфликтов? К чему приведет использование XML-форматов офисных документов, когда страсти улягутся? Станут ли они платформой для новой революции или по крайней мере появлению принципиально новых, более удобных средств работы, снимут ли они с нас еще какую-то часть рутинных занятий, оставив время для более интересных дел? Хочется верить, что да. Надо только перестать кричать и драться - и чуточку поработать…