Разработка ядра Linux — один из крупнейших ИТ-проектов современности. В нём принимает участие более 5 тыс. программистов из почти 500 компаний, живущих в самых разных странах мира. Каждый час в код ядра вносится примерно семь изменений, а его общий объём превысил 20 млн. строк.

В этом году проект отметил своё 25-летие. Ведущий разработчик Linux Грег Кроа-Хартман, ответственный за поддержку стабильной ветки ядра, рассказал на портале OpenSource.com об основных принципах, которые позволили такой большой и распределённой команде работать настолько долго и успешно.

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

Короткий цикл

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

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

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

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

Иерархическая модель

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

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

Инструментарий

Разработка и сопровождение достаточно сложного продукта невозможна без специального инструментария. До 2005 г. в проекте применялась распределённая система управления версиями BitKeeper, впоследствии заменённая на Git, которая была специально создана Линусом Торвалдсом для этого проекта.

Эксперт уверен, что без правильно подобранных инструментов такой крупный проект рано или поздно «рухнул бы под собственным весом». Таким образом, создание сопутствующих продуктов можно смело назвать неотъемлемой составной частью создания ядра.

Консенсус

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

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

Исключение регрессии

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

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

Равенство компаний

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

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

Отсутствие внутренних границ

Как правило, разработчик сосредоточен на решении задач какого-либо определённого направления. Несмотря на это, он может предложить изменение любой части ядра, если оно представляется оправданным.

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

Большое начинается с малого

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

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

Совместные усилия

С 2005 г. 14 тыс. программистов из более чем 1300 компаний внесли свой вклад в развитие ядра Linux. Кроа-Хартман особо подчёркивает, что проект стал возможен только благодаря сотрудничеству самых разных участников, которые в других областях ожесточённо конкурируют друг с другом.

Общая цель и совместные усилия — эти две составляющие создали современное ядро Linux. Пока существует этот базовый принцип, проект будет развиваться.