Просмотров: 10722

БСД: Большие и Страшные Демоны (2)


Продолжим нашу серию статей, посвящённую знакомству с ЮНИКС-подобным семейством BSD, и сегодня мы рассмотрим как модель разработки BSD, так и вообще проблемы развития сообщества открытых исходников. Сделать это будет и проще и нагляднее, если провести сравнение на конкретных примерах, например FreeBSD и Linux, как наиболее известных и популярных в широких народных массах проектах ОС.

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

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

Прежде всего, давайте остановимся на специфике так называемой базарной модели разработки ("bazaar model") и вкратце обозначим её основные закономерности, на которых базируется разработка open source проектов. Вот что пишет апологет BSD Джордан Хаббард:

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

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

В FreeBSD-мире существует т.н. Core Team, сама состоящая из разработчиков, и которая демократически выбирается самими же разработчиками (коммитерами) раз в 2 года путем открытого голосования, куда в результате выборов входит обычно 9 самых авторитетных и активных коммитеров данной ОС - к этой группе переходит вся полнота власти по управлению и модерированию проектом на указанный период времени. В Linux же мы имеем жесткую централизацию и монархический культ личности одного человека. В самом деле, в последнее время в сообществе Linux очень активно обсуждается проблема с излишней зависимостью всего проекта лишь от одного человека: "Не настало ли время для Линуса Торвальдса разделить бремя ответственности, лежащее на нём, с кем-нибудь ещё?" Модель разработки ядра Linux такова, что право публиковать код в "официальный" репозиторий имеет только один человек во всем этом гигантском проекте. Конечно, множество майнтейнеров присматривает за разными подсистемами ядра, но каждый утвержденный ими патч, если в итоге он должен быть влит в главную ветвь, будет лично проверен и добавлен туда только лично Линусом. Подобная суперавторитарная модель разработки просто немыслима для мира FreeBSD, где судьба всех  глобальных и спорных "коммитов" как в HEAD, так и в STABLE, в любом случае обсуждаются и решаются коллективно. Вспоминается знаменитый эпизод 1998 года, когда Линус был в сильной депрессии и раздражении, и вообще "забил" на разработку своей ОС, далеко посылая всех,  кто высылал ему любой патч (удаляя их вообще с общего ftp), что привело к ропоту и большим народным волнениям в рассылках линуксоидных разработчиков ("говорят, царь-то с ума сошёл!").

В связи с этим сейчас активно обсуждается так называемый "фактор автобуса" (bus factor), вошедший в обиход из известного шутливого исследования "Что будет с Linux, если Линуса Торвальдса собъет автобус" (можно найти много пародийных этому оригиналу псевдоисследований, например, "Что будет, если всех участников FreeBSD Core Team собьют автобусы", или "Что будет, если в автобус, в котором едут Стив Джобс, Билл Гейтс, Ларри Элисон и Линус Торвальдс угодит другой автобус?"). Как минимум высказываются мнения, что Линус должен начинать готовить себе преемников, как максимум - что подобный гигантский централизованный проект не должен быть замкнут на одном единственном человеке. Уже сейчас, процесс коммита в главную ветвь Linux занимает очень продолжительное время - Линукс буквально завален уже утверждёнными мантэйнерами патчами.

Как высказывается один из разработчиков Red Hat: "У Linux чрезвычайно распределённая и гибкая модель разработки, с единственным узким местом в ней - самим Линусом". Другой разработчик из IBM добавляет: "Возьмите сверхсложную систему, сложность которой шокирующе нарастает, добавьте туда жесткую централизацию в её управлении, и вы увидите, что в динамике такое развитие объективно приводит к "культу личности" в худших традициях социализма. Хотя изначально исходило всё как всегда, конечно же, из самых лучших побуждений".

Другая острейшая проблема Linux - это падения качества кода и чудовищный темп увеличения размеров ядра. Ранее, в 80-ых, классический подход разработки ПО, который, кстати, удачно сформулировал сам Линус Торвальдс,  утверждал, что "при достаточном количестве глаз все ошибки лежат на поверхности" ("Given enough eyeballs, all bugs are shallow"), поэтому всем большим коллективам разработчиков, несомненно, приписывались преимущества в разработке. Но глядя на современный мир, с его гигантскими сообществами разработчиков, например как у Linux, методология разработки вынужденно формулирует т.н. закон Брукса:

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

