Различные схемы лицензирования программного обеспечения, передачи прав собственности на исходные тексты или обеспечения доступа к ним имеют свои достоинства и недостатки в контексте каждого проекта. Но в случае государственных заказов приходит мысль о применимости именно открытого кода.

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

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

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

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

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

В каком-то смысле можно проследить аналогию с CRM (customer relationship management — управление отношениями с клиентами), только в данном случае customer (клиент) заменяется на citizen (гражданин). Поскольку eCRM (т.е. правление отношениями посредством электронных средств коммуникаций) может составлять, по оценкам экспертов, свыше 50% всех процессов взаимодействия, взаимоотношения государства и граждан все больше будут базироваться на современных технологиях. И их применение должно быть нацелено именно на гражданина (или гражданские организации), а не на само государство.

Из «черного ящика» с замкнутой на себя структурой (имеются только точки поступления данных) мы должны получить интерактивную систему общения власть имущих с народом (имеется интерфейс для двусторонней передачи информации). Эта мысль не нова: в Сети можно найти массу публикаций, в которых обсуждаются возможность и необходимость использования открытого кода в госсекторе (например, в США, Канаде и Германии), а также результаты исследований независимых групп и комиссий, созданных парламентскими и общественными структурами. Исходя из представления о государстве как о поставщике услуг, которые обеспечивают выполнение конституционных прав граждан, авторы отчетов считают: именно информационные системы с открытым кодом способны открыть ИТ-инфраструктуру государственных органов с целью более полного и эффективного использования их услуг.

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

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

  1. Оригинальный (или даже уникальный) формат статистических данных, собранных в результате переписи населения, требует трудоемкого процесса конвертации для составления отчетности. А ведь эти данные необходимо хранить на протяжении многих лет независимо от изменений в ИТ, от морального и физического старения платформ. Однако структуры данных и алгоритмы их сжатия были недостаточно описаны, знания утеряны вместе с исходными текстами, а потому для создания отчетов и переработки результатов переписи понадобились обратное проектирование решения и миграция данных в SQL-совместимую базу.
  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 («тянуть»). Это означает, что потребители (ИТ-службы государственных организаций) должны самостоятельно находить необходимое им программное обеспечение с открытым кодом и включать его в список рассматриваемых платформ. В свою очередь, регламентирующие органы должны продумать стимулы для включения открытого кода в число альтернатив при проведении тендеров. Здесь требуются ясная и четкая политика, однозначно трактуемые правила, которые позволят избежать как игнорирования открытого кода, так и радикализма типа «только открытый код».

***

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

Артак Оганесян (ArtakO@moscow.vdiweb.com) — директор по развитию бизнеса компании Vested Development (Москва).

Поделитесь материалом с коллегами и друзьями