История Linux - "не деяние" в действии

Закона Брукса гласит: "Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше". Однако проект Linux доказывает обратное, причем не в теории, а в реальной жизни. В чём же тут дело?

Менеджер пришел к мастеру программирования и показал ему документ, описывающий требования к новому приложению. Менеджер спросил у мастера:
- Сколько времени займет создание этой системы, если я поручу этот проект пяти программистам?
- Hа это уйдет год - сразу сказал мастер.
- Hо нам нужна эта система немедленно, как можно раньше! Сколько на это уйдет времени, если я поручу этот проект десяти программистам?
Мастер программирования нахмурился:
- В таком случае это займет два года.
- А что, если я поручу этот проект сотне программистов?
Мастер программирования пожал плечами.
- Тогда проект никогда не будет завершен, - сказал он.

Дао программирования, стих четвертый

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

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

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

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

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

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

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

Здесь можно провести аналогию со строительством: архитектор разрабатывает детальный проект здания, а рабочие воплощают его в жизнь. При этом никто не удивляется тому, что рабочие не участвуют в создании проекта или общих концепций. Существует строгая иерархия подчинения (начальник участка ® прораб ® рабочий), где каждый занимается свои делом, выполнять которое обучен. Так же и в корпоративном программировании: архитекторы дают четкие указания программистам, те, в свою очередь, "властвуют" над службой технической поддержки и администраторами (их я намеренно объединил в одну группу, так как в деле разработки программ они играют примерно одинаковые роли). Самая многочисленная группа находится в основании пирамиды - это пользователи. Они не принимают непосредственного участия в создании системы. Их мнения учитываются лишь на стадии проектирования системы, а также в процессе ее доводки. Архитекторы прислушиваются к пожеланиям пользователей при составлении технических требований. Или не прислушиваются.

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

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

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

По своему опыту и опыту некоторых моих друзей могу сказать, что Linux - довольно ненадежная система. Microsoft выпускает не слишком надежные программные продукты, но Linux хуже.

Не стоит забывать также, что эта программа изначально писалась Торвальдсом не как операционная система, а всего лишь как программа эмуляции терминала. Приведем отрывок из его книги "Just For Fun":

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

Пришлось писать собственную программу эмуляции. Я решил не подстраивать ее под Minix, а опираться прямо на аппаратный уровень. Разработка программы позволяла, кроме всего прочего, детально изучить работу 386-го. У меня был крутой компьютер. Важнее всего было разобраться, что эта машина может, и использовать ее возможности в свое удовольствие.

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

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

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

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

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

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

"Все будут управлять по очереди всеми. К власти будет привлечено буквально все население: кухарка научится управлять государством. Потом люди постепенно придут к тому, чтобы никто никем не управлял, и оно отомрет - ненавистное государство, веками порабощавшее человека!" - слова председателя ЦК РСДРП (Центрального Комитета Российской социал-демократической рабочей партии) товарища Ленина. И русский народ поверил ему, отдав в руки вождя страшную силу - силу масс, не знавшую пределов. Возвращаясь к нашему разговору, отметим: совершенно неважно, что "кухарка" не разбирается в архитектурных проблемах ядра ОС; главное в том, что она чувствует свою причастность к созданию ядра. А причастность к чему-то потаенному и сокровенному есть великая сила, которая привлекает все новых и новых адептов. Это что-то вроде религиозной секты - с фанатичным поклонением местному божеству и слепой верой в систему.

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

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

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

C продуктами Microsoft ситуация несколько иная. Своей железной рукой компания держит их под жестким контролем.

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

Насколько я могу судить, привлечение Линуса было чисто маркетинговым ходом или PR-акцией. Хотя Линус и заявляет, что он создавал там бинарные интерпретаторы архитектуры x86, мне плохо представляется, как он мог совмещать столь серьезную тему с усердной работой над Linux. Тем не менее, его работа в Transmeta, как мы убедились, непосредственно с Linux не связана.

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

С 1992 по 1995 год российские специалисты - представители команды "Эльбрус" - работали в Sun вместе с известным микропроцессорным архитектором Дейвом Дитцелом. Как рассказывает Б. А. Бабаян: "Потом Дейв образовал собственную фирму - Transmeta - и начал работать над машиной, очень похожей на нашу. Мы по-прежнему поддерживаем с Дитцелом тесные контакты. Да и он очень хочет с нами сотрудничать". Про будущий продукт Transmeta пока известно мало. Сообщалось, что это VLIW/EPIC-микропроцессор с низким энергопотреблением; двоичная совместимость с x86 обеспечивается динамической трансляцией объектного кода. Линус как раз и занимался созданием динамического транслятора кода. Идея которого, кстати говоря, изначально была разработана профессором Бабаяном и его командой.

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

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