Журнал Компьютерра - Журнал Компьютерра N734

- У меня нет цифр - только ощущения, но я считаю, что такой риск до сих пор существует. Но чтобы что-то изменилось, должны начать жаловаться наши клиенты. Пока же все довольны тем, что мы делаем. Если, например, к нам придут люди из Novell и скажут, что качество нашей работы падает, - значит, пришла пора что-то менять. И мы можем поменять: в качестве одного из средств можно ввести более формальный процесс рецензирования кода. Еще мне иногда хочется сделать этап разработки "no new features", во время которого просто не принимать никаких патчей, реализующих новые функции.

Я засомневался в эффективности такой меры - и компаниям, и индивидуальным разработчикам обычно интереснее реализовывать что-то новое, а не исправлять ошибки, - и, как мне казалось, если такой этап будет введен, на это время разработка ядра просто замрет.

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

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

- Сейчас в ядро вкладывается несколько сотен миллионов долларов в год. Да, теоретически кто-то может взять ядро и развивать его в каком-то другом направлении - лицензия это позволяет. Но ему придется тратить те же сотни миллионов долларов на поддержку кода. Это просто безумие! Гораздо проще и правильнее поддерживать собственный набор патчей, который модифицирует официальное ядро так, как вам нужно, и постепенно обновлять его по мере выхода новых версий ядра. Получается не форк ("развилка"), а бранч ("ответвление"). Например, так делает компания Parallels, создавая систему виртуализации OpenVZ.

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

- Форк не может произойти из-за каких-то технических вопросов, над которыми мы работаем все вместе, - считает Мортон. - Но раскол возможен по "политическим" причинам - например, связанным с лицензиями. Допустим, Линус однажды скажет: мы переходим на GPLv3… или GPLv4… или BSD-лицензию. Часть людей может согласиться, а часть - уйти.

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

- Откровенно говоря, я уже несколько месяцев не слышал никаких споров по поводу GPLv3 - видимо, мы остаемся на GPLv2, и это можно считать принятым решением, - с некоторой долей облегчения говорит Мортон. К GPLv3 он имеет множество претензий, с которыми согласны многие ведущие разработчики ядра.

Что касается принятия решений по техническим вопросам, то здесь у ядра есть свой особый путь. Обычно в сообществах свободного ПО работает одна из двух схем. Либо в проекте есть лидер - "великодушный диктатор" (benevolent dictator), принимающий окончательные решения по своему усмотрению, либо ищется консенсус среди всех активных разработчиков (например, так действуют в Apache Software Foundation). Ядро Linux не использует ни одну из этих схем в чистом виде.

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

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

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

- Да, участники LKML иногда бывают грубыми, но обычно это допустимо только между людьми, которые хорошо знают друг друга. Если появляется кто-то, о ком мы никогда не слышали, скажем, с сообщением об ошибке или патчем, мы проявляем к нему большое уважение. У нас действительно была репутация людей, недружелюбно относящихся к новичкам, но ситуация изменилась примерно пять лет назад. Это открыто обсуждалось на Kernel Summit - мы тогда поняли, что наша репутация отталкивает от нас людей и вредит процессу разработки - и решили изменить манеру поведения. Принятое тогда решение приносит плоды: например, у нас существенно выросло количество новых участников из Азии - в частности, из Японии, где вежливость возведена в культ.

Почтовый список LKML - основное средство взаимодействия между разработчиками.

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

Список рассылки вообще кажется Мортону самым удачным способом обсуждения технических вопросов.

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