что такое открытый исходный код и закрытый
Открытый исходный код — благо или троянский конь?
Сразу хочется сузить рамки — разговор идет о продаже программного продукта (php+MySQL).
Вопрос — (про)давать ли исходный код?
Аргументы в пользу закрытого кода.
— Подавляющему большинству клиентов нужно чтобы продукт работал и исходный код не нужен.
— При закрытом коде проще осуществлять тех. поддержку — клиент своими руками не залезет куда не надо и не породит новых уникальных ошибок, в которых хрен разберешься.
— Сложнее стырить исходный код. А точнее его можно получить, но вот что-то серьезное переделать в этом «исходнике» сложно — максимум сломать защиту, внести незначительные правки.
— Есть некоторая надежда разработчика, что закрытый код спасет от перепродажи его продукта лихими людьми.
— Есть легкая надежда, что купят продукт, потому как «сломать» не смогут, либо «ломанный» побоятся использовать.
— Народ (наш народ 🙂 ) привык что если код открыт, значит бесплатно!
Аргументы в пользу открытого кода.
— Иногда клиенту просто хочется иметь возможность взглянуть на код. То есть не обязательно даже его иметь, но чтобы возможность такая была. Это могут быть параноики безопасности в хорошем смысле или просто борцы за какие-то права.
— Клиент имеет возможность внести правки, причем весьма серьезные. Вплоть до потери совместимости с последующими версиями продукта (хотя вот это возможно уже в минус).
— Нет проблем с дешифратором закрытого кода. Не секрет, что такие проблемы встречаются (отсутствие Зенда и иже с ним, какие-то локальные глюки т.д.).
— Есть возможность построить сообщество разработчиков купивших скажем девелоперскую лицензию с доступом к открытому коду.
Добавлю немного конкретики.
Вопрос «открытого кода» интересует в связи с «внутрифирменной» дискуссией по поводу развития одного из наших продуктов (CNCat). Мы проходили разные стадии (открытый код, Зенд) и сейчас осуществляем обфрускейтивание (замену названий переменных на бессмысленные) и легкую шифрацию. Когда мы давали продукт в открытом коде и давали его бесплатно — много кто тырил код и на его основе делали свои продукты без всяких ссылок на нас. Что было немного обидно и сейчас не хочется на этом обжечься опять.
Однако правильное позиционирование открытого кода (АПИ, поддержка, контроль и т.д.) может дать нам приток сторонних разработчиков новых фич, мощную обратную связь, отладку — в общем новый импульс.
Дык хочется получить какие-то дополнительные аргументы или мысли по данному вопросу. Как бы Вы повели себя как клиент, как разработчик (конечно желательно чтобы Вы им являлись, чтоб не голословно)? Может есть какие в мире устоявшиеся теории и доказанные практикой подходы (типа фри версия закрыта, купленная открыта)?
Открытый или закрытый исходный код скрипта, в чем разница?
Доброго времени, мои уважаемые читатели! Сегодня я немного расскажу о разнице открытого и закрытого кода программного обеспечения(ПО) и как это может отражаться на работе предпринимателей, которые покупают ПО для организации своих бизнес процессов. Несмотря на то, что предприниматель редко задается таким вопросом, этот момент не стоит упускать из виду, т.к. он может оказаться ключевым при возникновении потребности внести изменения в работу программного обеспечения.
В качестве вступления приведу небольшой пример истории из жизни. Предприниматель Екатерина Сергеевна, приобрела программное обеспечения для создания на его безе интернет магазина, на момент покупки Екатерину Сергеевну устраивало практически все, что касалось функционала приобретаемого ПО. В течении нескольких дней был запущен сайт, затем на протяжении месяца сайт наполнялся полезными статьями, писался раздел справки и помощи, активно добавлялись товары. Параллельно с этим была развернута рекламная компания, по привлечению клиентов в интернет магазин. Спустя 6 месяцев, сайт начал приносить доход, и перед предпринимателем встал вопрос о его улучшении, внесении ряда правок, чтобы сделать работу сайта лучше и эффективнее. Екатерина Сергеевна, обратилась к разработчику ПО, собственно у кого оно и было куплено. Но, как оказалось разработчик в данный момент занят, и не может заняться её проектом. Тогда, Екатерина обратилась к стороннему программисту, найти которого не составило большого труда. Подготовила подробный список того, что хочет изменить в своем сайте, и договорилась с ним, о начале работ. Но каково было удивление Екатерины, услышать от программиста ответ: «Я не могу реализовать ваши пожелания, т.к. исходный код ПО закрыт, я не имею к нему доступа». Работа встала.
Я очень часто наблюдаю такие ситуации, когда программа требует внесения доработок, а сделать этого нельзя, из-за того, что исходный код закрыт. Само понятие «закрытый исходный код» носит двусмысленный характер, оно может означать что:
1) код закрыт(скомпилирован, зашифрован, обфусцирован) и его нельзя посмотреть, а следовательно нельзя внести правки, изменения, дополнения;
2) код закрыт согласно лицензионному соглашению, такой код нельзя модифицировать(запрещено правообладателем) даже в том случае, если технически это возможно.
На фоне вышесказанного, возникает вопрос: кто может вносить изменения в работу такого программного обеспечения? Ответ — только разработчик, и то если пожелает, или вы сможете с ним договориться.
В свою очередь, открытый исходный код, лишен всех этих недостатков. Он может быть просмотрен, изменен, доработан и так далее, как правило лицензия по которой распространяется такое программное обеспечении разрешает пользователю модифицировать его любым образом, и если носит какие-то ограничения, то они как правило связаны с распространением его(программного обеспечения) копий.
Возвращаясь к истории предпринимателя Екатерины Сергеевны, в её случае решить возникшую задачу так и не получилось. Спустя год работы её сайта, накопилось очень большое количество изменений, которые требовалось внести в скрипты. Во первых её бизнес вырос, количество клиентов перевалило за несколько тысяч, и встал вопрос о добавлении на сайт различных сервисов: «расчет стоимости доставки», «личный кабинет», «отложенные товары» и т.д. Разработчик так и не смог выделить время на то, что-бы поработать с Екатериной (впрочем его винить за это не стоит, он изначально не оказывал услуг по доработкам, плюс ко всему таких запросов ему поступает ежедневно по несколько штук и он физически не способен их все удовлетворить), а сторонние программисты просто бессильны в данной ситуации. В итоге Екатерина приняла решение, полностью переделать весь сайт и в качестве платформы использовать уже ПО с открытым исходным кодом, это был её основной критерий к покупаемому продукту. Какие издержки она при этом понесла: покупка нового ПО, расходы по переносу базы клиентов, товаров, прочих материалов, работа по сохранению адресов страниц(что-бы не выпасть из индекса ПС) для сохранения позиций в поисковых системах, плюс её сайт простаивал некое время, и она также упустила часть выгод от возможных продаж. Все это обошлось её в крупную денежную сумму, потраченное время и нервы.
Данная история, это случай из жизни, из моей практики. Екатерина обратилась ко мне и мы славно поработали, впрочем еще многое предстоит сделать, ведь в голову постоянно приходят новые идеи, которые способствуют росту её бизнеса.
Что лучше открытое или закрытое ПО?
Однозначного ответа на этот вопрос нет, в ряде случаев закрытое ПО не чем не хуже открытого. Оно выполняет поставленные задачи, обеспечивая пользователя хорошим функционалом, таких примеров много iOS, Windows, MS Office и т.д. Но если речь идет о бизнесе, который зависит от ПО, и который со временем будет расти требуя внедрения новых идей, выбор однозначно падает на программное обеспечение с открытым исходным кодом!
Больше чем софт: что такое код open source и для чего он нужен
Согласно определению на Open Source Initiative, Open Source Software или программное обеспечение с открытым исходным кодом — это ПО, «исходники» которого доступны для просмотра и изменения. Исходный код можно использовать, чтобы создавать свои модификации софта, а также свободно распространять и даже продавать их.
Принцип открытости со временем охватил не только сферу программирования, но и другие области. Дизайнеры могут размещать в открытом доступе бесплатные шрифты и шаблоны, программисты — коды мобильных приложений и онлайн-игры, ученые — исследования.
В последние годы потребителями открытого ПО становятся целые страны. Французская жандармерия использует на своих компьютерах свободное ПО Ubuntu, а другие министерства переходят с Microsoft Office на бесплатный LibreOffice. Этот офисный пакет также используют министерства обороны Нидерландов и Италии, муниципалитеты Албании и Испании. А правительство Великобритании перешло с формата PDF в документации на опенсорс-формат Open Document Format for Office Applications (ODF) по умолчанию. РБК Тренды разобрались, в чем плюсы и минусы открытого софта.
С чего начиналось свободное ПО
С 1952 по 1955 год компания IBM начала выпускать IBM 701, первый коммерчески доступный компьютер. ЭВМ не продавали конечным потребителям, а сдавали в аренду научным институтам, военным компаниям и госпредприятиям. Машины поставлялись без операционной системы и программ. Ученые и инженеры начали писать софт сами и делились им с коллегами из других компаний, у которых были аналогичные ЭВМ.
Со временем коммерческих моделей компьютеров становилось больше, и они стали доступны обычным пользователям. Однако под каждую из этих моделей придумывали отдельное ПО. Компании-производители создавали каждый свою операционную систему: BESYS, Compatible Time-Sharing System или CP/CMS. Эти ОС начинали продавать вместе с ПК, и иногда они стоили дороже самого компьютера.
Разработчик Ричард Столлман присоединился к лаборатории искусственного интеллекта при Массачусетском технологическом институте (MIT). Он принимал участие в работе над свободным ПО, например, над EMACS — текстовым редактором для мини-компьютеров семейства PDP. Позднее редактор продали коммерческому дистрибьютору. В 1984 году Столлман решил основать проект свободного ПО под названием GNU (рекурсивный акроним от англ. GNU’s Not UNIX).
В рамках этого проекта энтузиасты придумали термин «свободное ПО» и сформулировали его критерии: использование, изучение, шеринг и улучшение. Они опубликовали манифест GNU. В 1985 году Столлман основал фонд Free Software Foundation (FSF) для развития свободного ПО за счет пожертвований. В 1989 году появилась первая версия лицензии GPL — General Public License («Универсальная общественная лицензия GNU»). Она должна защитить свободу всех пользователей программ, давать права на копирование, модификацию и распространение софта. Столлман добавил в лицензию понятие «авторское лево» в противовес «авторскому праву», по которому пользователи всех производных программ получают все оригинальные права создателя. Позднее появились другие лицензии, которые позволяют использовать свободное ПО, например, лицензия MIT от Массачусетского технологического института или лицензия BSD от Калифорнийского университета в Беркли.
К 1991 году разработчикам удалось создать независимую работоспособную ОС, но ей не хватало ядра. Тогда Линус Торвальдс выпустил ядро Linux с открытым кодом, а в 1992 году лицензировал его по GPL.
В середине 1990-х годов в open source пришла первая крупная компания Netscape. Ее браузер Navigator был одним из самых популярных в мире, но с появлением Internet Explorer он стал вытесняться с рынка. В 1998 году в Netscape решили открыть исходный код своего браузера. Год спустя компании не стало, но исходный код Navigator стал основой для одного из самых популярных браузеров — Mozilla Firefox.
В 1998 году возникла организация Open Source Initiative (OSI), которая занимается популяризацией открытого кода. В том же году разработчики придумали альтернативу термину «свободное ПО». Они решили внедрить понятие open source, чтобы сменить парадигму бесплатности на доступность. Впоследствии разработчики Эрик Реймонд и Брюс Перенс написали «Определение Open Source».
В 2014 году представители фонда поддержки открытых проектов Linux Foundation заявили, что в будущем 80% стоимости технологий будет приходиться на открытый код и только 20% — на платные программы.
Плюсы открытого кода
Обсуждения плюсов и минусов и активны по сей день. Однако многие разработчики сходятся в общем понимании позитивных и негативных сторон опенсорс-проектов.
Для пользователей
Для разработчиков:
Для корпораций:
Минусы open source
Плагиат. Коммерческие структуры могут использовать открытый код для своих продуктов без указания его авторства. Иногда они вносят минимальные изменения в код, чтобы выдавать его за собственный. Подобное случилось с участниками проекта Leela, которые разработали бесплатный шахматный движок Chess Zero с настраиваемой нейронной сетью. Его использовала компания ChessBase, которая выпустила шахматную программу Fat Fritz. Пакет программ ChessBase Fritz компании стоит от €79 до €99. При этом она отрицает, что каким-либо образом задействовала открытый код.
Аналогичная история была и с Amazon Web Services, которая запустила CloudWatch Synthetics Recorder, расширение Chrome для записи взаимодействий с браузером. Однако данный сервис оказался полностью скопирован с проекта Headless Recorder, созданного разработчиком Тимом Нолетом. В AWS факт плагиата не признавали.
Отсутствие поддержки. Открытый код может использоваться в тех проектах, о которых его авторы даже не подозревают. Таким образом, они не могут оказывать должную поддержку. Кроме того, существует риск, что разработчик небольшого проекта отойдет от дел, а продолжать его дело будет некому, и код начнет устаревать. Проект Libraries.io обнаружил более 2 400 библиотек с открытым кодом, используемых минимум в 1 тыс. других программ, не получавших должного внимания со стороны опенсорс-сообщества. Для потребителя такой программы это может стать проблемой. К примеру, когда программист Азер Кочулу удалил свою библиотеку Leftpad из интернета, проблемы возникли у Facebook, Netflix и других проектов.
Незамеченные уязвимости. Каждый открытый проект зависит от более мелких. В этой цепочке зависимостей легко может возникнуть дыра в безопасности, которую могут долго не замечать. В 2014 году такая уязвимость в безопасности Heartbleed была обнаружена в OpenSSL — программе с исходным кодом, используемой практически всеми веб-сайтами, обрабатывающими платежи с банковских карт. Она делала все эти ресурсы уязвимыми для атак хакеров и кражи данных. По данным GitHub, 17% всех уязвимостей создаются со злонамеренными целями. Исследователи отмечают, что они могут просуществовать до четырех лет, прежде чем будут устранены.
Проекты с открытым кодом
Проекты GNU и Linux послужили основой для многих продуктов. А приход компании Netscape позволил привлечь внимание ИТ-гигантов, которые со временем начали активно вкладываться в open source.
Проект Debian, одной из старейших операционных систем, основанных на ядре Linux, с момента своего основания разрабатывался открыто. Фонд свободного программного обеспечения спонсировал проект с 1994 по 1995 год, а затем создатели организовали некоммерческую организацию «Программное обеспечение в общественных интересах» для финансирования Debian. Проект включает популярные бесплатные программы, такие как LibreOffice, браузер Firefox, почту Evolution, устройство записи дисков K3b, медиаплеер VLC, редактор изображений GIMP и программу просмотра документов Evince.
Организация Apache Software Foundation тоже начиналась как открытый проект по развитию одноименного программного обеспечения, в том числе веб-сервера Apache. Данный сервер считается одним из наиболее популярных. Он позволяет запускать сайты небольших проектов и малого бизнеса на WordPress. В наше время разработчики поддерживают множество софтверных проектов, которые имеют открытую лицензию Apache Software License. Спонсорами ASF выступают такие гиганты как Microsoft, Huawei и Amazon Web Sevices.
Компания Red Hat, производитель программного обеспечения на основе операционной системы Linux, возникла в 1995 году. Она не только выпускала софт, но и занималась технической поддержкой и обучением системных администраторов и разработчиков. В 2018 году компанию купила IBM.
Google развивалась благодаря Linux и открытому ПО. Компания сама поддерживает такие проекты как библиотека машинного обучения TensorFlow, язык программирования Go, ПО для автоматизации развертывания приложений Kubernetes и другие. В 2017 году Google открыла портал для 2 тыс. своих open source проектов. Компания делится своими наработками в области открытого кода, а также рассказывает о поддержке новых инициатив.
Microsoft, которая изначально была против open source, в последние годы также изменила отношение к свободному ПО. В 2018 году компания передала 60 из 90 тыс. своих патентов на разработки Open Invention Network (OIN) — организации, которая владеет патентами на программное обеспечение открытой экосистемы GNU/Linux и предоставляет право на их бесплатное использование. Чуть позже корпорация приобрела портал репозиториев открытого года GitHub, а также активно принимает участие в развитии открытых проектов, в том числе, Linux.
Организация Open Source Design объединяет дизайнеров, которые разрабатывают проекты с открытым кодом. Она существует более пяти лет. В работе организации принимают участие UX-дизайнеры Mozilla, GNOME, Fedora, Canonical (Ubuntu), WordPress, Drupal, Libre Office, «википедии» для дизайнеров XWiki и других компаний.
В науке опенсорс-подход распространяется не только на открытое ПО, но и на публикации работ исследователей, открытое рецензирование и развитие открытых образовательных ресурсов. Еще в 1991 году физик Пол Гинспарг основал электронный архив arXiv при Лос-Аламосской национальной лаборатории для публикации в открытом доступе препринтов. Теперь там публикуются работы не только по физике, но и по медицине, математике и еще ряду направлений. Европейская организация по ядерным исследованиям (ЦЕРН) поддерживает не только выпуск оборудования с открытым исходным кодом и открытой лицензией, но и собственный портал открытых данных. Ученые применяют инструменты с открытым кодом также для того. чтобы раскрывать методологию своих исследований. К примеру, они используют Open Notebooks для документирования рабочих процессов.
Продукты с открытым кодом используют не только специалисты, но и обычные пользователи, причем иногда они даже не подозревают об этом. LibreOffice, OpenOffice и NeoOffice позволяют бесплатно работать с текстовыми документами, таблицами, графиками, рисовать и делать презентации. 7-Zip, файловый архиватор с высокой степенью сжатия, помогает экономить место на ПК и передавать большие файлы. Графический редактор GIMP способен заменить Photoshop, так как включает инструменты цветокоррекции, фильтры, рисующие инструменты, маски и слои.
Примеру опенсорс-проектов следуют и корпорации, которые открывают свои программы для улучшения. Так, Microsoft решила поделиться кодом приложения «Калькулятор» для Windows, чтобы открытое сообщество предлагало для него исправления и новые функции.
Открытый исходный код в наши дни помогает поддерживать технологии искусственного интеллекта, блокчейна и сложных вычислений. Согласно отчету Red Hat, который опросил 1 250 ИТ-лидеров по всему миру, 90% этих предприятий используют открытый исходный код: 64% компаний задействуют такое ПО для модернизации инфраструктуры, 54% — для разработки приложений, 53% — для цифровой трансформации. За последние два года эти показатели увеличились на 11%, и в будущем открытый код, вероятно, поможет заменять ручные процессы автоматизированным управлением на программном обеспечении, способствуя инновациям.
Надежность и безопасность: открытый код против закрытого
Выпуск программного обеспечения с открытым кодом стал одним из важнейших ИТ-направлений. Но по мере роста популярности открытых систем все острее встают вопросы их надежности и безопасности.
Изначально системы с открытым кодом были результатом свободного сотрудничества программистов-добровольцев. Законченные системы выпускались в свет, и любой мог их использовать без внесения лицензионной платы. Поддержка этих систем также осуществлялась добровольцами с помощью списков рассылки и 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.