Різні схеми ліцензування програмного забезпечення, передачі прав власності на вихідні тексти або забезпечення доступу до них мають свої переваги і недоліки в контексті кожного проекту. Але в разі державних замовлень приходить думка про можливість застосування саме відкритого коду. 
Чому? Чи не тому, що програми з відкритим кодом умовно безкоштовні і це нам, як платникам податків, має подобатися. Відомо, що ціна ліцензій - не єдина складова вартості рішень, часом доопрацювання і супровід обходяться значно дорожче.
Чи не тому, що відкритий код можна спокійно вивчати і досліджувати до придбання програми, а це дозволяє приймати більш зважені рішення при виборі платформи. З постачальниками можна домовитися, і вони навряд чи відмовлять в передачі версії для тестування, націленого на перевірку безпеки і надійності коду, а також продуктивності і масштабованості. Зовсім не обов'язково мати вихідні тексти, щоб перевірити систему за ключовими критеріями.
Чи не тому, що відкритий код не належить виробнику, а державні мужі, особливо представники силових структур, ревниво ставляться до питань авторства, власності тощо Одна з «заповідей» вільного програмного забезпечення свідчить, що неприпустимо ховати створені рішення під грифом секретності.
Чи не тому, що при наявності доступу до вихідних текстів завжди можна модифікувати їх, виправивши виявлений в ході експлуатації дефект, адаптувати до умов, що змінилися вимогам або доповнити нові функції. Виробники забезпечують різні рівні технічної підтримки - аж до вирішення виявлених проблем протягом 24 годин. До багатьох комерційні пакети входять розвинуті механізми настройки і параметризації, а також вбудовані засоби швидкої розробки.
А тому, що відкритий код в поєднанні з відкритими стандартами і відкритою архітектурою може зробити інформаційний простір країни більш прозорим для громадян.
В якомусь сенсі можна простежити аналогію з CRM (customer relationship management - управління відносинами з клієнтами), тільки в даному випадку customer (клієнт) замінюється на citizen (громадянин). Оскільки eCRM (тобто правління відносинами за допомогою електронних засобів комунікацій) може становити, за оцінками експертів, понад 50% всіх процесів взаємодії, взаємини держави і громадян все більше будуть базуватися на сучасних технологіях. І їх застосування повинно бути націлене саме на громадянина (або цивільні організації), а не на саму державу.
З «чорного ящика» з замкнутої на себе структурою (є тільки точки надходження даних) ми повинні отримати інтерактивну систему спілкування можновладців з народом (такий інтерфейс двосторонньої передачі інформації). Ця думка не нова: в Мережі можна знайти масу публікацій, в яких обговорюються можливість і необхідність використання відкритого коду в держсекторі (наприклад, в США, Канаді та Німеччині), а також результати досліджень незалежних груп і комісій, створених парламентськими і громадськими структурами. Виходячи з уявлення про державу як про постачальника послуг, які забезпечують виконання конституційних прав громадян, автори звітів вважають: саме інформаційні системи з відкритим кодом здатні відкрити ІТ-інфраструктуру державних органів з метою більш повного і ефективного використання їх послуг.
Є ще один аспект, який пов'язаний з поглядом у досить далеке майбутнє: держава має перед суспільством зобов'язання щодо захисту цілісності, конфіденційності та доступності публічній і приватній інформації протягом тривалого часу, в умовах територіальної розподіленості центрів обробки даних і величезних обсягів надходження в них відомостей. Застосування закритого коду, специфічних засобів обробки інформації або зберігання даних в приватних форматах може стати загрозою для самої можливості держави виконувати свої зобов'язання в довгостроковій перспективі. Причинами є залежність від конкретного виробника і пов'язані з ним суб'єктивні (добра воля розробника, кон'юктура ринку) і об'єктивні (фінансова стабільність) фактори.
Наведемо кілька прикладів.
- Оригінальний (або навіть унікальний) формат статистичних даних, зібраних в результаті перепису населення, вимагає трудомісткого процесу конвертації для складання звітності. Але ж ці дані необхідно зберігати протягом багатьох років незалежно від змін в ІТ, від морального і фізичного старіння платформ. Однак структури даних і алгоритми їх стиснення були недостатньо описані, знання загублені разом з вихідними текстами, а тому для створення звітів і переробки результатів перепису знадобилися зворотне проектування рішення і міграція даних в SQL-сумісну базу.
- Алгоритм обробки результатів голосування викликав нарікання, але оскільки програмний продукт був поставлений без вихідних кодів, експертиза ПО виявилася неможливою. В результаті перерахунок був проведений вручну. Наявність вихідних текстів дозволило б погоджувальної комісії запросити експертів для вивчення коду.
- Для збору податкової звітності безпосередньо у юридичних і фізичних осіб їм було запропоновано придбати спеціально розроблену програму для оформлення електронних бланків і їх передачі зі спеціального протоколу до податкових органів. Після досить бурхливих дискусій податківцям довелося погодитися з тим, що компоненти заповнення форм і передачі даних можна отримувати з загальнодоступного Web-сайту безкоштовно. А головне, протокол був замінений на стандартний; це дозволило розробникам фінансових систем автоматично формувати і передавати звітність.
- Для реалізації принципу «єдиного вікна» при реєстрації нових підприємств потрібно взаємодія кількох відомств. За законодавством термін перевірки всіх даних в установчих документах становив п'ять робочих днів, що можна було забезпечити лише за допомогою автоматизованої системи. Проект її розробки провалився через складність інтеграції з різнотипними інформаційними системами, які експлуатуються в різних відомствах. У свою чергу, це було пов'язано з неможливістю отримати якусь інформацію засобами наявних інтеграційних механізмів.
- Реалізація концепції «електронної держави», яке має надати громадянам можливість взаємодіяти з різними гілками влади за допомогою Web-технологій, вимагає заміни сайтів окремих державних органів на Web-портали, що інтегрують різні внутрішні і зовнішні джерела даних (в тому числі що надходять від додатків автоматизації внутрішньої діяльності ).
- Для боротьби з бюрократизацією місцевих органів самоврядування губернатор прийняв рішення відкрити доступ до системи контролю над виконанням завдань громадськості через Web-сайт, на якому повинні відображатися метрики проходження документів. Однак розроблена свого часу за держзамовленням програма формування звітів не дозволяла отримувати їх для подання на сайті, що спричинило за собою трудомістку повторну реалізацію алгоритму агрегації даних.
- Муніципалітет вирішив розмістити інформаційні кіоски в поштових відділеннях та офісах місцевих банків для інформування населення про іпотечній програмі. Добре, що узгодження самої ідеї установки кіосків відбувалося заздалегідь: банки запропонували використовувати власну мережу банкоматів, для чого достатньо було опрацювати загальний стандарт доступу. Вибір був зроблений на користь відкритого коду, що дозволило уникнути проблем з ліцензуванням, передачею прав і т.п.
Більшість прикладів свідчать про те, що проблема полягає скоріше не в адаптації програмного забезпечення, а в можливостях отримання інформації, обміну даними та взаємодії програмних модулів. Іншими словами, вона відноситься до області інтеграції інформаційних систем.
У звіті канадських дослідників (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 ( «тягнути»). Це означає, що споживачі (ІТ-служби державних організацій) повинні самостійно знаходити необхідну їм програмне забезпечення з відкритим кодом і включати його в список розглянутих платформ. У свою чергу, що регламентують органи повинні продумати стимули для включення відкритого коду в число альтернатив при проведенні тендерів. Тут потрібні ясна і чітка політика, однозначно трактуються правила, які дозволять уникнути як ігнорування відкритого коду, так і радикалізму типу «тільки відкритий код».
***
Отже, ось аргументи на користь застосування відкритого коду в проектах автоматизації держсектора: оптимальна вартість комплексних рішень; усунення залежності від конкретного виробника програмного забезпечення; зниження залежності від можливості і термінів усунення дефектів в закритому коді; забезпечення цілісності інформації та процесів її обробки; забезпечення гнучкості при розробці, розширенні і інтеграції додатків; відкритість інформаційних систем для взаємодії із зовнішнім середовищем.
Артак Оганесян ( [email protected] ) - директор з розвитку бізнесу компанії Vested Development (Москва).
Чому?
