CITKIT.ru - свободные мысли о свободном софте
Деловая газета CitCity.ru Библиотека CITForum.ru Форумы Курилка
Каталог софта Движение Open Source Дискуссионный клуб Дистрибутивы Окружение Приложения Заметки Разное
30.09.2016

Последние комментарии

ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)
24 December, 22:53
Kubuntu Feisty (15)
24 December, 18:42
Один на один с Windows XP (3758)
24 December, 11:46

Каталог софта

Статьи

Дискуссионный клуб
Linux в школе
Open Source и деньги
Open Source и жизнь
Windows vs Linux
Копирайт
Кто такие анонимусы
Лицензии
Нетбуки
Нужен ли русский Linux?
Пользователи
Дистрибутивы
Идеология
Выбор дистрибутива
Archlinux & CRUX
Debian
Fedora
Gentoo
LFS
LiveCD
Mandriva
OpenSolaris
Slackware
Zenwalk
Другие линуксы
BSD
MINIX
Движение Open Source
История
Классика жанра
Окружение
shell
Библиотеки UI
Графические среды
Шрифты
Приложения
Безопасность
Управление пакетами
Разное
Linuxformat. Колонки Алексея Федорчука
Заметки
Блогометки
Файловые системы
Заметки о ядре

Движение Open Source :: Классика жанра

Разработка программ с открытыми исходниками как особый вид научных исследований

Статья Эрика Рэймонда "Собор и базар" на русском языке

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

Содержание

Введение

"Программирование [с открытыми исходными текстами] подобно сексу: одна ошибка, и вы уже должны воспитывать и поддерживать ребенка всю оставшуюся жизнь."
М. Синц (M. Sinz), CBM Inc.

Природа разработки программ с открытыми исходниками увлекает меня - вот почему я стал наблюдателем и исследователем процессов в сообществе открытых исходных текстов наряду с участием в его жизни. В то же время, в течение моей работы главным редактором Softpanorama Bulletin и преподавательской деятельности, я довольно болезненно осознал распространенность излишне оптимистичных и нереалистичных взглядов на открытые исходники, исповедуемых студентами и частично даже участниками движения, такими, как Эрик Раймонд (Eric Raymond, ESR).

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

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

Теперь о скептической части статьи. Начиная своей знаменитой публикацией "Собор и Базар" ("Cathedral and Bazaar"), Эрик Раймонд опубликовал цикл статей (в особенности характерны в этом смысле его комментарии к так называемым Хеллоуинским документам, Halloween documents), где предложил чрезмерно оптимистичный и упрощенный взгляд на открытые исходники, как на вариант социалистической (или, более точно, вульгарно марксистской) интерпретации разработки программ.

Эта работа является в некоторой степени реакцией на его политику "захвата жизненного пространства", касающуюся Linux и программ, запускаемых в этой системе, попытку представить ее как единственный (и простой) феномен, который и назвать "открытыми исходниками". Особенно неприятна проводимая ESR политика сознательного принижение достижений Фонда Свободного ПО (Free Software Foundation, FSF). Без FSF существование Linux было бы попросту невозможным. Что касается Инициативы Открытых Исходников (Open Source Initiative) - термин "открытые исходники" выглядит красиво, и я предпочитаю его, но это всего лишь красивый термин. Проявляемый в последнее время интерес к открытым исходным текстам своим происхождением обязан Linux, а не тому, что термин "открытые исходники" вошел в моду. Дополнительная информация на эту тему приведена, в частности, в комментариях к статье "Shut Up And Show Them The Code"; я рекомендую обратить особое внимание на письмо Леандро Дютра (Leandro Dutra).

Постулаты "Собора и Базара"

"Для каждой сложной задачи существует ответ, который короток, прост и неправилен."
Х. Л. Менкен (H. L. Mencken)

Серия статей "Собор и Базар" (Cathedral and Bazaar) (и особенно комментарии ESR к так называемым Хеллоуинским документам) предлагает некоторые неявные постулаты (термин "постулат" используется здесь в значении базовое предположение, подобно постулатам Евклидовой геометрии), которые представляют "открытые исходники" волшебным решением всех проблем:

  • Мессианский подтекст:
    Открытые исходные тексты - прогрессивный феномен (светлое будущее человечества), не имеющий проблем.
    Это частично правда, поскольку открытые исходники действительно представляют собой феномен, основанный на Интернете. Но в большей части это утверждение неверно, поскольку сообщество открытых исходных текстов напоминает обычное научное сообщество в большей мере, чем это готовы признать апологеты открытых исходных текстов. Будучи подобным научному сообществу, движение за открытые исходники унаследовало некоторые важные проблемы, включая лысенковщину. Что касается новизны распространения исходных текстов, это беспочвенная претензия. Компания IBM на протяжении многих лет распространяла в исходных текстах свое программное обеспечение для мэйнфреймов.

     

  • Лучшие проекты с открытыми исходниками основаны на так называемой "базарной модели" ("bazaar model").
    Эта децентрализованная модель однозначно превосходит методы, используемые разработчиками коммерческих программ. Все возможные альтернативы, (считающиеся одним и тем же, и называемые "соборной моделью", "Cathedral model") являются порочными и обречены. Ничто не может состязаться с качеством разработки выполненной в открытых исходниках с использованием "базарной модели". Это выглядит как проповедь религиозной нетерпимости: "базарная модель" просто идеальная среда разработки программ. Вследствие неких таинственных причин она также автоматически ведет к получению лучших программистских решений. Простой вопрос о разнице между проектом с открытыми исходниками объемом в миллион строк и в тысячу строк никогда не обсуждался (см. письмо Джейми Завински (Jamie Zawinski)). Является ли бинарная программа в 1K более открытой, чем миллион строк исходников без адекватной инфраструктуры и документации? Открытые исходники, с точки зрения Раймонда, суть исключительно исходный текст, а не вся сложная инфраструктура и неявные знания, используемые в крупных программных проектах. Создание и сопровождение интеллектуальной среды и эффективной инфраструктуры для успешной разработки коммерческих программ даже не обсуждалось. В дополнение к этому уровень децентрализации мира Linux не стоит принимать на веру, и он нуждается в дополнительном анализе (см. статью Кристофера Брауни (Christopher Browne) на эту тему).

     

  • Компания Microsoft должна быть уничтожена.
    В какой степени жизнеспособность идеи открытых исходников связана с существованием отрицательного отношения к "M$"? Что произойдет, если вдруг общий враг исчезнет? Фирма Microsoft играет не одну, а несколько важных ролей в движения за открытые исходники.

     

  • Все разработчики программ движутся к "подарочной экономике" ("gift economy") в "пост-лишенческом мире" ("post scarcity society").
    Причины такого движения определены нечетко. В чисто марксистской манере Эрик Раймонд пишет в Homesteading the Noosphere: "окончательно индустриально-капиталистическое производство программ было обречено уступить лидерство с момента, когда капитализм начал создавать излишки материальных ценностей, достаточные для многих программистов, чтобы они могли жить в "пост-лишенческой культуре подарков" (post-scarcity gift culture)." Я прожил в неком обществе, которое обещало "догнать и перегнать капитализм", достаточно долго, чтобы стать скептиком. Не совсем ясно, как "многие программисты" могут создать "излишки материальных ценностей", чтобы жить в "пост-лишенческой культуре (сплошных) подарков". Классификация работы над открытыми исходниками как некоторого хобби выглядит более-менее правдоподобно. Действительно, для некоторых наука была и есть хобби, многие научные открытия были сделаны непрофессиональными учеными. По существу, экономическая жизнеспособность модели открытых исходных текстов трактуется Эриком Раймондом излишне упрощенно. Кто получит материальные выгоды за необычайно трудоемкие усилия по разработке программ с открытыми исходниками?

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

     

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

     

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

