Компьютерра, 2008 № 18 (734) 13.05.2008 - [22]

Впрочем, работая в Google, Мортон продолжает наслаждаться свободой индивидуального разработчика.

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

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

- Действительно, наибольшую лепту сейчас вносят компании, которым интересен рынок серверов. С другой стороны, если говорить о самом ядре, то версия 2.4 была не сильно хуже для десктопов, чем 2.6. Изменения потребовались именно для серверного сегмента: у 2.4 были серьезные проблемы на "большом железе". Сейчас я просто не понимаю, какую дополнительную существенную работу можно сделать в ядре для применения на десктопах. Если у кого-то есть проблемы - скажите нам. Сам я вижу несколько мест, которые можно было бы улучшить, - но люди об этом не просят. Пожалуй, у нас есть трудности с горячим подключением устройств - это действительно сложная область, поскольку устройств очень много. Но над этим мы работаем постоянно.

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

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

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

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

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

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

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

Вид изнутри

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

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

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