Системы с открытым кодом. Часть 1/2
2 июня 2005
Рубрика: Обзоры и мнения.
Автор: Владислав Михайликов.
pic

Другие звери в общем зоопарке
Кроме вышеупомянутых Linux и Windows, существуют и другие операционные системы как платные, так и бесплатные. Ниже даны краткие характеристики наиболее популярных из них:

MacOS X (www.apple.com)
Mac OS X — современная операционная система. Разработана и распространяется компанией Apple Computer. Состоит из двух частей:

• потомок UNIX-подобной ОС Darwin с открытыми исходными кодами, представлявшей собой реализацию BSD на микроядре Mach2. Работает на платформе PowerPC.
• собственная графическая оболочка Aqua. Возможна установка стандартной графической подсистемы для UNIX — Xfree86.

Подробнее читайте на http://www.apple.ru/macosx/

Novell Netware
Об этой замечательной операционной системе так же, как и о продукте Sun Solaris компании Sun Microsystems и HP UX компании HP (Hewlett Packard), вы можете подробно узнать на следующих сайтах: http://www.novell.com, http://www.sun.com и http://www.hp.com Операционные системы и программные продукты этих компаний столь многообразны, что требуют отдельной статьи. Так что любопытным рекомендуется почитать поподробнее.

IBM AIX
AIX (Advanced Interactive eXecutive) — операционная система семейства Юникс компании IBM.
Первая версия AIX — AIX/RT 2 вышла в 1986 году и была построена на базе UNIX System V Release 2 и Berkeley Software Distribution(5) 4.2 Extensions для первых RISC-компьютеров IBM RT Personal Computer (последняя версия — AIX/RT 2.2.1 1987).
Существовала версия для запуска в среде VM для мейнфреймов IBM S/370 под названием AIX/370 (последняя версия — AIX/370 1.2.1 1991).
В 1989 году была выпущена AIX/6000 V3, предназначенная для нового семейства RISC-компьютеров IBM RS/6000, выпущенных в 1990 году. Эта ОС в 1990 году вместе с выпуском версии 3.1 была переименована просто в AIX.
В 1991 году представлена версия этой ОС для семейства IBM System/390 под названием AIX/ESA (последняя версия — AIX/ESA 2.2 1994).
Выпускались также версия для персональных компьютеров IBM PS/2 под названием AIX PS/2 (последняя версия — AIX PS/2 1.3 1992).
В 1998 году была предпринята неудавшаяся попытка совместно с компанией SCO портировать AIX на процессор Intel Itanium (проект Monterey). Проект закрыли из-за маркетинговых соображений.
В настоящий момент операционная система AIX является стандартной ОС для компьютеров с процессорами Power и PowerPC семейств IBM RS/6000 (1990-2000), а также IBM pSeries (начиная с 2000 года) и называется сейчас AIX 5L (где буква L обозначает Linux Affinity — «Близость к Линуксу» — возможность использовать программы для ОС Linux под AIX).
Подробнее читайте на http://www-1.ibm.com/servers/aix/index.html

FreeBSD
Проект FreeBSD возник в первой половине 1993 года частично как результат развития «Неофициального комплекта исправлений к 386BSD (patchkit)», последними тремя координаторами этого проекта: Nate Williams, Rod Grimes и Jordan Hubbard.
Главной задачей было привести промежуточный снэпшот 386BSD в порядок, исправив множество проблем, которые механизм patchkit не мог решить. Некоторые из вас, возможно, помнят раннее название этого проекта: «386BSD 0.5», или «386BSD Interim».

