CC BY
75
Открытые стандарты и новые формы международного сотрудничества1
Н.В. Пакулин, А.К. Петренко, О.Л. Петренко, А.А. Сортов, А.В. Хорошилое.
Аннотация. Открытые коды (ОК), или Open Source постоянно находятся в сфере внимания специалистов ИТ-индустрии. Зримыми показателями успеха ОК является глобальное наступление ОС Linux или популярность таких международных проектов, как Википедия. В статье выделяется общий принцип модели ОК - формирование открытого сообщества. Проекты по развитию и продвижению открытых стандартов также удовлетворяют этому принципу и представляют собой новую форму международного сотрудничества, что иллюстрируется примерами проектов, в которых принимает участие ИСП РАН.
1. Введение
Модель Открытого кода (Open source) - это не только соглашения о формах использования программ или других результатов творческой деятельности людей и целых организаций. Правила использования ОК - это лишь формальная сторона, задающая рамки функционирования модели. Другой, возможно, более важной стороной модели, является свободный, индивидуальный выбор участия в создании и использовании ОК. В мире ОК никому не придет в голову заставить кого бы то ни было что-то создать или что-то использовать вопреки желаниям субъекта. ОК предоставляет человеку или организации возможности участия в процессе, а субъект, соответственно, сам делает выбор, что и как он будет делать, не нарушая оговоренных правил использования ОК.
Заметим, что такое партнерство сильно отличается от отношений, которые типичны для мира коммерции, где главными действующими лицами являются заказчик и исполнитель. В коммерческом мире один принимает решение, что нужно сделать (заказчик), а другой вынужден делать это (исполнитель). В то же время, в нашей реальности имеется распространенная модель совместной деятельности, где стороны не навязывают друг другу директив, а сотрудничают, соблюдая при этом свои интересы, и развиваются исходя опять же из собственных интересов. Речь идет о международных программах, в которые страны входят на добровольной основе и двигаются к общей цели, не теряя из виду и свои собственные интересы.
1 Работа частично поддержана грантами РФФИ 05-01-00999 и 06-07-89261.
Не удивительно, что проекты, работающие по модели ОК, часто одновременно являются международными, и наоборот, в между народных проектах по созданию и/или продвижению программных платформ и новых стандартов используется модель ОК. Эго объясняется тем, что модель ОК и международные программы, построенные на добровольном участии стран, по духу близки друг другу, в обоих случаях мы видим суверенных партнеров, которые пытаются достичь общих и своих собственных целей, не ущемляя интересы партнеров.
Понятно, что, наряду со сходством, между проектами ОК и международными проектами, имеются и важные различия. Одной из причин таких различий служит существенно более высокая динамика проектов ОК: страны живут в соседстве веками, а проекты ОК длятся от нескольких недель до нескольких лет, но не больше. Высокая динамика означает, что партнеры должны быстро договориться не только о том, что делать, каковы цели и этапы проекта, но и о том, кто и что может и хочет делать. То есть в жизненном цикле проекта появляется существенная составляющая, которая направлена не на результат проекта, а на построение и усовершенствование процесса. При этом, как правило, нет никакого априорно предписанного процесса, а, скорее, выбирается некоторый шаблон, который может адаптироваться для конкретных условий. Акцент в проектах ОК делается на механизмы самоорганизации, которые позволяют найти процесс, приемлемый всем партнерам. Модель ОК не следует трактовать слишком узко и ограничивать ее пригодность только сферой разработки программных систем. По этой модели организуются проекты из различных областей творческой деятельности -составление словарей и энциклопедий (например, сетевая энциклопедия Wikipedia [1], математическая энциклопедия проекта PlanetMath[2]), разработка учебных курсов (например, проекты PlanetMath и PlanetPhysics[3]), живопись и графика (например, открытый проект ОрепСИр[4]), музыкальное творчество (см. список открытых музыкальных проектов на сайте Remix Commons [5]) и т.д. Трактовка Политики открытого кода в Википедии не ограничивается только созданием программного обеспечения:
Политика открытого кода (open source politics) — принцип «распределенной» разработки, использующийся в технологии, искусстве, политике общественных организаций и сетей и, прежде всего, — в создании свободного программного обеспечения.
2. Открытый код и открытые сообщества
Особенность проектов по созданию открытого кода заключается в том, что эти проекты выполняются открытым сообществом. Что такое открытое сообщество?
Корпорация Microsoft распространяет исходные тексты стандартной библиотеки языка Си вместе со средой разработки MS Visual Studio, и каждый
пользователь Visual Studio может легко с ними ознакомиться. Делает ли это стандартную библиотеку языка Си корпорации Microsoft открытым кодом? Нет, потому что у пользователей нет возможности организовать сообщество для развития этой библиотеки.
Открытое сообщество строится вокруг информационного ресурса. Это может быть сервер с исходными кодами некоторой программной системы, виртуальная энциклопедия или база стандартов. Люди объединяются в сообщество с целью развивать информационный ресурс - разрабатывать программу, писать и редактировать статьи в энциклопедии или разрабатывать или уточнять спецификации некоторого стандарта. Мы будем называть сообщество открытым, если оно удовлетворяет следующим требованиям:
1. У всех членов сообщества есть доступ к информационному ресурсу, над которым ведётся работа.
2. Сообщество ведёт коммуникацию через доступные извне каналы общения - дискуссионные листы, форумы.
3. Известны правила, которые регулируют отношения людей в сообществе, причём для того, чтобы узнать эти правила, не требуется вступать в сообщество.
4. Для вступления и участия в работе сообщества не требуется выплачивать лицензионные отчисления.
5. Участие в сообществе не ограничивает социальных свобод (в частности, не требуется подписка о неразглашении коммерческой или иной тайны).
Участие в открытом сообществе налагает на человека определённые обязательства. Открытое сообщество представляет собой принципиально новую социальную формацию по сравнению с корпоративными или исследовательскими коллективами разработчиков. Прежде всего, это высокая личная ответственность каждого за качество и объём работы. Кроме того, проекты ведутся совместно несколькими независимыми разработчиками, и результат их работы является совместной интеллектуальной собственностью.
В условиях современного общества доступ к информационному ресурсу и интеллектуальной собственности определяется юридическим соглашением между пользователем ресурса и его поставщиком или его создателями. В мире ОК роль такого соглашения выполняет лицензия, определяющая правообладателя ресурса или его отдельных частей и регламентирующая условия использования ресурса. Условия лицензии играют ключевую роль в формировании открытого сообщества. Лицензии, запрещающие изменения или требующие сокрытия знаний об устройстве программы, разрушают всякую возможность создать открытое сообщество. И напротив, если лицензия позволяет изменять и дополнять исходные тексты программы, открыто
обсуждать архитектуру и детали реализации, то она создаёт достаточные предпосылки, чтобы вокруг программы возникло открытое сообщество.
При первом знакомстве с понятием открытых кодов у многих возникает впечатление, что с такими работами можно делать всё, что заблагорассудится
- использовать, продавать, изменять. Такая возможность есть в том случае, когда результаты работы передаются в общественное достояние (public domain), однако немногие из тех, кто задействован в работе с ОК, согласны передавать свои работы в общественное достояние с добровольным отказом от своего авторства. Но обозначение авторства на результатах работы, в частности, на исходных текстах программ, влечёт множество дополнительных вопросов, связанных с ответственностью за применение работы автора, имущественными отношениями и просто сохранением формального обозначения авторства в производных работах.
В движении открытых кодов нет окончательного понимания того, какие ограничения, налагаемые лицензией, позволяют создать открытое сообщество вокруг защищаемых ею информационных ресурсов. Причина, возможно, заключается в том, что к движению открытых кодов постоянно присоединяются новые игроки - крупные компании и корпорации - со своими юридическими отделами, которые «изобретают» свои лицензии для защиты открываемых исходников. Апологеты ОК сформулировали ряд требований к лицензии, с которыми согласно большинство участников движения открытых кодов (но не все!). Эти требования опубликованы на сайте Open Source Initiative [6], здесь мы приведём их в сокращённом виде: лицензия должна обеспечить свободное распространение, доступ и модификацию открытых кодов, и не должна содержать положений, ущемляющих права отдельных категорий пользователей.
Наибольшей популярностью в настоящее время пользуются четыре лицензии: Gnu Public License (GPL) [7], Lesser Gnu Public License [8], Apache License (AL) [9] и BSD License [10]. На сайтах Free Software Foundation [11] и Open Source Initiative [12] приведены перечни лицензий, которые составители сочли удовлетворяющими требованиям открытых кодов. Эти лицензии используются не только для компьютерных программ, но и для документации, книг и даже произведений искусства.
Помимо лицензии, на формирование сообщества оказывают влияние правила, регулирующие отношения между участниками. В частности, правила могут описывать процедуру добавления новых членов в сообщество, организационную структуру и механизмы принятия решений. Эти правила могут быть закреплены формально, например, в уставе некоторого консорциума или могут входить в состав неформальной культуры сообщества. Последний вариант наиболее широко распространён.
Следование принципам открытых проектов, в особенности, принципу «открытых правил» требует совершенного нового стиля организации рабочего процесса в открытых проектах. Смена привычных стилей управления
происходит постепенно, и во многих открытых проектах можно наблюдать те или иные рудименты закрытых методов управления. Например, в проекте по созданию ядра ОС Linux право записи в дерево исходных текстов предоставляется только тем, у кого «есть приемлемый вклад в ядро Linux и достаточное основание в получении непосредственного доступа» [13]. Объём «приемлемого вклада» и «достаточность основания» определяются здравым смыслом администраторов проекта kemel.org, причём они разрешают себе отказывать в выдаче такого разрешения или отмене уже выданного разрешения без объяснения причин.
Центр стандартизации Интернета (Internet Engineering Task Force, IETF) [14] вот уже на протяжении 25 лет является главным органом разработки стандартов технологий, поддерживающих сеть Интернет. В частности, именно в IETF приняты стандарты на стек протоколов TCP/IP, протоколы FTP, HTTP, SIP, TELNET, системы обеспечения безопасности в сети Интернет. Центр стандартизации Интернета является примером организации, в которой уже сложилась полностью открытая структура управления - разработаны и зафиксированы правила рабочего процесса, управления рабочим процессом, публикации и отзыва стандартов. Необходимо отметить, что эта структура складывалась на протяжении более чем 20 лет, причём работы по дальнейшему развитию и совершенствованию механизмов управления открытыми проектами в IETF не прекращаются.
Открытые сообщества складываются из добровольцев, которые зачастую не имеют материальной заинтересованности в результатах проекта. В силу этой особенности открытых сообществ приказные механизмы управления, как правило, не эффективны - несогласные просто уйдут и приложат свои силы в других проектах. Поэтому в открытых сообществах обязательно возникают элементы самоорганизации, которые позволяют вырабатывать организационные формы, приемлемые для всех участников. В частности, распространены коллегиальные механизмы принятия решений, выборный характер руководства проекта.
В соответствии с историей возникновения открытые сообщества можно разделить на две группы - те, что «возникли сами», и те, что «были созданы». К первой группе мы причисляем сообщества, возникшие вокруг небольшой инициативной группы или даже одного человека для создания или развития информационного ресурса. Примером может служить сообщество разработчиков ядра ОС Linux, которое выросло из инициативной группы, поддержавшей в начале 1990-х Линуса Торвальдса в его работе над новой операционной системой для персональных компьютеров. В таких проектах выделяется группа наиболее активных и уважаемых разработчиков, которые зарекомендовали себя в ходе проекта. Они наделяются полномочиями управлять проектом - принимать или отклонять изменения, вносимые в информационный ресурс, планировать разработку и т.д. Важной чертой этих проектов является то, что такая руководящая группа образуется как бы «сама
по себе», зачастую с использованием демократических механизмов, таких как выдвижение кандидатов и голосование сообщества.
Ко второй группе мы относим сообщества, которые развиваются по принципам открытых сообществ, но изначально были созданы общественными или коммерческими организациями. Начиная с 1998 года, когда компания Ыс^сарс открыла исходные тексты своего браузера, всё больше компаний и корпораций передают свои ранее закрытые разработки в мир открытых кодов. При этом компании, как правило, учреждают некоммерческие общественные комитеты для управления открытым проектом. Эти организации выполняют те же самые функции, что и управляющие группы в проектах из первой группы, состав комитета также может формироваться на демократических принципах, но начальный состав комитета определяется компанией-основателем проекта.
3. Основные принципы проектов по разработке и продвижению открытых стандартов
Разработка программного обеспечения - это самая распространенная область применения модели ОК, но и здесь есть неожиданные «открытия». Одним из них служит разработка и продвижение открытых стандартов интерфейсов программных и аппаратных систем. Заметим, что текст стандарта (часто говорят «спецификация») больше похож на книгу, чем на программу. Совместная работа над книгой - это совсем другой процесс по сравнению с процессом создания программной системы. Еще меньше сходства между процессами создания ПО и процессами продвижения стандарта. Продвижение стандарта больше похоже на программы пропаганды и агитации в политике или на программы развития культурных связей или распространения знаний.
Разработка и продвижение стандартов обладают рядом особенностей, обусловленных природой стандартов.
1. Стандартизацией занимаются не столько отдельные люди, сколько целые организации, поскольку реализация стандарта - это задача, требующая больших ресурсов и, как правило, непосильная для одного человека.
2. В стандартизации часто бывают заинтересованы индустриальные компании. В таком случае в состав группы, разрабатывающей стандарт, делегируются представители компаний. Они получают зарплату за участие в работе над стандартом и отстаивают в стандарте интересы компании-работодателя.
3. Стандарты могут затрагивать национальные интересы отдельных государств, поэтому многие международные органы стандартизации, в том числе и те, что ведут открытые проекты стандартизации, поддерживают сеть базовых организаций или региональных представительств в различных странах. Посредством базовых организаций решаются
вопросы коммуникации с правительствами и адаптации стандарта и методов его продвижения к особенностям соответствующих стран. В этом проекты по стандартизации отличаются от большинства проектов ОК, которые являются в чистом виде интернациональными проектами без привязок к национальным структурам.
Разработка стандартов также имеет ряд отличий от типичных проектов ОК, направленных на создание программ. Программы разрабатываются инкрементально, небольшими кусками с частыми обновлениями исходных текстов. Проектная документация создаётся редко, даже пользовательская документация на программы, разработанные в проектах ОК, редко существует в полном объёме. Не всегда серьёзное внимание уделяется тестам, которые проверяют функциональную корректность программ.
Стандарты разрабатываются иначе. К ним предъявляются жёсткие требования (полнота, непротиворечивость, понятность, однозначность), поэтому изменения в стандарты вносятся, как правило, сразу большими частями, чтобы обеспечить высокое качество стандарта. Стандарты могут содержать отдельные части или главы, поясняющие их назначение и основные идеи, что аналогично проектной документации для программного обеспечения. Тестирование стандарта заключается в разработке реализаций-прототипов, что само по себе может быть гораздо сложнее, чем тестирование программ в проектах ОК.
Немаловажной частью продвижения стандарта является задача создания тестовых наборов для проверки соответствия стандарту. Эта задача лежит на стыке областей стандартизации и разработки программных средств. От обычных проектов по созданию ПО разработка тестовых наборов отличается, прежде всего, более глубокой проработкой требований, тщательной реализацией тестового набора, использованием специализированных средств разработки.
Тем не менее, несмотря на указанные особенности, мы считаем, что разработку и продвижение открытых стандартов тоже можно рассматривать в русле глобального движения Открытых кодов. Тому есть несколько оснований:
1. Открытость проекта для включения новых участников. Создание и продвижение открытых стандартов осуществляется некоммерческими консорциумами или публичными форумами, которые не взимают плату за участие в работе сообщества. Участие в консорциуме или форуме происходит на добровольной основе.
2. Открытость результатов для ознакомления. Разработанные стандарты, тестовые наборы, демонстрационные и агитационные материалы выкладываются в открытый доступ в сети Интернет, за скачивание и использование результатов проектов не взимается плата.
3. Открытость результатов для использования. Разработанные открытые стандарты можно реализовать без выплаты лицензионных платежей.
Можно самостоятельно проводить акции и кампании по продвижению стандарта, для этого не требуется получать специальные разрешения и платить лицензионные отчисления.
Открытые сообщества стандартизации демонстрируют одно существенное отличие от закрытых органов стандартизации - они могут начинать процессы стандартизации для предложений, внесённых людьми или организациями, не входящими в сообщество. Это позволяет, в частности, оперативно стандартизировать технологии, разработанные в открытых программных проектах.
Продвижение стандартов требует вовлечения в процесс разных групп людей -чиновников, разработчиков программ и конечных пользователей этих программ. Для наибольшего эффекта необходимо сочетать различные активные методы обучения и вовлечения в процесс использования стандарта:
• Проведение семинаров по популяризации стандартов, в том числе таких, на которых пользователи смогут попробовать прототипы систем с новыми технологиями.
• Распространение бесплатных материалов, а также выступления на конференциях, учебные курсы в университетах и т.п.
• Active tutorials - последовательное освоение новой технологии на практических примерах под руководством преподавателей и тренеров.
В начале 2000 года Европейский институт стандартизации телекоммуникаций предложил новую форму продвижения и развития стандартов, которая получила название Plugtests [15]. Это сравнительно новое изобретение в области развития и продвижения стандартов, поэтому мы рассмотрим более подробно.
Изначально идея Plugtests заключалась в том, чтобы проверить новые технологии (как правило, в телекоммуникационной сфере - Bluetooth, WiFi, IPv6 и т.д.) на практике. Представители различных компаний-производителей собирались в одном месте и привозили прототипы или уже запущенные в серию устройства. Далее на протяжении нескольких дней они проигрывали различные сценарии использования новой технологии, используя при этом устройства разных компаний. Фактически, они проверяли совместимость устройств между собой. По этой причине Plugtests позиционируются как «Interoperability Events».
В последнее время для многих сравнительно новых технологий появились более-менее полные тестовые наборы, что привело к появлению на Plugtests новых действующих лиц - производителей тестовых наборов и новых сценариев работы - прогона тестового набора на образцах продукции представителей промышленных компаний. У этого сценария есть два аспекта: производители проверяют соответствие своей продукции стандартам, а разработчики тестовых наборов проверяют корректность своего тестового набора.
Помимо непосредственных участников Plugtests - как промышленников, так и тестировщиков, в этих мероприятиях заинтересована ещё одна категория лиц
- авторы стандарта или спецификации новой технологии. На Plugtests приезжают, как правило, инженеры-разработчики, которые досконально разбираются в соответствующих стандартах и имеют опыт их практической реализации, поэтому они могут дать очень ценные отзывы о качестве стандарта, ошибках или неточностях, обнаруженных в ходе работы.
Plugtests позволяют за сравнительно небольшую плату (или вовсе бесплатно) провести «живое» тестирование реализаций новых технологий в различных ситуациях, проверить совместимость продукции конкурентов до начала официальных продаж, «обкатать» новые тестовые наборы и провести тестирование соответствия новых реализаций. Помимо этого, Plugtests дают возможность экспертам-практикам и разработчикам стандартов встречаться и обмениваться идеями, прояснять непонятные места в стандарте.
4. Международное сотрудничество в области открытых стандартов
4.1. The Austin Group
Проблемы обеспечения корректного взаимодействия программных систем от различных производителей актуальны не только в области телекоммуникаций. Аналогичные проблемы возникают также на уровне взаимодействия прикладных программ с операционной системой. Операционные системы одного семейства предоставляют приложениям почти одинаковые сервисы, но это «почти» стоит множества бессонных ночей независимым разработчикам приложений.
Так, в 80-х годах XX века данная проблема крайне остро встала среди сообщества пользователей семейства операционных систем UNIX. Разнообразные вариации UNIX-систем обладали одинаковой архитектурой, базировались на общих принципах и имели практически одинаковые программные интерфейсы, но отличались в многочисленных деталях. В результате разработка переносимых приложений являлась настоящим испытанием и требовала от разработчиков приложений огромных финансовых вложений. Стандартизация интерфейса между прикладными программами и операционной системой появилось как естественное решение данной проблемы. Предпринималось множество попыток стандартизации программного интерфейса операционных систем семейства UNIX, но наибольшее признание получил стандарт POSIX (Portable Operating System Interface for Computing Environment). Работа над этим стандартом началась в 1984 году в рамках образованного под эгидой IEEE CS комитета по стандартам для переносимых приложений (Portable Application Standards Committee, PASC).
Первая версия стандарта POSIX, имевшая официальное название IEEE Std 1003.1, вышла в 1988 году. Она содержала требования к функциям прикладного интерфейса операционной системы на языке программирования С. В течение последующих нескольких лет стандарт немного доработали, устранили выявленные неточности и в 1990 году выпустили вторую редакцию IEEE Std 1003.1-1990, которая была принята в качестве международного стандарта ISO/IEC 9945-1:1990.
Затем основная работа PASC проводилась в подкомитетах и заключалась в разработке дополнений к базовому стандарту. Этот этап развития стандарта POSIX завершился выпуском очередной редакции IEEE Std 1003.1-1996, в которую вошли дополнения IEEE Std 1003.lb-1993 (Realtime Extension), IEEE Std 1003.1C-1995 (Threads) и IEEE Std 1003.H-1995 (Technical Corrigenda to Realtime Extension). Эта редакция также была утверждена в качестве международного стандарта ISO/IEC 9945 1:1996.
Среди других организаций на поле стандартизации UNIX-подобных систем следует выделить The Open Group, образованную в 1993 году посредством слияния Х/Open и Open Software Foundation (OSF). В том же году The Open Group получила от Novell права на торговую марку UNIX и начала работу над единой спецификацией UNIX (Single UNIX Specification, SUS). Эта спецификация включала в себя стандарт POSIX и дополняла его достаточно большим набором функций, являющихся устоявшейся практикой среди UNIX-подобных систем.
Ключевое событие в истории стандартизации UNIX-подобных систем произошло в сентябре 1998 году, когда была образована The Austin Group -рабочая группа по развитию совместного стандарта IEEE Std 1003, ISO/IEC 9945 и Single UNIX Specification. Результатом работы этой группы стал выпуск новой, единой версии всех этих стандартов IEEE Std 1003.1-2001, ISO/IEC 9945:2001 и базовой части Single UNIX Specification version 3.
Наиболее важным новшеством в принципах работы The Austin Group стал переход к открытым методам развития стандарта POSIX. Представитель любой коммерческой компании или учебного заведения и любое частное лицо может стать членом The Austin Group и принимать активное участие в процессе стандартизации. Единственное, что для этого требуется сделать - это подписаться на электронный список рассылки The Austin Group [16].
В этом списке рассылки и происходит основная работа группы. Среди обсуждаемых в нем вопросов следует выделить следующие темы:
• интерпретация требований стандарта и ответы читателям относительно непонятных мест стандарта;
• обсуждение предложений по уточнению текста стандарта;
• обсуждение предложений по развитию стандарта (стандартизации новой функциональности, удалению устаревшей и т.д.)
В ходе обсуждений участники группы пытаются прийти к соглашению по каждому вопросу и сформировать окончательное решение. Эго решение обычно утверждается в ходе телеконференций группы, проходящих на регулярной основе раз в одну-две недели. Протоколы телеконференций публикуются в списке рассылки, что делает их доступными всем участникам.
Важную роль в деятельности The Austin Group играет председатель группы (в настоящее время - Andrew Josey из The Open Group). Он отвечает за организацию жизнедеятельности группы, проведение телеконференций, подготовку протоколов и других документов группы. В сфере его ответственности также лежит организация взаимодействия группы с формальными органами ISO и IEEE, необходимого для принятия обновленных версий стандарта как официальных международных стандартов.
Текст стандарта Single UNIX Specification является общедоступным на сайте The Open Group [17]. Тексты стандартов IEEE Std 1003 (POSIX) и ISO/IEC 9945 распространяются согласно традиционным принципам распространения стандартов этих организаций. Но так как IEEE Std 1003 (POSIX), ISO/IEC 9945 и Single UNIX Specification являются единым стандартом, то недоступность текстов с логотипами IEEE и ISO/IEC не сильно ограничивает возможности пользователей.
Открытость The Austin Group для всех заинтересованных сторон влечет за собой множество преимуществ. Свободная доступность текста стандарта ведет к большему признанию и распространению стандарта в среде разработчиков приложений для UNIX-подобных систем. Большее количество читателей стандарта приводит к более быстрому обнаружению скрытых проблем в стандарте, неочевидных непосредственно рабочей группе. Возможность свободного участия разработчиков операционных систем и разработчиков приложений в обсуждениях рабочей группы по интерпретации требований стандарта и по путям его дальнейшего развития позволяет более полно учитывать мнения различных сторон и скорее находить общепризнанные решения.
4.2. Free Standards Group
Стандартизация прикладного программного интерфейса UNIX-подобных операционных систем стала большим шагом вперед на пути достижения переносимости приложений. Стандарт POSIX описывал сервисы, предоставляемые операционной системой, на уровне прикладных программных интерфейсов языка программирования Си. Такой подход никак не ограничивал свободу поставщиков операционных систем по выбору архитектуры системы и способам ее реализации. Поэтому практически все операционные системы, в том числе и не являющиеся наследниками UNIX, в той или иной степени стали поддерживать стандарт POSIX.
Одна из наиболее распространенных UNIX-подобных операционных систем -операционная система Linux с самого начала являлась POSIX-совместимой за
исключением небольшого числа отдельных несоответствий. Тем не менее, Linux не сумела избежать проблем с переносимостью приложений и фрагментацией рынка. Недостатки POSIX применительно к рассматриваемой ситуации заключаются в следующем.
Во-первых, интерфейсов, специфицированных в POSIX, оказывается недостаточно для полноценной разработки всех видов приложений. Если системные приложения и приложения, взаимодействующие с пользователем посредством терминала, могут быть реализованы в рамках интерфейсов POSIX, то приложения с графическим пользовательским интерфейсом и приложения, использующие системную информацию, оказываются вне стандарта POSIX.
Во-вторых, описание требований на уровне исходного кода требует перекомпиляции приложений для переноса приложения на другую систему. Это не является большим препятствием при распространении приложений с открытыми исходными кодами, но существенно осложняет распространение приложений в двоичном виде. В последнем случае разработчику для сборки своего приложения требуется иметь доступ ко всем поддерживаемым дистрибутивам. Нелегко приходится и конечному пользователю. Так как среди поставщиков операционной системы Linux нет устоявшейся традиции поддерживать обратную двоичную совместимость компонентов, то любое обновление системы может привести к потере работоспособности отдельных приложений. И даже в тех случаях, когда приложение поставляется с исходными кодами, и пользователю для восстановления его работоспособности требуется только выполнить перекомпиляцию приложения, такая ситуация не приносит пользователю ничего, кроме дополнительной головной боли.
По этим причинам сообщество Linux инициировало работу по стандартизации базовых интерфейсов операционной системы на бинарном уровне. Для этого в 1998 году была образована некоммерческая организация Free Standards Group, под эгидой которой началась разработка стандарта Linux Standard Base (LSB). Деятельность по созданию стандарта поддержали Линус Торвальдс, Брюс Перенс, Эрик Раймонд, несколько поставщиков дистрибутивов Linux, разработчики приложений, члены Linux International, а также Джон Хаббард из проекта FreeBSD [18].
Работа Free Standards Group по разработке стандарта LSB следует духу открытости, принятому в среде программного обеспечения с открытым кодом, каким является ОС Linux. В этом вопросе LSB Workgroup (рабочая группа по разработке стандарта LSB) не ограничивается открытостью процесса работы рабочей группы и текста стандарта. В отличие от The Austin Group, в LSB Workgroup открыты все внутренние средства и инструменты по разработке стандарта, а также тестовые наборы для проверки на соответствие.
Стандарт LSB генерируется на основе информации о составе интерфейсов, хранящейся в базе данных, и описаний этих интерфейсов из отдельных
SGML-файлов. На основе этой же базы данных генерируются дополнительные инструменты, упрощающие разработку приложений на основе стандарта. И база данных, и скрипты, участвующие в генерации, доступны всем на сайте Free Standards Group.
Рабочий процесс LSB Workgroup имеет очень много общего с процессом The Austin Group. Обсуждения основных вопросов ведутся в списке рассылки рабочей группы [19], еженедельно проводятся телеконференции, на которых обсуждаются ключевые вопросы. Два раза в год проводятся двух-трехдневные личные встречи участников рабочей группы, посвященные вопросам развития стандарта.
Отдельно можно выделить процесс обработки замечаний к стандарту, который выглядит следующим образом. По специальному шаблону оформляется и заносится в базу сообщение, описывающее суть замечания к стандарту. Ответственный за обработку замечаний (в настоящее время момент это Mats Wichmann - сотрудник Intel, экс-глава LSB Workgroup) принимает сообщение на обработку или же задает уточняющие вопросы, если информации в сообщении недостаточно. Помимо вопросов к инициатору сообщения, могут задаваться вопросы другим заинтересованным лицам, получившееся в результате обсуждение также записывается.
Информация о зарегистрированных замечаниях появляется в рассылке рабочей группы, кроме того, периодически рассылается дайджест с информацией о последних замечаниях, дискуссиях и принятых по замечаниям действиях. Подписка на рассылки свободная, так что любой желающий может принять участие в обсуждении. После обсуждения замечания принимается решение о внесении изменений в текст стандарта и публикуется «заплатка» к базе данных, содержащая необходимые изменения, которые тоже выносятся на обсуждение.
Завершающие действия по обработке замечания - внесение изменений в базу данных и фиксация этих изменений в системе конфигурационного управления
- происходят после окончательного одобрения изменений (иногда молчаливого).
Являясь некоммерческой организацией, Free Standards Group получает поддержку от многих крупных организаций, заинтересованных в успешном развитии операционной системы Linux. В число активных членов Free Standards Group входят все ключевые производители дистрибутивов ОС Linux (Red Hat, Novell/SuSe, Mandriva, Debian, Red Flag), компании разработчики приложений (MySQL, RealPlayer), а также такие компании, как IBM, Intel, HP, Oracle, AMD и т.д.
Free Standards Group уделяет достаточно много внимания вопросам международного сотрудничества. Во всех частях света она старается организовать неформальные центры поддержки и распространения стандарта LSB. В Китае в качестве такого центра выступает China Electronics Standardization Institute (CESI), в Южной Корее - Electronics and Telecommunications Research Institute
19
(ETRI), в Сингапуре - Center for International Cooperation for Computerization (CICC), в Японии - Japan Linux Association (JLA), в России - Институт Системного Программирования РАН (ИСП РАН).
4.3. Стандартизация Linux: сотрудничество с The Austin Group и Free Standards Group
Сотрудничество ИСП РАН на поле стандартизации ОС Linux началось в середине 2005 года. На первом этапе проводилась формализация требований стандарта LSB к поведению компонентов ОС Linux, а также разрабатывался систематический тестовый набор OLVER [20], проверяющий различные реализации на соответствие требованиям этого стандарта LSB. Процесс формализации требований и разработки тестового набора базировался на технологии UniTESK [21, 22].
В ходе формализации обнаруживались «дефекты» стандарта - неясные и неточные ограничения, двусмысленности, противоречия между разными частями стандарта, неполное описание функциональности и т.д. Неясные и двусмысленные формулировки стандарта обсуждались и прояснялись с разработчиками стандарта; по противоречивым и ошибочным формулировкам составлялись сообщения с предложениями по улучшению текста стандарта.
Для обсуждения замечаний Free Standards Group предоставляет доступ к базе данных (для проекта выбрана Bugzilla [23] - система управления ошибками, распространяемая свободно с открытым кодом), в которой фиксируются все действия по обработке замечаний к стандарту [24]. Дискуссия, которая возникает при обсуждении замечаний, приятые решения и отчет о внесенных изменениях в текст стандарта - все это фиксируется в базе данных.
В настоящее время на сайте проекта опубликовано 44 замечания к стандарту LSB [25], по которым подготовлены и отправлены сообщения. Эти замечания приняты к обработке, 23 из них уже обработаны, и соответствующие изменения будут внесены в следующие версии стандартов или отражены в документах, описывающих известные дефекты стандарта.
12 опубликованных замечаний описывают обнаруженные в стандарте опечатки - такие замечания обрабатывались и исправлялись в течение нескольких дней. 13 замечаний относятся к противоречиям в стандарте (например, константам, определяющим скорость работы терминала, в разных частях стандарта соответствовали разные значения2). 19 замечаний выявляют неточности или же ошибки в стандарте (например, при описании функции inflate() использовалась константа Z BLOCK, которая нигде в стандарте не определялась3, или же неправильное определение констант, описывающих тип мьютекса в тексте стандарта и в заголовочных файлах4). При обработке таких
2 Зарегистрировано под номером 26 в [25], под номером 1294 в [24]
3 Зарегистрировано под номером 267 в [25], под номером 1518 в [24]
4 Зарегистрировано под номером 398 в [25],, под номером 1432 в [24]
20
замечаний часто начинались дискуссии с участием других членов рабочей группы, решения по некоторым замечаниям до сих пор не приняты.
При обработке замечаний в The Austin Group база данных для фиксации обсуяедений и действий не используется, обсуждение происходит в рассылке рабочей группы, а принятые решения фиксируются в официальном документе, содержащим замечания к стандарту. Этот документ находится в свободном доступе и периодически обновляется [26]. На сайте проекта опубликовано 15 замечаний к стандарту POSIX [27], об этих замечаниях сообщено в The Austin Group.
Все замечания приняты, но окончательное решение по замечаниям пока не принято.
Хотя исправление противоречий, неточностей и т.д. позволяют улучшить стандарт, для развития и продвижения стандарта не менее важно наличие качественного тестового набора. Только систематическая проверка соответствия ОС требованиям стандарта позволит разработчикам приложений не тратить усилия на проведение тестирования на разных платформах, если эти платформы прошли проверку на соответствие стандарту.
Для обеспечения систематичности тестирования на соответствие стандарту LSB при разработке тестового набора была реализована автоматическая оценка покрытия требований, проверенных в ходе тестирования.
В тестовый набор входят параметризованные спецификации и тестовые сценарии, что позволяет настраивать тестовую систему на конкретную реализацию - определять проверяемые ограничения в зависимости от конфигурационных опций (наличие некоторой функциональности, дополнительные коды ошибок и т.д.). Все это относится к требованиям, которые стандарт не фиксирует жестко, позволяя разработчикам вносить свои особенности в реализации и оставаться при этом в рамках стандарта. Разработанный тестовый набор также находится в открытом доступе на сайте проекта [20]. В ходе отладки тестового набора на разных реализациях обнаруживались отклонения реализаций от требований стандарта, а также дефекты стандарта, не замеченные на этапе анализа и разработки спецификаций. Сообщения о найденных несоответствиях поведения реализации требованиям стандарта отсылались разработчикам библиотек и дистрибутивов. Процесс обработки ошибок в реализациях в целом аналогичен процессу, применяемому при обработке замечаний к стандарту LSB. Так, например, для обработки ошибок в проекте glibc [28] также используется Bugzilla [29].
В качестве примера ошибок, обнаруженных в ходе разработки тестового набора, можно привести ошибку в текущей версии glibc (glibc-2.4): реализация функции insque() не соответствовала стандарту POSIX. Требуемая инициализация элемента очереди при обращении со значением второго параметра
NULL не была реализована, что приводило к аварийному завершению работы процесса, попытавшегося использовать функцию именно для этого5.
Не всегда несоответствие, обнаруженное при тестировании, является ошибкой в реализации. Например, расхождение между требованиями стандарта LSB и поведением функции basename(), обнаруженное при тестировании, являлось следствием ошибки в стандарте LSB6.
Все результаты проекта (каталог требований, разработанный в ходе анализа стандарта, спецификации и тестовые сценарии) открыто распространяются на сайте проекта по лицензии Apache 2.0. Интерес к результатам проекта был проявлен со стороны индийских и китайских разработчиков.
Для обеспечения прослеживаемости требований в спецификациях используются цитаты из стандартов. Лицензия LSB позволяет цитировать текст стандарта без дополнительных ограничений, а для цитирования стандарта POSIX необходимо было получить разрешение от The Open Group, владеющего правами на текст стандарта. The Open Group дала положительную оценку деятельности ИСП РАН и предоставила все необходимые права на использование текста стандарта в каталоге требований и других компонентах тестового набора, создаваемых в ходе проекта.
Взаимодействие ИСП РАН с Free Standards Group происходило более тесно. Открытость стандарта LSB позволила специалистам ИСП РАН изучить в ходе работ по проекту инфраструктуру стандарта и внести предложения по ее улучшению. В результате Free Standards Group решила привлечь ИСП РАН к работам по развитию инфраструктуры стандарта LSB и улучшению сертификационного тестового набора.
На новом этапе сотрудничества ИСП РАН с Free Standards Group, намеченном на 2007 год, предполагается привлечение специалистов ИСП РАН к работам по следующим направлениям развития стандарта LSB:
• разрешение проблем с сертификационным тестовым набором (улучшение покрытия и удобства использования);
• развитие инфраструктуры и установления связей между ее компонентами (текстом стандарта, тестовыми наборами, дистрибутивами и их компонентами).
Таким образом, сотрудничество с The Austin Group и Free Standards Group будет развиваться по трем направлениям - во-первых, это улучшение текста стандартов, уточнение формулировок и устранение противоречий, во-вторых, создание тестового набора, предназначенного для проверки дистрибутивов на соответствие стандарту LSB, и, наконец, развитие инфраструктуры стандарта LSB.
5 Зарегистрировано под номером 2766 в [29]
6 Зарегистрировано под номером 207 в [25], под номером 1430 в [24] 22
Опыт сотрудничества ИСП РАН с The Austin Group и Free Standards Group продемонстрировал интересную особенность открытых проектов.
Когда ИСП РАН начинал проект по разработке тестового набора, предназначенного для тестирования соответствия стандарту LSB, сообщество, образовавшееся вокруг этого проекта, практически не пересекалось с сообществами проектов The Austin Group и Free Standards Group. Только несколько человек из проекта OLVER участвовали в рабочем процессе этих сообществ.
В то же время цели проекта OLVER - обеспечение высокой надежности и совместимости платформы Linux с помощью использования открытых стандартов и наукоемких технологий верификации и тестирования - во многом совпадали с целями Free Standards Group и частично пересекались с целями The Austin Group. Это привело к появлению взаимного интереса сообществ OLVER и Free Standards Group и началу активного взаимодействия. Обратная связь, полученная проектом OLVER от сообщества Free Standards Group, позволяет определить приоритетные направления развития тестового набора, а поддержка Free Standards Group помогает распространять результаты проекта OLVER в сообществе Linux.
В настоящее время мы наблюдаем взаимопроникновение сообществ OLVER и Free Standards Group, которое обусловлено, в первую очередь, общностью целей этих сообществ.
Такая ситуация типична для открытых проектов: открытость проектов позволяет сообществам легко проникать друг в друга, любой член одного сообщества может присоединиться к другому сообществу, если это отвечает его интересам. Если цели проектов оказываются близки, то таких людей становится достаточно много и постепенно это приводит к тому, что проекты начинают обогащать друг друга интересными идеями, наработками, решениями и т.д. При этом происходит взаимное дополнение проектов, приводящее к синергетическому эффекту.
5. Международный проект Go4IT
Современная сеть Интернет ведёт своё происхождение от исследовательской сети ARPANET, созданной в конце 1970-х с целью объединения в единую сеть разрозненных исследовательских центров Министерства обороны США. Для решения этой задачи были разработаны новые сетевые технологии, которые впоследствии получили название «Интернет-протокол». Когда в 1981 году принимали стандарт Интернет-протокола, никто не предполагал, что сети на его основе станут глобальными и объединят сотни миллионов узлов. Непредвиденный взрывообразный рост Интернета, начавшийся в 1990-х и продолжающийся по сей день, выявил ряд узких мест, заложенных в Интернет-протокол при его создании, которые ограничивают функциональность глобальной сети. Для их преодоления был разработан новый комплекс сетевых технологий для замены Интернет-протокола,
получивший название «Интернет-протокол нового поколения» или, кратко, IPv6. Для того чтобы различать новый и старый Интернет-протоколы, последнему присвоили аббревиатуру IPv4.
Наиболее существенным ограничением Интернет-протокола IPv4 является исчерпание адресного пространства. Максимальное число уникальных адресов в глобальной сети составляет около 4-х миллиардов, однако неоднородность распределения адресов по различным регионам привела к тому, что в отдельных странах общее число пользователей Интернета превысило число 1Р\4-адрссов. выделенных стране. В частности, такая ситуация сложилась в странах Евросоюза, России, Китае, наиболее развитых странах Латинской Америки.
Г лобальная сеть IPv6 может функционировать только при условии корректного функционирования всех составляющих её устройств. Поэтому задача валидации и верификации как стандартов IPv6, так и их реализаций является чрезвычайно актуальной. Если принять во внимание то, что сеть Интернет охватывает весь земной шар, становится очевидной необходимость международной кооперации в этой области. В противном случае может возникнуть угроза появления несовместимых национальных сетевых стандартов, и, как результат, нарушения связности сети.
В ноябре 2005 года начался международный проект Go4IT. Проект ставит перед собой цель внедрения современных методов валидации и верификации в процессы создания и разработки открытых стандартов Интернета и, в особенности, IPv6. Для достижения этой цели в проекте Go4IT решаются следующие задачи:
• Пропагандировать подход к обеспечению качества, основанный на тестировании соответствия стандартам, и соответствующие технологии, такие как TTCN3.
• Создать сообщества пользователей такого подхода в области открытых стандартов Интернета.
• Предоставить исполнимые тестовые наборы и инструменты тестирования в свободный доступ для верификации реализаций стандартов Интернета и, в первую очередь, IPv6.
• Предоставить свободную поддержку этих инструментов.
• Подготовить окружение для разработки недорогой и открытой тестовой платформы общего назначения.
Проект Go4IT выполняется в рамках программы Европейской Комиссии «Structuring the European Research Area - FP6 - Infrastructures». Длительность проекта составит 30 месяцев, с ноября 2005 года по апрель 2008-го.
Проект Go4IT объединяет 11 исследовательских и коммерческих организаций Европы, России, Китая и Бразилии для создания программных средств и предоставления услуг по тестированию реализаций IPv6. Со стороны Евросоюза в проекте участвуют:
• Европейский институт стандартизации телекоммуникаций (ETSI) -крупный между народный центр исследований и стандартизации;
• Национальный исследовательский институт информатики и автоматики (INRIA) - один из ведущих исследовательских центров Франции;
• Институт открытых взаимодействующих систем Г ерманской Академии Наук (FOCUS);
• Центр коммуникационных технологий (СЕТЕСОМ) - ведущая тестовая лаборатория Испании в области тестирования коммуникационных систем.
Китай представлен в проекте тремя организациями:
• Китайская академия телекоммуникационных исследований (CATR) Министерства информационной промышленности КНР -национальный исследовательский центр и тестовая лаборатория;
• Университет почты и связи (BUPT) - крупнейшее учебное заведение в сфере связи и телекоммуникационных сетей в КНР;
• Пекинский институт Интернета - исследовательский центр крупной промышленной группы BII Group, первый провайдер в КНР, предоставивший доступ к сетям IPv6.
От России в проекте принимает участие Институт системного программирования РАН. ИСП РАН ведёт активные исследования в области тестирования, валидации и верификации различных систем, включая телекоммуникационные и открытые стандарты Интернета, принимает активное участие в работе Российского форума IPv6.
Рассмотрим факторы, обусловившие такой выбор стран-участниц проекта.
Ведущие индустриальные державы Европы - Франция и Германия - давно исчерпали адресное пространство, выделенное им в Интернете IPv4. По заказам правительства Европейского союза (Еврокомиссии) в Европе были развёрнуты крупные исследовательские сети, в которых отрабатывались различные сценарии построения Интернета нового поколения. Неудивительно, что именно Европейские институты стали организаторами международного проекта по валидации и верификации открытых стандартов Интернета.
Как и объединённая Европа, Китай и Россия являются крупными индустриальными державами, которые вплотную столкнулись с проблемами нехватки адресов для сетей, основанных на протоколе IPv4. В КНР есть государственная программа перевода внутренних сетей на IPv6, что и обусловило включение в состав консорциума сразу трёх исследовательских центров Китая.
Консорциум Go4IT открыт для приёма новых участников. В отличие от многих индустриальных консорциумов и форумов, за вступление в Go4IT не взимается плата. В консорциуме предусмотрен механизм расширения через включение ассоциированных членов. Предусмотрены три степени
вовлечённости ассоциированных членов в работу консорциума Go4IT. Первая степень называется Форум Go4IT и предусматривает полный доступ ко всем информационным ресурсам проекта, включая внутреннюю документацию, бета-версии и исходные коды программных средств, разрабатываемых консорциумом Go4IT. Следующая ступень получила название Мастерская Go4IT и предназначена для тех новых участников консорциума, кто хочет принять участие в разработке тестовой платформы Go4IT или готовы передать в консорциум исходные тексты уже существующих программных средств. В настоящее время в Мастерскую Go4IT входят несколько китайских организаций, которые принимают участие в работах по созданию свободного компилятора TTCN3 (см. далее). Для наиболее активных ассоциированных членов консорциума предусмотрена ещё одна степень вовлечения в работу консорциума. Они могут получить приглашение принять участие в управлении консорциумом.
Рабочий процесс консорциума основывается на сайте www.go4-it.eu, на котором размещаются рабочие материалы, документация, форум, исходные файлы программных модулей, разрабатываемых членами консорциума. Материалы пока не выложены в открытый доступ, но это ограничение легко преодолеть, если стать ассоциированным членом консорциума. Достаточно просто участвовать в Форуме Go4IT, чтобы получить возможность скачивать материалы с сайта консорциума. Разрабатываемые программные средства публикуются под открытыми лицензиями (GNU Public License и Apache Public License), можно свободно пользоваться материалами сайта для распространения информации о проекте Go4IT.
Рабочий процесс в проекте Go4IT организован по следующей схеме. Задачи проекта разделены на две группы, Package 1 и Package 2. У каждой группы есть ведущая организация, которая координирует действия участников консорциума в рамках своей группы задач. Регулярно, один-два раза в месяц, проводятся телефонные конференции, на которых обсуждаются текущая ситуация и намечаются или уточняются ближайшие планы. Раз в полгода проводятся личные встречи представителей всех участников консорциума.
К Package 1 относятся задачи разработки и распространения инструмента тестирования реализаций протокола IPv6. В рамках Package 1 ведутся работы по созданию исполнимого тестового набора для IPv6, который основывается на открытых тестовых спецификациях, опубликованных Европейским институтом стандартизации телекоммуникаций (ETSI). Эти тестовые спецификации разработаны на языке TTCN3. Авторские права на TTCN3 принадлежат ETSI, но сам стандарт опубликован в Интернете, доступен для скачивания всем желающим, и ETSI разрешает создавать трансляторы TTCN3 и средства тестирования на основе TTCN3 без выплат лицензионных отчислений. На данный момент существуют только коммерческие реализации TTCN3, и их использование в Go4IT противоречит целям и задачам консорциума - распространение тестового набора для IPv6 в исходном виде
потребует от пользователей приобретать средства компиляции и исполнения TTCN3. Соответственно, одна из задач, стоящих перед Package 1, заключается в том, чтобы построить исполнимый тестовый набор, в котором содержится минимальная зависимость от коммерческих средств работы с TTCN3. Эта задача решается следующим образом: участники Package 1 поставляют тестовый набор в откомпилированном виде и набор свободно распространяемых инструментов для конфигурирования, запуска тестового набора и анализа результатов. Благодаря этому, пользователям тестового набора не требуется приобретать дорогостоящие коммерческие TTCN3-системы.
Решение, предлагаемое в Package 1, обладает одним существенным недостатком - тестовый набор поставляется в откомпилированном виде, поэтому пользователи лишены возможности изменять или расширять его. Для этого необходим компилятор TTCN3, а он в состав Package 1 не входит. Как показало исследование потребностей пользователей, проведённое консорциумом Go4IT, существует значительная доля потенциальных пользователей тестового набора для IPv6, которым нужны возможности по изменению или расширению тестового набора. По этой причине было принято решение создать в рамках Go4IT подпроект Package 2 для решения задач по созданию платформы для валидации и верификации открытых стандартов Интернета.
В рамках Package 2 ведутся работы по разработке открытой реализации TTCN3 и подготовке на её основе платформы по тестированию телекоммуникационных систем. Бюджет консорциума Go4IT недостаточен для разработки полной TTCN3 системы, поэтому перед Package 2 поставлены следующие задачи:
1. Подготовить полный комплект технических заданий для компилятора TTCN3, библиотек времени исполнения, средств конфигурации и запуска тестов и анализа результатов.
2. Разработать прототипы компилятора и всех подсистем для проверки корректности подготовленных технических заданий.
Основная доля работ Package 2 выполняется в Китае. Эго объясняется, прежде всего, тем, что в КНР предполагается использовать TTCN3 в качестве основы для национального стандарта языка спецификации тестов. Проектные работы ведутся в основном европейскими участниками консорциума Go4IT, так как у них есть большой опыт работы с TTCN3.
ИСП РАН принимает участие преимущественно в Package 2. Роль ИСП РАН в Package 2 заключается в валидации и верификации создаваемой платформы. В частности, задача ИСП РАН - подготовить комплект тестов для компилятора TTCN3 и ряда вспомогательных подсистем платформы. Такой выбор задач для ИСП РАН объясняется тем, что среди участников консорциума ИСП РАН обладает наибольшим опытом практического тестирования, в том числе и компиляторов. В ИСП РАН разрабатываются методы систематического тестирования различных видов систем - программных интерфейсов,
реализаций протоколов, компиляторов и встроенных систем. Основная идея, объединяющая эти методы, заключается в том, что тесты извлекаются автоматически из формальных моделей тестируемой системы.
Помимо Package 1 и Package 2 в рамках проекта Go4IT ведутся работы по распространению знаний о проекте Go4IT, предлагаемых средствах и сервисах валидации и верификации. Эго направление работ возглавляет ИСП РАН.
Для обеспечения открытости необходима обратная связь как от участников проекта, так и людей, внешних по отношению к консорциуму. В Go4IT для этой цели запланирована система семинаров в России, которые организует ИСП РАН - базовая организация в проекта Go4IT в стране.
Для распространения знаний существует несколько форм, используя которые ИСП РАН пытается добиться наибольшей эффективности в деле популяризации Go4IT и стандартов IPv6. Известно, что мы запоминаем 10% того, что мы читаем; 20% того, что мы слышим; 30% того, что мы видим; 50% того, что мы видим и слышим; 70% того, что мы говорим; 90% того, что мы говорим и делаем. Задача ИСП РАН построить такую систему сотрудничества, при которой каждый может занять свою активную позицию. Первоначальное знакомство российских специалистов с проектом Go4IT происходило на семинаре со следующей программой:
1. Введение в проект Go4T и Европейские рамочные программы.
2. Введение в Интернет протокол нового поколения IPv6.
3. Демонстрационная сессия прототипа тестовой платформы Go4IT.
4. Введение в язык спецификации тестов TTCN3.
5. Обзор архитектуры тестовой платформы Go4IT.
6. Круглый стол - перспективы IPv6 и Go4IT в России.
Одна из сложностей в распространении Go4IT состоит в малом числе пользователей Интернет-протокола IPv6 - целевой системы тестовой платформы Go4IT. Для привлечения участников на семинар были задействованы каналы, специфичные для специалистов по сетям IPv6 -потенциальных пользователей Go4IT. Наибольший отклик дало распространение объявления о семинаре через дискуссионный лист российского форума IPv6.
При распространении Go4IT особое внимание необходимо уделить практическому применению тестовой платформы. С этой целью в состав материалов семинара был включён прототип тестовой платформы для ознакомления с новыми технологиями тестирования. Другая форма адаптации программы к реальным потребностям пользователей - проведение Plugtests. В апреле 2007 г. планируется провести в России IPv6 Plugtests, на котором любой производитель или владелец оборудования IPv6 сможет проверить соответствие своего оборудования или программной системы набору базовых 28
стандартов IPv6 и, тем самым, познакомиться и испытать «на себе» тестовую платформу Go4IT.
6. Заключение
Международные проекты, построенные по модели открытого кода - это новая форма сотрудничества людей, организаций и стран, которая значительно отличается от видов отношений, традиционных для проектов по созданию коммерческого программного обеспечения. Проекты ОК выполняются сообществом добровольцев, и можно констатировать, что к настоящему времени сложились основные принципы организации таких сообществ. В этой статье мы выделили несколько признаков открытого сообщества, которые позволяют вести открытые проекты и добиваться в них значительных результатов.
Процессы разработки и продвижения открытых стандартов интерфейсов программных и аппаратных систем мало похожи на процессы создания программного обеспечения. Работа над стандартом больше похожа на написание книги, а продвижение стандарта напоминает программы пропаганды и агитации в политике или программы развития культурных связей и распространения знаний.
Тем не менее, проекты по разработке и продвижению открытых стандартов удовлетворяют ключевым свойствам модели открытых кодов: открытость проекта для включения новых участников, открытость результатов для ознакомления, открытость результатов для использования. Такие проекты подчиняются тем же законам открытых сообществ, что проекты по созданию открытых программ.
Опыт ИСП РАН показывает, что вхождение в открытые самоорганизующиеся сообщества крупной исследовательской структуры, такой как институт РАН, не составляет труда. При этом, однако, необходимо учитывать специфику и общие принципы развития открытых сообществ, т.к. пренебрежение ими может снизить эффективность участия в открытом сообществе.
Литература
[1] Проект свободной многоязычной энциклопедии Wikipedia.
[HTML] (http://www.wikipedia.org/).
[2] Проект PlanetMath - энциклопедия, публикации и учебные курсы по математике. [HTML] (http://planetmath.org/).
[3] Проект PlanetPhysics - энциклопедия, публикации и учебные курсы по физике. [HTML] (http://planetphysics.org/)
[4] Архив графических работ OpenClipArt для оформления элементов GUI и Web-страниц. [HTML] (http://www.openclipart.org/)
[5] Сеть свободных музыкальных проектов Remix Commons.
[HTML] (http://www.remixcommons.org/).
[6] Open Source Initiative. [HTML] (http://www.opensource.org/index.php).
[7] GNU General Public License. [HTML] (http://www.gnu.org/copyleft/gpl.html).
[8] GNU Lesser General Public License. [HTML] (http://www.gnu.org/copyleft/lgpl.html).
[9] Apache License. [HTML] (http://www.apache.Org/licenses/LICENSE-2.0.html).
[10] BSD License. [HTML] (http://www.opensource.org/licenses/bsd-license.php).
[11] Перечень лицензий на сайте Free Software Foundation .
[HTML] (http://www. gnu.org/licenses/license-list.html).
[12] Перечень лицензий, одобренных Open Sources Initiative.
[HTML] (http://www.opensource.org/licenses/index.php).
[13] Часто задаваемые вопросы на сайте kemel.org.
[HTML] (http://www.kemel.0rg/faq/#acc0unt).
[14] Internet Engineering Task Force. [HTML] (http://www.ietf.org/).
[15] ETSI Plugtests Service Center. [HTML] (http://www.etsi.org/plugtests/).
[16] Электронный список рассылки The Austin Group.
[HTML] (http://www.opengroup.org/austin/lists.html).
[17] The Open Group. [HTML] (http://www.opengroup.org/).
[18] Project Proposal and Call for Participation: The Linux Standard Base (LSB) Project. [HTML] (http://old.lwn.net/1998/0528/a/lsb.html).
[19] Linux Standard Base discussion.
[HTML] (http : //lists. freestandards. org/mailman/listinfo/lsb-discuss).
[20] Проект OLVER. [HTML] (http://linuxtesting.ru/).
[21] Баранцев A.B., Бурдонов И.Б., Демаков A.B., Зеленов C.B., Косачев A.C., Кулямин В.В., Омельченко В.А., Пакулин Н.В., Петренко А.К., Хорошилов A.B. Подход UniTesK к разработке тестов: достижения и перспективы. // Труды ПСП РАН, №5, 2004. [HTML] (http://www.citforum.ru/SE/testing/unitesk).
[22] В. В. Кулямин, Н. В. Пакулин, О. JI. Петренко, А. А. Сортов, А. В. Хорошилов. Формализация требований на практике. // Препринт № 13 ПСП РАН, 2006.
[23] Система управления ошибками Bugzilla. [HTML] (http://www.bugzilla.org/).
[24] Система управления ошибками в LSB. [HTML] (http://bugs.linuxbase.org/).
[25] OLVER, замечания к стандарту LSB
[HTML] (http://linuxtesting.ru/results/std_reports_LSB).
[26] Список замечаний к части System Interfaces (XSH) стандарта POSIX.
[HTML] (http://www.opengroup.org/austin/aardvark/latest/xshbug2.txt).
[27] OLVER, замечания к стандарту POSIX
[HTML] (http://linuxtesting.ru/results/std_reports_SUSv3).
[28] GNU С Library. [HTML] (http://www.gnu.org/software/libc/).
[29] Система управления ошибками проекта sourceware.org.
[HTML] (http: //sourceware.org/bugzilla/).
