Open Source: уроки для программной инженерии

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

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

СПО как чудо-средство

Двадцать пять лет тому назад выдающийся разработчик программного обеспечения Фред Брукс в своей знаменитой работе No Silver Bullet — Essence and Accidents of Software Engineering заявил: «Не существует таких достижений ни в технологиях, ни в методах управления, которые сами по себе обещали бы в течение ближайшего десятилетия хотя бы на порядок повысить производительность, надежность и простоту разработки программного обеспечения». Тем не менее многие утверждают, что СПО это именно такое «чудо-средство».

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

Еще одно упоминаемое преимущество — быстрые темпы разработки. Сообщество Open Source спорит с известным законом Брукса: «Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше», который был выведен автором на основании личного опыта управления разработкой IBM OS/360. Этому закону противопоставляется закон Линуса: «При достаточном количестве глаз все ошибки выходят на поверхность».

Среди приложений самых разных классов есть немало примеров продуктов из разряда Open Source исключительного качества и надежности. Безусловно, программные системы вроде ядра Linux или сервера Apache работают столь надежно, что практически не оставляют шанса на появление альтернатив.

Трезвый взгляд

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

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

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

Качество

В рамках исследования, проведенного в 2002 году, оценивались проблемы качества SUSE Linux 6.0. С помощью анализатора кода Logiscope были обработаны более 600 тыс. строк кода в 100 модулях, и выяснилось, что только половина строк отвечает приемлемым стандартам качества. Из оставшихся строк 31% требовали комментариев, 9% — дополнительного изучения, 4% — тестирования, а 6% необходимо было полностью переписать. Следует отметить, что данные результаты вполне типичны для программной индустрии в целом — обычно только половина всех модулей отвечает общепринятым стандартам.

В 2005 году исследователи изучили реализацию Address Resolution Protocol в стеке TCP/IP Linux и обнаружили в ней многочисленные проблемы с качеством кода.

Отзывчивость сообщества

Утверждение о грамотных откликах сообщества Open Source тоже можно подвергнуть сомнению. Как показали результаты исследования процесса разработки операционной системы FreeBSD, проведенного в 2001 году, несложный код получает больше откликов, но обычно они бесполезны. Похоже, работает нечто вроде обратного «закона Парето» (эмпирического правила о том, что 20% усилий дают 80% результата, а остальные 80% усилий — лишь 20% результата): 99% разработчиков программ с открытым кодом замечают 80% ошибок, но лишь 1% разработчиков могут заметить трудно идентифицируемые 20%. Более того, данное исследование показало, что по структурным недоработкам обычно поступает очень мало откликов, а это является серьезным недостатком.

Проблемы также может создать тот факт, что СПО — это выбор технически грамотных. Том Надо на своем сайте OS/2 Headquarters утверждает, что разработчики проприетарного ПО всегда адресуют его «самым невежественным заказчикам», тогда как в сообществе Open Source ориентируются на «самых умных заказчиков» и поэтому могут позволить себе отказаться от удобств вроде дружественного к пользователю интерфейса. Подтверждением служат, например, комментарии пользователей Linux, публикующих описание захватывающего приключения, в которое превращается процесс установки ОС.

Уроки для СПО

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

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

Еще одним свидетельством важной роли модульности для СПО может служить утилита Sendmail, разработанная в конце 70-х в Калифорнийском университете Беркли Эриком Оллманом, который распространил исходный код среди всех заинтересованных. В результате утилита начала развиваться силами нескольких разработчиков, но возникли проблемы с интеграцией этих усилий, и Оллман переписал Sendmail, сделав программу модульной. Благодаря этому утилита стала прекрасно подходить для «массово-параллельной разработки», свойственной OSS, так как программисты получили возможность работать независимо друг от друга над разными компонентами. Сейчас Sendmail является господствующим маршрутизатором электронной почты Интернета, обрабатывающим 80% всех сообщений.

Модульный подход применим и к структуре проекта, и к кодовой базе: крупные СПО-проекты нередко состоят из множества малых. Благодаря такому подходу разрабатывать, исправлять и выпускать компоненты можно независимо друг от друга.

Конфигурационное управление — не менее важный элемент разработки OSS, для реализации которого существует ряд развитых инструментов. Кроме того, высоких ступеней развития в OSS достигли позаимствованные из программной инженерии принципы независимой коллективной экспертизы и тестирования.

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

Уроки для программной инженерии

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

Открытые инновации

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