386BSD была операционной системой Била Джоилца, который тогда находился, строго говоря, в состоянии полного пренебрежения к ней. Так как patchkit разрастался, его поддержание становилось более неудобным день от дня, разработчики пришли к единодушному соглашению, что что-то нужно делать, и решили помочь Биллу путем предоставления промежуточных «очистных» снэпшотов. Эти планы были грубо оборваны, когда Билл внезапно решил прекратить поддержку проекта без всяких ясных комментариев, что должно было быть сделано.
Остальным разработчикам потребовалось немного времени, чтобы прийти к решению продолжать следовать той же цели, даже без поддержки Билла, и было принято имя «FreeBSD», приобретенное Дэвидом Гринмэном. Начальные цели были определены после консультаций с пользователями существовавшей системы, и как только стало понятно, что проект на пути к тому, чтобы стать реальностью, Jordan Hubbard связался с Walnut Creek CDROM с идеями о путях последующего улучшения каналов распространения FreeBSD для множества пользователей без доступа к Internet. Walnut Creek CDROM не только поддержал идею распространения FreeBSD на CD, но также пошел далеко вперед и предоставил проекту компьютер для работы и быстрый доступ к Internet. Без почти беспрецедентной веры Walnut Creek CDROM в этот в то время полностью неизвестный проект вряд ли FreeBSD зашел бы так далеко и так быстро, как сегодня.

Первым дистрибутивом, распространяемым как на CDROM, так и в сети, стал FreeBSD 1.0, выпущенный в декабре 1993 года. Эта версия была выполнена на основе ленты 4.3BSD-Lite («Net/2») из Калифорнийского университета в Беркли, с многочисленными добавлениями из проекта 386BSD и Фонда свободного программного обеспечения. Это был довольно внушительный успех для первого предложения, и мы закрепили его с выходом FreeBSD 1.1 RELEASE в мае 1994 года.

В это же время на горизонте сгустились тучи в связи с назревающим скандалом между Novell и Калифорнийским университетом, Беркли. Это был вялотекущий судебный процесс о легальности версии Net/2 из Беркли. Обстоятельства тяжбы с Калифорнийским университетом заключались в том, что большие куски Net/2 были «загромождены» кодом, права на который принадлежат Novell, которая, в свою очередь, получила их (права на код) ранее от AT&T. Чтобы вернуть «благословение» Novell, Беркли выпустил версию 4.4BSD-Lite, которая была объявлена полностью «свободной», и всем пользователям Net/2 было рекомендовано переключиться на ее использование. Это также касалось FreeBSD, и проекту было дано время до конца июля 1994 года для прекращения распространения его продукта, базирующегося на Net/2. На этих условиях проекту было разрешено выпустить последний релиз до окончания срока, это был FreeBSD 1.1.5.1.

Тогда FreeBSD приступил к сложной задаче — буквально полному изобретению себя из абсолютно новой и довольно неполной системы 4.4BSD-Lite. «Lite» был в прямом смысле light (легким) потому, что CSRG Berkeley удалил большие куски кода, необходимого для создания реально загружающейся системы (по причине различных лицензионных требований), и фактически порт 4.4BSD для платформы Intel был очень неполным. Проекту потребовалось время почти до ноября 1994 года для того, чтобы выполнить этот переход и на этом этапе FreeBSD 2.0 была опубликована в сети и на CDROM (в конце декабря). Несмотря на множество «острых углов» в этой версии, она пользовалась значительным успехом и была продолжена более устойчивой и простой в установке FreeBSD 2.0.5, выпущенной в июне 1995 года.

