Вільне програмне забезпечення: до чого
приведе "свобода"?
Максим
Мамчіц
Про те, що стало настільки потужного
просуванню ВПЗ в маси, можна тільки здогадуватися. Ймовірно, причиною цьому
став інтерес уряду до вільних продуктів, прагнення впровадити їх у
органи державної влади і тим самим позбутися кайданів пропрієтарних
продуктів. А, може бути, на ринку пропрієтарного софта настала криза,
який дозволив вільного програмного забезпечення підняти голову? Або
доступність обчислювальної техніки спровокувала зростання спільноти
програмістів, які підняли прапор руху СПО? Безсумнівно, все це стало
передумовами до розвитку СПО в усьому світі, і зараз вже можна впевнено
говорити, що ВПЗ - це не казки і не міфи, це відбулося сьогодення і
цілком реальне майбутнє
Сьогодні багато уваги приділено вільному
програмного забезпечення (ВПЗ), про нього говорять на всіх рівнях: і в
уряді, і в освіті, і в комерційних організаціях. Всюди
проводяться семінари, конференції, на яких розглядаються різні аспекти
використання ВПЗ: від практичної реалізації тих чи інших продуктів до
юридичних особливостей застосування вільних ліцензій.
Але давайте заглянемо глибше і подивимось, до
чого призведе така "свобода" і чи вона необхідна для
програмного забезпечення?
Філософія "свободи"
Щоб зрозуміти філософію свободи ПЗ,
необхідно ознайомитися з діяльністю Фонду вільного програмного
забезпечення (англ. Free Software Foundation, скорочено FSF) - некомерційною
організації, заснованої у жовтні 1985 Річардом Столлманом для підтримки
руху СПО. На думку прихильників FSF, будь-яке ПЗ повинно володіти чотирма
свобод:
1) програму можна використовувати з будь-якою
метою ( "нульова свобода ");
2) можна вивчати, як програма працює,
і адаптувати її для своїх цілей ( "перша свобода ");
3) можна розповсюджувати копії програми
( "другий свобода ");
4) програму можна покращувати і публікувати
свою поліпшену версію ( "третя свобода ").
У результаті СПО в порівнянні з
пропрієтарним софтом володіє такими перевагами, як:
- висока якість продуктів;
- висока надійність/стабільність;
- безпека;
- висока швидкість розробки;
- доступ до величезного пулу готових
програм;
- локалізація;
- відкриті стандарти;
- незалежність від розробників ...
Повинно мати ... А чи володіє?
Висока якість продуктів
Твердження про те, що продукти СПО
володіють більш високою якістю, ніж їх пропрієтарні аналоги, є,
мабуть, найбільш спірним. Дійсно, а як оцінити якість сучасних
програмних продуктів, що відрізняються високою складністю? Спробуйте-но провести
експертну оцінку якості операційної системи Mandriva Linux і зіставити
отримані результати з результатами такої ж оцінки Windows Vista. І хоча
методики оцінки якості програмних продуктів існують і визначені в
різних стандартах (насамперед це міжнародні стандарти ISO 9000-й
серії), отримати об'єктивну оцінку практично неможливо. І все ж пара
козирів у СПО є: відкритий вихідний код і можливість вибрати як
основи для розробки вже готовий, що зарекомендував себе продукт. Завдяки
доступності вихідного коду процес налагодження програми та виправлення помилок
може здійснюватися не тільки силами розробника, але і всіма користувачами.
Ну а чим менше помилок, тим вища якість! Крім того, код програми стає
більш оптимальним (700 Мб інсталяційного диска можуть містити
"голу" ОС Linux або Windows з чималим пакетом необхідних програм і
утиліт). А взявши в якості основи для розробки якісний продукт, складно
отримати на виході щось погане. От і Mac OS X - операційна система
компанії Apple для комп'ютерів Macintosh базується на FreeBSD - вільної
UNIX-подібної операційної системи.
Висока надійність/стабільність
Питання надійності є не менш
спірним, ніж питання якості, але зате більш простим у визначенні об'єктивної
оцінки. І всього-то треба запастися парою-трійкою однакових комп'ютерів (а
краще серверів), встановити на них випробувані програмні продукти, підключити
до одного джерела живлення, одночасно запустити і з сумним виглядом
фіксувати всі відхилення в роботі. Щоб процес йшов веселіше, можна як
слід навантажити машини, наприклад, розмістивши на них сайт
"одноклассники.ру" і відкривши до нього доступ. На щастя, подібні
дослідження проводяться досить часто на замовлення різних IT-компаній, тому
можна обійтися лише аналізом результатів. Одне з таких досліджень було
проведено компанією Yankee Group. У ході опитування "2008 Server OS
Reliability Survey "(Обстеження надійності серверних ОС-2008) була зібрана
інформація про показники надійності різних серверних систем. У результаті
опитування з'ясувалося, що протягом 2007 і 2008 рр.. Linux-дистрибутиви від Red Hat
і Novell збільшили свою надійність в середньому на 75%. Дослідження показало, що
час простою Windows 2003, тим часом, збільшилася на 25% (до 9 годин на
сервер на рік). Час простою стандартною коробкової версії Red Hat Enterprise
Linux зменшилася на 75% (з 7,1 до 1,75 години).
Безпека
Цей аргумент є, мабуть, найбільш
популярним у прихильників СПО. Втім, розробники пропрієтарного софта теж
на все горло заявляють про високий рівень безпеки своїх продуктів. Так кому
ж довірити збереження своєї інформації? Інтуїція підказує, що довіритися
треба тому, у кого більш прозорі механізми захисту, тобто продуктів з
відкритими вихідними текстами, що базуються на відкритих стандартах. Але ж
інтуїція може і підвести, а жертвувати своєю інформацією не хочеться. На допомогу
приходять численні дослідження, присвячені аналізу уразливості тих або
інших систем, проте не завжди їх можна назвати об'єктивними. Справа в тому, що на
рівень безпеки впливає безліч факторів, і, якщо не врахувати хоча б один
з них, отримати адекватні результати не вдасться.
Одне з досліджень безпеки
операційних систем сімейства Windows і * nixподобних ОС було проведено
Ніколасом Петрелі (Nicholas Petreley) в 2004 р. В якості критеріїв оцінки були
вибрані наступні:
- серйозність вразливостей в системі
безпеки;
- кількість вразливостей, серйозність
яких визначається як "критична". Результат: 38% критичних
вразливостей Windows Server 2003 проти 10% Red Hat Linux. Звичайно, пройшло вже 4
року, протягом яких з'явилися нові операційні системи, що мають більш
ефективною системою безпеки, але незмінним залишився підхід до вирішення
завдання забезпечення безпеки у вільних продуктах (відкриті стандарти,
система поділу повноважень, безпечне адміністрування з консолі,
модульність системи) і пропрієтарних (закриті стандарти, монолітність систем,
як правило, графічний інтерфейс адміністрування). Однак не час робити
поспішні висновки і приступати до роздачі рад, нехай це буде справою суто
кожного.
Висока швидкість розробки
"Базарна" модель розробки ядра Linux, по суті, стала
революційної, і в даний час більшість продуктів СПО розробляються
саме на цій моделі. Найбільш докладно ця модель описана у творі
Еріка Стівена Реймонда (один із засновників організації Open Source Initiative
- Ініціатива відкритих ресурсів) "Собор і базар". Суть
"базарної" моделі полягає в тому, що завдяки відкритості і
безперешкодному поширенню розробляється програми створюється
спільнота програмістів, що може стати величезною силою, збільшивши швидкість
розробки програми. При розробці закритих продуктів така міць, як
правило, недоступна або обходиться дуже дорого.
Проте тут є один підводний камінь --
"закон Брукса", який свідчить, що привнесення в проект нових сил на
пізніх стадіях розробки лише відсуває термін здачі проекту ( "Міфічна
людино-місяць, або Як створюються програмні системи ", Фредерік Брукс, 1975 р.). Іншими словами,
збільшення спільноти програмістів не завжди приводить до збільшення швидкості
розробки, а іноді може і погубити весь проект. Фредерік Брукс пояснював це
тим, що більша кількість людей складніше організовувати, збільшується час
взаємодії розробників між собою, що призводить до скорочення корисного
часу на розробку. До того ж нових, щойно залучених програмістів
необхідно навчити і ввести їх в курс справи.
Проаналізувавши всі "за" і
"проти" цієї моделі, можна прийти до наступного висновку: дана
модель має істотні обмеження у застосуванні, для деяких проектів
краще використовувати класичну модель розробки ПЗ, а значить, швидкість
розробки СПО не завжди вища за швидкість розробки пропрієтарного софта.
Локалізація
На Землі налічується близько 5-6 тисяч
різних мов і діалектів. Інтерфейс програми може відображатися тільки на
одному ... Який вибрати? Цілком природно, що розробник пише графічний
інтерфейс користувача на тій мові, яким володіє він сам. Крім цього
розробник може включити підтримку тих мов, які йому допоможуть
поширити свій продукт в інших країнах і тим самим забезпечити достатню
кількість користувачів. Але що робити, якщо розробник не включив підтримку
вашого рідної мови, а вам дуже хочеться використовувати його програму? Відповідь
один: локалізувати програму силами програмістів і перекладачів своєї країни.
Ось тут і проявляється перевага СПО: локалізувати вільний продукт набагато
простіше з технічної і юридичної точки зору, ніж локалізувати пропріетарний
софт. Як наслідок, ВПЗ має більш широку географію, ніж закрите ПЗ.
Відкриті стандарти
Однією з особливостей СПО є те,
що воно майже завжди використовує відкриті стандарти. Що це дає пересічному
користувачеві? Як правило, існує кілька програмних продуктів,
що використовують будь-який відкритий стандарт. Це дозволяє змінити набір
програмних продуктів без негативних наслідків. Як приклад можна
привести Rich Text Format (RTF, "формат збагаченого тексту" --
вільний міжплатформову формат зберігання розмічених текстових документів).
Даний формат підтримують практично всі текстові редактори (Word, WordPad,
AbiWord, Open-Office.org, TextEdit). У той же час корпорація Microsoft
використовує закриті донедавна формати збереження даних для свого
пакету офісних додатків (. doc,. xls,. ppt). Правильна робота з даними в
цих форматах можлива тільки за допомогою продуктів Microsoft. Таким
чином, при переході на інший набір програм постає проблема конвертації всій
інформації з одного формату в іншій, а це не завжди представляється
можливим. Використання відкритих стандартів дозволяє уникнути подібної
проблеми.
Висновок
Очевидно, що СПО володіє своїми плюсами
і мінусами. Ніщо не ідеально в цьому світі і в світі програмного забезпечення в
Зокрема, а отже, не існує єдиного конкретного рішення всіх проблем.
Тому вибирати вільне ПЗ або пропрієтарне - справа суто кожного. Критерій
може бути тільки одна: завдання повинно бути вирішено максимально ефективно.
Однак СПО все більше і більше претендує на роль основного інструменту для
вирішення завдань, і це не може не радувати. -
***
Доступ до величезного пулу готових програм
СПО розповсюджується під різними ліцензіями. Найвідомішою є GNU
(General Public License - Універсальна загальнодоступна ліцензія). Одне з
обов'язкових умов цієї ліцензії - доступність початкового коду програми.
Також доступним повинен стати вихідний код програми, розробленої з
використанням коду, яке розповсюджується за ліцензією GPL. Таким чином,
формуються репозиторії з вільними програмами, що знаходяться у відкритому
доступі. Слід зазначити, що не всі вільні ліцензії вимагають розміщення в
відкритому доступі похідних програмних продуктів, однак репозиторії кожен
день поповнюються новими програмами. І все це "багатство" доступно
програмістам для створення своїх продуктів, а значить, не треба заново винаходити
колесо, а можна взяти готовий програмний модуль. Як далеко зробила крок би вперед
програмна індустрія, якби Microsoft відкрила код своєї
"операційки "...
***
Незалежність від розробників Життєвий
цикл будь-якого ПО включає в себе не тільки етапи розробки та використання ПЗ,
а й етапи супроводу і модернізації. Дуже часто на етапах супроводу і
модернізації вкладається більше коштів, ніж на етапі розробки.
Таким чином, вибір організації, що займається супроводом ПЗ, повинен
проводитися також з урахуванням економічної ефективності. У випадку з
пропрієтарним ПО все просто: вихідний код закритий, а значить, супроводжувати його
може тільки сам розробник, який в даному випадку буде монополістом з
великим апетитом. СПО дозволяє вибрати для супроводу програми не тільки
розробника, а й будь-яку іншу організацію, якій під силу розібратися в
вихідному коді. З'являється вільна конкуренція, яка призводить до зниження
витрат.
Список літератури
Information Security № 1, лютий-березень
2009