Разработка ПО с открытыми исходными текстами как особый вид прикладной науки

"Если вы продолжаете доказывать то, что другие уже сделали, приобретая уверенность, увеличивая сложность ваших решений просто ради интереса, - в один прекрасный день вы оглянетесь вокруг и увидите, что никто в действительности не делал этого! И это путь стать прикладным математиком."
Ричард Фейнманн.
// Кнут считал, что computer science == prikladnaia matematika
// Lecture Notes in Computer Science, N 122, p.82
//
// (Здесь и далее "//" выделены примечания переводчика.)


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

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

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

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

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

Относительно реальных механизмов функционирования виртуальных творческих коллективов, основанных на Интернете (Internet-based virtual teams, IVT) и проблем, порождаемых таким видом сотрудничества, пока известно немного, Среди типичных трудностей можно назвать следующие:

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

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

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

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

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

Проблемы и ограничения модели ПО с открытыми исходными текстами

"Опыт - чудесная вещь, он позволяет вам узнавать свою ошибку в тех случаях, когда вы ее допускаете снова и снова."
jdstone@ingr.com

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

Действительно ли модель открытых исходников предоставляет собой среду быстрой разработки программ?

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

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

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

// я искренне сожалею о тех поистине добрых старых временах, когда
// TeX еще помещался на одну дискету, не искалеченный доброжелателями
// вроде авторов teTeX, LaTeX, TDS и т.п.


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

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

Но существует еще одна проблема, связанная со скоростью и разработкой программ с открытыми исходниками. Я полагаю, что когда скорость становится действительно важной, авторитарные методы управления получают явные преимущества над демократическими. "Скорость убивает" и ее первой жертвой становится демократия (впервые отмечено Фредериком Бруксом в его анализе разработки OS/360). Чисто авторитарный стиль ведет к созданию внутри проекта элиты и жесткой иерархии, которая рано или поздно может погубить проект с открытыми исходниками. Поэтому любая попытка ускорить существующий проект с открытыми исходниками может, по достижении определенного предела, привести к неожиданным последствиям, включая непредвиденные изменения в существующей социальной структуре проекта. Состязание с Microsoft (поощряемое некоторыми евангелистами Linux) являет собой опасную угрозу движению за открытые исходники в целом. В попытке соревноваться с авторитарной организацией скорость создания новых версий может стать вопросом жизни и смерти.

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

Эту мысль удачно сформулировал Джордан Хаббард (Jordan Hubbard): "Вопреки периодическим заявлениям пропагандистов программ с открытыми исходниками, централизованные модели разработки, подобные применяемым в проекте FreeBSD, нельзя назвать устаревшими или неэффективными в мире свободного ПО. Внимательный анализ причин успехов анархической ("базарной") модели разработки программ зачастую выявляет существование значительной степени централизации, которая на самом деле является неотъемлемой чертой процесса разработки таких программ."

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

В общем случае, любой быстро развивающийся проект с открытыми исходниками имеет высокий уровень централизации. Эта потребность в централизации может восприниматься участниками как "культ личности", когда один разработчик имеет огромный авторитет (например, как Линус Торвальдс в Linux). Это, в свою очередь, может привести к высокому уровню внутренних трений и разногласий, иногда вызывающему разделение проекта на два или более соревнующихся направления разработки. Примерами могут служить NetBSD/OpenBSD, Emacs/Xemacs и gcc/egcs. Если вдруг Линус Торвальдс начнет отвергать слишком многие важные исправления и будет считаться "узким местом" для разработки ядра Linux, то вы можете в будущем стать свидетелями раскола среди разработчиков.

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

Эффект "городского совета" или же Эффект "Комитета по администрированию структурного планирования ядра Linux"

"Покажите мне исходники."
Линус Торвальдс

Разработчики не создают программ в изоляции. Последнее слово остается за пользователями, и они посредством электронной почты могут сыграть важную роль в этом процессе. Электронные послания могут нередко принимать форму перепалки либо использоваться как средство повышения статуса внутри движения, с тем, чтобы поставить в привилегированное положение какую-то бюрократическую суперструктуру, так называемый "эффект городского совета". Алан Кокс (Alan Cox) ввел в обиход два удачных термина: "эффект городского совета" ("town council effect"), и "Комитет по администрированию структурного планирования ядра Linux" ("The committee for the administration of the structural planning of the Linux kernel.") В своей статье "Cathedrals, Bazaars and the Town Council" Алан Кокс пишет (курсив мой):