Выпустили FreeBSD 2.1.5 в августе 1996, и она стала достаточно популярной среди большого количества ISP и коммерческих производителей, чтобы выпустить еще один релиз из ветви 2.1-STABLE. Это была FreeBSD 2.1.7.1, вышедшая в феврале 1997 и завершившая главную ветвь разработки 2.1-STABLE. Сейчас в режиме поддержки в эту ветвь (RELENG_2_1_0) вносятся только расширения безопасности и другие критически важные исправления.
FreeBSD 2.2 была ответвлена от основной линии разработки («-CURRENT») в ноябре 1996 как ветвь RELENG_2_2, а первая полная версия (2.2.1) появилась в апреле 1997. Последующие версии ветви 2.2 появлялись летом и в конце 1997 года, а последняя версия (2.2.8) вышла в ноябре 1998. Первая официальная версия 3.0 была подготовлена к выходу в октябре 1998, завершив развитие ветви 2.2.
Третье ветвление произошло 20 января 1999 года, появились ветви 4.0-CURRENT и 3.X-STABLE. Из ветви 3.X-STABLE были получены: 3.1 — 15 февраля 1999, 3.2 — 15 мая 1999, 3.3 — 16 сентября 1999, 3.4 — 20 декабря 1999, 3.5 — 24 июня 2000, за которым последовал через несколько дней немного обновленный 3.5.1, который содержал несколько исправлений в области безопасности Kerberos. Это был последний релиз из ветви 3.X.
Другое ветвление было выполнено 13 марта 2000 года, в результате чего появилась ветвь 4.X-STABLE. Из этой ветви было выпущено несколько релизов: 4.0-RELEASE был представлен в марте 2000 года, самый свежий 4.11-RELEASE был выпущен Jan 2005. Из ветви 4.X-stable (RELENG_4) будут выпущены и следующие релизы.
Долгожданный 5.0-RELEASE был анонсирован 19 января 2003 года. Он стал кульминацией приблизительно трех лет работы, с этого релиза начался курс FreeBSD на расширенную поддержку мультипроцессорности и потоков в приложениях, была также представлена поддержка платформ UltraSPARC® и ia64. За этим релизом последовал релиз 5.1 в июне 2003 года. Последним релизом 5.X из ветви -CURRENT стал 5.2.1-RELEASE, представленный в феврале 2004.
Ветвь RELENG_5 была создана в августе 2004, после чего был выпущен релиз 5.3-RELEASE, который открыл серию релизов из ветви 5-STABLE.
Подробнее читайте на http://www.freebsd.org

OpenBSD
OpenBSD — свободно распространяемая в исходных текстах, многоплатформенная UNIX-подобная операционная система, базированная на UNIX версии BSD 4.4. Основным отличием от двух остальных свободно распространяемых операционных систем, базирующихся на 4.4BSD (FreeBSD, NetBSD) является изначальная ориентированность проекта на создание наиболее безопасной из существующих операционных систем. Проект OpenBSD отпочковался от проекта NetBSD в 1995, когда нынешний руководитель проекта, Theo de Raadt, решил заняться созданием настолько безопасной операционной системы, насколько это возможно.
Проект OpenBSD выпускает два релиза в год — 1 мая и 1 ноября. В настоящий момент поддерживается более десятка различных платформ и архитектур, включая популярные i386-совместимые компьютеры, MacPPC «New World», Mac68k, Sun SPARC и ULTRASparc системы. Наиболее популярным (хотя далеко не единственным) применением OpenBSD являются системы защиты сетей, так называемые брандмауэры.
Подробнее читайте на http://www.openbsd.org

Экономическая целесообразность: вся власть потребителю
В конце концов, каждый счастливый обладатель персонального компьютера, а теперь уже и сотового телефона или карманного персонального компьютера сталкивается с программным обеспечением, а точнее, с необходимостью платить за лицензию на его (программное обеспечение) использование.
Поскольку у нас в Узбекистане наиболее распространены операционные системы производства компании Microsoft Corporation, то со всеми вытекающими пользователи вынуждены искать программное обеспечение, которое совместимо с разными версиями этой ОС.
А вот теперь давайте посчитаем (как говорил один крот из известного мультфильма «Дюймовочка») типичную стоимость закупки программного обеспечения для трех конкретных категорий пользователей:

• типичный домашний пользователь
• типичный корпоративный пользователь
• специализированный пользователь («геймер», проектировщик, программист, веб-мастер и т.д.).

Домашний пользователь

Что нужно домашнему пользователю? В принципе не очень много, но все-таки:

просматривать web-страницы
читать и писать электронную почту
работать с электронными документами – такими, как тексты, таблицы, презентации
смотреть фильмы
слушать музыку
читать электронные книги.

Во что же это обойдется обладателю персонального компьютера следующей конфигурации (указаны только наиболее значимые компоненты):

pic

