Open Source: уроки критически важных проектов

К моменту публикации этой статьи, исследовательские станции Mars Exploration Rover, запущенные NASA к Марсу, приблизятся к конечной цели своего путешествия. Их полет к Красной планете длился более семи месяцев. Когда Spirit и Opportunity в целости и сохранности опустятся на ее поверхность, операторы центра управления полетом в лаборатории Jet Propulsion Laboratory будут использовать программные инструментальные средства управления марсоходами и анализа полученных ими данных№.

При разработке одного из таких инструментов, Science Activity Planner, активно использовались свободно распространяемые программные компоненты [1]. Расскажем об опыте, накопленном при его разработке, и обсудим возможную роль Open Source в создании критически важных программ. Исследование было проведено в лаборатории Jet Propulsion Laboratory Калифорнийского технологического института в рамках контракта с NASA.

Science Activity Planner

SAP — основной инструмент для анализа присылаемой на Землю информации, планирования действий исследовательского аппарата Mars Exploration Rover и передачи ему команд с наземной станции в рамках проекта NASA. В течение каждых солнечных суток (так называют марсианский день, продолжительность которого составляет 24 часа 39 минут. — Прим. пер.) ученые и инженеры с помощью SAP просматривают данные, полученные марсоходом за предыдущие сутки, и разрабатывают план его действий на следующий день. Затем, с помощью других инструментальных средств этот план совершенствуется и передается на космический аппарат. В NASA это программное обеспечение считают критически важным, поскольку из-за ошибки в его работе могут пропасть целые сутки драгоценного времени марсианской экспедиции.

Кроме того, SAP будет использоваться для управления космическими аппаратами в проекте Mars Technology Program, реализуемом лабораторией Jet Propulsion Laboratory; планируется модернизировать SAP и для предстоящего в 2009 году полета Mars Science Laboratory. Открытый вариант SAP можно загрузить с сайта wits.sdsu.edu.

SAP реализует широкий круг возможностей, в том числе визуализацию двух- и трехмерных данных, обработку изображений, распределенные операции и моделирование действий космического аппарата. Рисунок демонстрирует некоторые возможности основного интерфейса SAP.

Основной интерфейс Science Activity Planner. С помощью браузера, используемого для передачи данных на Землю (на переднем плане), можно видеть и анализировать изображения и другую информацию. Браузер позволяет создавать и моделировать планы действий марсохода, проверять их корректность.

Spirit и Opportunity несут на себе самое совершенное из научного оборудования, которое когда-либо посылалось на Марс. Из-за этого потребовались серьезные изменения практически в каждом компоненте архитектуры, используемой для приема и передачи данных в SAP. Система должна была получить возможность визуализации на порядок больших наборов данных, чем в предыдущих полетах, и в то же время анализа данных совершенно новыми способами. В связи со сложностью моделирования производительности таких инструментов потребовалась и разработка новой системы моделирования. Все это вызвало необходимость полной переработки SAP.

Амбициозные цели проекта в сочетании с весьма скромным бюджетом, выделенным на программное обеспечение, потребовали отказа от традиционной модели разработки. Она предполагала создание всех необходимых решений в стенах NASA и применялась в отношении критически важных программ (в том числе для предыдущих версий SAP). В данном же случае группа разработки использовала подход к проектированию, который обеспечивал удовлетворение максимального числа требований с помощью свободно распространяемых компонентов, созданных и поддерживаемых вне Jet Propulsion Laboratory. Такое решение коснулось практически всех этапов переработки SAP, от проектирования до кодирования.

Разработка на фундаменте Open Source

Разработка SAP началась с определения требований к инструментарию — совместно с учеными и инженерами, которые должны были стать его основными пользователями. При этом предусматривались активные «походы по магазинам» в поисках компонентов с открытыми исходными текстами, удовлетворявших запросам заказчиков. Найдя такие компоненты, мы смогли оценить затраты на выполнение всех требований более объективно, чем в случае самостоятельной разработки подобных решений. В ряде случаев мы даже порекомендовали заказчикам изменить требования, чтобы добиться желаемого с помощью открытых компонентов. Они согласились с нашими предложениями, понимая, что сэкономленные ресурсы пойдут на реализацию большего числа функций.