"Проблемой, которая начала возникать, был наплыв множества опасно малокомпетентных людей (в основном настроенных благожелательно) со своими мнениями - не отлаженным исходным кодом, а мнениями. Они знают достаточно, чтобы представлять, как все должно быть написано, но большинство из них не в состоянии запрограммировать "hello world" на C. Поэтому они неделями обсуждали, а потом устроили голосование по поводу того, какой компилятор надо использовать и не написать ли новый... И это год спустя, как работа над проектом уже началась с использованием вполне приличного компилятора. Они также долго дебатировали, как генерировать загрузочные модули для "большой" модели памяти (large model binary), совершенно игнорируя наличие в ядре средств подкачки (swapper).

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

В случае Linux пользовательско/программистская база росла медленно и происходила из неявной базы людей, которые писали код и либо принадлежали к изначальному сообществу хакеров Minix, либо изучили некоторые основные структуры в коде самым трудным путем - многократно перегружая повисшую после внесения очередного изменения систему. С ростом проекта люди, которые должны были бы превратиться в "Комитет по администрированию структурного планирования ядра Linux" вместо этого очутились в окружении, в котором от них ожидали отдачи в виде кода, и где провал не считался проблемой. Цитируя Линуса: "покажите мне исходники"."

Коэффициент зашумленности почтовых рассылок и проблемы преувеличенного "эго"

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

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

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

Позвольте привести несколько примеров. Фред Муди (Fred Moody) пишет:

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

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

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

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

// Когда-то я угробил 1.5 года, чтобы написать свой собственный Ассемблер
// для своего ZX-Spectrum. Я до сих пор не могу понять, почему многие, с
// кем я об этом говорил, заявляли, что "подумаешь, вот у мелкомягкого
// MASM под CP/M возможностей куда больше...". Интересно, а какое право
// они имели судить мою работу, не попытавшись сделать нечто подобное сами?
// Точно так же, зачем "наезжать" на Linux, если сам не в состоянии
// написать хотя бы что-то близкое к этому? На словах все такие умные...
// НО! Я уважаю авторов ядра Linux и программ для нее за проделанную
// работу, и тем не менее, не решился бы использовать ее для ответственных
// приложений без серьезного экспертного исследования (включающего анализ
// исходников).


Существуют и обличители Free BSD; Ларри Мак-Вой (Larry McVoy) оценивает ситуацию так:
"Я хотел бы отметить, что некоторые фанаты BSD (подобные мне) отказались от нее в пользу Linux по причинам, отличным от чисто технических. В частности, мир BSD элитарен, антагонистичен и не склонен к сотрудничеству. Вы либо входите в группу лиц, особо приближенных к императору, либо нет, и это, как говорят в Одессе, "две большие разницы". Я из тех, кто определенно имел заслуги и статус для того, чтобы быть принятым в их число, но отказался от этого предложения, поскольку не люблю организации, где играют в подобные игры. Linux - гораздо более приятное место для меня.

Наконец, Linux подчиняется GPL, а BSD - нет. Если BSD даже и станет опять популярной, то стоящие у руля смогут (и, возможно, попытаются) закрыть доступ к исходным текстам (попробуйте, к примеру, достать все исходники BSDi)."

Конфликты между разработчиками ПО с открытыми исходными текстами

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

"Какова "обычная" судьба проекта с открытыми исходниками, когда его участники не уживаются друг с другом? Как авторы открытых исходных текстов решают конфликты с другими авторами? Позвольте мне поведать историю моего первого опыта поддержки программы с открытыми исходниками, поскольку я полагаю его хорошей иллюстрацией. Я работал над программой (далее будем называть ее P, т.е. Program) и около двух лет назад вызвался взять на себя ее дальнейшее совершенствование, после того, как инициатор проекта выпустил версию 1.0 и не имел более времени работать над P.

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

Время уходило, наш бизнес разрастался, и я имел все меньше времени для работы над P. Мне пришлось выпустить альфа-версию с некоторыми улучшениями, но некоторые люди не были довольны темпом работы. Один из них решил начать работу над собственной версией P. Для краткости я буду называть его Mr. J, т.е. Jerk (ничтожество).

Вообще говоря, я должен был бы это приветствовать, поскольку именно в этом суть открытых исходников. Тем не менее, казалось, что в действительности Mr. J хотел просто славы. Я выпустил бета-версию P номер 2.0 , основанную на версии 1.0 изначального автора. Mr. J выпустил свою версию, названную P 1.2, также основанную на оригинальном коде 1.0, но с его собственными модификациями. Это послужило причиной множества недоразумений, по крайней мере, на мой взгляд, поскольку он использовал для своего пакета то же самое имя и сходный номер версии, что и я. Поэтому я попросил его проявить любезность и сменить название пакета на что-то иное, чтобы прояснить ситуацию.

Его ответом было публичное заявление, что его следует официально считать ответственным за сопровождение P, поскольку я слишком затягиваю работу. Должен отметить, что в этот момент я бы с радостью перепоручил ему дальнейшую разработку, если бы думал, что он сможет справиться с ней, но я так не думал (мягко говоря). Я собираюсь не приводить здесь дискуссию, которую мы вели по этому поводу в списке рассылки, посвященном P (на моем почтовом сервере), поскольку она включает немало ребячества со стороны Mr. J. Ограничусь ее результатами: Mr. J назвал меня некоторыми именами, и заявил, что берется за работу над P, как часть большего проекта, в котором он участвует.

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

Но это продолжалось, пока кто-то не послал вопрос, касающийся моей версии P, в его рассылку (на которую он подписал и меня).

Он воспользовался случаем назвать меня еще несколькими именами, и сделал некоторые комментарии об отсутствии прогресса в моей работе. Это переполнило мое терпение, и я написал ему, что не хочу, чтобы мое имя вообще ним упоминалось когда-либо еще. Я надеялся, что далее он будет полностью меня игнорировать, и я смогу спокойно работать над P, не отвлекаясь из-за его вмешательства.

Увы, я ошибался. Mr. J ответил мне, что будет делать все, что пожелает (опять-таки, мягко говоря). Он также добавил текст, предлагающий мне совершить с ним непристойность, в свой .sig-файл, который использовал публично в списках рассылки и прочих местах.

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

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

Проблема "Самого низко висящего яблока"