А тепереь посчитаем стоимость лицензионного ПО, которое будет установлено на компьютер такой конфигурации (цены приведены с сайта компании Softline, предлагающей лицензионное программное обеспечение компании Microsoft и других производителей ПО в Узбекистане):

• операционная система Microsoft Windows XP Home Edition (N09-01034 Windows XP Home Edition Russian CD Windows/ServicePack 2 ) – 156 долларов США
• работа с текстами, электронными таблицами и презентациями Microsoft Office 2003 (021-06304 Office 2003 Win32 Russian CD) обойдется в 293 доллара США
• Adobe Acrobat Reader 7.0 от компании Adobe обойдется вам бесплатно
• отсканировать и распознать документы на русском, узбекском и других языках лучше всего делать в ABBYY Fine Reader (12-69-ABBYY-SL ABBYY FineReader 7.0 Home Edition) за 24 доллара США
• редактирование фотографий в Adobe Photoshop (23102150 Photoshop CS2 Full Window) легко можно сделать за 875 долларов США
• антивирусное ПО, без которого жизнь уже практически невозможна, поэтому Антивирус Касперского 5.0. (29-8-KASPERSKY-SL Kaspersky Anti-Virus Personal Russian Edition. 1-Desktop 1 year Base Box) вам обойдется за 39 долларов США.

Итого, среднестатистический домашний пользователь должен приготовить 1387 долларов США на лицензионное ПО и 20% (то есть 277 долларов США) от стоимости всех лицензий для ежегодного обновления (что превышает стоимость ПК в 1,5 раза).
Для сравнения дистрибутивный диск с Linux и годом поддержки обойдется от 50 до 100 долларов США, причем в него войдут аналоги всего вышеперечисленного ПО с не меньшей функциональностью. Что касается совместимости, то OpenOffice, KOffice и StarOffice замечательно открывают и редактируют документы Microsoft Office.

Корпоративный пользователь
Запросы корпоративного пользователя существенно выше, поскольку требования к программному обеспечению гораздо более проффесиональные. Под этим понимается выбор программного обеспечения класса Proffesional или Enterprise, что увеличивает цену в два раза (около 2500 долларов США на одно рабочее место). Чтобы не быть голословным, приведу список вышеперечисленных продуктов для корпоративного пользователя из расчета на 25 рабочих мест (небольшая компания):

• операционная система Microsoft Windows XP Professional Edition (E85-02725 Windows XP Professional Russian CD Windows/ServicePack 2) – 233 доллара США
• работа с текстами, электронными таблицами и презентациями Microsoft Office 2003 (269-06846 Office Professional 2003 Win32 Russian CD) – 358 долларов США
• также для поддержки новейших информационных технологий просто необходим Microsoft Small Business Server 2003 (T72-00056 Win Small Business Server Standard 2003 Russian CD 5 Client) за 591 доллар США, что на одного пользователя составит 118,2 доллара США
• Adobe Acrobat Reader 7.0 от компании Adobe также обойдется бесплатно, а вот подготовка документов в формате PDF (22001944 Acrobat Standard Full Windows) будет стоить 410 долларов США
• отсканировать и распознать документы на русском, узбекском и других языках лучше всего делать в ABBYY Fine Reader (12-67-ABBYY-SL ABBYY FineReader 7.0 Professional Edition) за 129 долларов США
• редактирование фотографий в Adobe Photoshop (23102150 Photoshop CS2 Full Window) также можно сделать за 875 долларов США
• Антивирус Касперского 5.0. (38-10-1262-KASPERSKY-SL Kaspersky Anti-Virus Corp Suite Russian Edition. 1-1 FileServer 1 year Base Licence) обойдется в 649 долларов США.

Итого, среднестатистический корпоративный пользователь должен приготовить не менее 2800 долларов США на лицензионное ПО и 20% (то есть 560 долларов США) от стоимости всех лицензий для ежегодного обновления.
Корпоративное издание Linux, включающее все вышеперечисленное – также весьма недорогое. Средняя цена с годом поддержки составит 50-150 долларов США.