Составить итоговый список открытых компонентов оказалось довольно сложно. Во врезке «Открытые компоненты» приведено описание свободно распространяемого программного обеспечения, которое используется в SAP. Большая часть таких компонентов играет критически важную роль в SAP, и все они необходимы для выполнения задач, стоящих перед этим инструментарием.

Мы не только добавили открытые программные компоненты в SAP, но и активно использовали свободно распространяемые инструментальные средства. Помимо известного редактора GNU Emacs и системы управления версиями CVS мы задействовали JUnit для тестирования модулей, JavaCC — для генерации программы синтаксического разбора в целях изображения арифметических выражений и т.д.

Разработка SAP усложнялась не только сжатыми сроками. Превышение общей сметы проекта Mars Exploration Rover потребовало двух серьезных сокращений бюджета, которые в общей сложности составили почти 50% от общего объема средств, выделенных на SAP. В связи с нестабильностью требований к программному обеспечению несколько раз пришлось прибегнуть к перепроектированию, причем уже на поздних этапах.

Однако при создании SAP мы всерьез полагались на открытые решения, и нам удалось оперативно адаптироваться ко многим изменениям. Так, во время одной из переработок проекта потребовалось исключить функцию, которую должен был выполнять свободно распространяемый компонент. Поскольку нам не нужно было оплачивать реализацию этой функции за счет средств, отведенных на разработку SAP, ее исключение практически не отразилось на проекте в целом. Наш опыт свидетельствует, что при использовании свободно распространяемых продуктов реализация проекта зачастую ускоряется, так как все ресурсы концентрируются на разработке основной архитектуры системы, а не на воплощении конкретных функций.

Следствием использования свободно распространяемых программных компонентов стал юридический конфликт: два из выбранных для SAP компонентов распространяются по условиям ограниченной лицензии GNU General Public License, а та требует, чтобы все полученные с использованием этого кода программы также были свободно распространяемыми. Однако, особый статус SAP не позволял сделать это программное обеспечение общедоступным. К счастью, в обоих случаях поставщики позволили нам за небольшую плату приобрести лицензию с менее жесткими ограничениями и согласились на приоритетную техническую поддержку.

Результаты разработки

Использование свободно распространяемых компонентов при разработке SAP, безусловно, себя оправдало. Качество выбранных для проекта открытых компонентов оказалось превосходным — лучшим, чем у двух коммерческих компонентов, приобретенных нами за тысячи долларов. Кроме того, в открытых решениях было меньше ошибок. Рассчитывая, что доступ к исходным текстам позволит эффективнее диагностировать проблемы в коммерческих компонентах, мы приобрели соответствующую лицензию. За единственным исключением, исходный текст открытых компонентов был лучше документирован и более понятен, чем тексты коммерческих решений. Естественно, наш случай нерепрезентативен, но, возможно, именно открытость кода заставляет разработчиков писать более качественные программы.

Разительнее всего различия проявились в «отзывчивости» авторов. Когда мы сообщали разработчикам открытых программ о найденных ошибках, они сразу предлагали возможные обходные решения и постоянно информировали нас о своих действиях для исправления дефектов. Однажды они диагностировали ошибку, исправили ее и отослали нам откорректированную версию всего за день. А вот при обнаружении ошибок в коммерческом продукте мы зачастую даже не могли связаться с разработчиками. Кроме того, стало ясно: рассчитывать приходится лишь на исправление ошибок в следующей версии продукта, которая, не исключено, появится лишь через несколько месяцев.

