закрытый исходный код что это
Открытый или закрытый исходный код скрипта, в чем разница?
Доброго времени, мои уважаемые читатели! Сегодня я немного расскажу о разнице открытого и закрытого кода программного обеспечения(ПО) и как это может отражаться на работе предпринимателей, которые покупают ПО для организации своих бизнес процессов. Несмотря на то, что предприниматель редко задается таким вопросом, этот момент не стоит упускать из виду, т.к. он может оказаться ключевым при возникновении потребности внести изменения в работу программного обеспечения.
В качестве вступления приведу небольшой пример истории из жизни. Предприниматель Екатерина Сергеевна, приобрела программное обеспечения для создания на его безе интернет магазина, на момент покупки Екатерину Сергеевну устраивало практически все, что касалось функционала приобретаемого ПО. В течении нескольких дней был запущен сайт, затем на протяжении месяца сайт наполнялся полезными статьями, писался раздел справки и помощи, активно добавлялись товары. Параллельно с этим была развернута рекламная компания, по привлечению клиентов в интернет магазин. Спустя 6 месяцев, сайт начал приносить доход, и перед предпринимателем встал вопрос о его улучшении, внесении ряда правок, чтобы сделать работу сайта лучше и эффективнее. Екатерина Сергеевна, обратилась к разработчику ПО, собственно у кого оно и было куплено. Но, как оказалось разработчик в данный момент занят, и не может заняться её проектом. Тогда, Екатерина обратилась к стороннему программисту, найти которого не составило большого труда. Подготовила подробный список того, что хочет изменить в своем сайте, и договорилась с ним, о начале работ. Но каково было удивление Екатерины, услышать от программиста ответ: «Я не могу реализовать ваши пожелания, т.к. исходный код ПО закрыт, я не имею к нему доступа». Работа встала.
Я очень часто наблюдаю такие ситуации, когда программа требует внесения доработок, а сделать этого нельзя, из-за того, что исходный код закрыт. Само понятие «закрытый исходный код» носит двусмысленный характер, оно может означать что:
1) код закрыт(скомпилирован, зашифрован, обфусцирован) и его нельзя посмотреть, а следовательно нельзя внести правки, изменения, дополнения;
2) код закрыт согласно лицензионному соглашению, такой код нельзя модифицировать(запрещено правообладателем) даже в том случае, если технически это возможно.
На фоне вышесказанного, возникает вопрос: кто может вносить изменения в работу такого программного обеспечения? Ответ — только разработчик, и то если пожелает, или вы сможете с ним договориться.
В свою очередь, открытый исходный код, лишен всех этих недостатков. Он может быть просмотрен, изменен, доработан и так далее, как правило лицензия по которой распространяется такое программное обеспечении разрешает пользователю модифицировать его любым образом, и если носит какие-то ограничения, то они как правило связаны с распространением его(программного обеспечения) копий.
Возвращаясь к истории предпринимателя Екатерины Сергеевны, в её случае решить возникшую задачу так и не получилось. Спустя год работы её сайта, накопилось очень большое количество изменений, которые требовалось внести в скрипты. Во первых её бизнес вырос, количество клиентов перевалило за несколько тысяч, и встал вопрос о добавлении на сайт различных сервисов: «расчет стоимости доставки», «личный кабинет», «отложенные товары» и т.д. Разработчик так и не смог выделить время на то, что-бы поработать с Екатериной (впрочем его винить за это не стоит, он изначально не оказывал услуг по доработкам, плюс ко всему таких запросов ему поступает ежедневно по несколько штук и он физически не способен их все удовлетворить), а сторонние программисты просто бессильны в данной ситуации. В итоге Екатерина приняла решение, полностью переделать весь сайт и в качестве платформы использовать уже ПО с открытым исходным кодом, это был её основной критерий к покупаемому продукту. Какие издержки она при этом понесла: покупка нового ПО, расходы по переносу базы клиентов, товаров, прочих материалов, работа по сохранению адресов страниц(что-бы не выпасть из индекса ПС) для сохранения позиций в поисковых системах, плюс её сайт простаивал некое время, и она также упустила часть выгод от возможных продаж. Все это обошлось её в крупную денежную сумму, потраченное время и нервы.
Данная история, это случай из жизни, из моей практики. Екатерина обратилась ко мне и мы славно поработали, впрочем еще многое предстоит сделать, ведь в голову постоянно приходят новые идеи, которые способствуют росту её бизнеса.
Что лучше открытое или закрытое ПО?
Однозначного ответа на этот вопрос нет, в ряде случаев закрытое ПО не чем не хуже открытого. Оно выполняет поставленные задачи, обеспечивая пользователя хорошим функционалом, таких примеров много iOS, Windows, MS Office и т.д. Но если речь идет о бизнесе, который зависит от ПО, и который со временем будет расти требуя внедрения новых идей, выбор однозначно падает на программное обеспечение с открытым исходным кодом!
Закрытый исходный код
Закрытый исходный код — программа, лицензия которой не подходит под определение открытого ПО. Как правило, это означает, что распространяются только бинарные (откомпилированные) версии программы и лицензия подразумевает отсутствие доступа к исходному коду программы, что затрудняет создание модификаций программы. Доступ к исходному коду третьим лицам обычно предоставляется при подписании соглашения о неразглашении.
ПО с закрытым исходным кодом является проприетарным (собственническим) ПО.
Двусмысленность
Фраза «Закрытый исходный код» двусмысленна, так как она может подразумевать лицензии, в которых исходный код программ недоступен. Однако если считать её антонимом открытого кода, то она относится к программному обеспечению, не подходящему под определение лицензии открытого ПО, что имеет несколько другой смысл.
Лицензия Microsoft Shared source — пример лицензии, при которой доступен исходный код, но не под открытой лицензией. Если закрытый исходный код понимать как ПО, не подходящее под определение открытого ПО, то Shared source — пример лицензии закрытого исходного кода. Но если подразумевать под ним только те программы, исходный код которых недоступен, то это не так.
См. также
Полезное
Смотреть что такое «Закрытый исходный код» в других словарях:
Закрытый код — Проприетарное, частное или собственническое программное обеспечение (англ. proprietary software) программное обеспечение, являющееся частной собственностью авторов или правообладателей и не удовлетворяющее критериям свободы ПО (речь именно о… … Википедия
Warp4 — OS/2 Warp Разработчик Microsoft Семейство ОС OS/2 Исходный код Закрытый исходный код Последняя версия 4.52 декабрь 2001 Тип ядра модульное Интерфейс графический Л … Википедия
Warp 3 — OS/2 Warp Разработчик Microsoft Семейство ОС OS/2 Исходный код Закрытый исходный код Последняя версия 4.52 декабрь 2001 Тип ядра модульное Интерфейс графический Л … Википедия
Warp3 — OS/2 Warp Разработчик Microsoft Семейство ОС OS/2 Исходный код Закрытый исходный код Последняя версия 4.52 декабрь 2001 Тип ядра модульное Интерфейс графический Л … Википедия
Warp5 — OS/2 Warp Разработчик Microsoft Семейство ОС OS/2 Исходный код Закрытый исходный код Последняя версия 4.52 декабрь 2001 Тип ядра модульное Интерфейс графический Л … Википедия
Warp 4 — OS/2 Warp Разработчик Microsoft Семейство ОС OS/2 Исходный код Закрытый исходный код Последняя версия 4.52 декабрь 2001 Тип ядра модульное Интерфейс графический Л … Википедия
Миранда (IM) — Miranda IM Тип Программа мгновенного обмена сообщениями Разработчик Miranda IM Project Написана на C/C++ ОС Microsoft Windows … Википедия
Миранда IM — Miranda IM Тип Программа мгновенного обмена сообщениями Разработчик Miranda IM Project Написана на C/C++ ОС Microsoft Windows … Википедия
Миранда АйЭм — Miranda IM Тип Программа мгновенного обмена сообщениями Разработчик Miranda IM Project Написана на C/C++ ОС Microsoft Windows … Википедия
ОС/2 — OS/2 Warp Разработчик Microsoft Семейство ОС OS/2 Исходный код Закрытый исходный код Последняя версия 4.52 декабрь 2001 Тип ядра модульное Интерфейс графический Л … Википедия
Закрытый код
Проприета́рное, частное или собственническое программное обеспечение (англ. proprietary software ) — программное обеспечение, являющееся частной собственностью авторов или правообладателей и не удовлетворяющее критериям свободы ПО (речь именно о свободе, а не просто открытости ПО) и, с позиции Фонда свободного ПО, при этом не являющееся полусвободным ПО. Правообладатель сохраняет за собой монополию на его использование, копирование и модификацию, полностью или в существенных моментах. Часто проприетарным называют любое несвободное ПО, включая полусвободное.
Не следует путать с проприетарным коммерческое программное обеспечение, которое может быть и свободным. [1]
Содержание
Термин «проприетарное программное обеспечение» используется Фондом свободного ПО для определения программного обеспечения, которое с позиции Фонда не является свободным или полусвободным. [2] Технически, слова «собственническое» и англ. proprietary обозначают программное обеспечение, которое имеет собственника, который осуществляет контроль над ПО. Таким образом, этот термин может быть использован ко всему программному обеспечению, которое не находится в общественном использовании. Однако слово «proprietary» иногда используется в рекламе как положительное владельцами монопольных прав на что-нибудь. Так и Фонд Свободного Программного Обеспечения использует термин для выделения того, что собственник является основным фактором, в контрасте со свободным ПО, где этим фактором является свобода компьютерных пользователей.
Полусвободное ПО
Несвободное ПО, которое разрешает практически неограниченное использование, распространение и изменение (в том числе с распространением изменённых версий) ПО в некоммерческих целях, Фонд СПО называет полусвободным. [2] Как и Open Source Initiative и [2]
Средства ограничений
Предотвращение использования, копирования или модификации могут быть достигнуты правовыми или техническими средствами.
Технические средства включают в себя выпуск только машинно-читаемых двоичных файлов, ограничение доступа к читаемому человеком исходному коду (закрытый исходный код), затруднение использования собственноручно сделанных копий. Доступ к закрытому коду обычно имеют сотрудники компании-разработчика, но могут применяться и более гибкие условия ограничения доступа, в которых предоставление исходного кода разрешено партнёрам компании, техническим аудиторам или другим лицам в соответствии с политикой компании.
Правовые средства могут включать в себя коммерческую тайну, авторское право и патенты.
Типичные ограничения проприетарного ПО
Существует большое количество различных бизнес-моделей, и компании, занимающиеся разработкой проприетарного программного обеспечения, составляют собственные лицензионные соглашения в соответствии с ними. Наиболее типичные ограничения проприетарного ПО приведены ниже.
Ограничение на коммерческое использование
Существует огромное количество программных продуктов, разрешающих техническую поддержку со стороны специалистов, у которых отсутствует необходимость дополнительных затрат на обучение.
Если это — единственное значительное ограничение данного ПО, Фонд СПО считает это ПО полусвободным.
Ограничение на распространение
Этот вид ограничений сопровождает обычно крупные программные проекты, когда правообладатель требует оплаты за каждую копию программы. Обычно с таким ограничением используются программные продукты, ориентированные на узкий «профессиональный» сегмент рынка или у программного обеспечения, требующегося большому числу пользователей. Примером может служить пакет программ Adobe CS3 или операционная система Microsoft Windows XP.
Ограничение на модификацию
Этот вид ограничения используется только в программных пакетах с закрытыми исходными кодами и может запрещать или ограничивать любую модификацию программного кода, дизассемблирование и декомпиляцию.
Проприетарные форматы
Примечания
См. также
Полезное
Смотреть что такое «Закрытый код» в других словарях:
Код да Винчи (фильм) — Код да Винчи The Da Vinci Code Жанр триллер … Википедия
Код Да Винчи (фильм) — Код да Винчи The Da Vinci Code Жанр триллер Режиссёр Рон Ховард Автор сценария Акива Голдсман … Википедия
Закрытый исходный код — В этой статье не хватает ссылок на источники информации. Информация должна быть проверяема, иначе она может быть поставлена под сомнение и удалена. Вы можете … Википедия
Код аутентичности — MAC (имитовставка, англ. message authentication code код аутентичности сообщения) средство обеспечения имитозащиты в протоколах аутентификации сообщений с доверяющими друг другу участниками специальный набор символов, который добавляется к… … Википедия
Код аутентичности сообщения — MAC (имитовставка, англ. message authentication code код аутентичности сообщения) средство обеспечения имитозащиты в протоколах аутентификации сообщений с доверяющими друг другу участниками специальный набор символов, который добавляется к… … Википедия
ПЕРСОНАЛЬНЫЙ ИДЕНТИФИКАЦИОННЫЙ НОМЕР, ПИН — (англ. Personal Identification Number, PIN) – передаваемый банком эмитентом держателю платежной карты идентификационный секретный код (пароль). Применяется при совершении операции с картой и служит подтверждением того, что операция выполняется… … Финансово-кредитный энциклопедический словарь
Список свободных игр — Основная статья: Свободные игры Это список игр, исходный код которых является свободным программным обеспечением. Он включает несколько типов свободных игр: изначально выпущенных как свободные (free software) и бывших платных, код для которых был … Википедия
Android — У этого термина существуют и другие значения, см. Андроид (значения). Android … Википедия
Windows «Vienna» — Windows 7 Вид рабочего стола Windows 7 RC build 7100 Разработчик Семейство ОС Windows NT Исходный код Закрытый код Первый выпуск 22 октября … Википедия
Программное обеспечение с закрытым исходным кодом (closed source software, проприетарное ПО)
Программное обеспечение с закрытым исходным кодом (closed source software, проприетарное ПО) — это ПО, все права на использование, изменение и копирование которого принадлежат его автору. В общем случае к программам с закрытым исходным кодом относят все разработки, не удовлетворяющие требованиям к свободному ПО.
Ограничения ПО с закрытым кодом
Авторы проприетарных программных продуктов контролируют доступ к исходному коду своих программ. Обычно такие разработки поставляются исключительно в виде исполняемых двоичных файлов и скомпилированных библиотек.
Как правило, лицензионное соглашение программы с закрытым кодом содержит положения, запрещающие ее декомпиляцию, а также любое изменение исходного кода.
Недоступность исходного кода — распространенное, но не обязательное свойство проприетарного программного обеспечения. В ряде случаев код может быть полностью или частично доступен, но его использование без разрешения автора будет неправомерным.
Владелец проприетарного ПО может:
Законодательство большинства стран предполагает проприетарность программного обеспечения по умолчанию. Создавая программу, ее автор автоматически получает полные права на ее распространение, модификацию и использование. При этом полный или частичный отказ от таких прав, напротив, должен быть подтвержден документально.
В противовес этому во многих случаях открытое ПО, в том числе и распространенные библиотеки, выпускаются по лицензии, которая обязывает делать любые продукты, использующие компоненты этого ПО, также открытыми. Это, например, не позволяет создавать ПО с закрытым кодом на базе Linux.
Публикации на схожие темы
Свободное железо — не панацея
TrueCrypt: необъяснимое исчезновение
Удаленные знакомства: кому мы доверяем свои данные
Уязвимость нулевого дня в диспетчере окон рабочего стола (CVE-2021-28310)
Дорога к «интернету вещей»: преимущества и риски смарт-езды
Надежность и безопасность: открытый код против закрытого
Выпуск программного обеспечения с открытым кодом стал одним из важнейших ИТ-направлений. Но по мере роста популярности открытых систем все острее встают вопросы их надежности и безопасности.
Изначально системы с открытым кодом были результатом свободного сотрудничества программистов-добровольцев. Законченные системы выпускались в свет, и любой мог их использовать без внесения лицензионной платы. Поддержка этих систем также осуществлялась добровольцами с помощью списков рассылки и Web-сайтов. Сегодня, однако, над многими открытыми системами трудятся профессионалы, разработки осуществляют оплачиваемые программисты, а поддержка системы может осуществляться как на бесплатной, так и на платной основе.
Традиционные частные системы создаются крупными коллективами, состоящими из разработчиков, менеджеров, программистов, технических писателей и инженеров по проверке качества. Такие системы обычно подвергаются многочисленным ревизиям и официальным проверкам. В законченном виде они представляют собой потребительские товары, которые продаются или лицензируются для массового платного использования. Поддержка программного продукта обычно обеспечивается разработчиком.
Какая модель лучше с точки зрения надежности и безопасности? Каждая из них имеет сторонников, выражающих свои мнения в многочисленных публикациях. Рассмотрим аргументы, представленные в этих публикациях, а также показатели надежности и безопасности открытых и частных систем.
Надежность и безопасность открытых и частных систем
Сегодня горячо обсуждаются надежность и безопасность открытых систем. Частные поставщики финансируют исследования и публикуют отчеты, свидетельствующие о том, что системы с закрытым кодом безопаснее их открытых аналогов. Но на каждый отчет, восхваляющий превосходство частных систем в этом отношении, открытое сообщество отвечает «опровергающим» отчетом. Возможно, основная причина горячих дебатов состоит в том, что широкое распространение открытой модели угрожает доходам поставщиков частного программного обеспечения. В недавних квартальных отчетах для Комиссии по ценным бумагам и биржам США компания Microsoft, один из крупнейших производителей ПО, заявила, что популяризация и распространение открытых систем представляют собой существенную угрозу ее бизнес-модели [1].
Неудивительно, что поставщики частного ПО пытаются дискредитировать открытые системы. Причем споры о безопасности и надежности открытого и частного программного обеспечения обычно сводятся к двум ключевым темам: доступность исходного кода и уровни дефектности ПО. Обсудим эти проблемы.
Доступность исходного кода
В июне 2002 года институт Alexis de Tocqueville Institution, частично финансировавшийся Microsoft, опубликовал работу [2]. Среди самых спорных ее результатов был вывод о том, что в госучреждениях использование программного обеспечения с открытым кодом по лицензии GPL (General Public License) может стать проблемой для национальной безопасности. Основанием для этого вывода стало такое предположение: общедоступность исходного кода провоцирует хакеров к исследованию его уязвимостей, разработке «троянских коней» и других типов вредоносных программ. Доступность исходного кода была представлена как существенная угроза для безопасности госорганизаций, применяющих открытое ПО.
Такой вывод далеко не бесспорен. Подразумевается, что частные системы с закрытым исходным кодом автоматически более безопасны (для них характерна так называемая «безопасность благодаря непостижимости»). Если это так, число выявленных уязвимостей в закрытых системах должно быть значительно меньшим, чем в открытых аналогах. Однако по опубликованным данным множество открытых систем имеют существенно более низкие рейтинги уязвимостей, чем их частные аналоги. Например, по сведениям координационного центра по безопасности CERT Coordination Center (www.cert.org), в Web-сервере с открытым кодом Apache HTTP Server (httpd.apache.org) обнаружено существенно меньше уязвимостей, чем в Microsoft Internet Information Server, и лишь немногим больше, чем в Netscape Enterprise Server.
Сокрытие исходного кода не ведет к повышению уровня защищенности системы. Злоумышленники не нуждаются в исходном коде для обнаружения дефектов ПО. Например, распространенный способ поиска дефектов состоит в том, чтобы послать программе неожиданные или необычные данные, а затем пронаблюдать за реакцией системы [3]. Если она отказывает или при обработке таких данных ведет себя нештатно, это может указывать на недостаток, заслуживающий дальнейшего исследования.
С распространением изощренных инструментальных средств мониторинга, отладки и дизассемблирования большая часть исходного кода может быть получена из двоичной версии исполняемой программы. Любой, кто заинтересован в получении исходного кода, просто должен применить к программе один из широко доступных инструментов. Выходные данные таких инструментов, хотя и не совсем совершенные, дают достаточно информации для получения представления о внутреннем устройстве системы. Кроме того, часто происходит непреднамеренная утечка исходного кода, а производители отдают разработку программ на аутсорсинг или по целому ряду причин обмениваются исходными кодами с другими организациями.
Есть, конечно, и примеры небезопасности открытых систем. Программные дефекты в открытой почтовой программе sendmail были любимой мишенью для нападок в течение многих лет. В ноябре 1988 года студент Корнельского университета Роберт Моррис создал первый Internet-червь [4]. Отчасти из-за уязвимостей в программах sendmail и fingerd он быстро распространился по Internet и привел к массовым отказам компьютеров. Согласно одному из отчетов, червь Морриса затронул 6 тыс. из 60 тыс. (10%) систем Internet, причем Моррис обнаружил эти уязвимости при анализе исходного кода программ sendmail и finger. Однако та же доступность исходного кода позволила Internet-сообществу быстро среагировать на угрозу и смягчить ее последствия. В [5] отмечается: «Доступность исходного кода очень важна. Все стороны, которые быстро откликнулись и достигли успеха в понимании природы вируса, имели исходный код Unix».
Доступность исходного кода — палка о двух концах. Сообщество хакеров может использовать анализ кода для поиска уязвимостей. В свою очередь, сообщество разработчиков способно поддерживать и улучшать код, применять формализованные методологии испытаний, чтобы обнаруживать и исправлять дефекты программного обеспечения прежде, чем ими смогут воспользоваться злоумышленники. Сообщество пользователей может задействовать исходный код для обнаружения и предотвращения атак, причем после выявления недостатков удается быстро устранять уязвимости и публиковать исправления. Имея дело с закрытой системой, потребители полностью зависят от способности поставщика быстро обнаруживать уязвимости, разрабатывать и рассылать исправления.
В данном случае различие между широко распространенными открытыми системами и их частными аналогами проявляется в ценности применения исходного кода при ответе на угрозы. Наличие исходного кода оказалось критически важным для системных администраторов при борьбе с червем Морриса в 1988 году. Технические специалисты рассмотрели исходный код атакованных систем, нашли уязвимости и разработали меры защиты против конкретной угрозы и будущих нападений. Преимущество обладания исходным кодом было подчеркнуто в отчете корпорации MITRE [6], опубликованном в июле 2001 года. В нем утверждалось, что в открытом сообществе «популярные продукты с открытым кодом подвергаются обширной экспертизе, позволяющей программному обеспечению достичь высокого уровня эффективности» и что программные заплаты и исправления выпускаются «потенциально на порядок быстрее, чем в случае частного программного обеспечения».
Уровни дефектности
Любой пакет программ, открытый или закрытый, имеет множество недостатков, и их процент непосредственно влияет на безопасность системы. По данным Software Engineering Institute, опытный программист «пропускает» приблизительно один дефект на 100 строк кода [7]. Если в течение жизненного цикла программного обеспечения 99% этих дефектов будут обнаружены и исправлены, то в пакете программ, состоящем из 1 млн. строк исходного кода (довольно скромный объем по современным стандартам), останется примерно 1 тыс. дефектов.
Например, дистрибутив Red Hat Linux 7.1 состоит приблизительно из 30 млн. строк кода, а Microsoft Windows XP содержит около 40 млн. строк. Даже с учетом обширных испытаний и работы по устранению недостатков в этих системах все еще остается масса программных дефектов. Используя упомянутую статистику, число невыявленных дефектов в Windows XP и Red Hat Linux можно оценить, соответственно, как 40 тыс. и 30 тыс. Кроме того, частные и открытые системы постоянно развиваются. В ходе жизненного цикла в систему добавляются новые функции, а дефекты обнаруживаются и устраняются. А поскольку большинство программных пакетов находятся в состоянии постоянного развития, трудно оценить число дефектов конкретной системы.
Программные дефекты — неизбежная проблема, которая может снизить надежность системы, а соответственно, и ее общую безопасность. Надежность и безопасность неразрывно связаны между собой.
Итак, каждый выпуск открытой или частной программы содержит множество дефектов. Имеющиеся данные, однако, показывают, что когда недостаток программного обеспечения обнаружен, открытое сообщество реагирует быстрее, чем частные поставщики. Согласно [8], открытые организации обычно реагируют на проблемы быстро и откровенно, тогда как частные поставщики «инстинктивно тянут, скрывают и отрицают». Открытые организации вносят небольшие поправки, которые становятся общедоступными через списки рассылок и Web-сайты. Пользователи могут загрузить обновление, применить заплату и восстановить систему. Сама заплата, в свою очередь, является сегментом исходного кода, который доступен для публичной ревизии. Напротив, частные поставщики стремятся выжидать и выпускать большие сводные пакеты обновлений. Они обычно содержат только двоичный код, который закрыт для публичного исследования и потенциально может внести в систему новые проблемы. При этом пользователям приходится слепо доверять честности и компетентности производителя.
Независимые исследования
Если открытое сообщество легче откликается на программные дефекты, то можно заключить, что открытые продукты должны иметь в среднем более высокую надежность, чем их частные аналоги. Хотя каждая из сторон спора по проблемам открытого кода приводит в поддержку своей точки зрения самые убедительные свидетельства, авторы некоторых независимых исследований отдают предпочтение именно популярным открытым системам.
В 1990 году профессор Бартон Миллер из Университета штата Висконсин разработал инструмент тестирования fuzz, который подавал случайные потоки данных на вход программ из нескольких частных версий Unix [3]. Миллер обнаружил, что 24-33% программ отказали под воздействием этих данных, и каждый из отказов мог быть непосредственно отнесен к программному дефекту. Правильно написанная программа не должна выходить из строя при получении неожиданных или случайных данных.
В 1995 году Миллер включил в испытания также утилиты Linux и другие свободно доступные программы из проекта GNU. Он протестировал свыше 80 утилит из девяти версий Unix. Семь из них принадлежали частным поставщикам, а две были разработаны открытым сообществом. Основные результаты исследования, опубликованные в [9], свидетельствуют о следующем. С момента первого исследования частные системы улучшились, и коэффициент их отказов снизился с 24-33 до 18-23%. В открытых системах утилиты Linux заняли второе место с коэффициентом отказов примерно 9%. Самым низким был коэффициент отказов утилит GNU, который составил 6%. Итак, популярные открытые реализации утилит Unix существенно более устойчивы к неожиданным данным, чем их частные аналоги, что указывает на более высокие качество и надежность утилит с открытым кодом. Нельзя сказать, что все открытые системы надежнее частных, но они могут быть качественнее коммерческих разработок.
В другом исследовании, предпринятом в 1999 году независимой консультационной и аналитической организацией Bloor Research из Великобритании, сравнивались Windows NT и GNU/Linux [10]. Испытание проводилось в течение года, и каждая из платформ оценивалась по девяти критериям. GNU/Linux была оценена выше, чем Windows NT, по семи критериям.
Так, по критерию готовности ОС GNU/Linux получила значительно более высокую оценку, чем Windows NT. За год GNU/Linux не продемонстрировала ни одного отказа, который можно отнести на счет программного обеспечения. Однако аппаратный отказ из-за сбоя жесткого диска послужил причиной отключения системы, которое продолжалось четыре часа. Итоговый коэффициент готовности GNU/Linux составил 99,95%. За тот же период система Windows NT «выдала» 68 отказов: один был отказом жесткого диска, 26 были связаны с ошибками управления памятью, восемь относились к ошибкам файловой системы, а остальные имели неизвестное происхождение. Потери времени из-за этих отказов составили 65 часов, что дало коэффициент готовности Windows NT, равный 99,26%. Результаты исследования убедительно показывают, что открытые системы могут по меньшей мере на равных конкурировать с частными аналогами, обеспечивая устойчивые и надежные серверные платформы.
Сегодня несколько компаний предлагают услуги проверки программного обеспечения, что позволяет производителям отдавать проверку кода на аутсорсинг. Фирма Reasoning почти 20 лет помогает организациям улучшать качество систем путем автоматизированной проверки программного обеспечения и считается лидером в этой области. В 2003 году Reasoning провела исследование реализации протокола TCP/IP в ядре Linux версии 2.4.19 и в пяти частных операционных системах [11]. Цель состояла в применении автоматизированных методов проверки кода для сравнения качества и уровней дефектности разных реализаций протокола. Выяснилось, что коэффициент дефектности для кода Linux составлял 0,1 дефекта на 1 тыс. строк кода, а для частных реализаций — 0,55. Reasoning пришла к выводу, что открытая реализация TCP/IP имеет значительно меньшую плотность дефектов, чем реализации в пяти частных операционных системах. Исследование также показало, что по общему качеству открытая система находится в первой трети списка рассмотренных проектов.
В июле 2003 года Reasoning проанализировала популярный открытый Web-сервер Apache [12], разработанный и поддерживаемый некоммерческой корпорацией Apache Software Foundation (www.apache.org). По данным Netcraft [13], сейчас Apache является доминирующим HTTP-сервером в Internet. В июне 2004 года он занимал 67% рынка, составлявшего 51,6 млн. серверов, а на долю продуктов Microsoft приходился 21%. Если столь много организаций полагаются на открытые технологии при организации своих Internet-представительств, то очевидно, что ИТ-администраторам был бы полезен независимый от поставщика показатель качества ПО, помогающий при выборе между открытыми и частными системами. Reasoning пришла к выводу, что коэффициент дефектности Apache версии 2.1 составляет 0,53 на 1 тыс. строк кода. В Reasoning сравнили плотность дефектов Apache с 200 другими открытыми и частными программами общим объемом 33 млн. строк кода. В первой трети списка этих проектов коэффициент дефектности был менее 0,36, во второй трети — от 0,36 до 0,71, а в последней трети — более 0,71. Коэффициент дефектности системы Apache попадает примерно в середину списка и несколько превосходит средний коэффициент дефектности частного программного обеспечения (по оценкам Reasoning, он составляет 0,51).
Reasoning продолжила исследования качества открытых систем на примере исходного кода ведущей открытой СУБД MySQL версии 4.0.16 [14]. В декабре 2003 года в Reasoning проверили 236 тыс. строк исходного кода MySQL и обнаружили в системе 21 программный дефект. Качество кода MySQL оказалось в шесть раз выше, чем в среднем у сопоставимого частного кода (коэффициенты дефектности, соответственно, 0,09 и 0,51). Разработчики MySQL быстро устранили обнаруженные проблемы и выпустили версию 4.0.17.
Эти исследования показывают, что по качеству открытые системы могут превосходить частные аналоги. Кроме того, исследования Reasoning касались лишь дефектов исходного кода, но не затрагивали столь важные аспекты, как удобство применения, совместимость, функциональные возможности и эксплуатационные затраты, которые нужно рассматривать в процессе принятия решения о развертывании системы. Исследования Reasoning показали, что открытые системы являются жизнеспособной альтернативой частным системам с точки зрения качества и надежности.
Процессы разработки
Очевидно, что разработка и поддержка частного программного обеспечения требует огромных затрат. Каким же образом гораздо более слабо связанная группа разработчиков может бесплатно создать систему с сопоставимым качеством? Рассмотрим процесс разработки программного обеспечения с открытым кодом, чтобы лучше разобраться в причинах успеха открытых проектов.
В большинстве традиционных частных программных проектов используется тот или иной вариант модели водопада [15], которая имеет пять хорошо определенных стадий.
Процесс в целом имеет итеративный характер: в любой момент из-за появления новых проблем или изменения требований проект может вернуться к более ранней стадии. Это цепочка обратной связи с разработчиками. Проблемы, обнаруженные на стадиях тестирования и эксплуатации, доводятся до сведения программистов. Программисты ищут решения проблем, разрабатывают исправления и повторно предоставляют компоненты для тестирования и включения в систему.
Открытая разработка зачастую менее структурирована, но в какой-то мере повторяет традиционные стадии. Главное отличие состоит в добавлении цепочки обратной связи с пользователями, с помощью которой последние вовлекаются в процесс разработки. В частной среде пользователи могут сообщить о программных дефектах или что-то предложить, но не способны непосредственно участвовать в процессе разработки, поскольку не имеют доступа к исходному коду. При открытой разработке каждый потребитель получает доступ к исходному коду и может участвовать в непрерывном совершенствовании программ. Правда, лишь небольшая доля пользователей имеет необходимый опыт или желание активно участвовать в проекте. Однако когда сообщество потребителей становится достаточно большим, эта доля дает значительное число участников.
Наглядной иллюстрацией служит разработка Web-сервера Apache. Система Apache возникла в 1995 году из набора заплат (patch) для исходного кода популярного в то время Web-сервера Национального центра суперкомпьютерных приложений США. Этим заплатам система и обязана своим названием (игра слов: Apache server — a patchy server, то есть «заплаточный сервер» — Прим. перев.). Заплаты были предоставлены пользователями сервера (в то время почти лишенного поддержки), которые нуждались в дополнительных функциях. Потребители имели доступ к исходному коду сервера и могли изменять систему в соответствии со своими нуждами. Изменения поступали в группу добровольцев, поддерживающих систему.
В конечном счете эта группа отказалась от первоначального набора заплат и полностью перепроектировала систему. В декабре 1995 года был официально выпущен сервер Apache версии 1.0, который, как уже отмечалось, быстро стал доминирующим Web-сервером в Internet. По мере роста популярности системы Apache росло и число организаций, полагающихся на нее при решении своих основных задач. Как следствие, множилось число участников проекта. Группа добровольцев, рассматривавших усовершенствования и поддерживавших исходный код Apache, продолжала расти, в 1995 году превратившись в Apache Group, в 1999-м была преобразована в Apache Software Foundation.
В цепочке обратной связи пользователи вскрывают дефекты системы, создают отчеты об ошибках и предлагают усовершенствования основным разработчикам. Благодаря публичной доступности исходного кода потребители могут определять местонахождение дефектов, указывать подозрительные фрагменты кода и предлагать заплаты для устранения ошибок. Когда заплата поступает по цепочке обратной связи с пользователями, она подвергается строгой ревизии и тестированию в цепочке обратной связи с разработчиками и лишь потом попадает в репозиторий исходного кода системы. Система распределения бремени проверки кода между разработчиками и пользователями весьма эффективна. Каждый потребитель может стать разработчиком и внести свой вклад в общий успех пакета программ.
Один из недостатков этой системы заключается в том, что она хорошо работает лишь с популярными открытыми проектами. Маленькому проекту может не хватить критической массы ресурсов, которой располагает большой популярный проект с широким кругом пользователей. Есть много примеров открытых систем с огромным числом потребителей, непрерывно работающих над повышением их надежности и расширением функциональных возможностей. При накоплении критической массы разработчиков и пользователей программный проект с открытым исходным кодом может достичь соответствия столь же высоким стандартам надежности и безопасности, каким должна отвечать частная система.
Закрытое или открытое?
Что безопаснее — закрытое или открытое программное обеспечение? К сожалению, однозначного ответа пока нет. Открытые и частные системы не имеют явных преимуществ друг перед другом с точки зрения безопасности и надежности, а доводы в пользу любого из подходов не имеют окончательного характера. Эмпирические исследования показали, что открытые системы потенциально могут превзойти частные, но если безопасность не заложена при проектировании, то система защищенной не будет. Есть, конечно, частные системы, более защищенные, чем их открытые аналоги (например, S/COMP или GEMSOS в сравнении с GNU/Linux). Есть и открытые системы, которые кажутся более безопасными, чем их частные эквиваленты (например, Apache в сравнении с IIS).
Одним из препятствий при количественной оценке безопасности частных и открытых систем является то, что достоверно заслуживающие доверия системы очень трудоемки и дороги в разработке и сертификации. Пока существуют лишь семь операционных систем, достигших четвертого уровня CC EAL (Common Criteria Certification Evaluation Assurance Level), который означает «систематически разработанная, проверенная и проанализированная» [17]. Среди открытых операционных систем самый высокий рейтинг CC EAL, который составляет 3+ (т.е. «систематически протестированная и проверенная»), имеет дистрибутив SuSE Enterprise Server V8. Отсюда вовсе не следует, что открытые операционные системы с меньшими рейтингами менее надежны, чем частные. Это может означать, что не удалось добиться финансирования официальной сертификации. Поскольку сертификат Common Criteria дорог, только крупные организации позволяют себе субсидировать его получение, особенно на высших уровнях сертификации.
Другая проблема состоит в том, что любая программная система требует частого внесения исправлений для устранения дефектов, а это само по себе небезопасно. Использование подсчета заплат в качестве меры защиты может ввести в заблуждение. Система, требующая заплат в механизмах обеспечения безопасности каждые полгода, не является вдвое более безопасной, чем система, которая требует внесения исправлений каждые три месяца. Они обе небезопасны. Программные системы постоянно изменяются, и при всяком устранении старых дефектов в систему могут быть введены новые. Пока нет простого способа определения абсолютного числа дефектов системы. Однако открытые системы имеют явное преимущество в ответах на угрозы. К примеру, организации, которые наиболее успешно справлялись с червем Морриса в 1988 году, имели доступ к исходному коду Unix. Наличие исходного кода позволило техническому персоналу понять угрозу и поделиться этой информацией с другими организациями.
Именно совместное использование информации — ключевая сила открытого движения. Разработчики открытого кода могут анализировать предыдущие системы и «стоять на плечах гигантов». Как и в научно-исследовательском сообществе, свободный обмен информацией способствует продвижению новшеств и расширению поля деятельности. Открытое движение может использовать обобществленную информацию для привлечения талантов из неисчерпаемого источника. Рост числа пользователей открытого проекта означает и рост количества его потенциальных разработчиков. Как только сформирована критическая масса пользователей, импульс объединенных усилий приводит к появлению высококачественных систем, которые по надежности и безопасности превосходят частные аналоги — при значительно меньшей стоимости.
Литература
Алан Буланже (boulange@us.ibm.com) — сотрудник лаборатории анализа глобальной безопасности исследовательского центра IBM Thomas Watson Research Center.
A. Boulanger, Open-source versus proprietary software: Is one more reliable and secure than the other? IBM Systems Journal, Vol. 44, No. 2, 2005. Copyright 2005, International Business Machines Corporation. All rights reserved. Reprinted with permission.