"Благословенны те, кто не питает надежд, они никогда не разочаровываются."
Будда

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

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

// FSF в своих документах неоднократно подчеркивалось, что их задача -
// не писать, что хочется, а координировать действия и побуждать (возможно,
// деньгами) других писать то, что нужно для общества. Писать компиляторы
// интересно немногим, особенно, когда они уже существуют. То есть свобода
// творчества в написании свободных программ неотъемлема от осознанной
// необходимости в выборе направления. Если бы не эта политика FSF,
// законченной системы, такой как GNU/Linux сегодня, мы бы не имели.
// (Очередной довод в пользу того, что демократия - не вседозволенность.)


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

Фрагментация и синдром NIH

Давайте начнем с выдержек из недавнего интервью журнала Linux Focus с Деннисом М. Ритчи (Dennis M. Ritchie):

"LF: Я не могу избежать сравнения между вами и теми людьми, которые в настоящий момент работают над бесприбыльными проектами бесплатно, лишь потому, они им нравятся, хоть я уверен, что они не отказались бы и от денег. Могли бы вы представить себя в проекте, подобном Linux, или в чем-то вроде того, если бы вы не работали в Bell Labs? Как вы смотрите на всех этих людей изнутри передовой исследовательской лаборатории, с многолетним опытом за плечами? Поскольку наш журнал в основном предназначен для пользователей Linux, мы не можем позабыть спросить вас о Linux. Прежде всего, каково ваше мнение о том резком росте популярности, который сейчас получила эта система, и о решении многих компаний начать разработку программ для нее (в Bell Labs, например, Inferno переносится под Linux)?

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

И это наблюдение, что мир наследников Unix со "свободными исходными текстами", по-видимому, страдает от тех же проблем множественности версий и расколов, которые имели и еще имеет место среди разработчиков коммерческих версий Unix", является симптомом фундаментальной проблемы - "трагедии общего пастбища". Мы уже имеем дюжину слегка несовместимых дистрибутивов Linux, с Debian и Red Hat, как двумя ведущими игроками, обладающими мощной пользовательской базой, и несколькими игроками второго уровня (Suse, Caldera, Mandrake, Slackware, и т.д.). Я хотел бы также сказать, что в известном смысле Linux страдает от "раздвоения личности". Это значит, что приложение, предназначенное для Red Hat Linux, может не запуститься под Caldera вследствие, например, использования отличающейся версии библиотек.

Как сказал Джордан Хаббард: "... это совершенно естественное человеческое желание - создавать кланы и гордо носить их символы в праздник Robert the Bruce Day, или вроде того; разнообразие и состязательность являются хорошими вещами, которые поощряют нововведения и вдохновляют людей на большие достижения. В то же время, когда к этой смеси добавить Безудержный Эгоизм, быстро возникает хаос, поскольку каждый клан решает, что он и есть тот самый единственно правильный Клан, и только его члены могут стоять в очереди за наградами за лучшие знамена и самый оригинальный спорран (кожаная сумка, часть национального шотландского костюма,-прим. перев.) . Естественно, что вскоре враждующие кланы принимаются метать друг в друга горящие стрелы ("flaming arrows" напоминает "flame mail" - перепалку по почте - прим. автора) и совершать набеги на враждебный лагерь, затрудняя существование всем окружающим, тем, кто хочет просто "жить дружно" или хотя бы просто жить."

Проблема NIH (NIH problem, "Not Invented Here"-"Не Реализовано Здесь",-прим. перев.) связана с этим феноменом. Все в мире программного обеспечения искусственно (напоминает математическую теорию - прим. автора). Как и в академической среде, по достижении определенного уровня зрелости теории проблемы с добавлением новых возможностей, либо некоторых модификаций, либо лицензионных ограничений внезапно становятся идеологическими. Это означает, что в рамках группы образуется "либеральная", "угнетенная" (подгруппа, которой не дают внести интересующие ее изменения) и "ортодоксальная"(господствующая) подгруппы. Если одна из этих подгрупп успешна, то с течением времени она неминуемо станет "ортодоксально-господствующей", после чего неизбежно со временем произойдет новый раскол.

Очевидно, что Linux желает отличаться от FreeBSD, и FreeBSD нуждается в том, чтобы не быть похожим на Linux. Эти два лагеря сражались за одну и ту же экологическую нишу, за персональный престиж. Будучи менее PC-дружественным, чем Linux, и вследствие правовых конфликтов с AT&T, в какой-то момент движение FreeBSD потеряло время и скорость и позднее также пострадало от дополнительной конкуренции со стороны OpenBSD. (После того, как последняя появилась в роли жизнеспособного конкурента на платформе Intel в результате внутреннего раскола NetBSD/OpenBSD.) Как следствие, сегодня Linux выглядит королем PC-платформы, поглощающим львиную долю доступного пула разработчиков.

Но это не значит, что проблема не может всплыть снова в какой-то подходящий момент. Например, если значительная часть разработчиков ядра почувствует, что руководство со стороны Линуса неудовлетворительно и вредит будущему Red Hat, Linux может разделиться на "ортодоксальный" Linux и, скажем, Redux. Было бы интересно увидеть, расколются ли разработчики ядра Linux, если, к примеру, Алан Кокс преисполнится убеждением, что Линус Торвальдс слабо или неправильно руководит проектом. Смена имени может быть необходимой, поскольку последний владеет торговой маркой Linux.

Фактически, главная "религиозная война" ведется сегодня за относительное первенство между KDE и GNOME. Само по себе это не удивительно. Подобно научным сообществам, движение за свободное ПО постоянно приводится в движение фракционными дискуссиями как на идеологические, так и технологические темы. В большинстве своем они непонятны посторонним. Но конфликт KDE versus GNOME помогает проиллюстрировать как неотъемлемую силу Linux-сообщества, так и его потенциальную ахиллесову пяту. Конфликт имеет идеологический характер, поскольку KDE построена на базе программного продукта, не подчиняющегося лицензии GPL, она не полностью "свободна" в глазах пуристов Linux.