Поскольку цикл разработки коммерческих продуктов оказался столь длительным, было бессмысленно тратить время на передачу их авторам списка ошибок. Зачастую мы самостоятельно исправляли изъяны в нашем экземпляре исходных текстов и двигались дальше. При обнаружении и исправлении ошибки в свободно распространяемой программе, мы передавали корректный текст разработчикам и буквально через несколько дней могли загрузить исправленную программу. Вознаграждение за устранение ошибок в свободно распространяемых программах — неизменно более высокое качество программ с открытыми кодами.

Кто-нибудь может предположить, что использование свободно распространяемого программного обеспечения привело к снижению надежности системы, но наш опыт свидетельствует об обратном. Для начала поговорим о нашей стратегии тестирования компонентов SAP. Мы испытывали компоненты с разной степенью «придирчивости», в зависимости от ряда факторов. Наиболее тщательная проверка проводилась с помощью специализированных автоматизированных пакетов тестирования модулей и простых интерактивных приложений, позволяющих определить корректность взаимодействия компонентов. Тестирование на системном уровне и опытная эксплуатация программ будущими пользователями позволили оценить производительность каждого компонента системы.

Многие из выбранных нами открытых компонентов включали в себя детальные тесты, которые вполне соответствовали уровню тестирования большинства других составляющих SAP, а то и превосходили его. Кроме того, у всех выбранных компонентов есть множество активных пользователей, которые постоянно работают со свободно распространяемым программным обеспечением, сообщают об ошибках и предлагают исправленные варианты. Можно сказать, что каждый из них принял участие в тестировании SAP на уровне компонентов. Очевидно, что компоненты SAP, созданные нами самими, не имели тысяч пользователей, и что никто помимо членов нашей группы не анализировал исходные тексты этих программ. Таким образом, использование свободно распространяемого программного обеспечения лишь привело к повышению общей стабильности SAP.

Разработка системы синхронизации данных в SAP показала, что многие положительные моменты связаны с применением свободно распространяемого программного обеспечения. Первоначально архитектура SAP включала в себя мощное приложение для синхронизации данных, которое создавали разработчики SAP, а также исследователи, принимавшие участие в технологической программе Jet Propulsion Laboratory. К сожалению, уже после начала разработки бюджет проекта был сокращен, и технологическая программа поглотила все доступные ресурсы. Выделенных нам средств оказалось недостаточно для создания приемлемой программной системы.

По истечении года нам пришлось решать, стоит ли тратить быстро истощающиеся ресурсы на завершение разработки системы или следует остановиться на менее сложной архитектуре. После тщательного изучения этого вопроса мы отказались от создававшейся в лаборатории системы в пользу новой реализации на основе четырех свободно распространяемых компонентов (Castor-JDO, MySQL, MySQL Connector/J и HSQLDB). Даже для частичного завершения нашего собственного решения потребовались бы несколько человеко-месяцев; между тем, на альтернативную реализацию, которая оказалась более стабильной и функциональной, ушло менее месяца.

Наш опыт позволяет поставить под сомнение, на первый взгляд, логичное опасение относительно качества и стабильности свободно распространяемого программного обеспечения. Хотя члены группы могут точно адаптировать разрабатываемый ими компонент к определенным требованиям, спешно создаваемая своими силами система вряд ли будет соответствовать по качеству своему стабильному, широко применяемому открытому аналогу. Смешно предполагать, что мы могли за несколько месяцев разработать сервер синхронизации, сопоставимый по производительности и надежности с СУБД MySQL, которая создавалась почти два десятилетия и используется тысячами компаний по всему миру. Более того, ни один из наших сотрудников не имел опыта создания высокопроизводительного автоматизированного серверного программного обеспечения, и мы были рады доверить реализацию этой части нашей системы сообществу Open Source.

Советы участникам критически важных проектов

Мы резюмировали свой опыт разработки SAP в руководстве, предназначенном для тех, кто планирует использовать свободно распространяемое программные компоненты в критически важных приложениях.

Оценка свободно распространяемых программ

