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

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

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

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

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

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

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

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

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

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

- Теоретически возможна атака с использованием софтверных патентов - но я не вижу никаких признаков того, что кто-то намерен это сделать. Это будет атака против собственных клиентов. Мне кажется, что open source находится в безопасности - просто потому, что люди хотят пользоваться открытым софтом.

В своем докладе на Open Source Forum @ Interop Мортон рассказал, как компании используют ядро Linux и включаются в процесс разработки. Дело в том, что ядро зачастую приходится адаптировать для каких-то специфических внутренних применений - и очень часто компании не планируют внедрять эти изменения в основную ветвь. В результате им приходится адаптировать свою модификацию по мере выхода новых версий официального ядра - и чем дальше, тем этот процесс требует все больше ресурсов. Гораздо правильнее с самого начала планировать интеграцию внутренних модификаций с основной веткой - это позволит не только сэкономить на дальнейшей поддержке кода и исправлении ошибок, но и улучшит репутацию компании в сообществе разработчиков.