// А что они хотели, используя Qt? Нельзя быть "частично свободной"
// системой, это вроде "слегка беременна". Можно согласиться, что
// компромисс может способствовать продвижению системы, но отнюдь не
// ее развитию пользователями: лично я из принципа не напишу ни строчки
// под Qt (разве что под заказ - тогда правовые проблемы лягут
// на заказчика, которого я честно заранее о них предупрежу) и многие
// сделают то же самое - зачем нам библиотека, в которой
// нельзя ковыряться?
//
// Впрочем, все сказанное выше, относится к прежним версиям Qt, которые
// имели другую лицензию. Текущая же версия Qt, подчиняющаяся
// QPL, существенно ближе к идеологии GPL (на мой взгляд). Тем не менее,
// поезд, как говорится, ушел.


Хотя на сегодня KDE является наиболее полным дружественным к пользователю Linux-десктопом, главный дистрибьютор Linux, Red Hat, вкладывает программистские ресурсы и деньги в GNOME. Как пишет Эндрю Леонард (Andrew Leonard):

"Мы огорчены фактом, что был начат проект GNOME,- говорит Бернд Йоханнес Веббен (Bernd Johannes Wuebben), разработчик KDE.- Мы чувствуем, что сообщество свободных программ нуждается в единстве и общей цели, а не в соревнующихся стандартах и в постоянной враждебности, которую члены проекта GNOME и более радикальные элементы движения GNU [за свободное ПО] направляют против KDE ... Мы, разработчики KDE, верим в свободное ПО, но мы считаем, что радикальные взгляды ... утопичны и, в конечном счете, существенно вредят сообществу разработчиков свободных программ. В нашем видении оба направления имеют свою нишу: и свободная, и коммерческая разработка программ."

// Не нужно путать коммерческое (commercial) с собственническим
// (proprietary). Еще хуже, если они понимают разницу, но разводят
// демагогию. Жаловаться на ГНОМ, который перебегает им дорогу,
// вообще, по-моему, не стоит. Вирт однажды писал, что весьма
// печально, когда первая появившаяся в данной области система
// становится стандартом де-факто, уничтожая все другие более
// поздние идеи. Почему именно КДЕ нужно считать эталоном?
// Лично мне она не нравится. (Не внешне, а обилием ненужных
// файлов и засорением home-каталога).
// Уступает тот, кто умнее ... Будьте достаточно умными,
// чтобы признать свои ошибки. Digital свернула разработки
// Ultrix в пользу OSF/1, причем не потому, что та лучше,
// а потому, что ее приняли как стандарт, и это повод
// уважать DEC.


Ларри Августин (Larry Augustin) верит, что GNOME в перспективе является лучшим графическим интерфейсом для десктопов по чисто технологическим причинам. Но при этом он сожалеет, что Red Hat, рыночный лидер, не будет продавать самый передовой пользовательский интерфейс под Linux, этим замедляя дальнейшее ее проникновение на рынок. Боб Янг (Bob Young) из Red Hat аргументирует это тем, что Red Hat лидирует на рынке потому, что "техническое сообщество нам доверяет", и это доверие зависит от выбора компанией адекватных технологий. Он также высказал предположение, что следующая версия Red Hat может включать KDE как дополнительный пакет, не входящий в базовый дистрибутив.

Люди, не использующие Linux, могут смотреть на весь этот спектакль с некоторым недоумением. Громадное преимущество Microsoft в том, что она предлагает разработчикам ПО единый стандарт, которого нужно придерживаться при программировании, а пользователям гарантирует программную совместимость. С другой стороны Linux имеет, по крайней мере, пять основных дистрибутивов; в дополнение к Red Hat и Caldera, существуют также S.u.S.E. (Германия), Slackware и Debian (полностью некоммерческая версия). Каждый дистрибутив отличается от других, имеет собственную процедуру инсталляции и требует различных подходов к установке новых программ.

// Как Debian может быть "некоммерческой", если продается за деньги,
// причем не по себестоимости? Имеется в виду отсутствие
//"собственнических" пакетов?
// Так это "свободная", не "некоммерческая".


Корпоративную Америку, не говоря об индивидуальных пользователях, смущает это разнообразие с его потенциалом создавать недоразумения. Но в то же время оно является и главным источником силы Linux. "Это великолепие анархии. Это великолепие свободы,- говорит Боб Янг из Red Hat.- Дистрибутивы, которые не ведут серьезной работы по совершенствованию системы и поддержанию передового технического уровня ... не выживут в долгосрочной перспективе."

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

Ориентация на опытных пользователей

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

Проблема критической массы - означает ли победа застой?

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

Подобно корпоративной программной среде, самый жизнеспособный проект с открытыми исходниками негативно влияет на конкурирующие проекты (Linux vs Hurd) истощая ресурсы разработчиков (см. меморандум Halloween I):

"Коль скоро проект не имеет критической массы пользователей, он становится историей. Сегодня Linux подавляет разработку BSD Unix, поглощая большинство ее основных идей. Этим ограничивается конкуренция, что очень похоже на мир PC... Захват львиной доли рынка обеспечивает исключительно мощный контроль за его эволюцией."

// Несмотря на все попытки представить Linux абсолютным совершенством,
// в серьезных задачах (серверы, Интернет-провайдеры и т.п.) по-прежнему
// лидер - FreeBSD (у нас в городе, по крайней мере). И дело здесь,
// видимо, опять-таки в качестве разработки "тесной группы", которое
// было и будет выше "базарного" (естественно, группа должна иметь
// соотв. уровень компетенции. Хороший пример - группа "Кен Томпсон
// и Деннис Ритчи", или "Дональд Кнут, лично".)


Большая доля рынка подразумевает риск, к примеру, замедления инноваций. Как это отметил Джейми Завински:

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

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

Культ личности, сгорание лидера

"Никогда в области человеческих конфликтов столь многие не были так много обязаны столь немногим."
Уинстон Черчилль

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

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

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

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

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

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

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

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

