<< Пред. стр.

стр. 16
(общее количество: 22)

ОГЛАВЛЕНИЕ

След. стр. >>

шение репутации позволяет человеку удовлетворять его индивидуальные по-
Я участвую в создании
требности во внимании, возможности работать в команде и признании коллег.
66,2 77,8 68,8 73,1 73,1
открытого ПП потому, что
64,9 63,9 63,4 73,1 73,1
убежден в обязательности
По большому счету «социальный статус человека определяется не тем, чем он
53,2 69,4 51,6 69,2 53,8
свободы информации
42,2 38,9 46,2 34,6 46,2
управляет, а тем, какую память он о себе оставляет»31. Именно это поддерживает
Отсутствие оплаты за 23,4 25,0 20,4 15,4 42,3
участие в проекте Linux стало добровольцев в их постоянном участии в проекте. В противном случае они
22,1 27,8 23,7 11,5 34,6
для меня серьезным
покидают сообщество, после того как сочтут, что приобретенной ими репута-
разочарованием
ции достаточно для признания на рынке труда.
Внешние стимулы
Для меня очень важно
Другая составляющая мотивации — внутренние стимулы. В отличие от вне-
повысить собственные
шних стимулов, внутренние заставляют добровольцев участвовать в проекте,
навыки программирования
поскольку для них ценен сам факт участия в столь престижной работе. К числу
Участие в проекте
способствует моей
подобных стимулов можно отнести стремление к новизне, жажду приключений,
повседневной работе,
желание удовлетворить собственную любознательность, повысить профессио-
поскольку для меня очень
нальное мастерство. По мнению авторов, под эту категорию стимулов подпадают
важно располагать более
совершенными
заявления опрошенных участников проекта о том, что их привлекает «удоволь-
программными средствами
ствие от самого процесса программирования», «убежденность в необходимости
Повышение качества ядра
свободы информации», «отрицание того, что деньги решают все». В частности,
Linux
Личное общение с другими
«радость от мастерски выполненной работы проистекает из доказательства самому
разработчиками ПП
себе собственных талантов и способностей»32.
Преимущества для
Как описанная схема мотивации разработчиков способна обеспечить устой-
карьерного роста
Завоевание репутации
чиво высокое качество ПП, демонстрируемое Linux? Поиск ответа на этот воп-
опытного программиста
рос подводит нас к следующему аспекту рассмотрения данного проекта.
внутри сообщества
разработчиков Linux

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