Оценка открытых компонентов для использования в критически важном приложении — задача непростая. Необходимо обратить внимание на ряд характеристик компонентов, которые предполагается использовать.

Зрелость. Чтобы оценить зрелость проекта, обратите внимание на то, сколько времени разработчик потратил на его реализацию и сколько версий выпустил. Проекты, находящиеся на этапе альфа- или бета-тестирования, как правило, — плохой выбор для критически важных приложений. Если не ясно, на каком именно этапе находится проект, оцените его состояние применительно к целям вашей разработки. Если многие функции до сих пор не реализованы, то проект, по всей видимости, недостаточно зрелый.

Надежность свободно распространяемого программного обеспечения имеет определяющее значение для критически важных приложений. Каждый компонент, который вы планируете использовать, должен быть охвачен общим планом тестирования. Свободно распространяемые компоненты, которые включают в себя средства автоматизированного тестирования, значительно упростят эту задачу. При отсутствии таких возможностей вам, скорее всего, придется писать автоматические оценочные тесты, чтобы определить, насколько безопасно интегрировать новую версию данного компонента. Наличие согласованного хорошо продуманного плана тестирования — превосходный показатель зрелости программного компонента.

Долговечность. Как оценить потенциальную долговечность проекта? Зрелый проект с большой вероятностью будет существовать долго, поэтому начните именно с оценки его зрелости. Затем обратите внимание на даты появления последних версий, новостных рассылок, сообщений на пользовательских форумах и в списках рассылок, чтобы составить представление об активности разработчиков и пользователей в данном проекте. Некоторые свободно распространяемые компоненты — как города-призраки. Они кажутся «основательными», качественными, но в действительности их разработчики давно махнули на них рукой. Оценить уровень активности работы над проектом поможет SourceForge.net, где указывается уровень активности, рассчитываемый на основе нескольких факторов: передача данных в хранилище исходных текстов, активность на форуме и количество обращений в службу отслеживания ошибок.

Наконец, ищите крупную разнородную группу разработчиков. Если свободно распространяемый компонент создается одним разработчиком, его судьба зависит от желаний этого человека. Стоит насторожиться и в случае, если все разработчики являются сотрудниками одной компании или, скажем, одного университета. Если по каким-то причинам в организации изменятся приоритеты, проект может прекратить свое существование.

Гибкость. Насколько адекватно свободно распространяемый компонент будет «реагировать» на меняющиеся требования вашего проекта? Даже если в момент выбора компонент кажется подходящим по всем статьям, следует помнить, что, скорее всего, рано или поздно вы обнаружите ошибку или захотите получить новую функцию. Некоторые участники движения Open Source быстро откликаются на предложения пользователей, а другие придерживаются более жесткой концепции и имеют четкое представление о желаемых результатах воплощения их проекта.

При оценке гибкости сначала убедитесь, что вы планируете применять данное программное обеспечение с учетом его предназначения так же, как и большинство клиентов. Если вы слишком далеко отклонитесь от проторенного пути, разработчики, возможно, не захотят помогать вам при возникновении проблем.

Потом потратьте какое-то время на чтение пользовательских форумов и списков рассылок. Насколько оперативно разработчики отвечают на вопросы потребителей? Принимают ли и насколько быстро их предложения? Не стоит недооценивать активное и заинтересованное сообщество пользователей: оно часто становится ценным источником поддержки.

Наконец, выясните, насколько разработчики готовы поддерживать ваш собственный проект.

Взаимодействие с разработчиками

Выбрав и интегрировав свободно распространяемый компонент в свою программу, вы можете решить, что на этом ваше взаимодействие с его авторами закончилось. Однако в идеале это — лишь начало. Если такой компонент становится частью важного приложения, ваша цель не сводится к получению кода. Интеграция тысяч написанных кем-то строк кода в критически важный проект — мероприятие рискованное. Вы должны стремиться установить долговременные отношения с группой разработчиков свободно распространяемого программного обеспечения.