Темп работ над проектом с открытыми исходниками следует определять самому разработчику, и здесь опять уместна аналогия с академическими исследованиями. Я хотел бы повторить еще раз, что "скорость губит". Нажим на разработчика часто ведет к результатам, противоположным ожидаемым. Linux не является бизнесом в обычном понимании этого слова. Существует тесная связь между Linux и сообществами FSF на базе общих культурных ценностей "поколения GNU". Эта культурные ценности во многом те же, что и культурные ценности Unix в начале и середине 1980-х. До начала недавнего массового найма Red Hat и другими дистрибьюторами Linux, программисты работали под Linux по множеству причин, но в основном ради удовольствия и преодоления трудностей (многие со времен Minix). Эти программисты получали признание и имели чувство контроля над событиями и чувство сопричастности к благородному делу. Если убить эти чувства прессом жестких сроков, то те из них, кто еще не стал обычным наемным служащим, или миллионером (миллиардером), получив бесплатные акции, могут просто сойти с поезда. Поэтому тот факт, что многие разработчики Linux (включая самого Линуса) сегодня работают в качестве наемных служащих (а не "свободных художников"), в некоторой степени позитивен, поскольку, вероятно, предотвратил бунт "старой гвардии".

Microsoft как жизненно важная часть движения за открытые исходники: ABM/BTM как политическая программа

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

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

Вероятно, наиболее важной частью этой программы является ее негативный аспект, принимающий форму восстания против Microsoft (в духе "отречемся от старого мира, отряхнем его прах с наших ног"). Я называю это тезисом ABM/BTM ("anything but Microsoft/Better than Microsoft" - "все, кроме M$/лучше M$"). Обе части этого тезиса предельно просты; обе подразумевают, что программы Microsoft непригодны ни для каких задач, обе также видят Microsoft в черно-белом образе и в лучших традициях философии военного лагеря "мы против них". Вот почему движение за открытые исходники в целом и Linux в частности имеют сильных союзников в лагере пользователей OS/2 и Macintosh. Как OS/2, так и Macintosh основываются на закрытых собственнических моделях (в действительности не слишком отличающихся от модели Windows). Обе эти операционные систем имеют влиятельные сообщества пользователей, также исповедующие идеи ABM/BTM.

Программа действий ABM/BTM, подобно любой политической программе, проста, и в то же время привлекательна для определенной категории пользователей. И что более важно, она импонирует некоторым слоям корпоративного менеджмента, включая поддержку со стороны широкого спектра руководителей среднего звена Intel, IBM и почти всех главных поставщиков PC. Прикинув объем лицензионных выплат Microsoft, производимых Compaq, Gateway и другими поставщиками PC, вы начинаете понимать, почему в этих компаниях программисты работают над развитием Linux при полной (и, если необходимо, скрытой) поддержке начальства. Политически некоторые сравнивают Microsoft с IBM в 70-е годы; такая позиция питает сознательные попытки создать оппозицию Microsoft. (В 70-х годах все ненавидели IBM до такой степени, что вмешалось правительство.)

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

Документ cWare White Paper был одним из первых, в котором Microsoft представлена как важная организующая сила для движения за открытые исходники:

"На заре существования Интернета преобладала компания IBM и мейнфреймы. Сегодня - Microsoft. Подобно тому, как Реформация в Германии предоставила дополнительные свободы некоторым группам, которые раньше не имели влияния (конкретно, Лютеру и германским князьям), Интернет придал силы отдельным лицам и группам, до этого не входившим в круг традиционной, хорошо финансируемой технократии, которая поддерживала и в свою очередь получала поддержку от IBM. Продвижение Linux стимулировалось этими силами. На сегодня основная доля коммерческих программных ресурсов концентрируется вокруг продуктов Microsoft подобно крупной области низкого давления. Тем не менее, такое объединение силы и влияния ограничивает права многих, кому высокие цены и запретительные лицензии (нехватка реальной свободы) преграждали полноценный и легкий доступ к компьютерным ресурсам. Поэтому велся поиск альтернативных путей. Подобно погоде, альтернативы могут появляться внезапно и затем рассеиваться. Как правило, требуется дополнительная поддерживающая сила, противостоящая области низкого давления. Лютеру эту поддержку предоставили немецкие князья, на заре жизни Интернета ее обеспечивало агентство ARPA, а для Linux ее дает само Интернет-сообщество. В случае Linux оно отчаянно нуждалось в полноценной ОС. AT&T отпугнула многих пользователей Unix ограничительными лицензиями и высокой платой. Университет в Беркли (UC Berkeley) был вынужден искалечить BSD, изъяв из нее весь собственнический код, адаптировавший ее к аппаратуре: вы можете изучать его, но не запускать! Многие видели потенциал разработанной Энди Танненбаумом (Andy Tannenbaum) системы Minix создать противовес росту несвободы Unix. Но Minix была незавершенной, не имела критической массы, и распространение ее исходников стало излишне ограничительным. Эти условия вдохновили усилия общества по созданию ОС, изначально производной от Minix, результатом которой стало ядро Linux, ставшее демократически доступным и имевшим непрерывно возрастающие возможностями. Когда было принято решение распространять это ядро на базе лицензии FSF (GNU), и по своим возможностям ядро достигло уровня позволяющего использовать все мощные утилиты, уже разработанные проектом GNU, наряду с возможностью работы на широком спектре дешевого железа, родилась действительно полезная операционная система. Интернет-сообщество наконец получило способ использовать Unix с полноценной сетевой поддержкой дешево и надежно без дополнительных сложностей.

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

Следовательно, "Linux-базар" - это не просто слабо связанное сообщество дистрибуторов и других сторонников системы, мотивируемых только взаимным признанием. "Базар" в действительности оперирует на более широкой арене. Когда силы на этой арене самоорганизуются вокруг доминирующей группы, которая ограничивает выбор для остальных, остальная часть общества самоорганизуется в оппозиционную силу. Последняя ищет и пробует различные альтернативы. Если одна или более этих альтернатив в состоянии получить поддержку (Интернет-сообщества в случае Linux), то рождается новое "движение", которое поддерживается и даже обогащается за счет мощных сил, работающих на поддержание status quo на арене. Ирония состоит в том, что чем более доминирует Microsoft, все более мощными становятся силы оппозиции, и тем большую поддержку получают альтернативные движения, подобные Linux. Если бы "неободранная" BSD стала бы доступной ранее, работая на недорогом железе Intel, она могла бы стать ядром этого шторма. Та же пьеса была бы сыграна с другими актерами: тезис и антитезис в диалектическом противоречии, чья неодолимая движущая сила будет существовать, пока Microsoft не выдохнется или потеряет целеустремленность. Microsoft достаточно оглянуться на цикл гегемонии и упадка, уже продемонстрированный однажды когда-то практически всемогущим старым технократом: IBM."

