Главная | Новости | Информация | Статьи | Программы Законы | Ссылки | О проекте | Off topic

Повторный взгляд на Собор и Базар

 
Эта статья предлагает обзор недостатков публикации Эрика Раймонда (Eric Raymond, ESR) "Собор и Базар" (The Cathedral and the Bazaar, или CatB) наряду с более последовательной демонстрацией внутренней противоречивости метафоры "базара". Данная работа также в определенной степени является реакцией на выход новой книги Эрика Раймонда "Собор и базар: размышления случайного революционера по поводу Linux и открытых исходников" [The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary.--- Sebastopol, Calif.: O'Reilly & Associates, 1999]. В статье также предложена более объективная картина социального процесса соревнования за статус при разработке программ с  открытыми исходными текстами.

Содержание

• Введение
• Пробелы и недостатки аргументации "Собора и Базара"
• Состязание за статус в коллективах разработчиков, основанных на Интернете.
• Заключение

Введение

"Факты --- упрямая вещь, и каковы бы ни были наши желания, склонности либо веления наших страстей, они не могут поколебать факты и улики."
- Джон Куинси Адамс

Выход новой книги Эрика Раймонда (Eric Raymond или ESR) "Собор и базар: размышления случайного революционера по поводу Linux и открытых исходников" [The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary.--- Sebastopol, Calif.: O'Reilly & Associates, 1999] делает критический анализ его наиболее влиятельной статьи ("Собор и Базар" -- прим. автора) весьма актуальным. Хотя эта книга включает помимо статьи "Собор и Базар" (СиБ) (The Cathedral and the Bazaar, CatB) целый ряд других статей Эрика Раймонда, ни одна из них не написана на том же уровне и не столь влиятельна, как СиБ. Неудивительно, что Собор и Базар иногда считают Манифестом Движения за открытые исходные тексты. Поэтому данная статья посвящена анализу именно СиБ.

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

Как я отмечал в своей предыдущей статье, в СиБ метод разработки программ на базе открытых исходных текстов описывается как новое, революционное явление. Я считаю, что это всего лишь еще одна разновидность научного сообщества. Аналогично, для меня разработка Linux не является новой революционной моделью разработки программ, а всего лишь логическим продолжением проекта GNU Фонда Свободного Программного Обеспечения (Free Software Foundation, FSF). Этот проект тесно связан с Массачусетским Технологическим Институтом (MIT). Я убежден, что связь с этим вузом сыграла решающую роль в успехе проекта GNU, подобно тому, как связь с Университетом Хельсинки оказалась исключительно важной в обеспечении успеха разработки ядра Linux на его ранних, самых трудных стадиях.

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

Пробелы и недостатки аргументации "Собора и Базара"

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

• Закон Брукса (Brooks' Law) неприменим к распределенным разработкам, основанным на Интернете;
• "При достаточном количестве глаз все ошибки лежат на поверхности";
• Разработка Linux является классическим примером "базарной" модели разработки программ;
• Разработка программ методом открытых исходных текстов автоматически приводит к лучшим результатам;
• "Базарная" модель разработки является новой революционной моделью разработки программного обеспечения.

Закон Брукса неприменим к распределенным разработкам, основанным на Интернете

"Самообман --- это наиболее массовая форма лжи;
ложь другим людям встречается гораздо реже."
- Фридрих Ницше

"В книге Мифический человеко-месяц (The Mythical Man-Month) Фред Брукс (Fred Brooks) заметил, что время программистов не аддитивно; увеличение числа разработчиков проекта, который отстал от графика, ведет к еще большему запаздыванию. Он утверждал, что сложность и затраты на общение в проекте возрастают пропорционально квадрату числа разработчиков, в то время, как полезная работа возрастает только линейно. Это утверждение стало известным как "закон Брукса" и часто рассматривается как очевидный факт. Однако, если бы закон Брукса отражал существующее положение вещей, то разработка ядра Linux была бы невозможной."

"Возможно, в итоге культура открытых исходных текстов будет праздновать победу не потому, что сотрудничество морально или что "присвоение" программ (software "hoarding") аморально (предполагая, что вы являетесь сторонником этой точки зрения, чего нельзя сказать обо мне или Линусе), но просто потому, что мир закрытых исходников не может выиграть эволюционной гонки с коллективом разработчиков, практикующих метод открытых исходных текстов, поскольку последние могут использовать для решения проблем на порядок больше времени квалифицированных специалистов."

Во-первых, я хотел бы подчеркнуть, что известная книга Мифический человеко-месяц завоевала статус классической работы среди монографий, посвященных проблемам разработки программного обеспечения. Она, безусловно, на несколько порядков важнее СиБ, и никакая критика со стороны последней ничем этой книге не повредит. Целый ряд концепций, фраз и даже заголовков отдельных разделов этой популярной книги стали частью стандартной терминологии в области разработки программного обеспечения. Достаточно упомянуть "эффект второй системы" ("the second-system effect"), "десять фунтов в пятифунтовом мешке" ("ten pounds in a five-pound sack"), "планируй выбросить разработанную систему" ("plan to throw one away"), "Каким образом проект может опоздать на целый год?... постепенно, по одному дню." ("How does a project get to be a year late?...one day at a time"). В начале 60-х, занимая пост менеджера проекта Operating System/360 (OS/360), Фредерик Брукс заметил снижающуюся отдачу коллективов, включающих большое количество разработчиков, а также то, что подход к планированию срока выполнения проекта на основе подсчета так называемых человеко-месяцев является ложным. И это положение остается истиной в 1999 году совершенно так же, как оно было верно в 1975-м, когда книга была впервые опубликована.

Реальная проблема тезиса (о неприменимости закона Брукса), выдвинутого СиБ состоит в том, что благодаря популярности этой статьи подрывается понимание важности изучения книги Мифический человеко-месяц (которая, кстати, является одной из немногих книг на компьютерную тематику, сохранивших свою актуальность спустя несколько десятков лет после первой публикации) программистами, разрабатывающими программы методом открытых исходников. В действительности "закон Брукса" обычно формулируется как "добавление разработчиков на поздних стадиях запаздывающего программного проекта еще больше отодвигает срок его сдачи" ("adding manpower to a late software project makes it later"). Термин "мифический человеко-месяц" (или, более точно "постулат о ложности человеко-месяца как единице измерения производительности программистов") обычно используется, чтобы подчеркнуть факт снижающейся отдачи от индивидуальных членов по мере увеличения коллектива разработчиков, даже в том случае, когда все они работают над данным проектом с самого начала. Одно из лучших пояснений этой концепции дал Рэй Дункан (Ray Duncan) в своем обзоре в журнале Dr. Dobbs Journal Мифического человеко-месяца:

"Что такое мифический человеко-месяц? Представьте себе программу средней сложности времен начала микрокомпьютерной эры, наподобие первых версий электронной таблицы Lotus 1-2-3, базы данных dBASE фирмы Ashton-Tate или редактора Wordstar. Предположим, что эта программа потребует от одного очень талантливого высоко мотивированного программиста примерно год на проектирование, реализацию, отладку и документирование. Другими словами, 12 человеко-месяцев. Представим, что ситуация на рынке такова, что нам во что бы то ни стало нужно завершить разработку этой программы за один месяц, а не за год. Как решить эту проблему? Вы можете сказать: "возьмите 12 опытных кодировщиков, разделите работу, не приставайте к ним в течение одного месяца, и проблема будет решена. Это те же 12 человеко-месяцев, не так ли?"

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

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

Большинство выдающихся программистов напоминают людей искусства в значительно большей степени, чем это можно предположить, исходя из технического характера данной специальности. Не случайно другая замечательная книга по программированию названа Искусство программирования для ЭВМ (The Art of Computer Programming). Трудности в общении с другими, личные проблемы и борьба за власть вмешиваются в ход любого реального проекта, и этот факт может подтвердить любой менеджер, которому приходилось руководить крупным программным проектом. Все эти проблемы определенно ведут к снижению производительности труда.

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

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

Я считаю, что иллюзия неприменимости "постулата о ложности человеко-месяца как единице измерения производительности программистов" и закона Брукса ограничивается исключительно проектами, для которых полный функциональный прототип уже существует, и большинство или все архитектурные проблемы решены. Подобное, скорее всего, имело место в случае разработки ядра Linux, являющегося, по сути, повторной реализацией ядра Unix методом использования открытых исходников. С некоторыми оговорками, это, наверное, также справедливо при реализации любой системы, для которой как спецификация (Posix в случае ядра Linux), так и эталонная реализация (скажем, FreeBSD или Solaris) уже существуют и доступны всем разработчикам. Как было подчеркнуто в документе Halloween-I:

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

"При достаточном количестве глаз все ошибки лежат на поверхности"

"Существуют всего две бесконечные вещи: вселенная и человеческая глупость, причем насчет бесконечности первой у меня есть некоторые сомнения ."
- Альберт Эйнштейн

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

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

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

• Является ли это лучшим применением для талантливых разработчиков?
  Зачем выбрасывать их время и способности на отладку? В некоторых коммерческих системах разработки программ для этой цели используются профессиональные тестеры (чем экономится время наиболее квалифицированных разработчиков --- прим. автора). Взаимовыгодное использование как коммерческих разработчиков и тестеров, так и разработчиков-добровольцев может принести значительные выгоды (в действительности этот подход уже давно используется при разработке ядра Linux --- прим. автора). Талантливые разработчики обычно не любят отлаживать чужой код, если только это не является абсолютно необходимым, они хотят писать свой собственный. Более того, если мы предположим, что десять талантливых разработчиков непрерывно продолжительное время работают над выявлением какой-то одной ошибки, то такой подход выглядит как вариант "метода монгольской орды". Любой более совершенный метод управления проектом может быть значительно выгоднее, чем выбрасывание времени и сил десятка программистов на поиск и исправление одной-единственной ошибки. Талантливые разработчики, которые глубоко понимают конкретную систему, исключительно редки, и подобное отношение к их таланту является невероятно расточительным.

   

• Все ли ошибки одинаковы?
  Нет, это не так. Существует как минимум три основных класса ошибок: ошибки кодирования, логические ошибки и проблемы архитектуры. Один большой подкласс составляют простые ошибки кодирования, которые несложно найти (например, if (i=1){...} в языке C). Во второй входят логические ошибки, которые приблизительно на порядок сложнее обнаружить и устранить. Наиболее сложные ошибки являются последствиями неверных архитектурных решений (как, например, средства управления доступом в Unix) или ограничений используемых инструментальных средств (C и утечки памяти или ошибки перезаписи буфера (buffer overflow bugs)). Многочисленные архитектурные проблемы ядра Linux достаточно широко известны и постепенно устраняются. С точки зрения технологии программирования они схожи с архитектурными проблемами любого исследовательского прототипа, который был преобразован в систему промышленного уровня; изначально Linux планировался как временная система, которую впоследствии заменит Hurd.
  
  // Но кто решится сказать это сегодня, когда в Linux вкладывают
  // серьезные деньги? Теперь это лишь желание FSF, которое уже можно
  // похоронить. Увы, такая интересная система, как HURD, похоже,
  // разделит участь многих удобных вещей, которые появились слишком
  // поздно.

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

   

• Легко ли заставить одаренных программистов искать одну и ту же ошибку?
  Когда как. Обычно попытка заставить множество талантливых программистов искать ошибку в одном и том же коде напоминает попытку компактно собрать в одном месте целую стаю котов. Эту задачу никак не назовешь легким или благодарным занятием, если только данная ошибка не является по-настоящему критичной (в техническом или политическом плане). Талантливые разработчики в первую очередь программисты, а не тестеры: они обычно предпочитают делать собственные ошибки, а не исправлять ошибки других. Любая ситуация, при которой множество талантливых разработчиков действительно работает сообща над одним и тем же кодом является скорее исключением, чем правилом. С ростом сложности проекта возможность собрать значительное количество талантливых разработчиков для работы над одной проблемой будет появляться крайне редко и только в случае самых критических либо наиболее политически значимых ошибок. Фактически, для любого достаточно сложного проекта никогда не хватит глаз, чтобы обнаружить и исправить все имеющиеся в нем ошибки.

   

• Имеет ли смысл отлаживать плохо написанные программы?
  Обычно --- нет. Когда исходный текст написан плохо, а как считает Кен Томпсон (Ken Thompson --- автор первых версий системы Unix --- прим. автора), таковы некоторые части ядра Linux, в процессе исправления ошибок легко могут быть внесены новые. Переписать заново, а не отлаживать, было бы в этом случае куда более разумным подходом. Однако как раз в этом плане модель разработки программ на базе открытых исходников, с ее преувеличенной верой в отладку, может оказаться помехой. В коммерческих программных проектах опытный менеджер может частично избежать этой проблемы, оценивая качество отдельных модулей и применяя в нужных случаях данную ему власть. В мире открытых исходников модули, включенные в проект на ранних стадиях, могут намного пережить свою полезность. Благодаря инерции и перегрузке ведущих разработчиков, попытки переписать эти модули могут не предприниматься до тех пор, пока не возникнут серьезные проблемы, которые оправдают усилия. Часто только лишь когда проблема станет видимой, вы сможете привлечь подходящего специалиста с тем, чтобы он переписал код --- уж очень это неблагодарная задача, как может подтвердить любой программист. В этом случае шум, связанный с обнаружением ошибки делает ее исправление ценной инвестицией в поднятие собственного статуса (часто это ситуации с прорехами в защите).

Это концептуально бесконечное множество существующих в программе ошибок (тесно связанных с архитектурными просчетами) исключает позитивное влияние бессистемного исправления ошибок на конечное качество продукта. В случае ядра Linux я не вижу какого-то прорыва в качестве кода по сравнению с Solaris или FreeBSD. В своем интервью журналу IEEE Computer Society Computer Кен Томпсон сказал:

"Computer: В известном смысле, Linux следует этой традиции [Unix]. Ваше мнение по поводу этого феномена?

Томпсон: Я смотрю на Linux как на что-то типа "не-Microsoft", как негативную реакцию на Microsoft, ни более, ни менее. Я не думаю, что в конечном счете она окажется очень успешной. Я просматривал исходные тексты --- там есть как удачные, так и откровенно слабые куски. Большое количество случайных людей принимало участие в написании этих исходников, и качество программирования варьируется очень сильно.

Мой опыт и опыт некоторых моих друзей показывает, что система Linux весьма ненадежна. Продукты Microsoft действительно ненадежны, но Linux еще хуже. На архитектурах, отличных от PC, она просто не конкурентоспособна. Если вы используете ее на отдельном персональном компьютере, это одно дело. Но для того, чтобы ее можно было использовать на брандмауэрах, шлюзах, встроенных системах и так далее, ей предстоит еще довольно долгий путь."

В своем ответе на письмо ESR, посвященное этому интервью, Кен Томпсон отметил, что:

"Я полагаю, будет наивным считать, что в этой гонке у Linux есть надежда потеснить Microsoft, начав гонку из положения значительного отставания [от положения в этого гонке фирмы Microsoft] и имея лишь долю ресурсов и любительскую рабочую силу. (Я придерживаюсь того же мнения по отношению к Unix.)"

Даже поверхностный анализ архива Bugtraq подтверждает, что большинство разработчиков предпочитают делать свои ошибки, нежели исправлять чужие. Для случайных добавлений в код ядра ситуация может быть еще хуже. В очень интересных воспоминаниях о своем раннем опыте работы с Linux Ларс Вирзениус (Lars Wirzenius) пишет:

"Например, одна из моих попыток поучаствовать в разработке ядра привела к ошибке, на поиск и исправление которой ушло три года, и даже тогда это было сделано кем-то, кто специализировался на игре со внутренностями OS/2. Я имею в виду функцию sprintf внутри ядра."

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

Следует ли разработка ядра Linux "соборной" или "базарной" модели?

"Истинная вера заставляет нас признать, что есть только одна святая Католическая Апостольская Церковь, во что мы твердо верим и открыто исповедуем. И вне нее нет и не может быть ни спасения, ни отпущения грехов."
- Папа Бонифаций VII (1294--1303)

Многие указывают, что уровень децентрализации при разработке ядра Linux нуждается в дополнительном обсуждении. Черно-белая картина, нарисованная в СиБ (монолитная авторитарная Соборная модель разработки программ против демократичной, распределенной Базарной модели), представляется чрезмерно упрощенной. Эти метафоры для высокой централизации разработки (Собор) и ее отсутствия (Базар) не учитывают ни размеров конкретного проекта, ни его сложности, ни временных ограничений и давления по срокам, ни доступности ресурсов и инструментов, а также говорим ли мы о ядре системы (подобно ядру Linux) или же о периферийных ее частях. Для крупных проектов, подобных операционным системам, особенно важно, чтобы ядро системы разрабатывалось централизованно небольшой тесно сплоченной командой. В то же время при разработке периферийных частей системы более выгоден менее жесткий, более децентрализованный подход. Я считаю, что в СиБ эти два типа разработки совершенно не различаются , что отражено в следующей цитате:

"В ретроспективе одним из случаев успешного использования методов разработки ядра Linux следует признать разработку Lisp-библиотеки GNU Emacs Lisp и архивов кода на Lisp. В отличие от "соборного" стиля ядра Emacs, реализованного на C, и большей части другого программного инструментария, разработанного FSF, эволюция общего фонда кода на Lisp была быстрой и в основном контролировалась пользователями. Идеи и прототипы команд зачастую переписывались трижды или четырежды, прежде чем достичь стабильной окончательной формы. При этом часто образовывались неформальные коллективы разработчиков связанные через Интернет, в стиле Linux."

Ни в коем случае нельзя смешивать эти два типа разработки: разработку ядра Emacs на C и разработку кода команд на Lisp. Они различны и должны рассматриваться с точки зрения необходимости применения разных моделей разработки. В больших и сложных проектах существуют определенные преимущества в использовании смешанных моделей разработки, отличающихся от крайних случаев чистой централизации (Собор) или полной децентрализации (Базар). Неудивительно, что в реальности преобладают смешанная форма, или что в мире Linux есть место для разработок с высокой централизацией. По мнению Линуса Торвальдса:

"Идея разработки с использованием открытых исходников может звучать демократично, но это не так. В среду на выставке LinuxWorld Expo лидеры некоторых из самых известных проектов с открытыми исходниками заявили, что действуют как диктаторы.

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

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

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

В этом описании существующей организации разработки ядра Linux, принадлежащем ведущему разработчику ядра, можно сразу заметить элементы, чуждые стилю Базара. Описанная организация более похожа на весьма централизованную ("соборную") модель разработки. Например, вы не можете общаться с Линусом напрямую, а должны передавать свои модификации ниже стоящим разработчикам, ответственным за отдельные части ядра (trusted lieutenants). Если ваши предложения отвергнут, жаловаться некуда и некому, что звучит совсем недемократично. Как отмечал Джордан Хаббард (Jordan Hubbard -- известный адвокат системы FreeBSD -- прим. автора):

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

Безусловно, эти аргументы не исключают возможности классифицировать некоторые части разработки Linux как принадлежащие децентрализованной (базарной) модели, в особенности разработку драйверов, утилит и небольших приложений. То же самое справедливо (и даже в большей мере) для мира DOS/Windows/Windows NT. Очевидно, что для DOS/Windows по сравнению с Linux доступно больше условно-бесплатных (shareware) и бесплатных (freeware) программ. Система DOS была первой демократичной

// shareware и freeware --- вовсе не то, что free software, а последнего
// для DOS не так и много, в основном --- перенесенные из *nix программы GNU

программной средой, использовавшей возможности Интернета и задолго до Linux послужившей основой для основных архивных сайтов, которые "удачно воплощали" базарный стиль, принимая "взносы от каждого". Symtel и cdrom.com --- лишь некоторые примеры. Джонатан Юнайс (Jonathan Eunice) отметил:

"Проблема не в том, что делаются неверные выводы, но скорее в том, что предполагается мировоззрение "открытое хорошо, коммерческое плохо", которое на наш взгляд, вряд ли разделяется большинством руководителей отделов программирования и вычислительных центров. Помимо попыток обращения в свою веру, СиБ делит все программные разработки лишь на два крайних класса. Собор представляет монолитный, плановый стиль разработки программ "сверху вниз". Базар, который рекомендуется автором, служит примером хаотичной, эволюционной, рыночной модели. Редко такая примитивная классификация соответствует реальности. Наконец, смена компанией Netscape своей стратегии в сочетании с анти-Microsoft'овскими настроениями среди сторонников программ с открытыми исходниками может привести кого-то к заключению, что Netscape воплощает в себе Базар, а Microsoft --- регрессирующий, догматичный Собор. Но такой взгляд также излишне упрощен.

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

Какое прекрасное пояснение поведения бегемота по имени Microsoft! Как это понимают в Редмонде (место штаб-квартиры Микрософт -- прим. автора), ваш продукт не обязательно должен быть крутым в первой выпущенной версии, коль скоро в нем содержится "потенциальная возможность" вырасти в действительно крутую программу в последующих версиях, или же перспективы принятия этой реализации в качестве стандарта, или же уникальное удовлетворение какой-то неотложной потребности, и коль скоро ранние версии создают базу для получения дохода, пользовательскую базу -- инвестиционный пул, который можно умно вкладывать в непрерывное совершенствование и, в конце концов, достижения лидерства. Единицы измерения, принятые в мире открытых исходников и в мире коммерции, могут различаться, но концепция экономической базы по сути одна и та же.

То, что Microsoft --- антипод сообщества Linux/freeware/открытых исходников --- может столь эффективно использовать те же самые "базарные" принципы приводит к двум выводам. Во-первых, "Собор и Базар" предлагает слишком мало "точек", чтобы его можно было использовать для построения "графика прогресса программирования". Во-вторых, существует набор удивительно универсальных рекомендаций, применимых как коммерческими разработчиками, так и разработчиками, использующими метод открытых исходников и включающих гибкость, модульность и агрессивное использование обратной связи с пользователями для совершенствования продукта."

Многие бизнес-стратегии Microsoft имеют близкие аналоги в мире открытых исходников. Как говорят авторы меморандума Halloween-I:

"Различные рецензенты этой статьи единодушно указали, что внутренне нам следует рассматривать Microsoft как идеализированное общество разработки с использованием открытых исходников, но, по различным причинам, мы этого не делаем."

Согласно книге [James Wallace, Jim Erickson. Hard Drive: Bill Gates and the Making of the Microsoft Empire.--- New York: Harper Business, 1992] ранняя бизнес-практика Microsoft в основном соответствовала положениям философии "базарного стиля":

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

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

• Не забывайте о колоссальной важности количества пользователей.
  Культивируйте свою пользовательскую базу. Избегайте совершенства, как чумы. Смотрите на несовершенство не как на проблему, а как на возможность улучшения продукта в последующих версиях. Как отмечает Линус Торвальдс:

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

  Это вполне соответствует стилю Microsoft --- слова Линуса можно было бы с легкостью приписать любому руководителю этой компании. Фактически такой подход означает, что конкуренты некоторого продукта, атакующие его на фронте технических качеств, могут быть успешно контратакованы на фронте пользовательской базы. В конце концов, вы можете уничтожить конкурентов вне зависимости от технических качеств рассматриваемого продукта, а всего лишь выиграв войну за пользователей с помощью количества инсталляций. Наличие большой пользовательской базы так же важно (или даже более важно), как и технические характеристики продукта. При необходимости долю на рынке можно и нужно завоевывать с помощью бесплатной раздачи программ, публикации исходников, или тем и другим одновременно.

  Microsoft и остальные коммерческие разработчики давно поняли, что захваченная доля рынка является конвертируемой валютой, и во многих случаях успешно продемонстрировали это понимание конкурентам. Например, попросту существует некий эффект самоусиления ("кругов на воде" -- halo effect), когда пользователи говорят друг другу: "IE --- это лучший Internet-браузер" ("Red Hat --- ведущий дистрибьютор Linux"). "Подход имени McDonald's" --- быстрое обслуживание стандартными блюдами, который отвечают ограниченным потребностям среднего человека --- может считаться жизненно важной частью стратегии Microsoft (как и других коммерческих разработчиков). Microsoft просто раньше других поняла, что в программном бизнесе посредственный, достаточно простой в использовании продукт, доступный прямо сейчас и имеющий минимальные требования к железу, имеет больше шансов быть принятым рынком, чем действительно новаторский.

   

• Чтобы заняться бизнесом в области разработки программ, нужно уметь тщательно выбрать и атаковать существующие слабые места.
  Пытайтесь найти область, где рынок не насыщен, конкуренты слабы, либо существует крупное сообщество неудовлетворенных существующим положением пользователей. Анализируйте достижения и проблемы конкурентов и используйте их как возможности продвижения собственного продукта.

   

• Хорошие программисты знают, что написать. Великие --- знают, что переписать (и повторно использовать).
  Если вы в состоянии предложить "заманчивую перспективу", то новаторские решения и/или архитектурное превосходство не имеет принципиального значения. Не бойтесь заимствовать из существующих продуктов. Ожидайте, что в отдаленном будущем вы сможете выпустить версию (волшебная версия 6.0 для Microsoft), которая сделают данный продукт приемлемым по всем параметрам. Тем временем старайтесь захватить рынок с помощью серенького, среднего продукта, не давая тем самым возникнуть и встать на ноги конкурентам. Продвигайте свой продукт, как стандарт де-факто, с тем, чтобы задействовать конкурентов и других разработчиков в шлифовке и улучшении вашей базовой архитектуры. Следующая выдержка из СиБ вероятно может безо всяких изменений использоваться на любом семинаре разработчиков Microsoft:

"Давайте рассмотрим Linux. Представьте себе на минуту, что Линус Торвальдс пытался бы включить фундаментальные нововведения в архитектуру операционной системы в ходе разработки ядра. Насколько при этом было бы вероятно, чтобы ядро, полученное таким образом, оказалось бы столь же стабильным и успешным, как мы это видим сейчас?

Эти доводы разделяют и другие критики СиБ. Например, Джонатан Юнайс пишет:

"... Реальная действительность состоит в том, что Microsoft выпускает высоко функциональные программы, которые она потом стремительно улучшает. Хотя они часто перенасыщены возможностями (и танцуют, и читают, и поют), в то же время они имеют необычайно модульную конструкцию, а их возможности усиливаются тесной интеграцией с другими продуктами фирмы. Модель разработки, принятая в Редмонде, акцентирует внимание на тех же самых атрибутах, которые Раймонд отождествляет с "базаром": быстрая смена версий, модульные технологии разработки, большая и активная пользовательская база, множество независимых разработчиков, стремящихся развить и улучшить продукт в тысяче различных направлений, и исключительно тесная обратная связь с пользователями и разработчиками."

В мире открытых исходников существует еще один источник централизации, который неявно действует против "базарной" модели. Большинство выдающихся продуктов с открытыми исходниками, включая Linux, используют лицензию GNU; это, возможно, было самым толковым из всех решений, принятых Линусом Торвальдсом. Основанное на GNU коммерческое пространство дает колоссальное преимущество первому дистрибьютору/интегратору, который занял прочное положение, первой захватившей выгодные позиции торговой марке, тем самым подавляя раскол.

Авторы документа Halloween-I отметили этот аспект "лицензионного пространства" схожим образом:

"Подобно коммерческим программам, самые жизнеспособные проекты с открытыми исходниками во многих категориях будут, в долговременной перспективе, уничтожать конкурирующие проекты с открытыми исходниками и 'поглощать' их интеллектуальные достижения. Например, Linux подавляет развитие BSD Unix и уже интегрировал большинство его основных идей (наряду с идеями коммерческих версий UNIX). Эта особенность наделяет проект, вышедший на рынок первым, колоссальным преимуществом: возможностью раньше других присвоить себе (застолбить) любую новую территорию...

Захват львиной доли рынка предоставляет исключительно мощное средство контроля за его эволюцией."

Программная эволюция, а не революция --- вот настоящий лозунг любого добившегося успеха движения. Большая пользовательская база подавляет способность достигшего признания продукта к революционным изменениям. С точки зрения тех, кто "сражается в траншеях" все эти Linux, gcc, Perl, Apache и другие продукты с открытыми исходниками являются просто подходящим оружием, инструментами достижения поставленной цели. И как считает большинство пользователей, в этом деле стандартный инструмент гораздо лучше нестандартного. Поэтому очень сложно потеснить с доминирующих позиций программный продукт, который стал стандартом де-факто. В то же время успех создает условия, которые ведут к застою конкретных технических решений в продукте добившемся успеха. Например, как в любой Posix-совместимой ОС, возможность новаторства в Linux ограничена необходимостью придерживаться принятых стандартов группы Posix. Я склонен считать, что значительная часть ценности и привлекательности Linux состоит в том, что его можно рассматривать как новый громадный стандартный SuperBIOS, авторские права на который не принадлежат ни одной компании. В каком-то смысле для Linux игра закончена этим фактом (принятия его в качестве "нового стандартного SuperBIOS" для PC, на базе которого можно разрабатывать прикладные системы --- прим. автора) и стабильность ядра становится исключительно важной для успешной разработки приложений. Поэтому следует ожидать, что скорее всего мы станем свидетелями тщательной шлифовки базовых подсистем ядра с целью улучшить планировщик задач, поддержку SMP, TCP/IP, файловых систем и тому подобного, но никак не радикальных архитектурных изменений или, Боже упаси, изменений в системных вызовах (API). По существу, инновации в Linux будут, в основном, ограничиваться приложениями. Как говорит Джейми Завински (Jamie Zawinski):

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

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

Обеспечивает ли модель разработки с использованием открытых исходных текстов лучшие результаты автоматически?

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

Пора обсудить проблему качества программ с открытыми исходниками. Я не собираюсь превращать это обсуждение в проповедь на моральные темы (аналогом термина "discussion about family values" в оригинале статьи могут служить политические дискуссии в стиле "пикейных жилетов" из Золотого Теленка, но с несколько большей дозой лицемерия -- прим. автора). Я хочу обсудить всего одну конкретную и достаточно хорошо известную мне предметную область. Несколько лет я изучал проблемы разработки и использования так называемых традиционных файловых менеджеров. Из того множества программ, которое я проанализировал, напрашивается вывод, что качество лучших программ этого класса, разработанных методом открытых исходников (Midnight Commander и Northern Captain), и качество лучших программ, разработанных для Windows (FAR и Windows Commander), примерно совпадают. В небольших проектах даже число разработчиков не так важно, вопреки утверждениям СиБ об обратном. Например, в то время, как Midnight Commander был создан группой разработчиков, Northern Captain и две коммерческие (shareware т.е. условно-бесплатные, если быть более точным) версии разработаны отдельными программистами, но при этом имеют примерно то же, если не лучшее, качество. В действительности, автор FAR в основном известен как разработчик очень влиятельного архиватора RAR, который конкурирует по качеству с gzip. Для него разработка FAR была параллельной и побочной по отношению к разработке RAR (т.е. меньше половины Евгения Рошаля успешно конкурировало с группой разработчиков MC --- прим. автора). Таким образом, я в принципе согласен с первой частью следующей цитаты из СиБ:

"Возможно, это выглядит очевидным (давно существует поговорка "необходимость --- мать изобретений"), но слишком часто разработчики программ проводят многие дни, усердно работая за деньги над программами, которые им не нужны, и которые они не любят. Но в случае Linux это не так, чем и объясняется столь высокое среднее качество программ в Linux-сообществе."

Однако, честно говоря, вторая часть вызывает сомнения, поскольку "среднее качество программ" в мире Windows (дешевые коммерческие продукты, условно-бесплатные и бесплатные) также исключительно высоко, несмотря на недостатки архитектуры этой ОС. Чтобы убедиться в этом, достаточно просмотреть несколько игр для Windows. Более того, публичные архивы Windows --- это настоящий "большой шумный базар всевозможных планов и подходов", подобно архивным сайтам Linux (более того, в отличие от благотворительного базара Linux, там, в принципе, как на настоящем базаре, принято платить деньги за товары --- прим. автора)

Что действительно ново в модели разработки Linux ?

"Париж стоит мессы."
- Генрих IV

В предыдущей статье я рассматривал Linux как логическое продолжение проекта GNU Фонда Свободного ПО, который был тесно связан с MIT. Я убежден, что эта связь была исключительно важной для успеха проекта GNU, подобно тому, как связь с Университетом Хельсинки существенно помогла Linux на ее ранних и самых тяжелых этапах. Я смотрю на разработку GCC и Emacs как на генеральную репетицию разработки Linux. Несмотря на то, что не согласен с аргументами СиБ, которые превращают Linux в новую модель разработки,  я вижу одно важное нововведение, которое уже породило важную тенденцию. Для операционных систем сложность разработки в сочетании с организационными трудностями делает последствия открытия исходных текстов и свободного доступа к ним весьма отличными от открытия исходников приложений, а также других проектов малой или средней величины и сложности.

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

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

Реальная проблема --- это понимание программ. Всегда неплохо иметь исходники, но проблема состоит в том, что зачастую этого недостаточно

Каждый, кто участвовал в крупном проекте по реконструкции программного обеспечения, навсегда запомнит чувство беспомощности и потерянности, которое испытываешь, когда впервые видишь гору плохо документированных (хотя не всегда плохо написанных) исходных текстов. Доступность исходных текстов не сильно поможет, если отсутствует доступ к ведущим разработчикам. Если программа или система написаны на сравнительно низкоуровневом языке, вроде C, Cobol или Fortran, и плохо документирована, то все основные проектные решения растворились в деталях кодирования и требуют реконструкции. В таких ситуациях ценность документации более высокого уровня, такой, как спецификации интерфейсов и описание архитектуры, может превышать ценность самого исходного текста.

Такое осознание неадекватности исходных текстов для понимания программ привело к попыткам объединить код и документацию более высокого уровня. Одна из наиболее известных попыток такого рода была предпринята Дональдом Кнутом (Donald Knuth), см. его статьи в книге Грамотное программирование [Literate Programming.--- Stanford, Calif.: Center for the Study of Language and Information (CSLI), 1992]. Возможно, самой известной запрещенной книгой в истории компьютерных наук была книга [Lions' Commentary on Unix], которая содержала высокоуровневое описание исходных текстов Unix наряду с используемыми там алгоритмами. Она нелегально копировалась и распространялась в течение более чем двадцати лет с момента ее первой публикации в 1977 году.

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

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

Более того, сложность зрелого программного продукта служит "барьером вхождения" для конкурентов почти так же эффективно, как "подписка о неразглашении" (Non-Disclosure Agreement, NDA, которая, вообще говоря, не создает непреодолимых трудностей в доступе к исходным текстам продукта, а является лишь некоторым дополнительным ограничением, дополнительным барьером для доступа к исходникам). Скорость разработки некоторого коммерческого продукта может сделать незаконное присвоение фрагментов кода не столь привлекательным, как это может показаться на первый взгляд, особенно в случае, когда конкуренты тоже достигли определенной зрелой стадии, но основанной на других архитектурных решениях.

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

Принимая во внимание эти факты, я отвергаю высказанную в СиБ точку зрения, что разработка новой версии Netscape является тестом жизнеспособности разработки программного обеспечения методом открытых исходников:

"[Проект создания новой версии] Netscape предлагает нам крупномасштабные, проходящие в реальных условиях испытания "базарной" модели в коммерческом мире. Культура открытых исходников сегодня оказалась лицом к лицу с угрозой: если разработка новой версии Netscape не увенчается успехом, концепция открытых исходников может быть настолько дискредитирована, что коммерческий мир не вернется этой идее опять ранее, чем через десять лет."

Разработка новой версии Netscape попросту является неверным тестом. Я не верю, что эта неудача подорвет движение за открытые исходники. Уровень сложности, предложенный Netscape, открывшей уже существовавший проект новой версии на достаточно поздней стадии разработки, вероятно, является главной трудностью в привлечении новых разработчиков. В связи с этим, возможно, требуется определенное дополнительное время, прежде чем станет ясно, провалился этот эксперимент, или нет. Впрочем, учитывая важность новой версии Netscape как конкурента IE, несомненно, будут предприняты специальные усилия, чтобы избежать краха. Одно лишь ясно: сложность кода новой версии Netscape представляла и представляет сейчас собой огромный "барьер вхождения", и его нелегко преодолеть даже самым высоко мотивированным и квалифицированным разработчикам, желающим включиться в эту разработку.

Опыт разработки новой версии Netscape наталкивает на интересную гипотезу. Группа ключевых разработчиков обычно формируется на ранних стадиях жизни сложного проекта, когда проект и программа все еще остаются более-менее понимаемыми и интеллектуально-концептуальный барьер вхождения еще не слишком высок. Как только проект достигает определенного уровня зрелости, он автоматически закрывает сам себя вследствие "бинаризации" исходников. Сложность кода делает цену вхождения в зрелый проект гораздо выше, чем это было в начале его разработки. Было бы интересно проверить эту гипотезу на программах, подобных Perl, Apache и Linux. Остается ли состав ключевых разработчиков более или менее постоянным с момента, когда проект достиг определенной зрелости? Если вы не участвовали в нем с самого начала, то в каких случаях игра стоит свеч --- имеет ли смысл тратить огромное количество времени и ресурсов, которые теперь неизбежно требуются для вхождения в проект?

Безусловно, одним из впечатляющих примеров сложности работы с большими объемами программ в исходных текстах служит так называемая "проблема 2000". Если отбросить мифы, то суть проблемы состоит в том, что, несмотря на доступность исходных текстов, многие компании затратили существенное количество времени и денег, пытаясь исправить единственную и вполне тривиальную логическую ошибку, состоящую в том, что в некоторых программах год представлен всего лишь двумя цифрами. Важнейший урок, вынесенный из опыта решения этой проблемы состоит в том, что в старых и сложных программных системах даже небольшие проблемы, умножаются на сложность и возраст системы, и тем самым превращаются в гигантские. Понимание доисторического кода без понимания соответствующих (тоже доисторических --- прим. автора) архитектурных решений, вероятно, является одним из труднейших видов программистской деятельности. Зачастую это гораздо более сложная задача, чем переписать все заново. Следовательно,  при отсутствии первоначального разработчика или адекватной документации, написание полностью нового кода вместо латания старого может быть наиболее реалистичной а также наиболее экономичной по стоимости стратегией решения этого типа задач.

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

Состязание за статус в коллективах разработчиков, основанных на Интернет

"Можно сказать, что главный урок социологии состоит в следующем: видимость обманчива."
- Питер Бергер

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

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

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

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

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

Иерархическая структура и соответствующее распределение политической власти в мире открытых исходников

"Все проблемы являются политическими, а сама политика --- это масса лжи, уверток, глупости, ненависти и шизофрении."
- Джордж Оруэлл

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

"Хотя дешевый Интернет был необходимым условием развития модели Linux, я думаю, что сам по себе он не был условием достаточным. Другим жизненно важным фактором стала разработка стиля лидерства и набора традиций сотрудничества, которые могли позволить разработчикам привлекать к сотрудничеству других и максимально использовать эту среду для достижения своих целей.

Но что это за стиль управления, и каковы эти традиции? Они не могли основываться на базе отношений власти (power relationship), а если бы и могли, руководство на базе принуждения не обеспечило бы результатов, которые мы наблюдаем.

... "Ударные усилия сливающегося в единое целое множества добровольных волеизъявлений" --- это в точности то, в чем нуждается проект, подобный Linux, "командные методы" неэффективны среди добровольцев, в анархистском раю, который мы называем Интернетом. Чтобы эффективно работать и конкурировать, хакеры, желающие возглавить проекты, основанные на добровольном сотрудничестве, должны научиться мобилизовывать и вдохновлять эффективные группы разработчиков с общими интересами в режиме, в чем-то напоминающем "принцип понимания" князя Кропоткина. Короче, они должны освоить Закон Линуса."

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

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

Иногда естественный процесс образования иерархических структур осознается разработчиками не как естественный процесс складывания иерархии, а как защитная реакция на перегруженность от "шума чайников" и прежде всего завала электронной почтой с низким соотношением сигнал/шум. Обратите внимание, как Алан Кокс (Alan Cox) описывает соответствующую ситуацию:

"Проект Linux 8086 продолжал свою работу, но настоящие разработчики поместили в свои "черные списки" многих других членов списка рассылки, чтобы иметь возможность общаться друг с другом, поскольку просто слишком много малокомпетентных людей крутилось вокруг. Из базара [группа разработчиков] превратилась в группу ключевых разработчиков , что для многих людей служит вежливым эквивалентом слова "клика". В сложившихся обстоятельствах это было необходимой обороной."

Мы будем понимать под политическим поведением такую деятельность, которая не относится к непосредственному исполнению своих обязанностей в данном конкретном проекте или движении на базе открытых исходников, но которая влияет или пытается оказать влияние на поведение других членов группы. Некоторые виды такой деятельности тривиальны, например, почтовая перепалка (flaming), игнорирование распоряжений, создание коалиций, обструкция нежелательных решений лидера, либо завязывание контактов вне группы с тем, чтобы упрочить свою позицию внутри нее. Другие --- экстремальны ("жесткая игра по всему полю"), наподобие склок, саботажа, доносительства и публичных протестов, которые затрагивают статус проекта или движения в целом. Большая часть политики в коллективах, работающих над проектами в открытых исходниках, достаточно невинна и тривиальна, хотя некоторые участники порой пытаются продемонстрировать "жесткую игру". Объясняется это на основе прагматичного понимания личных интересов: экстремальное политическое поведение несет в себе весьма реальный риск ответных санкций со стороны группы, включающих в крайних случаях возможность потери статуса, и/или членства в проекте или группе.

Как только статус в мире открытых исходников становится более тесно увязан с возможностью получения различного рода выгод и "сладких пряников", то неизбежно следует ожидать возрастание опасности политического маневрирования, т.е. борьбы за власть. Это типичная проблема лидеров любых проектов. СиБ описывает руководителей проектов с открытыми исходниками как демократичных людей, но на практике ведущие разработчики склонны рассматривать свое положение, как лицензию на право принимать единоличные решения. Такие лидеры обычно пахали по-черному и зачастую заплатили высокую личную цену в процессе достижения своего нынешнего статуса. Поэтому идея делиться своей властью с другими противоречит их собственным целям и амбициям, хотя слишком сильное "закручивание гаек" может вести к нежелательным последствиям. Мнение СиБ об упразднении "командного метода управления" представляется излишним упрощением, точно так же, как и картина "анархистского рая". История проектов с открытыми исходниками предлагает немало убедительных контрпримеров:

"Одним из тех, кто активно работал над подсистемой поддержки сетевых протоколов, был Фред ван Кемпен (Fred van Kempen). После периода некоторой неопределенности, последовавшего за уходом Росса (Ross Biro) с места ведущего разработчика, Фред предложил свое время и усилия, после чего получил эту роль практически без возражений. У него были довольно амбициозные планы относительно того, в каком направлении развивать сетевые возможности, и он начал двигаться в этом направлении. Фред выпустил версию кода сетевой поддержки, названного NET-2, (версией 'NET' считается версия кода написанная Россом), которую многие пользователи могли довольно успешно применять. Он реализовал множество нововведений, ранее существовавших только в планах, таких как динамический интерфейс устройств, поддержку протокола Amateur Radio AX.25 и более модульную архитектуру сетевого интерфейса. Код Фреда NET-2 успешно использовался довольно значительным количеством энтузиастов, число которых росло по мере того, как ширилась молва, что программы действительно работают. Поддержка сетевых протоколов в то время состояла из довольно большого числа заплат к стандартным версиям исходных текстов ядра и не включалась в нормальный дистрибутив последнего. В документе NET-FAQ и последующих версиях этого документа под названием NET-2-HOWTO была описана довольно сложная процедура, необходимая, чтобы все это заработало. Однако Фред сосредоточился на разработке нововведений в стандартную реализацию, и это отнимало у него большую часть времени. В сообществе пользователей нарастало нетерпение по поводу выпуска новой, более надежно работающей версии, которая бы удовлетворяла уже 80% пользователей. Поэтому, как и в случае с Россом, давление на Фреда, как на ведущего разработчика, возрастало.

Алан Кокс предложил решение, направленное на исправление сложившейся ситуации. Он предложил отладить выпущенный Фредом код NET-2, повысив его надежность и стабильность до уровня, который бы удовлетворил потерявшие всякое терпение пользовательские массы, сняв тем самым давление с Фреда, чтобы он мог продолжать свою новую разработку. Алан приступил к исполнению этого плана и достиг определенных успехов уже в своей первой версии поддержки сетевых протоколов, которую он назвал Net-2D (debugged, отлаженная). Эта версия работала достаточно надежно во многих типичных конфигурациях, и пользовательские массы были счастливы. Однако было ясно, что Алан имел собственные идеи и способности и мог бы внести свой вклад в проект. В связи с этим начались многочисленные дискуссии о направлении дальнейшей эволюции кода NET-2. И среди пользователей Linux, использовавших сетевую поддержку, сложились два лагеря. Представители первого из них придерживались философии "сначала пусть заработает, улучшать будем позже", а представители второго лагеря принципа "давайте сначала напишем код покруче". Линус выступил в роди верховного арбитра этого спора и без лишних объяснений поддержал версию Алана, включив его код в стандартный дистрибутив ядра, тем самым перекрыв Фреду кислород. Любое продолжение его работы уже не могло опираться на большую пользовательскую базу, активно использующую и тестирующую код, а это означало, что прогресс был бы медленным и трудным. Фред еще некоторое время пытался бороться, но в конце концов был вынужден отступить и снять с себя обязанности ведущего разработчика. В результате Алан стал новым руководителем разработки сетевой поддержки ядра Linux."

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

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

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

Возможность несправедливых статусных иерархий (фаворитизм)

"Все животные равны, но некоторые несколько равнее других."
- Джордж Оруэлл

Фаворитизм --- это предоставление начальником некоторых выгод, наград или привилегий одному из подчиненных (т.е. преимущества в выборе и принятии заданий или, с обратным знаком, сознательное игнорирование вклада кого-либо), основанное на субъективных личных предпочтениях, а не на объективных соображениях связанных с прошлыми результатами выполнения заданий или техническими знаниями в конкретной области. Фаворитизм в традиционных организациях является достаточно типичным явлением (см., к примеру, [Prendergast & Topel, "Favoritism in Organizations," // Journal of Political Economy, volume 104 (October 1996): pp. 958--978]). Распределенные проекты, выполняемые через Интернет, также не имеют иммунитета к этой опасности. Фаворитизм, или даже его субъективное ощущение подчиненными, способствует потере взаимного уважения между членами группы, влечет за собой подозрительность, уничтожает инициативу и порождает другие негативные проблемы, подрывающие моральный климат в группе.

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

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

Отравление процесса рецензирования и проблемы с обезличенным программированием

"Радикал изобретает новые взгляды на вещи. А когда он их окончательно обтреплет и выбросит, их подбирает консерватор."
- Марк Твен

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

"Процесс рецензирования подвергался критике со стороны ученых (и не только ученых) на протяжении многих лет. Значительное количество комментаторов (например, Эггер [Agger, 1990; Readings, 1994]) утверждает, что научному рецензированию внутренне присущ консерватизм. Те кого используют в качестве рецензентов, по крайней мере, в "авторитетных" международных периодических изданиях, обычно являются "признанными" специалистами в своей области, которые сами уже пробились сквозь различные препятствия на пути к публикации. Оригинальная работа, бросающая вызов традиционным взглядам, хотя теоретически должна поощряться, на практике зачастую наталкивается на "торможение" академиками, которые заинтересованы в том, чтобы отфутболить все новые и критические научные работы подальше от респектабельных научных журналов. Если желающий опубликовать работу в ведущих журналах вступает в трения с общепринятыми научными концепциями в данной научной области, то вероятнее всего, что эта работе будет направлена на рецензирование как раз одному или нескольким академикам из числа ведущих представителей господствующей точки зрения.

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

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

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

Смотреть на мир открытых исходников как на идеальное общество постоянно сотрудничающих личностей означает находиться в плену иллюзий.

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

Обезличенное программирование (egoless programming) обычно определяется (IEEE Std 610.12-1990) так:

"Разработка программного обеспечения, основанная на концепции групповой, а не личной ответственности за создание программы. Ее цель --- предотвратить идентификацию себя со своей работой, которая у отдельных программистов становится настолько тесной, что негативно влияет на объективность оценок."

Даже в коммерческой среде бывает исключительно сложно "оградить отдельных программистов от слишком тесной идентификации себя с написанными программами". В проектах с открытыми исходниками такая слишком тесная идентификация себя с проектом (мотивы, продиктованные самолюбием) была названа в СиБ одной из главных движущих сил разработки. Это значит, что в этом классе проектов существует весьма шаткая основа для обезличенного программирования, если она существует вообще. Полное отождествление личности разработчика с проектом правит бал. Поэтому защита собственного статуса является неотъемлемой частью игры на поле открытых исходников, хотим мы этого или нет. Сам статус является результатом более высокого уровня понимания некоторой части системы (в случае ведущего разработчика --- критической ее части). Жерар Вейнберг (Gerard Weinberg --- автор этой концепции --- прим. автора) отметил недостатки концепции обезличенного программирования, когда писал [IEEE Software, volume 16, number 1 (1999), pp. 118--120]:

"Концепция "обезличенного программирования", впервые описанная в 1971 году в книге Психология программирования [Gerard Weinberg. The Psychology of Computer Programming], является, вероятно, самой цитируемой, самой неправильно понимаемой и наиболее часто отвергаемой из всех концепций, содержащихся в первом издании книги. Я часто задавал себе вопрос, что было бы, если бы я смог написать этот раздел с большей убедительностью. Возможно, если бы я использовал термин "программирование на основе меньшего эгоизма" ("less-ego programming") тогда это не вызвало бы таких  споров. Возможно, мне нужно было привести больше примеров или подобрать примеры более высокого качества. Возможно, следовало бы привести больше экспериментальных данных.

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

Кстати, хотя Линус Торвальдс опубликовал и произнес около сотни интервью и речей, он не опубликовал ни одной работы, освещающей структуру ядра Linux (если мы не будем считать попытку оправдать монолитную структуру ядра в The Linux Edge). Следует понимать, что ведущие разработчики находятся в противоречивой ситуации относительно распространения стратегической, архитектурной информации. И соответствующее противоречивое поведение может рационализироваться несколькими способами. Ведь есть же такая вещь, как реконструкция программы (т.е. позиция типа "умный разберется сам, а глупому знать это ни к чему",--- прим. автора). По-настоящему крутой программист путем вкалывания по-черному и с помощью интуиции разберется, раньше или позже, в архитектуре программы с минимумом посторонней помощи. В конце концов, способность реконструировать критическую архитектурную информацию о программе по ее исходному тексту является исключительно мощным тестом программистских способностей. Поэтому такая способность может служить рабочим критерием включения в число ключевых разработчиков конкретного проекта. Наличие таких "эгоистических" мотивов на самом деле неявно признается в СиБ. К сожалению, игнорируется подспудный конфликт, связанный с одновременным желанием сохранить власть и при этом не оттолкнуть коллег по разработке:

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

... "Целевая функция", которую максимизируют Linux-хакеры не чисто экономическая, а нечто неуловимое, состоящее из удовлетворения их собственного самолюбия и поднятия своего престижа среди других хакеров...

... Линус, путем успешного занятия позиции "хранителя" проекта, в котором разработка в основном ведется другими участниками, и подогревом интереса к нему, пока тот не сделался самоподдерживающим, показал мастерское владение принципом "взаимопонимания" князя Кропоткина."

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

Опасность перегрузки и "сгорания"

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

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

"Март

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

Октябрь

Напряженность в списке рассылки linux-kernel сменилась взрывом негодования после того, как Линус потерял слишком много присланных исправлений. Линус тоже вышел из себя и взял отпуск на некоторое время. Постепенно все пришло в норму, но разговоры не прекратились. Еще раз стало очевидным, что ядро Linux становится слишком большим, для того чтобы один человек мог быть на высоком уровне во всех вопросах. Обсуждались некоторые пути снижения загрузки Линуса, но ничего реального предпринято не было."

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

• Продолжительное состояние стресса вследствие чрезмерности взятой на себя нагрузки (работа в режиме 12*7 или "стольник в неделю" как такой режим называют программисты --- прим. автора);
• Конфликт между красивой мечтой и реальностью;
• Слишком интенсивный поток сообщений по электронной почте;
• Неумение планировать и распределять свое время (к примеру, круглосуточные отладочные авралы);
• Вовлечение в крысиные гонки с коммерческими разработками;
• Ролевые конфликты, в когда человек раздирается на части конфликтующими требованиями основной работы, семьи и его добровольных обязанностей (по разработке/поддержанию продукта с открытыми исходниками);
• Архитектурные проблемы, обнаруженные слишком поздно в процессе разработки, в сочетании с выбором неоптимальных инструментов и методов программирования (например, если продукт, который можно и нужно написать на Perl или Python, пишется на чистом С --- прим. автора);
• Чрезмерное стремление к совершенству (перфекционизм), т.е. трудности с адаптацией к росту объема обратной связи от пользователей и неспособность отвергать просьбы по расширению возможностей программы и исправлению имеющихся ошибок;
• Нереалистичные сроки наряду с неспособностью выдерживать график работы в других проектах (при одновременной работе сразу над несколькими проектами --- прим. автора);
• Недостаточный уровень поддержки со стороны других разработчиков проекта с открытыми исходниками или их полное отсутствие (разработка в одиночку --- прим. автора).

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

Руководство крупным проектом может существенно увеличить опасность сгорания ведущего разработчика. Он обычно "принимает на грудь" весь объем управленческой работы, который валится на него, и тратит на это больше времени, чем другие разработчики. С ростом пользовательской базы и числа разработчиков, даже количество писем по электронной почте может превысить способности по переработке информации любого нормального человека. Для успешных проектов это значит, что необходимость отвечать на письма пользователей конфликтует с процессом программирования и отладки, а все они вместе мешают семейной жизни и основной работе. Проблема техностресса вследствие перегрузки информацией (сочетание "стартового возбуждения", вызываемого постоянно приходящими новостями, перегрузки информацией и ролевых конфликтов) в коллективах разработчиков методом открытых исходников, а также сгорание лидеров даже не упоминается в СиБ. Крэйг Брод (Craig Brod) определяет техностресс так:

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

"Вопрос: Что представляет собой Ваш нормальный день (т.е. на что обычно тратится Ваше время: учеба, Linux, свободное время)?

Ответ: Linux забирает мое "рабочее время" --- даже простое чтение электронной почты требует как минимум два часа в день, а ответы на эти письма и собственно разработка заполняют весь остаток дня. Тем не менее, мне удается вырвать время на другие свои увлечения, поскольку я могу, по сути, заниматься Linux на своей работе в университете (там знают, что я занимаюсь разработкой Linux, и разрешают мне это делать)."

Здесь существует и другой аспект, который любая жизнеспособная модель разработки программ с открытыми исходниками должна уметь предсказывать. Это "смерть на служебной лестнице" как крайний случай гонки за статусом. Подобно спорту, где каждый хочет быть чемпионом, по крайней мере, на начальной стадии проекта с открытыми исходниками его лидер должен доказывать, что он превосходит своих конкурентов. Проблема в том, что иногда это превращается в непосильные крысиные гонки против более сильного или коммерческого продукта: с каждой новой версией альтернативных продуктов от разработчика свободной программы ожидают, по меньшей мере, быстрого достижения паритета с конкурентами, и никого не волнует, чего это ему будет стоит. Лояльные пользователи требуют и ожидают реализации новых возможностей, появившихся в конкурирующих продуктах, не понимая, что разработка "их" продукта ведется на добровольных началах, и поэтому может иметь иные приоритеты и другую скорость разработки. К примеру, в прошлом многие пользователи выражали неудовлетворение медленными темпами выпуска новых версий дистрибутива Debian по сравнению версиями Red Hat.

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

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

Страх исключения как мотивирующий фактор

"Вы можете достичь куда больше при помощи доброго слова и пистолета, чем с помощью одного только доброго слова."
- Аль Капоне

Теоретически, бояться нечего. Не существует никаких обязательств поддерживать любой проект с открытыми исходниками. Просто прекратите разработку/сопровождение продукта, если вы не желаете более этим заниматься. В реальности все более сложно. Чем более успешным становится тот или иной продукт, тем сильнее вы становитесь к нему привязаны; даже будучи разочарованным или подавленным трудностями, вы можете предпочесть "тянуть лямку" и продолжать разработку и сопровождение из-за таящейся в глубине души боязни быть исключенным из виртуального сообщества разработчиков и пользователей этого продукта. Чтобы создать успешный продукт, вы могли пожертвовать колоссальное количество времени и энергии. Разработчик успешного продукта с открытыми исходниками может потратить годы жизни и принести бесчисленные жертвы, чтобы лишь найти время для продолжения разработки. В некоторых случаях от разработчика могут отвернуться семья и друзья. Не каждый в состоянии положительно оценить смысл чересчур фанатичной пахоты по созданию какой-то программы методом открытых исходников. И в этом случае разработчик оказывается в ловушке. Проблема состоит в том, что не существует приемлемого выхода из сложившейся ситуации, и, как в старинной сказке, каким путем ни пойти, что-то надо терять. Конечно, если он решит продолжать разработку, то некоторый бальзам на раны можно поискать на сайтах типа Slashdot, Linuxtoday или чат-группах, которые пропагандируют важность усилий по созданию программ методом открытых исходников. Если ли же вы решите прекратить разработку, то Вам придется найти новую систему ценностей, что тоже сопряжено с проблемами. В СиБ делается предположение, что

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

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

Возможность выбора ошибочных путей повышения собственного статуса

"Только очень недалекие люди не оценивают других по внешнему виду"
- Оскар Уайльд

Исходя из своего опыта преподавания программирования в вузах, я подозреваю, что большинство участников проектов с открытыми исходниками, и в особенности та часть участников, которая тратит на них более чем номинальное количество времени, составляет молодежь (в возрасте от 16 до 25 лет). Последние классы средней школы и годы учебы в вузах --- это период перехода от юности к жизни взрослых. Чтобы его воспринимали как взрослого, молодой человек должен принять некоторые решения, имеющие долгосрочные последствия, причем в большинстве случаев они должны приниматься без достаточной информации о возможных последствиях того или иного выбора. Например, необходимо выбрать род занятий, спутника жизни, интегрировать подходящую систему жизненных ценностей. Программирование в целом и, в особенности, проекты с открытыми исходниками позволяет уклониться от принятия такого рода решений. Не случайно в среде хакеров деятельность за пределами традиционного и порочного цикла "кодирование/компиляция/отладка" обычно рассматривается как сомнительная и второсортная. Этот подход типа "сначала пишем, потом отлаживаем, а только потом думаем", вероятно, отражает суть стиля программирования присущего хакерам. Характерное для этого стиля многосуточное запойное кодирование и отладка служит в некоторых кругах характерной особенностью, отличающей настоящего хакера от рядового программиста. Если пренебрежительное отношение к пище и одежде распространяется и на архитектурные решения программной системы, то, естественно, время отладки будет преобладать в цикле разработки. Это связано с тем, что исправление любой ошибки, не выявленной на стадии проектирования (ошибки в архитектуре) обычно стоит на порядок дороже, если эта ошибка выявлена на стадии кодирования и еще на порядок дороже, если она будет выявлена только в процессе отладки системы. Неправильно выбранные или примитивные инструментальные средства могут дополнительно увеличивать перегрузку.

Некоторые считают способность работать 48 часов подряд как "правильный стиль жизни" и доказательство принадлежности к кругу настоящих хакеров. К сожалению, запойный стиль, круглосуточные кодировочно-компиляционно-отладочные бдения могут приносить значительный вред и работе, и здоровью. В результате лишь наиболее талантливые из тех, кто грешит подобной практикой, в состоянии выполнить работу на высоком уровне и довести разработку до конца. Остальные обречены на неудачу за счет ухода от проверенной практики разработки, поскольку такой скучный и неинтересный подход не повышает престиж человека в глазах тех, чьим мнением он более всего дорожит (референтной группы) в такой же степени, как многосуточные бдения и авралы. Безусловно, одним из самых негативных аспектов хакерской культуры является ее пренебрежительное отношение к архитектуре программных систем и к проверенным на практике технологиям разработки программ. Подобно игре на пианино, только самые талантливые программисты могут импровизировать на клавиатуре, т.е. работать без явных фаз исследований и проектирования, не уделяя внимания координации, и не изучая лучших книг по данному вопросу.

Несмотря на свой частичный эскапизм, хакерство может стать основной карьерой программиста. На самом деле СиБ умалчивает от том, что какие реальные мотивы поддерживают такую интенсивность работы и что придает столь важное значение гонкам за статус при разработке программ с открытыми исходниками. Я подозреваю, что здесь замешан не только альтруизм или раздутое самолюбие --- разработка может стать для участников попыткой сделать альтернативную карьеру. И подобно карьере в любом новом бизнесе, это весьма рискованный выбор, в котором лишь немногие счастливчики могут в итоге насладиться известностью и большими деньгами. Это, опять же, напоминает ситуацию в науке: кое-кто может совсем неплохо заработать на своем высоком неформальном статусе в сообществе открытых исходников. (Одно время состояние "пламенного пропагандиста и агитатора" Эрика Раймонда в виде полученных им бесплатно акций фирмы VA Linux оценивалось почти в 30 миллионов; см. статью Миллионер от открытых исходников открывает рот (Open Source Rich Opens Mouth) -- прим. автора). Подобно академическим кругам, репутация является для верхушки данного сообщества своего рода конвертируемой валютой и может превращаться в реальные доллары. И запах этих долларов может заставить рабски вкалывать других.

Роль прессы

"Я всегда буду строго придерживаться истины, за исключением тех случаев, когда мне это неудобно; я подвергну уничтожающей критике все виды преступлений и проступков, за исключением тех, что совершаются членами моей партии."
- клятва, принесенная Марком Твеном при вступлении в должность редактора Buffalo Express

Линус Торвальдс (подобно Microsoft в Интернет) пришел в мир Unix "к шапочному разбору". Но его первым и главным успехом был захват стратегически важной высоты в виде уже существовавшего сообщества разработчиков операционных систем типа Unix, сформировавшегося в группе пользователей операционной системы Minix, и соответствующего канала коммуникации (группу Usenet посвященной Minix). Позднее он создал на этой базе как свою собственную группу соразработчиков, так и собственный канал коммуникации. В этот исторический момент сообщество пользователей Minix --- весьма элитарная группа энтузиастов Unix --- насчитывало примерно 40,000 членов и включало заметное число талантливых программистов (которые уже успешно пытались переписать части Minix, чтобы сделать ее более совместимой с Posix). Эта переориентация существующего виртуального сообщества разработчиков на новую цель была одним из важнейших событий в истории Linux, демонстрирующим мощь Интернета как прессы нового типа. Ни одна из других ведущих ОС не разрабатывалась таким способом. Конечно, это сообщество разработчиков к тому моменту уже созрело для "переманивания". Уже наблюдались разногласия между политикой лидера сообщества Энди Танненбаума (Andy Tannenbaum) и устремлениями "сливок" этого сообщества. И неслучайно ключевые члены сообщества разработчиков модификаций к Minix стали ядром команды Linux. Иерархия членов этого сообщества разработчиков уже в основном была сформированной, что, вероятно, помогло избежать ненужных конфликтов.

Специализированные Linux-журналы возникли в 1994, когда Роберт Янг (Robert Young, один из основателей Red Hat и бывший ее исполнительный директор) и корпорация ACC выпустили первые два номера Linux Journal. Позднее редактором стал Фил Хьюз (Phil Hughes). В марте 1994 года компания SSC, издатель серии Unix Pocket References, приобрела права на издание Linux Journal у Роберта Янга и ACC Corporation. Неясно, в какой мере эти связи помогли Red Hat, но вполне понятно, что с самого начала специализированная пресса была мощной, высокополитизированной силой, имевшей явную про-Linux ориентацию.

Эта "партийная" Linux-пресса чрезвычайно помогла в разработке и становлении этой системы, так что сражения между альтернативами происходили не только на чисто технической почве, как утверждается СиБ. Не исключено, что при отсутствии такого уровня политической поддержки, FreeBSD (традиционный выбор Интернет-провайдеров) стала бы более популярной. Вообще говоря, причины популярности Linux более сложны, чем рассмотренные в СиБ. Я хотел бы лишь подчеркнуть, что Linux-пресса служит важным рычагом воздействия на конкурентов, подобных FreeBSD, и ее роль совершенно не учитывается СиБ.

Среди прессы, посвященной Linux, электронные службы новостей, такие, как Slashdot и Linuxtoday, вероятно так же важны, или даже превосходят по важности традиционные издания, наподобие Linux Journal, Linux Gazette и Linux Focus. Хотя сервер LinuxToday превратился в ведущую службу новостей для разработчиков и пользователей открытых исходников, недавно коммерциализованный Slashdot.org является несколько более интересным явлением. Это уникальная смесь службы новостей, технических дискуссий и пропаганды, которая породила общество "слэшдоттеров" ("slashdotters"), напоминающего давно забытые общества пользователей BBS. Количество участников так велико, что наблюдается так называемый "slashdot-эффект": когда информация об интересной статье или программе попадает на доску объявлений Slashdot, зачастую сервер, на котором размещена эта статья или программа, падает от перегрузки из-за слишком большого числа одновременно ломящихся туда слэшдоттеров.

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

Slashdot также служит политическим инструментом подавления оппозиции, но исследование этого явления выходит за рамки данной публикации. Я хотел бы лишь кратко упомянуть "Вопли протеста Slashdot" ("Slashnoise"). "Вопли протеста Slashdot" можно определить в общем случае как письма и другие формы комментариев от читателей, выражающих мнения о программах или статьях, которые никогда не читались и не использовались своими комментаторами. Такие письма можно характеризовать как особую форму лысенковщины, очень близкую по духу к "письмам рабочих и крестьян" в газету Правда в годы влияния Лысенко, в которых повторялась бессмертная и совершенно подходящая к пропаганде Linux фраза: "Я не читал [эту книгу], но я ее осуждаю". Некоторые исследователи, такие как доктор Шаффер (Dr. Shaffer) из Гарварда [The Addiction Letter, (August 1995)], считают, что форумы вроде Slashdot вызывают своего рода патологическую зависимость. В каком-то смысле фанатики Slashdot являются пленниками своей собственной "Slashdot-клетки":

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

Я предполагаю, что распределение частоты сообщений, посылаемых корреспондентами Slashdot очень неравномерно и, вероятно, близко к распределению Парето. Неформально его называют распределением 80-20, или другими словами, приблизительно 20% пользователей ("Slash-маньяки", "Slashaddicts") участвуют примерно в 80% дискуссий. Проверить эту гипотезу о распределении будет непросто. Многие подписывают свои послания общим псевдонимом, вроде "Анонимного Труса" ("Anonymous Coward"), кроме того, каждый может использовать несколько имен.

Проект Linux также породил интересную форму самиздата, называемую Проектом документирования Linux (Linux documentation project). В течение нескольких лет этот проект был очень успешным в создании небольших документов, подобных руководствам How-To. Более крупные работы, размером с книгу, в действительности не появились в сколь-нибудь значительном количестве. Поражает нехватка документации по внутренней структуре системы Linux. Почему она имеет место? Я считаю, что причиной на деле являются внутренние конфликты и уязвимость ведущих разработчиков (им, по сути, нечего терять, кроме знания "внутренностей" системы --- прим. автора). Согласно СиБ, никаких проблем с документацией не существует:

"Многие люди (особенно те, кто по политическим мотивам не доверяет свободному рынку) могут ожидать, что культура самоуверенных самолюбивых эгоистов будет фрагментированной, проникнутой борьбой за территории, расточительной, скрытной и враждебной к людям вне нее. Но это ожидание полностью опровергается (если назвать всего лишь один пример) ошеломляющим разнообразием, качеством и полнотой документации к Linux. Общепризнанно, что программисты ненавидят документирование, но как же тогда Linux-хакеры создали ее в таком количестве? Очевидно, свободный рынок Linux работает лучше по порождению добродетельного, ориентированного на других поведения, чем прекрасно финансируемые "цеха по выпуску документов" производителей коммерческих программ."

В действительности Проект документирования Linux страдает от излишней бюрократизации (например, подача документов ограничена использованием SGML и чистого текста, формат HTML не допускается) и слабого руководства (ранее в этом году некоторые авторы документов, входящих в этот проект, жаловались, что после подачи HowTo-документа требуется более месяца, чтобы он мог попасть в WEB-архив, т.е. стать доступным пользователям. Недавно были предприняты некоторые шаги по исправлению этой ситуации).

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

// недавно FSF опубликована GNU Free Documentation License, которая
// предположительно будет свободна от проблем GPL в отношении документации.

Заключение

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

Главная проблема "базарной" модели состоит в том, что она не имеет предсказательной силы относительно сильных и слабых сторон философии разработки программ методом открытых исходников. Вследствие этого, ее роль сводится к поставке важной метафоры, во многом подобной мифической единице измерения производительности программистов в человеко-месяцах. Я твердо убежден, что академическая модель разработки программ методом открытых исходников объясняет это явление значительно лучше. Причины популярности Linux гораздо сложнее, чем "базарная модель разработки", описанная в СиБ.

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

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

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

Николай Безруков --- ведущий аналитик корпорации BASF, профессор университета Fairleigh Dickinson (NJ) и веб-мастер www.softpanorama.org --- Open Source Software University - добровольного технического сайта программы ООН "United Nations SDNP programme", которая помогает с подключением к Интернет и распространением Linux в развивающихся странах.

Он является автором одной из первых систем классификации компьютерных вирусов и популярной книги --- Компьютерная вирусология (1991) (см. также сегодняшний взгляд автора на проблему). В настоящий момент область интересов автора включает проблемы безопасности электронной коммерции, язык Perl и так называемые традиционные файловые менеджеры (Midnight Сommander,  FAR и т.д.).
Email: postmaster@softpanorama.org

© 2000 Сергей Короп <svk@lib.ru> (пер. с англ.)

Конструктивные комментарии и критика будут с благодарностью рассмотрены.

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

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

Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. Translated by the author's permission.

Русский перевод опубликован в журнале BYTE/Россия, номер 8(24)/2000. Данная версия не полностью совпадает с опубликованной в журнале (различия в некоторых стилистических правках).

Оригинал статьи был опубликован в Интернет-журнале First Monday.

Copyright © 1999, First Monday.

A Second Look at the Cathedral and Bazaar by Nikolai Bezroukov
First Monday, volume 4, number 12 (December 1999),
URL: http://firstmonday.org/issues/issue4_12/bezroukov/index.html