Свободное программное обеспечение: к чему приведет "свобода"?
Максим Мамчиц
О том, что послужило столь мощному продвижению СПО в массы, можно только догадываться. Вероятно, причиной этому стал интерес правительства к свободным продуктам, стремление внедрить их в органы государственной власти и тем самым избавиться от оков проприетарных продуктов. А, может быть, на рынке проприетарного софта наступил кризис, который позволил свободному программному обеспечению поднять голову? Или доступность вычислительной техники спровоцировала рост сообщества программистов, поднявших флаг движения СПО? Несомненно, все это стало предпосылками к развитию СПО во всем мире, и сейчас уже можно уверенно говорить, что СПО – это не сказки и не мифы, это свершившееся настоящее и вполне реальное будущее
Сегодня много внимания уделено свободному программному обеспечению (СПО), о нем говорят на всех уровнях: и в правительстве, и в образовании, и в коммерческих организациях. Повсюду проводятся семинары, конференции, на которых рассматриваются различные аспекты использования СПО: от практической реализации тех или иных продуктов до юридических особенностей применения свободных лицензий.
Но давайте заглянем глубже и посмотрим, к чему приведет подобная "свобода" и так ли она необходима для программного обеспечения?
Философия "свободы"
Чтобы понять философию свободы ПО, необходимо ознакомиться с деятельностью Фонда свободного программного обеспечения (англ. 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