Отношения между разработчиком свободно распространяемого компонента и пользователями достаточно сложны. Очевидно, что они отличаются от отношений между производителем и заказчиком, поскольку в данном случае потребитель не платит разработчику. Кроме того, они отличаются от отношений между коллегами по работе, так как разработчик может ставить перед собой совершенно иную цель, нежели пользователь данной программы. Разработчик свободно распространяемой программы и пользователь добиваются собственных целей, и их сотрудничество продолжается до тех пор, пока оно выгодно обеим сторонам.

На первый взгляд, все выгоды от такого сотрудничества получает лишь пользователь. Что же заставляет разработчика писать тысячи строк кода и отдавать его безвозмездно? Ряд энтузиастов, с которыми нам пришлось взаимодействовать, заявили, что ими движет желание увидеть, как множество людей самым разным образом используют плоды их труда. Для них важна и возможность повысить свою квалификацию как разработчиков, ведь их программы анализируются огромным числом специалистов. Таким образом, самое лучшее, что вы можете сделать для такого разработчика, — просто периодически сообщать ему, как вы используете его программный продукт.

Перспективы

SAP — не единственный критически важный программный проект NASA, создававшийся с помощью свободно распространяемого программного обеспечения. Более того, SAP — не единственный фрагмент программного обеспечения в проекте Mars Exploration Rover, разработанный на основе этой стратегии.

Разработка с помощью готовых программных компонентов стала естественным шагом на пути создания свободно распространяемого программного обеспечения. NASA формально оценило разработку программного обеспечения на базе готовых программных компонентов (commercial of-the-shelf, COTS) как приобретающую с каждым годом все большую популярность [2]. Разработка с помощью открытых компонентов — логичное развитие модели COTS. Однако на нее может уйти значительно больше времени, поскольку в аппаратном мире аналогов Open Source не существует. Попробуйте представить производителя компьютеров, который бесплатно отдает ноутбук любому, кто его попросит, и вы поймете, почему внедрение идей свободно распространяемого программного обеспечения идет так медленно.

Если разработка с помощью общедоступных программ станет в NASA обычной практикой, это, возможно, значительно приблизит тот день, когда большая часть наработок агентства станет достоянием сообщества Open Source. Опубликованный недавно отчет исследовательского центра NASA Ames Research Center свидетельствует о растущем интересе к этой концепции внутри агентства [3]. Но вряд ли она воплотится прежде, чем будут предприняты официальные шаги к тому, чтобы сделать использование свободно распространяемых компонентов в NASA нормой.

Группа разработки SAP выбрала необходимые компоненты среди свободно распространяемых. Если бы мы не смогли найти компонент, удовлетворяющий нашим требованиям, мы создали бы его самостоятельно. Сообщество Open Source состоит из самых талантливых в мире разработчиков, большинство из которых принимают участие в проектах просто потому, что им нравится писать программы и видеть, как они используются в самых разных сферах. Даже если проект в целом нельзя отнести к свободно распространяемому программному обеспечению, его авторы могут отобрать компоненты, которые будут полезны и интересны специалистам вне их организации, и найти общедоступные проекты, позволяющие существенно ускорить их собственную разработку. При выполнении проекта, таким образом, удастся удвоить, а то и утроить численность группы разработки — при минимальных расходах самой организации.

Свободно распространяемое программное обеспечение уже во многих областях кардинально изменило подход к разработке, создатели критически важных проектов, скорее всего, последует этому примеру. По существу, общедоступные программы предоставляют еще один выход тем, кто стоит перед выбором: покупать или создавать самостоятельно. Если «создавать» дает гибкость, а «покупать» ускоряет разработку, то интеграция свободно распространяемых компонентов обеспечивает и то, и другое. Open Source — это возможность «купить», ничего не тратя, и «создать», ничего не разрабатывая. Трудно представить более выгодную сделку.

Литература