Источник: http://www.psychologie.uni-kiel.de/linux-study/writeup.html
202 служит тем местом, где разработчики могут экспериментировать с новыми тех-
Linux доказывают, что численность сообщества разработчиков системы за пе- нологиями и проверять возникшие идеи. Процесс обучения разработчиков на
риод с 1995 по 2000 г. увеличилась в четыре раза. Чем больше размеры сооб- собственных ошибках может быть легко реализован на экспериментальном ко-
щества, тем сложнее координировать и изучать все возможные взаимосвязи довом дереве, не создавая при этом помех для пользователей основной части
между составными частями ПП, разрабатываемыми разными представителями ПП. На экспериментальном дереве проверяют новейшие свойства ПП и инно-
этого сообщества. То, что разработчики Linux сумели справиться с этой про- вационные решения, в то время как на основном устойчивом дереве сосредото-
блемой без ущерба для качества системы, можно считать наиболее впечатляю- чены более зрелые программы. Структура, принятая сообществом разработчиков
щим их достижением. ядра Linux, представляется наиболее подходящей для реализации таких задач, как
Официальная структура, принятая сообществом для решения проблем коор- поощрение вариативности решений, постепенное совершенствование системы и
динации, основана на принципе модульного построения. Принятие решений на накопление опыта разработчиками. Все эти задачи являются важными
уровне отдельных модулей децентрализовано. Модульная структура гарантирует составляющими успешных инноваций.
разработчикам полную свободу одновременной работы над отдельными моду- Помимо официальных структур, сообщество разработчиков ядра Linux опи-
лями системы без риска создания помех для работы над другими модулями. Без рается на неформальные, подразумеваемые схемы координации своей деятель-
применения модульного принципа построения системы и при большом числе ности. Неформальность этих схем обусловлена тем, что состав исполнителей
разработчиков, совместно трудящихся над созданием компьютерной програм- формируется непосредственно в процессе выполнения отдельных задач. Не су-
мы, любые, самые мелкие изменения в одной ее части могут создавать суще- ществует официального закрепления каких-либо задач за определенными доб-
ственные проблемы с качеством, приводя к необходимости изменять и даже ровольными их исполнителями. Для того чтобы проследить эти неформальные
полностью перерабатывать остальные части программы. Поэтому главный иде- отношения между разработчиками, был применен метод, основанный на про-
олог Linux Лайнус Торвалдс (Linus Torvalds) решил использовать загружаемые смотре заголовков электронных сообщений, присутствующих в архиве элект-
модули версии 2.0.0 Linux, реализованной в 1996 г., с тем чтобы установить ронной переписки по Linux. При этом было выявлено, что добровольные учас-
границы, в пределах которых разработчики каждого модуля получили полную тники разработки системы вносят свой вклад в решение самых разнообразных
свободу в их отработке и внедрении. Благодаря этому модульная структура сис- задач, таких как поиск и устранение ошибок, испытания системы, написание
темы обеспечила надлежащую координацию между отдельными ее составными руководств, добавление новых возможностей, размещение операционной сис-
частями, позволившую минимизировать проблемы качества. темы на различных компьютерных платформах.
Кроме того, модульность позволяет системе непрерывно развиваться. Без это- Часть исполнителей специализируются на решении задач определенного типа,
го в случаях, когда разработчик оригинального модуля покидает сообщество, а поскольку для них требуются специальные навыки программирования. Напри-
другие разработчики присоединяются к нему позднее, им было бы трудно вклю- мер, выявлять ошибки и присылать соответствующие сообщения, подавать зап-
читься в работу из-за слишком высокого уровня сложности всей системы. Изве- росы на придание системе дополнительных возможностей способно большин-
стно, что при прочих равных условиях компании с высокой текучестью кадров ство пользователей, но лишь немногие из них обладают достаточной квалифи-
испытывают более серьезные трудности с поддержанием качества своих продук- кацией, чтобы разработать и прислать «заплатки» к программам для устранения
тов13. Это особенно справедливо при разработке ПП, создаваемых, подобно Linux, определенных проблем с их применением. Опрос участников разработки ядра
в виртуальной среде, когда разработчики могут свободно в любой момент поки- Linux показал, что большинство из них участвовало в создании системы в фор-
нуть сообщество или присоединиться к нему. Модульный принцип построения мах, не требующих специальных навыков программирования. Менее половины
системы позволяет четко и понятно формулировать задачи, стоящие перед новы- опрошенных было реально вовлечено в написание компьютерных программ.
ми членами сообщества. Таким образом, модульность служит важным структур- Только 30% из них прислало хотя бы по одной «заплатке» к программам в архив
ным механизмом разработки, который позволяет минимизировать проблемы ка- разработки и лишь 45% респондентов смогло сообщить о том, что ими написана
чества путем упрощения решаемых задач и предупреждения нарушения непре- хотя бы одна программная строка. Кроме того, только 45% опрошенных уча-
рывности процесса разработки в связи со сменой исполнителей. ствовало в проектах разработки отдельных подсистем, но 47% вообще не при-
Другой официально признанной сообществом разработчиков Linux структу- нимало участия в создании хотя бы одной подсистемы.
рой является параллельное существование двух кодовых деревьев, из которых Анализ распределения исполнителей различных задач позволил выявить че-
одно предназначено для экспериментирования, а другое — для уже отработан- тыре категории участников разработки ядра Linux, образующих двухъярусную
ных программ (основное устойчивое дерево). Экспериментальное кодовое дерево
_205
204 Глава 9 Обеспечение качества программного продукта
«Центр». Основатель и бессменный лидер проекта создания
структуру (табл. 9.2). Эта структура включает небольшой по численности операционной системы Linux Л. Торвалдс контролирует выпуск официальных
«центр», в который входят лидер проекта и около сотни ответственных за от- версий системы. Именно ему принадлежит решающее слово относительно
дельные подсистемы, и обширную «периферию», объединяющую собственно целесообразности включения того или иного дополнения или исправления в ядро
разработчиков и людей, присылающих сообщения об ошибках. В рамках двухъя- Linux. Несмотря на мифы о его диктаторских замашках35-37, Торвалдс, принимая
русной структуры и протекает эволюционный процесс отработки операцион- ключевые решения, обычно консультируется с людьми, отвечающими за
ной системы34. На «периферии» предлагаются и испытываются изменения к отдельные подсистемы, особенно в тех случаях, когда речь идет о проблемах, на
программам, из которых затем «центр» отбирает наиболее ценные для включе- решение которых тот или иной ответственный исполнитель потратил немало
ния в систему. Если в традиционных моделях проведения НИОКР руководи- личного времени.
тель проекта сам принимает решения о том, что подлежит разработке и как Согласно списку имен, содержащихся в файле Maintainers, за 132 подсисте-
внедрять полученные результаты, то в модели создания открытых систем эти мы, составляющие ядро Linux, отвечает 121 человек, причем за некоторые
решения разделены. На «периферии» сообщества разработчиков вырабатыва- подсистемы отвечают несколько человек. Ряд ответственных лиц закреплен за
ют предложения по совершенствованию системы и приданию ей новых воз- несколькими подсистемами одновременно. Анализ показывает, что закрепле-
можностей и характеристик, а в «центре» отбирают из поступивших предложе- ние ответственности за подсистемы происходит крайне неравномерно. Среди
ний заслуживающие включения в официально рассылаемые версии системы, девяти модулей, входящих в версию Linux 2.2.14, за самый крупный из них —
которые затем проходят многочисленные циклы доработок. модуль драйверов устройств — отвечает 72% от общего числа ответственных
исполнителей. Этот модуль включает 55% всех подсистем ядра Linux, на его
Таблица 9.2
долю приходится 58% объема ядра в мегабайтах и 63% программных строк.
Двухъярусная структура сообщества разработчиков ядра Linux,
Следующий по размеру модуль вчетверо меньше модуля драйверов. По срав-
включающая четыре категории участников
нению с программами, входящими в другие модули, драйверы устройств отно-
Основные роли Суммарное число
Число Процент от
сительно просты в написании, но более сложны для отладки. Поэтому пред-
разработчиков сообщений по e-mail
участников общего числа
ставляется оправданным, что большая часть усилий сообщества разработчиков
Linux от этой категории
данной сообщений в
участников в архиве ядра Linux сосредоточена именно на создании интерфейсов для тех перифе-
категории архиве