pic

Специализированный пользователь
Потребности специализированного пользователя весьма разнообразны, но, как показывает практика, затраты на специализированное ПО превышают аналогичные затраты на нужды корпоративных пользователей в 3-15 и более раз.
Вывод напрашивается: считайте сами, что выгоднее.

Интеграция в мировое сообщество: последствия одной ратификации
Как вы знаете, Узбекистан собирается вступать в ВТО (Всемирная торговая организация) и все бы хорошо, поскольку преимуществ у нашей республики появится масса. Но есть и минусы. А именно: Узбекистан подписал и ратифицировал Бернскую конвенцию об охране авторских прав. А это значит, что очень скоро вездесущий Билли предъявит всем нам счет за нелицензионное ПО.
Кстати, с января 2005 года в Узбекистане официально начал свою деятельность известный дистрибьютор Microsoft – компания Softline.

Что может дать Linux Узбекистану?
Что и почему? Не потому, что программы с открытым кодом условно бесплатны, и это нам как налогоплательщикам должно нравиться. Известно, что цена лицензий — не единственная составляющая стоимости решений, порой доработка и сопровождение обходятся куда дороже.
Не потому, что открытый код можно спокойно изучать и исследовать до приобретения программы, а это позволяет принимать более взвешенные решения при выборе платформы. С поставщиками можно договориться, и они вряд ли откажут в передаче версии для тестирования, нацеленного на проверку безопасности и надежности кода, а также производительности и масштабируемости. Вовсе не обязательно иметь исходные тексты, чтобы проверить систему по ключевым критериям.
Не потому, что открытый код не принадлежит производителю, а государственные мужи, особенно представители силовых структур, ревниво относятся к вопросам авторства, собственности и тому подобное. Одна из «заповедей» свободного программного обеспечения гласит, что недопустимо прятать созданные решения под грифом секретности.
Не потому, что при наличии доступа к исходным текстам всегда можно модифицировать их, исправив выявленный в ходе эксплуатации дефект, адаптировать к изменившимся требованиям или дополнить новые функции. Производители обеспечивают различные уровни технической поддержки — вплоть до решения выявленных проблем в течение 24 часов. Во многие коммерческие пакеты входят развитые механизмы настройки и параметризации, а также встроенные средства быстрой разработки.
А потому, что открытый код в сочетании с открытыми стандартами и открытой архитектурой может сделать информационное пространство страны более прозрачным для граждан.

В каком-то смысле можно проследить аналогию с CRM (customer relationship management — управление отношениями с клиентами), только в данном случае customer (клиент) заменяется на citizen (гражданин). Поскольку eCRM (то есть правление отношениями посредством электронных средств коммуникаций) может составлять, по оценкам экспертов, свыше 50% всех процессов взаимодействия, взаимоотношения государства и граждан все больше будут базироваться на современных технологиях. И их применение должно быть нацелено именно на гражданина (или гражданские организации), а не на само государство.
Из «черного ящика» с замкнутой на себя структурой (имеются только точки поступления данных) мы должны получить интерактивную систему общения власть имущих с народом (имеется интерфейс для двусторонней передачи информации). Эта мысль не нова: в Сети можно найти массу публикаций, в которых обсуждаются возможность и необходимость использования открытого кода в госсекторе (например, в США, Канаде и Германии), а также результаты исследований независимых групп и комиссий, созданных парламентскими и общественными структурами. Исходя из представления о государстве как о поставщике услуг, которые обеспечивают выполнение конституционных прав граждан, авторы отчетов считают: именно информационные системы с открытым кодом способны открыть ИТ-инфраструктуру государственных органов с целью более полного и эффективного использования их услуг.
Есть еще один аспект, который связан со взглядом в достаточно далекое будущее: государство имеет перед обществом обязательства по защите целостности, конфиденциальности и доступности публичной и частной информации на протяжении длительного времени, в условиях территориальной распределенности центров обработки данных и огромных объемов поступающих в них сведений. Применение закрытого кода, специфичных средств обработки информации или хранение данных в частных форматах может стать угрозой для самой возможности государства исполнять свои обязательства в долгосрочной перспективе. Причинами являются зависимость от конкретного производителя и связанные с ним субъективные (добрая воля разработчика, конъюнктура рынка) и объективные (финансовая стабильность) факторы.