• автономия, основа самоорганизации и гарант того, что индивидуальные участники будут сами стремиться к приобретению новых знаний;
• творческий беспорядок: когда участники не обязаны следовать организационным правилам, но стремятся к поиску альтернатив и оспариванию общепринятых аксиом;
• информационная избыточность: когда участники владеют большим объемом информации, чем требуется для решения конкретной задачи;
• необходимое разнообразие: когда участники обладают всевозможными навыками, необходимыми в условиях сложной и изменчивой среды, в которой они работают.

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

В большинстве СПО-проектов зависимость числа участников от масштаба проекта подчиняется эскпоненциальному закону, что утверждают Грег Мэди и другие в докладе The Open Source Software Development Phenomenon. Это очевидно на примере общеизвестных проектов. Несмотря на то что вину за проблемы с памятью в программе Firefox ранее возлагали на чересчур большое количество разработчиков, не стоит забывать, что тестовыми версиями этого браузера пользуются несколько тысяч человек, и примерно 20% из них находят время на то, чтобы составлять отчеты об обнаруженных ошибках. Эта гигантская группа пользователей — исключительно полезный ресурс.

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

Как в свое время заметил известный проповедник открытого кода Эрик Рэймонд, у каждого разработчика Open Source есть «своя зудящая царапина». Поэтому не случайно многие успешные СПО-проекты — это приложения для массового пользователя. С учетом приведенного замечания о том, что отзывы о структурных проблемах в таких продуктах редки, можно сделать вывод, что открытый код лучше всего подходит для разработки в «горизонтальных» сообществах с разнообразной специализацией участников и широким консенсусом по проектной архитектуре и требованиям к продукту. В «вертикальных» же сообществах, когда для разработки требований к продукту и его архитектуры необходимы знания в определенной узкой области, свободных продуктов создается меньше.

Учитывая инновационный потенциал СПО, парадоксальным выглядит тот факт, что в ряде первых открытых проектов копировались проприетарные программные продукты, однако именно в этих открытых «клонах» закрытых программ впервые появились многие уникальные особенности, которые позднее были перенесены в проприетарные аналоги.

Глобальная разработка ПО

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

Inner Source

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

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

Обычно компании применяют Inner Source, чтобы получить доход за счет успеха каких-либо проектов с открытым кодом. Между тем существуют важные различия между разработкой открытого и закрытого кода и между соответствующими сообществами. В традиционной разработке ПО разработчики и пользователи, участвующие в тестировании, обычно находятся в разных отделах или офисах. Из-за этого служащие могут быть не в курсе проектов и инноваций разработчиков, и нередко такая схема сотрудничества приводит к недостатку взаимного уважения и неэффективности взаимодействия.

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

Управление выпусками на основе расписания

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

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

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

В случае СПО, однако, не вполне ясно, каким образом заставить команду слабо связанных, распределенных по всему миру тысяч добровольных участников своевременно выпускать высококачественные программные продукты, иногда состоящие из миллионов строк кода. Есть немало свидетельств серьезности этой проблемы. Например, для Debian характерны постоянные задержки и непредсказуемость выпусков — между очередными стабильными версиями проходит до трех лет. Но все рекорды в этом случае бьет утилита компрессии gzip, у которой между стабильными релизами может пройти до 13 лет (1993-2006).

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

Хотя конкретные реализации принципа расписаний у разных проектов отличаются, есть общее свойство поэтапного продвижения к выпуску, когда на каждом этапе ужесточаются ограничения на внесение изменений. Эти механизмы контроля носят название «заморозки» (freezes) и служат для поэтапного прекращения разработки. Заморозки бывают следующих видов:

• заморозка функций (feature freeze): новая функциональность не может быть добавлена, главная задача данного этапа — устранение дефектов;
• строчная заморозка (string freeze): сообщения, отображаемые программой, например сообщения об ошибках, не могут быть изменены — это позволяет к выпуску перевести на поддерживаемые языки максимальное число сообщений приложения;
• заморозка кода (code freeze): требуется специальное разрешение на внесение любых изменений, вплоть до исправления ошибок.

При модульной схеме выпуска разработчики могут выпускать отдельные компоненты продукта по мере устранения в них дефектов, но при этом пользоваться расписанием для объединения модулей и тестирования интегрированного продукта, как это происходит в случае с Debian и пользовательским интерфейсом GNOME.

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

***

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

Брайан Фицджеральд (bf@ul.ie) — ведущий научный сотрудник Ирландского центра исследований программной инженерии Lero.