Джеймс Боттомли анализирует промахи Android при взаимодействии с Linux-сообществом

Компания Parallels [3], развивающая открытую систему изолированных контейнеров OpenVZ [4] и коммерческие решения для виртуализации, автоматизации хостинга и облачных вычислений, предоставила перевод тезисов доклада "Чему научил Android сообщество open source?", прочитанного Джеймсом Боттомли на конференции Linux Plumbers [5]. Джеймс Боттомли, входит в управляющий совет организации Linux Foundation, занимает [6] пост технического директора по серверной виртуализации компания Parallels и является известным разработчиком ядра Linux (мэйнтейнер SCSI-подсистемы). В своём выступлении Джеймс рассказывает о важности тесной работы с upstream-проектами, приводя в качестве примера отношение разработчиков Android к вливанию написанного кода в основное ядро Linux и размышляя, какие уроки можно извлечь из этой истории.
Джеймс начал своё выступление с общих вещей и для начала попытался ответить, что такое Android. Android – плоть от плоти Linux. И, конечно, самый успешный по количеству инсталляций дистрибутив мобильной операционной системы. Настольные версии Linux во всем их многообразии существенно отстают по численности установок.
Особенности Android:

• В основе платформы лежит форк ядра Linux;
• Написана с нуля часть инструментария, в частности Си-библиотека bionic;
• Создана оригинальная виртуальная машина Java (Dalvik JVM).