Приведем несколько примеров.

1. Оригинальный (или даже уникальный) формат статистических данных, собранных в результате переписи населения, требует трудоемкого процесса конвертации для составления отчетности. А ведь эти данные необходимо хранить на протяжении многих лет независимо от изменений в ИТ, от морального и физического старения платформ. Однако структуры данных и алгоритмы их сжатия были недостаточно описаны, знания утеряны вместе с исходными текстами, а потому для создания отчетов и переработки результатов переписи понадобились обратное проектирование решения и миграция данных в SQL-совместимую базу.
1.
2. Алгоритм обработки результатов голосования вызвал нарекания, но поскольку программный продукт был поставлен без исходных кодов, экспертиза ПО оказалась невозможной. В результате пересчет был проведен вручную. Наличие исходных текстов позволило бы согласительной комиссии пригласить экспертов для изучения кода.

3. Для сбора налоговой отчетности непосредственно у юридических и физических лиц им было предложено приобрести специально разработанную программу для оформления электронных бланков и их передачи по специальному протоколу в налоговые органы. После достаточно бурных дискуссий налоговикам пришлось согласиться с тем, что компоненты заполнения форм и передачи данных можно получать с общедоступного Web-сайта бесплатно. А главное, протокол был заменен на стандартный; это позволило разработчикам финансовых систем автоматически формировать и передавать отчетность.

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

5. Реализация концепции «электронного государства», которое должно предоставить гражданам возможность взаимодействовать с различными ветвями власти посредством Web-технологий, требует замены сайтов отдельных государственных органов на Web-порталы, интегрирующие разные внутренние и внешние источники данных (в том числе поступающих от приложений автоматизации внутренней деятельности).

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

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

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

В отчете канадских исследователей (e-Cology, 2003) была приведена статистика ответов руководителей ИТ-департаментов организаций частного и государственного сектора. Отвечая на вопрос, насколько хорошо приложения с открытым кодом приспосабливаются к ИТ-инфраструктуре их организаций, более 90% респондентов отметили такие преимущества открытого программного обеспечения, как интегрируемость, совместимость со стандартами, адаптируемость под существующую архитектуру, сосуществование с покупными и заказными приложениями и переносимость на различные платформы. Это является хорошей предпосылкой, чтобы рассматривать использование открытого кода как верное направление для решения интеграционных задач, стоящих перед ИТ-специалистами госсектора.
Проблема закрытого кода состоит в следующем. Даже при наличии хорошо документированного и корректно работающего программного интерфейса, который предоставляет исчерпывающий набор входящих и выходящих параметров, а также поддерживает соответствующие стандарты, протоколы и форматы, всегда сохраняется зависимость от производителя или команды разработчиков. Каждый производитель на свое усмотрение принимает решение о полной или частичной поддержке того или иного стандарта, о способе реализации и совместимости со спецификацией, поэтому в любом случае необходимо проводить «испытания» методом проб и ошибок.
Добившись стабильной интеграции всех приложений с текущей версией продукта, нельзя гарантировать, что изменение системного окружения или обновление самой программы не приведут к несоответствиям. К сожалению, коммерческие программные продукты для сохранения технической поддержки требуют постоянного обновления; в результате поддержка версий интерфейсов или обратной совместимости становится проблемой.
Постоянное обновление программ влияет на внутри- и межведомственную интеграцию, может стать препятствием для обращения к ней сторонних организаций. Строгое соответствие авторским версиям, которое принято в мире открытых исходных текстов, поможет решить часть проблем. Располагая кодом именно той версии, которая находится в эксплуатации, можно самостоятельно (без давления со стороны производителя) принимать решения о его изменениях или обновлениях.