1. P.G. Backes et al. The Science Activity Planner for the Mars Exploration Rover Mission: FIDO Field Test Results. Proc. 2003 IEEE Aerospace Conf., IEEE Press, vol. 8, 2003.
2. M. Morisio et al. Investigating and Improving a COTS Based Software Development Process. Proc. 22nd Int'l Conf. Software Eng., ACM Press, 2000.
3. P. Moran. Developing an Open Source Option for NASA Software, tech. report NAS-03-009, NASA, 21 Apr. 2003.

Jeffrey S. Norris, Mission-Critical Development with Open Source Software: Lessons Learned. IEEE Software, January-February 2004. IEEE Computer Society, 2004, All rights reserved. Reprinted with permission.

№ Прогноз автора статьи оправдался. Марсоходы достигли Красной планеты в срок, и за началом их опасного путешествия следил весь мир. Сейчас, впрочем, интерес этот заметно поутих. — Прим. ред.

Открытые компоненты

В Science Activity Planner используются следующие свободно распространяемые программы, обеспечивающие в рамках космического проекта выполнение критически важных задач — от записи планов работ марсохода до подсчета уровня использования ресурсов.

• Castor - платформа обмена данными, которая позволяет перемещать информацию между XML-документами, объектами Java и SQL-базами данных. На Castor основаны функции ввода/вывода SAP.
• Java Expression Parser - система, предназначенная для синтаксического разбора и оценки математических выражений. Используется в SAP для обработки формул из словаря операций полета.
• Xerces-J - подтверждающий синтаксический анализатор XML-документов, который используется в SAP вместе с Castor для записи и чтения всех форматов, установленных для проекта.
• MySQL - СУБД, применяемая в SAP для синхронизации данных между многочисленными экземплярами программы.
• MySQL Connector/J - программное обеспечение промежуточного уровня, который преобразует запросы Java Database Connectivity в формат SQL.
• HSQL Database Engine - SQL-база данных на основе Java. Позволяет предоставить приложению локальную базу данных в случаях, когда общий сервер баз данных MySQL недоступен.
• Virtual Reality Modeling Language (VRML97) - графический инструментарий, который используется в SAP для создания трехмерных моделей космического аппарата.
• Skaringa - платформа обмена данными, аналогичная Castor. В SAP используются ее функции, позволяющие работать с временными рядами.

Держите связь!

Пол-Хеннинг Кемп

В 1994 году я написал однопроходной кодировщик паролей на основе алгоритма MD5, чтобы ОС FreeBSD не нарушала установленных правил экспорта на средства шифрования. Я опубликовал исходные тексты с лицензией beerware («пивное программное обеспечение»), которая разрешает разработчикам использовать код, если они сохраняют в текстах формулировку лицензии и не приписывают себе его авторство; плата за «пиво» — дело сугубо добровольное.

Эта довольно небольшая программка стала на удивление популярной. Во всех версиях FreeBSD, начиная с 2.0, выпущенной в 1994 году, она используется как алгоритм защиты паролей по умолчанию. Ее применяют в NetBSD и OpenBSD, причем в последнем случае базовая концепция расширена за счет более надежных алгоритмов.

В GNU C Library также был использован этот алгоритм. Однако, в данном случае ко мне не обратились за разрешением на лицензирование данной реализации, а лишь переписали алгоритм и теперь распространяют по условиям лицензии GNU. Неприятное следствие такого шага состоит в том, что в GNU нет обратной ссылки ни на меня, ни на оригинальную реализацию FreeBSD.

Cisco Systems использует этот алгоритм для защиты пароля с самыми высокими привилегиями в своем известном программном обеспечении маршрутизации, IOS. Один из сотрудников Cisco подтвердил, что в компании взяли реализацию из FreeBSD «как есть», без каких-либо изменений.

В Internet-реестре RIPE (Reseaux IP Europeens) данный алгоритм используется для аутентификации запросов на обновление баз данных. Уверен, что и в этом случае также взяли мой код без изменений.