рийных устройств, которые каждый из разработчиков хотел бы подсоединить
Лидер (руководитель) 2840 (третье место по
к своему компьютеру, особенно если учесть многообразие производителей и
проекта числу сообщений)
марок этих устройств, имеющихся на рынке и доступных для пользователей
Ответственные за 37 387 (включая
1,4
1 121*
подсистемы сообщения лидера компьютеров.
Разработчики проекта)
«Периферия». Чтобы определить состав команды разработчиков, был про-
20 563
смотрен архив e-mail-системы за период с 1995 по 2000 г. и отобраны все авто-
18,8
2605**
ры, приславшие хотя бы по одному сообщению, где в строке «Содержание»
12,3
присутствовало слово PATCH. Предполагалось, что эти сообщения относятся
10,3
к предлагаемым «заплатам» к программам, устраняющим выявленные ошибки
1562"* 4216 2,1 или добавляющим новые свойства. В результате было выявлено 2605 человек,
Авторы сообщений
об ошибках
которых с полным основанием можно включить в состав команды разработчиков
системы, существовавшей в 1995—2000 гг. Другую часть команды составляют люди,
* Установлено по списку имен, содержащихся в файле Maintainers, входящем в перечень фай- сообщающие о выявленных ими ошибках и недостатках программ. Они были
лов исходных кодов системы.
определены путем отбора авторов сообщений, где в строке «Содержание» присут-
** Оценено по именам авторов сообщений, представленных в архиве e-mail и содержащих слово
ствовало слово OOPS. Задачи таких участников сводятся к выявлению ошибок,
PATCH (заплата) в строке «Содержание сообщения».
их описанию и подаче предложений по их устранению38. С 1995 по 2000 г. число
*** Оценено по именам авторов сообщений, представленных в архиве e-mail и содержащих слово
OOPS в строке «Содержание». OOPS — английское междометие, эквивалентное русскому
авторов сообщений об ошибках составило 1562 человека, причем некоторые
восклицанию «Ой!» и выражающее удивление или испуг от ошибки. — Примеч. пер.
члены сообщества разработчиков входят в обе указанные группы одновремен-
Источник информации: архив e-mail по ядру Linux за период с июня 1995 г. по август 2000 г.
но. 45% людей, сообщавших об ошибках программ, также прислали по одному
207
206 Глава 9 Обеспечение качества программного продукта
Качество в XXI веке

