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

Компания Parallels ⁰, развивающая открытую систему изолированных контейнеров OPENVZ и коммерческие решения для виртуализации, автоматизации хостинга и облачных вычислений, предоставила перевод тезисов доклада "Чему научил Android сообщество open source?", прочитанного Джеймсом Боттомли на конференции Линукс Plumbers. Джеймс Боттомли, входит в совет директоров организации Линукс Foundation, занимает пост технического директора по серверной виртуализации компания Parallels и является известным разработчиком ядра Линукс (мэйнтейнер SCSI-подсистемы). В собственном выступлении Джеймс рассказывает о важности тесной работы с upstream-проектами, приводя в качестве примера отношение девелоперов Android к вливанию написанного кода в главное ядро Линукс и размышляя какие уроки возможно достать из этой истории.

Джеймс начал начал своё выступление с общих вещей и сперва попытался ответить, что такое Android. Android - плоть от плоти Линукс. И, естественно, наиболее успешный по количеству инсталляций установочный пакет мобильной операционной системы. Настольные версии Линукс во всем их многообразии значительно отстают по численности установок.

Особенности Android:

В базе платформы лежит форк ядра Линукс;

Написана с нуля часть инструментария, в том числе Си-библиотека bionic;

Создана оригинальная виртуальная машина Java (Dalvik JVM).

На взгляд Джеймса, Android - канонический пример, как не нужно делать open source проекты. Болевые точки - существенное отклонение от апстрима в модификациях ядра и изобретение 2-х "велосипедов"(bionic и Dalvik). Так или иначе, Android - просто вопиюще успешный Линукс-установочный пакет. Стало быть, всему сообществу нелишне проанализировать ситуацию и узнать всю правду. Кто знает, может, трюки из арсенала Android помогут в создании еще одного успешного проекта на рынке. А успешный проект - не наименее привлекательно, чем правильный и красивый код.

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

Компания Google создавала Android как значительное ответвление от основного ядра Линукс - недаром дополнительно были сделаны 2 видные надстройки, библиотека C и JVM. Это было сделано для того, чтоб уложиться в жёсткие сроки и чтоб внести в ядро ряд значительных изменений, необходимых для мобильных устройств. К примеру - прибавить поддержку wakelocks (модуль для того, чтоб ядро поскорее засыпало, однако при этом не переходило в спящий режим тогда, когда этого делать нельзя - к примеру, в ходе диалога по телефону или игры). Все модификации изменили ОС так, что драйверы под обычное ядро Линукс и под ядро Линукс из состава Android - слегка различные.

Из в общей сложности вышесказанного можно заключить, что форк - зло. Хотя это не так. В первую очередь, все перемены обязательно выкладываются в общий доступ, как это предписывается GPL. Для сообщества это большой плюс: без форков сообщество остановилось бы в развитии, и Google с проектом Android никогда не достиг бы его нынешних высот. Тот факт, что форк был инициирован Google, дал возможность компании контролировать ход работ над Android и неплохо контролировать процесс разработки. Так что форки не только лишь не необходимо запрещать, их необходимо всячески поддерживать.

Иной важный вопрос - о том, насколько правомерно считать форк фрагментацией. Большая часть сторонников open source, естественно, ответят, что да, форк - и есть фрагментация. Однако Джеймс в данном вопросе категоричен. Форк - лишь только ответвление; фрагментация же начинается тогда, когда результаты форка не получается влить обратно в мейнстрим. В этом отношении - да, фрагментация есть безусловное зло. Она, к слову, уничтожила Unix. Однако чтоб форк оставался форком и не превращался во фрагментацию, его результаты необходимо вовремя влить в мейнстрим.

Еще 1 тема, вызывающая бурные дискуссии, - природа GPL для бизнеса: добро или зло? Бизнес-пользователи в большей части думают, что зло. Им не хочется делиться собственными разработками со всем миром. Похоже, у людей, которые стояли во главе проекта Android, были аналогичные представления. Однако избежать GPL без разницы не получилось, и ничего страшного не произошло. Самое основное - соблюдать условия лицензии. И помнить, что именно благодаря GPL мобильная платформа вообще родилась.

Что по поводу виртуальной машины Dalvik ? Это наиболее инновационная деталь в Android. Применив её, создатели ОС заложили в платформу огромной потенциал для создания на самом деле интересных решений. Ур. приложений для Android отделен от ядра. Ну а restricted АПИ - средство сделать для "Андроида" каждый пользовательский интерфейс. Что мы и видим на гаджетах от различных изготовителей.

Пока "Андроид" смотрится как чадо гениальных родителей. Между делом, при его создании был допущен ряд крупных и обидных ошибок. Главное и первое фиаско - с календарем, совместимым с 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 теперь усиленно работает над тем, чтоб интегрировать в основное ядро Линукс поддержку контейнеров OPENVZ. Это большая работа, так как код огромной.

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

Ряд рекомендаций для того, чтоб слияние прошло максимально гладко:

Разбивать код на мелкие фрагменты.

Однако при этом вливать код с реализацией определенной функциональности, а не кусками.

Быть готовыми приложить крупные усилия на этапе вливания кода в апстрим.

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

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

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

Сообщество должно объяснять, по какой причине бизнесу не нужно опасаться open source и GPL.

Любой форк должен разрабатываться с прицелом на последующее слияние кода с upstream.

Невзирая на все сложности, Android 1 из наиболее успешных проектов.