К слову, приложения с открытым кодом не могут не поддерживать стандарты в том виде, в каком они декларированы, поскольку совместно разрабатываются не всегда знакомыми друг с другом программистами. Все они имеют доступ к одним и тем же исходным материалам в виде спецификаций стандартов, и результат должен быть совместим с декларированным стандартом. Кстати, открытые стандарты разрабатываются коллективами, состоящими из специалистов различных компаний и независимых экспертов, примерно так же, как открытый код, то есть совместными усилиями и путем принятия общих решений. Все это свидетельствует в пользу открытого кода.
Однако возникают и ситуации, в которых такой «идеал» не достигается. Например, два ведущих «закрытых» сервера приложений, IBM WebSphere и BEA WebLogic, поддерживают последние версии J2EE, но со своими нюансами и расширениями. А два сервера приложений с открытым кодом, JBoss и JRun, совместимы только с ранними версиями J2EE, к тому же в усеченных вариантах.

Проблемами открытого кода являются организация обучения и создание документации. Не все разработчики открытого программного документируют свои продукты на должном уровне, и надо быть готовыми к тому, что для изучения кода и его «причесывания» могут потребоваться некие усилия. Выходом может послужить частичная коммерциализация: компании, ориентированные на доход от сервиса, а не от выдачи лицензий, выпускают продукт на базе открытого кода и отвечают за его сопровождение.
Безусловно, полностью открытым решением можно назвать лишь то, которое основано на трех «открытых» принципах: открытый код, открытые стандарты, открытая архитектура. Последние два принципа ни у кого не вызывают сомнений. А с распространением серверных платформ с открытыми кодами (Linux, Apache, MySQL и др.) многие производители коммерческого программного обеспечения корпоративного масштаба (такие, как IBM, Sun Microsystems, Oracle и SAP) приняли решение переносить свои продукты на системы с открытым кодом, тем самым признав первый принцип.
Однако переход на свободное программное обеспечение для заказчиков из госсектора — не самоцель, и едва ли руководители ведомственных ИТ-отделов получат директиву использовать открытый код в обязательном порядке (правда, в некоторых азиатских и латиноамериканских странах есть такие примеры). Это означает, что приложениям с открытым кодом надо обеспечить тот же уровень интеграционных средств, какой характерен для зрелых корпоративных решений.
На рынке уже предлагаются несколько платформ промежуточного уровня (S-Integrator, ObjectWeb, OpenLDAP, OpenSSL, JBoss, JRun, Samba и др.), поддерживающих различные стандарты и соглашения. Например, S-Integrator поддерживает Web-сервисы, EJB, HTTP, XML, WSDL, SOAP, RMI, ODBC/JDBC, SMTP, FTP и т.д., представляя собой контейнер для серии сервисов, которые можно совмещать для решения целого комплекса интеграционных задач.

ObjectWeb — сервисная шина предприятия (enterprise service bus, ESB), нейтральная по отношению к различным приложениям благодаря архитектуре, ориентированной на сервисы (service oriented architecture, SOA) и управляемой событиями (event driven architecture, EDA). В рамках проекта ObjectWeb разработаны:

• JOnAS — основанный на Java сервер приложений, совместимый с J2EE 1.4
• Bonita, Enhydra Shark, JaWE — инструментарий управления процессами; при этом Bonita поддерживает BPEL, а два последних компонента — XPDL
• JORAM — шина обмена сообщениями с коннекторами к JMS и SOAP/WSDL/UDDI
• JOTM — менеджер управления распределенными транзакциями
• XQuark — механизм сбора, преобразования и обработки данных на основе запросов XML/XQuery
• Enhydra Octopus, Enhydra Zeus — инструментарий извлечения и трансформации данных и конвертации Java2XML (DOM, SAX, XSLT).

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