ности построения сообщества разработчиков ядра Linux, о которых шла речь выше,
сообщению с пометкой PATCH, a 29% авторов «заплат» — не менее одного
сообщения с пометкой OOPS в строке «Содержание». помогают ему успешно справляться с растущими масштабами и разнообразием
Существует распространенное мнение о том, что в процессе разработки OSS решаемых задач.
отсутствуют всякий контроль и ответственность39-41. При этом считается, что про-
блемы координации усилий разработчиков порождают задержки и хаос в процес- Открытый эволюционный процесс отработки ядра Linux
се создания систем. Проведенный анализ тем не менее убеждает в наличии
Как уже отмечалось, двухъярусная структура сообщества разработчиков ядра
в проекте Linux как официальных, так и неформальных механизмов координа-
Linux способствует реализации эволюционного процесса отработки системы,
ции работ. Хотя крупномасштабные разработки обычно принято ассоциировать
с сильной централизацией процесса принятия решений42, в данном случае меха- при котором «центр» сообщества отбирает или отклоняет многочисленные пред-
ложения по доработкам, поступающим с «периферии», включая наиболее по-
низмы координации деятельности сообщества разработчиков ядра Linux уста-
лезные дополнения в очередную официальную версию системы.
навливают правила, согласно которым только принципиальные решения, такие
Ключевым звеном, связывающим процессы выработки и отбора дополнений
как официальная рассылка версий системы, принимаются централизованно, а
и изменений системы и придающим процессу ее отработки непрерывность и
конкретные решения, касающиеся конструкции программ, принимаются на
постепенность, служит рассмотрение и анализ предложений со стороны коллег.
уровне отдельных модулей, но при полном контроле со стороны ответственных
Как указано в файле Maintainers, «всякое, даже самое незначительное предло-
исполнителей за каждый модуль. Кроме того, процесс эволюционной отработки
жение должно быть обсуждено по крайней мере с четырьмя-пятью, а желатель-
системы происходит в рамках двухъярусной структуры, «центр» которой отби-
но и с большим числом специалистов». Рассмотрение предложений коллегами
рает доработки, создаваемые на «периферии», для включения в очередную офи-
позволяет заменить контроль качества, когда ошибки выявляют в готовом про-
циальную версию системы, а параллельно существует опытная версия, в рамках
дукте, их предупреждением на возможно более ранних стадиях. Такой подход
которой проверяются решения, имеющие новаторский характер.
хорошо согласуется с опытом организаций, добившихся высочайшего уровня
Описанная структура доказывает, что сообщество разработчиков ядра Linux
качества своей продукции45,46. В процессе взаимодействия с коллегами происходит
представляет собой систему, состоящую из многочисленных мелких модулей,
также коллективное обучение разработчиков. Таким образом, процесс отработки
причем каждый модуль функционирует в рамках естественной двухъярусной
ядра Linux можно с должными основаниями считать процессом постепенного и
структуры. Такая система отличается высокой гибкостью. Каждый ее модуль
непрерывного совершенствования продукта, который должен быть непременной
представляет собой органичную подсистему, в рамках которой участник решает
особенностью любой самообучающейся организации, стремящейся к высокому
свои задачи «в пределах собственного понимания целей сообщества разработ-
чиков системы в целом»43. качеству своей продукции и услуг.
Торвалдс считает, что процедура анализа любых предложений коллегами по
Фред Брукс (Fred Brooks) выявил наличие сильной положительной корреля-
сообществу разработчиков ядра Linux придает всему процессу отработки систе-
ции между размерами организации и продолжительностью ее запаздывания с
мы не только эволюционный, но также открытый характер47. Он указывает, что
выходом на рынок с новыми предложениями. Эта зависимость получила назва-
ние закона Брукса44. Анализ показывает, что эта корреляция может быть ослаблена, «распространенная ошибка заключена в участии в проверках программы ее со-
ставителей. В таких условиях анализ коллегами по сообществу лишен всякого
если поручать решение отдельных задач дополнительным исполнителям. Брукс
смысла. Задача состоит в том, чтобы подобрать для проверки программ других
считал, что сложность и стоимость коммуникаций внутри проекта растут пропор-
людей, обладающих собственным опытом, отличающимся от того, каким обла-
ционально квадрату числа исполнителей, в то время как объемы выполненной
дают авторы программы».
работы увеличиваются с ростом числа исполнителей линейно. Однако в случае
Рассмотрение любых предложений коллегами представляет собой открытый
разработки ядра Linux появление в любом модуле большего числа людей, сооб-
процесс, в котором все предлагаемые изменения программ и их критика доступ-
щающих об ошибках, никак не влияет на работу над другими модулями и не ведет
ны для обсуждения и ссылок всем пользователям Интернета. Открытость про-
к усложнению как самого модуля, так и системы в целом. Более того, применение
цесса разработки системы позволяет членам сообщества, обладающим разным
Интернета и веб-приложений, благодаря которым обеспечивается многосторон-
опытом и знаниями, анализировать любые предложения по изменению ее ис-
нее общение разработчиков, позволяет значительно сократить коммуникацион-
ходных кодов. Благодаря тому что любое предложение рассматривается многи-
ные затраты. Понятно, что Брукс не мог прогнозировать появление подобных
ми разработчиками, его автор, который мог что-то упустить или не обладает
средств связи между участниками проекта. Таким образом, структурные особен-
208 Качество в XXI веке
Глава 9 Обеспечение качества программного продукта
209
достаточным опытом для решения возникающих проблем, получает необходи- версиями системы. Он, в частности, писал: «Существо открытого процесса раз-
мую помощь в выявлении ошибок или других проблем, а также в повышении работки заключено в том, что люди видят все, что происходит (курсив автора).
качества предлагаемых изменений к программам. Разнообразие уровня подго- Не следует допускать, чтобы им был виден только конечный результат, скажем,
товки и опыта многочисленных разработчиков — это мощный инструмент для через год. Необходимо стремиться к тому, чтобы случайный человек имел возмож-
поиска, анализа и устранения ошибок в программах. ность видеть любые, самые мелкие доработки системы — тогда, возможно, он
Одним из способов активизации анализа программ является увеличение час- сумеет избавить разработчиков от глупых ошибок49. Ныне же, имея дело с гро-
тоты рассылки новых версий и сокращение продолжительности цикла разработки мадными «заплатами» к программам, их пользователи ощущают беспомощность.
каждой из них. Чем скорее требуется получить заключения на новую версию Если же публиковать мелкие доработки по мере их поступления и иметь при
системы, тем больше стимулов для разработчиков внести свой вклад в ее отработ- этом веб-сайт, на котором их можно комментировать, люди получают возмож-
ку. Таким образом, необходимость быстро отреагировать на новую версию сис- ность быть в курсе проводимых изменений системы и указывать мне и осталь-
темы поддерживает сообщество разработчиков в должном тонусе. Тем самым ным разработчикам на те глупости, которые мы совершаем»50.
находит свое воплощение базовый принцип теории развития систем48. По срав- В этом и заключена сущность модели непрерывного совершенствования, о
нению с коммерческими ПП Linux представляет собой постоянно развивающуюся которой столько говорят.
систему с очень частыми обновлениями ее версий (табл. 9.3). Большинство
Анализ показывает, что руководитель проекта и ответственные за отдель-
фирм — разработчиков коммерческих ПП объявляют о создании новых программ
ные модули системы очень консервативно подходят к отбору предлагаемых
или доработанных версий существующих продуктов один раз в несколько лет,
исправлений и «заплат» к программам, включаемым в официальные версии
причем начало их массовой реализации зачастую задерживается, хотя в этих фир-
системы. Только 23% опрошенных членов сообщества разработчиков ядра Linux
мах существуют ежедневно обновляемые отработочные версии каждого продукта,
подтвердили, что, по крайней мере, одно их предложение было реализовано.
которые имеют хождение только внутри организации. (В отработочных версиях
С одной стороны, такой подход обеспечивает сохранение устойчивости системы,
продукта ежедневно все файлы компилируются заново с учетом принятых
но, с другой стороны, его эффективность может показаться достаточно низкой.
изменений и объединяются в рабочую программу, которая затем проходит опыт-
Ведь 77% предложений оказывается пустой тратой времени и сил. Однако
ный прогон — относительно простую проверку, чтобы выявить отсутствие сбоев
учитывая открытость процесса обсуждения всех предложений, те из них,
во время ее исполнения, — так называемый «smoke test».)
которые были отклонены, создают питательную среду для обучения как самих
Процесс отработки системы Linux представляет пример непрерывного и по-
авторов предложений, так и других членов сообщества. На этих примерах они
стоянного совершенствования, причем ни одна версия системы никогда не ста-
получают возможность изучить те критерии, которым должны отвечать
новится окончательной. Во время одной из он-лайновых дискуссий вокруг ядра
предложения, чтобы быть принятыми для дальнейшего совершенствования
Linux в августе 1999 г. Л. Торваддс заявил, что считает благотворным подход,
системы. Такая практика отбора формирует публичный форум, на котором .
при котором «люди имеют возможность видеть все, что происходит», и настой-
члены сообщества, анализируя замечания коллег, учатся тому, как следует
чиво доказывал важность частой замены мелких «заплат» к программам новыми
совершенствовать собственную работу.
С момента выхода в свет первой версии Linux, как показывают подсчеты,
Таблица 9.3 Хронология выхода основных официальных
версий Linux в среднем каждую неделю появлялось по одной новой версии этой операци-
онной системы. В табл. 9.3 и 9.4 приведена хронология появления официаль-
Версия Первый и последний Даты выпуска первого Частота обновлений
варианты версии и последнего варианта ных основных и экспериментальных версий ядра Linux, причем эксперимен-
версии
тальные версии, выходящие параллельно с основными, обновляются чаще.
Только в 1996 г. появилось 80 экспериментальных версий и примерно 30 ос-
Linux-1.0 12.03.94
1.0
новных версий системы.
Linux-1.2.0: Linux-1.2.13 06.03.95; 01.08.95
1.2 14 раз за 5 месяцев
Linux-2.0.0: Linux-2.0.38 08.06.96; 25.08.99
2.0 39 раз за 40 месяцев
Почти непрерывный поток версий Linux резко контрастирует со строго кон-
Linux-2.2.0: Linux-2.2.16 25.01.99; 07.06.00 17 раз за 18 месяцев
2.2
тролируемым и относительно редким выходом в свет новых версий коммерче-
ских ПП. Это различие находит отражение в продолжающейся дискуссии вок-
Linux-2.4.0-test1: 25.05.00; 23.08.00 7 раз за 3 месяца
2.4
Linux-2.4.0-test17
руг латания брешей в системах защиты. Основные дебаты ведутся вокруг того,
как часто следует доводить до широкой публики информацию об ошибках в ПП
211
Качество в XXI веке
210 Глава 9 Обеспечение качества программного продукта