На взгляд Джеймса, Android – канонический пример, как не надо делать open source проекты. Болевые точки – значительное отклонение от апстрима в модификациях ядра и изобретение двух "велосипедов"(bionic и Dalvik). Тем не менее, Android – просто вопиюще успешный Linux-дистрибутив. Стало быть, всему сообществу нелишне проанализировать ситуацию и выяснить всю правду. Кто знает, может, трюки из арсенала Android помогут в создании ещё одного успешного проекта на рынке. А успешный проект – это не менее привлекательно, чем красивый и правильный код.
Цели бизнеса и разработчиков практически ортогональны. Для бизнеса важно найти свою нишу, заполнить её и работать над удовлетворением запросов клиентов. Для сообщества разработчиков ценность традиционно составляет лёгкость сопровождения и простота добавления новой функциональности, а также то, чтобы в коде непременно были реализованы наиболее удачные, красивые технические решения.
Компания Google создавала Android как существенное ответвление от основного ядра Linux – недаром дополнительно были созданы две заметные надстройки, библиотека C и JVM. Это было сделано для того, чтобы уложиться в жёсткие сроки и чтобы внести в ядро ряд существенных изменений, необходимых для мобильных устройств. Например – добавить поддержку wakelocks (модуль для того, чтобы ядро поскорее засыпало, но при этом не переходило в спящий режим тогда, когда этого делать нельзя — например, во время разговора по телефону или игры). Все модификации изменили ОС настолько, что драйверы под обычное ядро Linux и под ядро Linux из состава Android — немного разные.
Из всего вышесказанного можно сделать вывод, что форк – зло. Однако это не так. Во-первых, все изменения в обязательном порядке выкладываются в общий доступ, как это предписывается GPL. Для сообщества это огромный плюс: без форков сообщество остановилось бы в развитии, и Google с проектом Android никогда не достиг бы его нынешних высот. Тот факт, что форк был инициирован Google, позволил компании контролировать ход работ над Android и хорошо контролировать процесс разработки. Так что форки не только не нужно запрещать, их нужно всячески поддерживать.
Другой важный вопрос – о том, насколько правомерно считать форк фрагментацией. Большинство сторонников open source, конечно же, ответят, что да, форк – это и есть фрагментация. Но Джеймс в данном вопросе категоричен. Форк – это всего лишь ответвление; фрагментация же начинается тогда, когда результаты форка не получается влить обратно в мейнстрим. В этом отношении – да, фрагментация есть безусловное зло. Она, кстати, уничтожила Unix. Но чтобы форк оставался форком и не превращался во фрагментацию, его результаты нужно вовремя влить в мейнстрим.
Ещё одна тема, вызывающая бурные дискуссии, – природа GPL для бизнеса: добро или зло? Бизнес-пользователи в большинстве считают, что зло. Им не хочется делиться своими разработками со всем миром. Похоже, у людей, которые стояли во главе проекта Android, были аналогичные представления. Но избежать GPL все равно не удалось, и ничего страшного не случилось. Самое главное – соблюдать условия лицензии. И помнить, что именно благодаря GPL мобильная платформа вообще появилась на свет.
Что насчёт виртуальной машины Dalvik ? Это самая инновационная деталь в Android. Применив её, создатели ОС заложили в платформу большой потенциал для создания действительно интересных решений. Уровень приложений для Android отделен от ядра. Ну а restricted API – это средство сделать для «Андроида» любой пользовательский интерфейс. Что мы и видим на гаджетах от разных производителей.
Пока «Андроид» выглядит как дитя гениальных родителей. Между тем, при его создании был допущен ряд больших и обидных ошибок. Первое и главное фиаско – с календарём, совместимым с MS Exchange. По какой-то причине в Android не была добавлена эта функция. Хотя она является одной из основных, например, у Blackberry. Без календаря путь Android на корпоративный рынок был закрыт. Motorola исправила этот недостаток в версии Android 1.6, самостоятельно реализовав нужную функциональность (приложение CorpCal) для телефона Droid. Поддержка календаря в рамках ОС появилась только в версии 2.2. Таким образом ОС потеряла целый год только потому, что в ней не было очевидной возможности.
Более того, создатели Android почему-то не использовали код Motorola, чтобы перенести календарь в ОС. Все оттого, что разработчики Google привыкли писать код «за высоким забором». Google плотно контролирует разработку мобильной операционной системы, «выбрасывая через забор» лишь готовые версии. Для партнёров – производителей оборудования (HTC, LG, Samsung и т.д.) нет раннего доступа к коду. Соответственно, у них и нет времени, чтобы портировать свои разработки в новую версию ОС (хотя отдельные наблюдатели утверждают, что в последнее время ситуация с ранним доступом к коду постепенно улучшается). Возможно, Android боится копирования со стороны Apple.
Ну и самое основное: чему все-таки можно научиться на опыте Google и Android? Первое и основное – неким правилам правильного форка. Надо понимать, что форк – это благо: он развивает сообщество. Для разработчика upstream - единственный способ гарантировать долгую жизнь своему коду. Вот поэтому Parallels сейчас усиленно работает над тем, чтобы интегрировать в основное ядро Linux поддержку контейнеров OpenVZ. Это большая работа, потому что код большой.
С вливанием wakelocks и других модификаций ядра большие сложности, на преодоление которых реально потребуются годы. Сложности начинаются у точки слияния. Процессом нужно хорошо управлять. Как правило, код большой, что делает слияние ещё большей проблемой. Кроме того, те люди, которые вливают код в апстрим, часто воспринимают чужой код как никому не нужную поделку, сделанную на коленке (даже если это не так). Поэтому код, который планируется к вливанию, лучше регулярно показывать сообществу. Даже если слияние – дело далёкого будущего. Лучше, чтобы тебя услышали на раннем этапе. В том числе и те, кто потом будет вливать код в апстрим.
Ряд рекомендаций для того, чтобы слияние прошло как можно более гладко:

• Разбивать код на небольшие фрагменты.
• Но вместе с тем вливать код с реализацией определённой функциональности, а не кусками.
• Быть готовыми приложить большие усилия на этапе вливания кода в апстрим.

Краткое заключение:

• Android – яркий пример, как не стоит делать разработчикам, если хотят развивать детище, а для сообщества – урок по усмирению гордыни.
• Сообществу нужно искать более простые способы принимать ответвившиеся проекты.
• Сообщество должно разъяснять, почему бизнесу не надо бояться open source и GPL.
• Каждый форк должен разрабатываться с прицелом на дальнейшее слияние кода с upstream.
• Несмотря на все сложности, Android один из самых успешных проектов.