Далее последовал рассказ о том, как зародилась идея дистрибутива Ubuntu, и об особенностях процесса его разработки. Здесь Марк подчеркнул, что одной из целей дистрибутива было – достижение гармонии между стабильностью и актуальностью включенного в состав софта. Первая задача достигается долговременной поддержкой стабильных релизов, выходящих через определенные промежутки времени (примерно полугодичные, хотя подготовка текущего релиза несколько затянулась), и на протяжении длительного (трех- или пятигодичного) периода пользующихся поддержкой. Вторая же задача осуществима за счет регулярных промежуточных обновлений, предназначенных для пользователей, желающих работать с самым современным софтом.
Затем в выступлении прозвучала очень интересная мысль. Мы, дистростроители, сказал, Марк, часто забываем, что наша роль меньше, чем роль тех ребят, которые собственно и разрабатывают те пакеты, которые включаются в дистрибутивы. И дистростроитель должны уважать их работу – в том числе и с помощью сообщений об ошибках, извещения о новых возможностях, включаемых в эти продукты майнтайнерами дистрибутивов, и тому подобными способами.
Логическим продолжением этой мысли было высказывание об аналогичных горизонтальных связях с другими дистростроителями. В первую очередь речь зашла, конечно, о взаимоотношениях с разработчиками Debian – материнской. по отношению к Ubuntu, системы. Но не отвергается и сотрудничество с иными майнтайнерами, такими, как команда разработчиков Fedora, с целью обмена модификациями ядра и пакетов.
Однако и тут Марк подчеркнул, что связи, так сказать, вертикальные – с разработчиками крупных программных пакетов, таких, как Gnome, KDE, Apache, MySQL, Postgress, и многие, многие другие – являются более важными. Потому что в конечном счете именно их работа обеспечивает успех или неуспех любого дистрибутива.
В этом контексте прозвучал и ответ на вопрос, который меня интересовал с первого дня знакомства с Ubuntu: почему для титульного дистрибутива семейства, ориентированного, в том числе, и на начинающего пользователя, в качестве пользовательского окружения был выбран Gnome, хотя, казалось бы, KDE справляется с этой ролью как минимум не хуже. Марк объяснил сделанный выбор тем, что в момент создания Ubuntu Gnome был более простой в использовании средой, нежели KDE. Когда же разработчики KDE, оценив концепцию дистрибутива, предложили вариант со своим десктопом, – родился Kubuntu.
Зашла речь, конечно, и о бизнес-модели, призванной сделать разработку дистрибутива коммерчески выгодной. Здесь интересен следующий момент: вместо создания единой централизованной компании фирма Canonocal, обеспечивающая финансирование разработки Ubuntu и обеспечение его поддержки, привлекает к сотрудничеству распределенные фирмы из разных стран – в настоящее время их более 300, – которые и осуществляют регионально-ориентированную поддержку.
Маленькое отступление: как известно, Ubuntu оказался очень продуктивным клоно-породителем. Помимо всего прочего, от него происходит несколько испанских вариантов дистрибутива, ориентированных на использование в провициальной администрации этой страны; создается впечатление, что скоро в Испании каждая провинция будет иметь свой вариант Ubuntu. Тонкий намек: не пойти ли и нашей стране по этому пути? В этом случае востребованной окажутся и услуги фирм, способных оказать квалифицированную поддержку...
Наконец, речь дошла и до схемы разработки открытого софта вообще и дистрибутива Ubuntu в особенности: о механизмах контроля версий и веток исходного кода, о методах совместной работы над документацией и ее переводами на разные языки – например, на санскрит (да, товарищи, в Ubuntu предусмотрена и такая локаль). Что, как было убедительно продемонстрировано, действительно, оказывается нынче ключевым моментом для любого проекта Open Source – как с технологической стороны, так и со стороны, если так можно выразиться, социальной. Впрочем, для открытых исходников эти аспекты оказываются связанными практически неразрывно – и это тоже прозвучало в выступлении Марка.
Действительно, ведь сам принцип разработки открытых исходников базируется на вовлечении в процесс максимально широкого круга лиц, к таковой в принципе способных – и это одна сторона вопроса. Другая же, оборотная, выливается в проблему эффективности контроля над изменениями, которая может обеспечить целостность системы разработки и защиту ее от повреждения некорректно написанными фрагментами кода. То есть, попросту говоря, все сводится к тому, чтобы система была «дуракоустойчивой» – и при этом чтоб никто из разработчиков не ушел обиженным...