Заключение
Таблица 9.4 Хронология выхода экспериментальных
версий Linux
В настоящей главе приведены результаты анализа процесса разработки ядра
Версия Первый и последний Даты выпуска первого Частота обновлений
варианты версии и последнего варианта
операционной системы Linux, позволяющие выявить основные условия, обес-
версии
печивающие устойчивое поддержание ее высокого качества. Помимо общей схе-
мы, присущей процессам создания OSS, существует ряд других факторов, по-
Linux-1.1.13: Linux-1.1.95 22.05.94; 01.03.95 83 раза за 11 месяцев
1.1
Linux-1.3.0: Linux-1.3.100 11.06.95; 09.05.96 101 раз за 11 месяцев
зволяющих успешно разрабатывать ПП высочайшего качества с превосходными
1.3
Linux-2.1.0: Linux-2.1.132. 30.09.96; 22.12.98 133 раза за 27 месяцев
2.1
характеристиками. Существо процесса разработки OSS заключается в мобили-
Linux-2.3.0: Linux-2.3.51 11.05.99; 10.03.00 52 раза за 10 месяцев
2.3 Linux-pre2.0.1: Linux-pre2.0.14 11.05.96; 05.06.96 14 раз за 1 месяц
зации и координации усилий многочисленных разработчиков, обладающих са-
Рге-2.0 Linux-2.2.0-pre1: Linux-2.2.0-pre9 28.12.98; 20.01.99 9 раз за 1 месяц
Рге-2.2
мыми разнообразными талантами, в рамках формализованных и неформальных
организационных структур. Помимо этих структур, модульный принцип пост-
роения системы, использование двух параллельно существующих кодовых дере-
Рге-2.4 Linux-2.3.99-pre1: Linux-2.3.99-pre9 14.03.00; 23.05.00 9 раз за 2 месяца