Уязвимость

Так что же этот алгоритм защищает сейчас?

Одних только маршрутизаторов Cisco, вероятно, насчитывается десятки миллионов — от систем крупнейших телекоммуникационных компаний до терминалов широкополосной связи отдельных пользователей. Все они передают пароли, шифруя их при помощи алгоритма MD5. Уповать на разнообразие, которое, как правило, приводит к увеличению надежности, в данном случае не приходится. Компания Juniper — единственный конкурент Cisco на рынке магистральных маршрутизаторов. Ее оборудование работает с JunOS, созданной непосредственно на основе операционной системы FreeBSD и, как следствие, использующей тот же самый алгоритм.

В июле 2003 года NetCraft объявила, что ОС FreeBSD установлена почти на 2 млн сайтах, поддерживающих около 4 млн имен хостов [1]. Причем это — только общедоступные Web-серверы, обнаруженные в результате автоматизированного опроса. Никто даже не пытался всерьез оценить, сколько машин с FreeBSD работают в других системах, от межсетевых экранов до встроенных устройств. Так, недавно мне сообщили, что системы обработки документов, использующие FreeBSD, в США применяются для выполнения около 10% всех финансовых межкорпоративных транзакций.

Практически все Linux-системы включают в себя GNU Libc. По моим оценкам, несколько миллионов таких систем по всему миру (от домашних компьютеров до мэйнфреймов IBM) по умолчанию используют алгоритм MD5.

Защищенные паролями Web-страницы часто используют кодировщик паролей базовой операционной системы и содержат различные виды информации, закрытой для широкой публики. Большинство таких сайтов, скорее всего, — порнографические, но остальную часть составляют страницы, содержащие номера кредитных карт, информацию о пациентах или военные секреты.

Только одно замечание. Если я сделал ошибку в алгоритме или в его реализации, все это может в один прекрасный момент полететь в тартарары.

До того как взяться за эту статью, я не задумывался о судьбе фрагмента кода, который я написал, сидя на полу, пока мой сын учился ползать. И, честно говоря, осознание масштаба меня слегка напугало. К счастью, у меня нет причин считать, что я сделал ошибку. А с учетом достаточной надежности MD5 маловероятно, что какая-либо ошибка когда-нибудь проявится.

А что, если...?

Но только представьте, что я ошибся и затем обнаружил серьезный изъян в алгоритме. Я считаю, что все проблемы с программной защитой должны становиться достоянием гласности. Кроме того, я готов всем «хорошим людям» сразу же рассказать о найденной ошибке. Но в состоянии ли я это сделать?

Поскольку я знаю, что в FreeBSD, GNU, RIPE и в продуктах Cisco используется данный алгоритм, я могу связаться с соответствующими специалистами по защите прежде, чем CERT объявит о проблеме публично. Буквально за несколько часов (максимум дней) заплаты будут разосланы и установлены на 90% существующих систем.

А вот что произойдет с пользователями, о которых мне не известно? Сколько организаций импортировали мой алгоритм в свои продукты — готовые решения или внутренние приложения? И никто о них не знает. И я не смогу их предупредить, прежде чем о найденном изъяне не будет объявлено во всеуслышанье. Они узнают об ошибке из официального бюллетеня CERT одновременно со злоумышленниками. И то — если поймут, что этот бюллетень касается и их систем.

Но и с обратным нисколько не лучше. Предположим, один из пользователей обнаружил проблему и попытался меня о ней предупредить. По причинам, названным Аланом Гринспеном «неразумным изобилием» [2], адреса электронной почты, который я указал в оригинальной лицензии на исходный текст своей программы, больше не существует. В результате первая попытка такого пользователя связаться со мной практически наверняка окажется неудачной.