Позднее эта идея развивалась в Хеллоуинских документах (Halloween papers). В какой-то мере IBM предыдущего разлива (времен разработки OS/360) могла считаться организацией "базарного" стиля; однако это не давало ей существенных преимуществ, поскольку такой стиль (как убедился еще Брукс) не способствует быстрой реализации сложных проектов (см. комментарии Джонатана Юнайса (Jonathan Eunice)).

В какой-то мере можно говорить, что Линус Торвальдс "перебежал в другой лагерь" и начал играть роль политического лидера стиля ABM/BTM, более чем технического, продвигая курс на "доминирование в мире". Это значит, что Linux начал терять фокус и дрейфует к тактически выгодной, но потенциально опасной в долгосрочной перспективе идеологии ABM/BTM (со внутренне присущей необходимостью соревноваться с Microsoft как на рабочих станциях, так и на серверах), а не к модели академического сообщества, с ее целью и девизом "прежде всего реализуй свою идею [догоняй свою мечту, а не конкурента]".

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

Как умирают открытые проекты

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

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

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

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

Псевдопроблемы

Открытые исходники важны только для программистов

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

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

Идеология открытых исходников - "утопическая чепуха", подобно коммунизму?

Боб Меткалф (Bob Metcalfe), который выразил это настроение наиболее ясно, абсолютно не прав. Брайан Пфаффенбергер (Bryan Pfaffenberger) описал ошибки в его аргументации следующим образом:

"Для Боба движение за открытые исходники похоже на коммунизм, и он видит, что оно направляется к тому же окончательному растворению в руках капитализма. По общему мнению, если слушать Ричарда Столлмена (Richard Stallman) достаточно долго, это зазвучит как "Imagine" Джона Леннона. Но я не вижу никакого сходства с коммунизмом. Идеология открытых исходных текстов напоминает мне университет, или более точно, давнюю традицию открытого приобретения и распространения знаний, которым западная наука обязана своими впечатляющими успехами.

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

Что же служит им наградой? Возможно, мотиваций так же много, как и самих ученых. Некоторые просто от природы любопытны: они просто не могут прекратить думать, почему край водопада клубится, или почему рукава Млечного Пути принимают форму таких больших элегантных спиралей. Другие просто большие дети, которые не могут дождаться очередного посещения лаборатории, чтобы провести в ней еще один благодатный день утонченного исследовательского веселья. В то же время остальные серьезно заботятся о смысле и важности науки. В своем недавнем лекционном цикле физик Фримен Дайсон (Freeman Dyson) раскрыл источник своей привязанности к науке: поиск путей, которыми наука и технология может внести вклад в социальную справедливость, искоренение нужды и сохранение окружающей среды.

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