вьев и двухъярусная структура сообщества разработчиков обеспечивают посте-
пенное и непрерывное повышение надежности продукта и дополнение его но-
Примечание. Обозначение версий системы и их вариантов производится с использованием иерар-
хической системы нумерации, в которой первая цифра обозначает главную версию, а вторая —
выми прогрессивными свойствами в ходе открытого эволюционного процесса
соответствующее ей дерево версий и вариантов. Основным версиям соответствуют четные вто-
рассмотрения и анализа вносимых предложений коллегами по сообществу раз-
рые цифры в обозначении (например, 2.0; 2.2; 2.4), а экспериментальным — нечетные (напри-
мер, 2.1; 2.3). работчиков.
и заниматься их устранением. Поставщики коммерческих ПП утверждают, что
они должны располагать достаточным временем для решения обнаруженных
проблем, перед тем как делать их достоянием общественности, чтобы не ин-
формировать хакеров об уязвимости ПП. Однако специалисты по компьютер-
ной безопасности считают целесообразным доводить подобную информацию до
пользователей как можно раньше, чтобы те оказывали давление на поставщи-
ков, заставляя их быстрее латать возникшие бреши в защите и устранять другие
ошибки51. Применительно к Linux данная проблема стоит не столь остро, чем
для коммерческих ПП. Безусловно, Linux тоже испытывает определенные слож-
ности, обусловленные уязвимостью системы по отношению к действиям хакеров,
но, по словам одного из пользователей, «сообщество разработчиков ядра Linux
намного быстрее реагирует на проявления проблем безопасности, нежели по-
ставщики коммерческих операционных систем. Выявление и латание брешей
в защите Linux происходит публично и ведется намного быстрее»52. MITRE*
идет в своих оценках еще дальше, утверждая в своем отчете, что способность
быстро латать бреши, обеспечивая защиту против новых угроз кибернетическо-
го терроризма, «является отличительной чертой, присущей разработке ПП с
открытыми исходными кодами, которая недоступна системам с закрытыми ис-
ходными кодами»53. Продукты с открытыми кодами обладают заметными пре-
имуществами в смысле обеспечения их защиты, поскольку их исходные коды
всегда доступны для тщательной проверки и анализа. Исходные коды коммер-
ческих ПП хуже поддаются модификации54.

Интернет-агентство полного цикла. — Примеч. ред.
Глава 9 Обеспечение качества программного продукта
212 Качество в XXI веке
28
See note 15.
Ссылки и примечания 29
Raymond E. S. Homesteading the Noosphere // First Monday: Peer-Reviewed Journal on the Internet
(1998).
1
Ядро операционной системы планирует решение различных задач на компьютере, включая 30
Lerner J. and Tirole J. The Simple Economics of Open Source // NBER (working paper, 2000).
исполнение пользовательских приложений, например, подключение к веб-браузеру, использо

<< Пред. стр.

стр. 16
(общее количество: 22)

ОГЛАВЛЕНИЕ

След. стр. >>