Найти мое имя с помощью Google особого труда не составит, поэтому пользователь рано или поздно до меня доберется. Но если автора свободно распространяемой программы зовут, к примеру, Боб Смит, вряд ли пользователю улыбнется удача. Более того, начав свой поиск с написанной заново реализации алгоритма по версии GNU Libc, он не сможет узнать даже мое имя — и, естественно, никого не найдет.

Новый риск

Специалисты, которые занимаются разработкой и разработкой программ, должны попытаться уменьшить новый риск, порожденный феноменом Open Source. Правда, если правовые отношения между поставщиком программ и их пользователем состоит, главным образом, из уведомления в юридический отдел со словами «вы не сможете подать на меня в суд никогда!», риск уменьшить невозможно.

Не думаю, что существует универсальный рецепт. В каждом конкретном случае пользователи должны взвесить риски и оценить имеющиеся ресурсы, чтобы найти приемлемый компромисс. Я не в состоянии предложить решение для всех.

Но все же у меня есть одна идея. Пошлите автору письмо со словами: «Пожалуйста, считайте это конфиденциальной информацией. FroBoz Dam Construction использовала вашу программу в своем проекте строительства противопаводковой дамбы №3. Благодарим вас!». Авторы свободно распространяемых программ высоко ценят уважение и признательность пользователей. Поэтому, как мне кажется, они будут хранить подобные сообщения в особой папке и, в случае необходимости, всегда смогут узнать обратные адреса своих почитателей. Так что на всякий случай — держите связь!

Литература

1. Nearly Two Million Active Sites Running FreeBSD. Netcraft News, 12 July 2003. http://news.netcraft.com/archives/2003/07/12/ nearly_2_million_active_sites_running_freebsd.html.
2. S. Reier. Five Years Later, Greenspan's 'Irrational Exuberance' Alert Rings True. Int'l Herald Tribune, 1 December 2001. www.iht.com/articles/40648.htm.

Открытый скептицизм

Если вы решили интегрировать свободно распространяемые программные компоненты в критически важное приложение, будьте готовы к тому, что это вызовет немалый скепсис и у вашего заказчика, и у руководства. Вот наиболее часто возникающие в такой ситуации вопросы.

Что произойдет, если разработчики открытых программ решат прекратить реализацию своего проекта? Если проект действительно будет закрыт, а от него существенным образом зависит ваше приложение, вам придется самим поддерживать этот код. Некоторые считают, что риска можно избежать, самостоятельно создавая необходимый компонент с самого начала. Но что случится, если ведущий разработчик аналога такого компонента уволится, не завершив работы? Подобного риска избежать нельзя. Вы можете только уменьшить его, хорошо изучив разработчиков, которым доверяете создание самых важных частей своей системы.

Если этот компонент представляет столь большую ценность, почему он распространяется бесплатно? Многие считают: даром — значит, плохо. Скептики даже предпочтут, чтобы вы купили компонент, а не получили его бесплатно. Напомните им, что разработчики свободно распространяемого программного обеспечения получают вознаграждение не от прямых продаж своих продуктов.

Откуда вы знаете, что качество данного продукта приемлемо? Для начала почитайте, что пишут о нем пользователи, поэкспериментируйте с этим продуктом сами. Кроме того, сравните собственных сотрудников с членами коллектива, создавшего данную свободно распространяемую программу. Скажем, если ваши разработчики — эксперты в области трехмерного моделирования, то в состоянии ли они за несколько месяцев написать систему шифрования лучше, чем трудившиеся в течение года лучшие профессионалы-криптографы?

Как обстоит дело с лицензированием? В зависимости от того, что вы планируете делать со своим приложением, этот вопрос, возможно, потребует тщательного изучения. Обсуждение специфики лицензирования свободно распространяемого программного обеспечения выходит за рамки данной статьи. Скажем лишь, что многие открытые проекты с ограничивающими лицензиями позволят получить более либеральную лицензию за номинальную плату. Очень часто можно начать разработку незамедлительно, а заплатить после того, как удалось убедиться, что продукт полностью соответствует предъявляемым требованиям.