Исследованиями занимаются не только ученые, работающие в университетах. Коммерческие корпорации тоже занимаются исследованиями и разработками. Но последующее развитие событий в этом случае отличается и четко демонстрирует другие ставки и приоритеты (what's in stake). Результаты частных корпоративных исследований не распространяются свободно, если только это не улучшает положения компании. Это понятно, но нам нужна альтернатива. В самой капиталистической из всех стран, США, единодушным согласием двухпартийного Конгресса поддержаны общественные инвестиции в университетские исследования и создание знаний для всех, включая коммерческие компании. Это не коммунизм, это здравый смысл.

И что поставлено на карту в случае компьютерных программ? Ставка достаточно велика. Именно компьютерной технологии мы частично обязаны самым продолжительным экономическим подъемом во всей истории США. Она помогла установить экономическое, технологическое и политическое превосходство США в разобщенном и опасном мире. Она обещает помочь в решении наиболее важных проблем, стоящих перед нами: необходимость создать эффективные экологически чистые источники энергии, справиться с разрушительным действием мирового голода, раскрыть тайны рака. Жизненно важно, чтобы компьютерные знания оставались в открытом общественном владении, но этого не происходит. Прямо сейчас коммерческие компьютерные компании изо всех сил кувыркаются, пытаясь запатентовать даже самые тривиальные фрагменты кода, и невообразимо близорукий U.S. Patent Office каждый раз сдается без боя... Компьютерные системы, жизненно важные для безопасности и благосостояния общества в целом, управляются закрытым коммерческим кодом, полным неизвестных ошибок, которые и не могут быть найдены. Представьте себе ракетный крейсер "Норфолк" ("Йорктаун", насколько я помню,-прим. перев.), потерявший на два часа управление после отказа бортовых NT-систем, и вы поймете, что имеется в виду.

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

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

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

Более того, если мы (неверно) предположим, что существует тесная связь между идеологией открытых исходников и марксизмом, это не столь плохо, поскольку марксизм включает в себя очень широкий спектр политических течений, включая западные социал-демократические партии. Давайте предположим, что политическая программа движения за открытые исходники является разновидностью марксизма в применении к программам. Это неправда, Меткалф определенно ошибается, приравнивая марксизм и философию открытых исходных текстов. Тем не менее, в политической программе движения за открытые исходники определенно существует подтекст, весьма схожий с марксистскими взглядами. Поэтому давайте вообразим на минуту, что Боб Меткалф прав. Что это значит? Прежде всего, существует большая разница между теорией коммунизма (называемой марксизмом) и его практикой. Западные социал-демократии, русский большевизм (ленинизм) и китайский маоизм отличаются друг от друга. Марксизм был утопической теорией, созданной Карлом Марксом и его последователями, Ключевым компонентом этих взглядов было то, что компании должны принадлежать тем, кто на них работает; простейшим путем устранить ненужные затраты, которые представляют собой собственники и управленцы, является равномерное распределение богатств между рабочими. Этого следует достигать революционным путем, который низведет всех на уровень рабочих, своего рода рационализация системы управления путем уничтожения неэффективностей порождаемых существованием собственников и менеджеров, своего рода упрощение системы путем устранения промежуточных и избыточных уровней управления (middleware). Модифицированные и умеренные версии этих теоретических взглядов сегодня являются составной частью жизни наиболее развитых стран, радикальные ветви представлены русским большевизмом и китайским маоизмом, если вам нужны конкретные примеры. Каждое отличается от теоретической модели, предложенной Марксом, и друг от друга. Некоторые из этих социальных систем оказались успешными, некоторые - нет. Похожая дифференциация происходит в движении за открытые исходники. Подобно социал-демократам, умеренное крыло, представленное создателем Perl Ларри Уоллом (Larry Wall) и поддерживаемое O'Reilly, Red Hat и некоторыми другими компаниями, обладает наибольшей движущей силой. Подобное западным социал-демократическим партиям, умеренное крыло, возможно, победит. Но будущее непредсказуемо по определению.

Техническая поддержка ПО с открытыми исходниками хуже по сравнению с коммерческим

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

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

Джесси Берст (Jesse Berst) описывает ситуацию так:

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

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

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

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

Существование стандарта или прототипа может быть важным преимуществом для распределенных проектов, основанных на Интернете. Кажется, что Винод Валлопиллил (Vinod Valloppillil) впервые выделил этот важный фактор в своем известном меморандуме Halloween I:

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

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

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

// По-моему, существенная (если не б\'ольшая часть) свободных проектов
// направлена на повторную реализацию (либо имитацию) существующих
// собственнических проектов. И это стало неминуемо, как только акценты
// в мире свободного ПО переместились от "создания удобной среды для себя"
// к "конкуренции с M$". Помимо роста авторитарности (требуемой для
// скорости работ) имеем перенос проектных решений. Основное преимущество
// и удобство *nix в простой и мощной модели межпрограммного взаимодействия
// и в исторически сложившейся ориентации на мощные, но "невизуальные"
// средства. А сейчас - пожалуйста, в рамках проекта ГНОМ идет работа
// по созданию WYSI_A_WYG системы DTP на основе TeX... Лично я просто не
// могу себе представить визуальный ТеХ... И дело даже не в "принципе",
// а в том, что просто невозможно всунуть в визуальную среду все
// особенности всех существующих пакетов. А раз так, то скорее всего
// ограничатся скажем, LaTeX. И получим вместо осознанного выбора того
// пакета, который адекватен нашей задаче, принудительное пользование
// LaTeX, потому что стандарт... Как говорил Ф.Ф. Преображенский,
// "все, пропал калабуховский дом".
// Ergo: рост сложности свободных проектов неуклонно приближает их к
// собственническим.


Заключение

Движение за открытые исходные тексты играет жизненно важную роль в разработке программ в конце 20-го столетия и будет оставаться важным центром творческих усилий программистов в следующем веке. Но, несмотря на технические способности и изобретательность членов сообщества открытых исходников, существуют ограничения этой модели, которые следует тщательно изучать и, по возможности, пытаться компенсировать. Эти ограничения подобны тем человеческим качествам, которые делают науку вообще и прикладную науку в частности таким сложным родом деятельности. Эта статья подчеркивает важное преимущество модели открытых исходников над коммерческой разработкой - внутренне присущую возможность создания более простых продуктов, превосходящих коммерческие в функциональности и пользовательском интерфейсе. Известный принцип KISS ("Keep It Short and Simple" - "Сохраняйте краткость и простоту", есть и более грубый вариант, согласно "The Hacker's Dictionary", 2.9.11: "Keep It Simple, Stupid" - "Сохраняй простоту, идиот",-прим. перев.) более применим к проектам с открытыми исходниками, нежели к разработке коммерческих программ. Вторая важная идея состоит в том, что скорость разработки не является важным преимуществом данной модели, и иногда замедление разработки может быть жизнеспособной стратегией, которая должна рассматриваться среди прочих альтернатив. Затевать крысиные гонки наперегонки с коммерческими разработчиками может быть в действительности оказаться саморазрушительной стратегией. Опасно рассматривать идеологию открытых исходных текстов как новый рай - явление, целиком и полностью свободного от проблем и недостатков, при этом игнорируя всю историю прикладной науки, а также более чем 50-летний опыт разработки программного обеспечения. Нереалистичные ожидания и игнорирование важных исторических уроков, наряду с внутренне присущими данной модели ограничениями могут сделать некоторые жизнеспособные в принципе проекты с открытыми исходниками всего лишь интересным примечанием к общей истории компьютерной техники век спустя.

// Когда всем базаром наваливаются на одну несчастную программу и начинают
// ее портировать на древние калькуляторы, понять, что же в ней написано,
// почти невозможно, т.к. очень трудно прорваться через "напластования"
// вложенных на 2-3 уровня директив условной компиляции, полудюжины патчей
// и скриптов, которые латают исходник под конкретную платформу... Куда
// интереснее читать программы Кнута, написанные в стиле
// literate programming.
// Еще один довод в пользу идеи "одной программе - одного автора".
// Не очень "базарно", но такова жизнь.



Об авторе

Николай Безруков - ведущий аналитик корпорации BASF, профессор университета Fairleigh Dickinson (NJ) и веб-мастер www.softpanorama.org - Open Source Software University - добровольного технического сайта программы ООН "United Nations SDNP", которая помогает с подключением к Интернет и распространением 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/Россия, номер 5(21)/2000. Данная версия не полностью совпадает с опубликованной в журнале (различия в некоторых стилистических правках).

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

Copyright © 1999, First Monday.

Open Source Software Development as a Special Type of Academic Research
(Critique of Vulgar Raymondism) by Nikolai Bezroukov
First Monday, volume 4, number 10 (October 1999),
URL: http://firstmonday.org/issues/issue4_10/bezroukov/index.html




Комментарии

аноним, Wed Mar 4 12:27:53 2009:
хорошая статья :)
аноним, Fri Mar 2 18:52:43 2007:
Есть над чем поразмыслить :)

Комментарии заморожены.

Новости:

Все новости на CitCity.ru

Компании месяца

 
Последние комментарии
Почему школам следует использовать только свободные программы (101)
20 Декабрь, 14:51
ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)

24 Декабрь, 22:53
Linux в школе: мифы про школу и информатику (334)
24 Декабрь, 22:43
Kubuntu Feisty (15)
24 Декабрь, 18:42
Software is like sex: it's better when it's free.
©Linus Torvalds