Сервер JBoss совместим с J2EE, JMS, XML/XSLT, HTTP(S), FTP, SMTP, POP3&IMAP, NLIS и другими стандартами, а в его поставку входят готовые коннекторы доступа к таким системам, как BizTalk и WebSphere, а также к приложениям (Siebel, Oracle и др.). Лицензии на все эти программы поставляются в госсектор по правилам GNU, то есть оплачивается лишь себестоимость разработки новых адаптеров. Перечень стандартов показывает зрелость решений, созданных для государственных структур на базе открытого программного обеспечения, однако зрелость — это не только декларации поддержки индустриальных стандартов, но и качество созданного решения.
Для решений, предназначенных для госсектора, может оказаться оптимальной комбинация базового программного обеспечения (в качестве оного допустимо воспользоваться открытым кодом) и локальных разработок или даже компонентов с закрытым кодом от коммерческих производителей. Зачастую проекты представляют собой «изобретение велосипеда» — приходится повторно разрабатывать функции, уже реализованные в других решениях. Повторное использование затрудняется рядом объективных причин, в первую очередь недоступностью кода. Альтернативой является все та же интеграция. А если код все-таки доступен, затраты сокращаются: работа над разделяемым открытым кодом позволяет унифицировать общие алгоритмы, оставляя возможность ветвления под специфику задач участника проекта.

Примером может служить совместный проект немецких финансовых институтов, который связан с разработкой общего кода как альтернативы «многомиллионным» (по стоимости лицензий) продуктам категории EAI. Созданная в результате шина должна отвечать высоким требованиям к качеству, производительности, надежности, безопасности и отказоустойчивости. И каждый участник проекта адаптирует систему под свои специфические требования.
Агентство космических исследований NASA, которому приходится постоянно адаптировать программы с открытыми исходными текстами, определяет главное достоинство такого подхода к выполнению проектов как «сквозь границы организаций». Открытый код должен пробить барьер во взаимоотношениях как государственных структур, так и коммерческих и общественных организаций.
Однако посмотрим на открытый и закрытый код с точки зрения чиновников, принимающих решения по закупке ИТ-решений. Для них важен бюджет — запрошенный, выделенный и имеющийся в наличии. Ссылаясь на цены крупных производителей, а еще лучше — на консультантов «большой пятерки», всегда можно запросить значительный бюджет. Не по всем направлениям, но все же удается получать внушительные суммы на внедрение ИТ. Однако в ряде случаев ИТ не является приоритетным направлением для целевого транша, и тогда скудные «выделенные» средства могут заставить обратиться к решениям с открытым кодом.

Правда, есть одно «но». У открытого кода нет своего лобби и продавцов, чтобы «проталкивать» такие продукты, а тем более в госсекторе, где цикл принятия решений по закупкам достаточно длителен. Приобретение или привлечение программного обеспечения с открытым кодом должно осуществляться не в соответствии с моделью push («толкать»), а скорее на основе модели pull («тянуть»). Это означает, что потребители (ИТ-службы государственных организаций) должны самостоятельно находить необходимое им программное обеспечение с открытым кодом и включать его в список рассматриваемых платформ. В свою очередь, регламентирующие органы должны продумать стимулы для включения открытого кода в число альтернатив при проведении тендеров. Здесь требуются ясная и четкая политика, однозначно трактуемые правила, которые позволят избежать как игнорирования открытого кода, так и радикализма типа «только открытый код».
Итак, вот аргументы в пользу применения открытого кода в проектах автоматизации госсектора: оптимальная стоимость комплексных решений; устранение зависимости от конкретного производителя программного обеспечения; снижение зависимости от возможности и сроков устранения дефектов в закрытом коде; обеспечение целостности информации и процессов ее обработки; обеспечение гибкости при разработке, расширении и интеграции приложений; открытость информационных систем для взаимодействия с внешней средой.

P.S. Данный текст был подготовлен при помощи программных продуктов с открытым кодом, с чем автор себя и поздравляет. Присоединяйтесь и вы не пожалеете.

Orphus system
Подписывайтесь на канал infoCOM.UZ в Telegram, чтобы первыми узнавать об ИКТ новостях Узбекистана
В Telegram
В WhatsApp
В Одноклассники
ВКонтакте