В FreeBSD, как уже отмечалось выше, имеется иерархическая система принятия изменений в ядро, которая будучи распределённой - прекрасно справляется и переваривает нагрузку с постоянно поступающими нововведениями. Кроме того, в FreeBSD существует традиция, что каждый коммитер, ответственный за какую-либо подсистему ядра, формирует вокруг себя своих приемников, которым постепенно, по мере их контролированного прогресса и обучения, вручается права на коммит (commit bit) в дерево исходного кода. Таким образом, в FreeBSD существует негласная школа, которая последовательно передает опыт от одного другому поколению разработчиков, постепенно фильтруя из всех желающих наиболее способных и заранее готовя себе замену, что отчасти противостоит негативным последствиям закона Брукса, сдерживая некачественное разрастание основания в пирамиде модели разработки системы.

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

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

Итак, реальные увлеченные добровольцы уходят сегодня из Linux, статистика неумолимо констатирует это: сегодня более чем 90% всех значимых разработчиков ядра Linux работают за зарплату и на конкретные крупные коммерческие компании, которые таким образом вносят свой вклад в развитие ядра, и которые при этом транслируют именно свои коммерческие цели и задачи в развитие этого открытого проекта. Двухполюсность этой модели разработки в целом, когда с одной стороны царь Линус координирует развитие свободной, бесплатной и открытой ОС, а с другой стороны приоритетами разработки реально рулят коммерческие компании, платящие своим разработчикам деньги, - уж очень потенциально конфликтна и противоречива.

Это опять же сильно бросается в глаза, в сравнении с моделью той же FreeBSD, где от любой коммерциализации проекта и прихода "больших денег" шугаются как от огня, вполне справедливо понимая последствия такого поступка. На самом деле, очень мало из масштабных разработок в FreeBSD сторонних коммерческих компаний (того же Yahoo, или наших Yandex'a и Rambler'a, на ядре FreeBSD в которых работали их поисковые сервера), реально попало в официальную ветвь FreeBSD - только то, что было коллективно одобрено сообществом и укладывалось в последовательную и непротиворечивую концепцию развития ядра. Да, сервера под управлением FreeBSD традиционно удерживают все рекорды по uptime своей работы под реальной нагрузкой, но нужно понимать, что это результат именно жесточайшей дисциплины разработки и непреклонной независимости в своем развитии, где стараются на передний план выдвигать не коммерческую целесообразность и пиар для привлечения новых денег, как это всё больше прослеживается в мире Linux, но техническое качество и идейную чистоту реализации дизайна ОС.

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

twitter.com facebook.com vkontakte.ru odnoklassniki.ru mail.ru ya.ru pikabu.ru blogger.com liveinternet.ru livejournal.ru google.com bobrdobr.ru yandex.ru del.icio.us

Подписка на обновления блога → через RSS, на e-mail, через Twitter
Теги: , , , , , ,
Эта запись опубликована: Пятница, 17 сентября 2010 в рубрике Unix'овое.

8 комментариев

Следите за комментариями по RSS
  1. Интересная статья, большое спасибо

  2. Очень интересная статья, спасибо. Весьма полезно для общего развития всем интересующимся Open Source. Теперь наконец знаю, сколько человек в Core Team FreeBSD :)

  3. спасибо за статью.

  4. Обнять и плакать такой анализ, а после закапать.

    Лежите и дальше в своей канаве.

  5. http://netbsd.org/docs/guide/en/chap-intro.html

    One of the key characteristics of NetBSD is that its developers are not satisfied with partial implementations. Some systems seem to have the philosophy of “If it works, it's right”. In that light NetBSD's philosophy could be described as “It doesn't work unless it's right”. Think about how many overgrown programs are collapsing under their own weight and “features” and you'll understand why NetBSD tries to avoid this situation at all costs.

  6. Безумный программист

    Интересная статья, хотя и не скажу, что абсолютно бесспорная и не опирающаяся местами на эмоции. Тем не менее спасибо, жду продолжения!

  7. > бесконтрольное разрастание огромного и разнородного сообщества разработчиков Linux, на самом деле, приводит к тому, к чему оно и приводит

    Глубокомысленно :)

  8. >Да, сервера под управлением FreeBSD традиционно удерживают все рекорды

    >...

    >это результат именно _жесточайшей дисциплины_ разработки и непреклонной

    >независимости в своем развитии, где стараются на передний план

    >...

    >качество и идейную чистоту реализации дизайна ОС.

    Тот же "лагерь "Открытых системъ"", только в профиль???

Оставьте комментарий!

Не регистрировать/аноним

Используйте нормальные имена. Ваш комментарий будет опубликован после проверки.

Зарегистрировать/комментатор

Для регистрации укажите свой действующий email и пароль. Связка email-пароль позволяет вам комментировать и редактировать данные в вашем персональном аккаунте, такие как адрес сайта, ник и т.п. (Письмо с активацией придет в ящик, указанный при регистрации)

(обязательно)


⇑ Наверх
⇓ Вниз