За последние годы многие страны делали громкие заявления о создании национальных операционных систем на основе Linux. Прошли годы, но никто из них так и не преуспел. Самую громкую неудачу потерпел Китай. Цель данного документа – дать обзор основных «компонентов», из которых создается дистрибутив Linux, а также сделать некоторые оценки насчет стоимости подобного проекта и выгоды от него.
Часть 1. Что такое “Мой Личный Linux”?
Итак, если говорить о типичном дистрибутиве Linux, то что лежит в его основе? Какие основные “компоненты” делают архив программных пакетов дистрибутивом?
ОГРАНИЧЕНИЯ. Никогда и никаким образом невозможно включить в дистрибутив все открытое ПО, существующее на свете. Поэтому при создании дистрибутива необходимо ориентироваться на определенную аудиторию и на определенные задачи. Отталкиваясь от этого, можно определить, что должно войти в дистрибутив, а что останется за его рамками.
ПОЛИТИКА. Исходя из целевой аудитории необходимо определить политику развития и выбрать те версии программ, которые отвечают вашим потребностям. Включать ли в дистрибутив «новейшие» программы или «проверенные временем» - это полностью зависит от вашей аудитории. Например, Red Hat Enterprise Linux ориентирован на корпоративный сектор, поэтому его политика - «новейшие из стабильных»; Ubuntu ориентирован на домашние компьютеры и его политика - «новейшие» пакеты и т.д.
СИСТЕМА СБОРКИ. Основой для превращения разрозненных программ в дистрибутив служит система управления пакетами. После того, как политика определила, что включать в дистрибутив, система сборки определит, как это сделать. Стандартом LSB (Linux Standard Base) является система RPM. Тем не менее, DPKG или еще какие-либо системы также могут быть вариантами.
ПРАВИЛА. Необходимо сформулировать правила и четко следовать им. “Чистый” open source очень гибок. Это означает, что все правила, которым будет подчиняться ПО с составе дистрибутива, необходимо определить самостоятельно. В частности, это относится к тому, куда устанавливать ПО и библиотеки, где и в каком виде хранятся файлы настроек и т.д.
Часть 2. Пятый элемент.
Таким образом, все выглядит несложно. Необходимо только сделать некоторое количество рутинной работы – выбрать “нужные” версии “нужного” программного обеспечения, “нужным” образом его собрать в “нужные” пакеты. Технически это очень просто, и именно по этой причине многие создают свои дистрибутивы.
Однако, для создания успешного дистрибутива необходимо задуматься еще о ряде вопросов. И именно по этой причине ведущие дистрибутивы Linux можно пересчитать по пальцам одной руки. Что же мешает всем остальным? Ответ на этот вопрос следует из основного подхода к бизнесу вокруг open source:
«В open source нет ни лицензионных отчислений, ни интеллектуальной собственности – все держится на полезных для пользователя дополнениях к технологии».
Отсюда возникает «пятый элемент», о котором большинство забывают:
ДОПОЛНЕНИЕ К ТЕХНОЛОГИИ. Ключевой вопрос при создании эффективной Linux-компании – каково ВАШЕ дополнение? Что вы предлагаете своим клиентам? Чем вы отличаетесь от всех остальных?
Ведь если компания не предлагает ничего своего, то зачем с ней вообще работать, если все те же компоненты дистрибутива можно взять самостоятельно?
Часть 3. Информация к размышлению.
НЕУПРАВЛЯЕМЫЕ ПАКЕТЫ. Вы можете включить в дистрибутив ПО, на развитие которого никак не влияете. Давайте возьмем для примера типичный дистрибутив, состоящий из примерно 3000 пакетов. Сколько разработчиков работают над ними? Тысячи, а скорее даже десятки тысяч. А теперь задайтесь вопросом – сколько из них будут работать для вас? Если ответ меньше чем хотя бы «сотни» - вы явно не лидер. Вы не определяете развитие «своего» продукта. Вы, конечно, можете изобрести велосипед еще раз, создать неплохой «Еще один дистрибутив», но кому это надо? Кто будет заинтересован в продукте, который не может определить свою собственную стратегию развития?
ПОДДЕРЖКА 3-ГО УРОВНЯ. Для обеспечения адекватной поддержки вам необходимо наладить постоянный контакт с сообществом разработчиков. А сделать это можно только активно участвуя в разработке и тем самым зарабатывая себе авторитет. Без этого ваша поддержка будет крайне ограниченной. Разумеется, можно нанять десяток человек и организовать call-центр. Но такая служба поддержки не сможет решить хоть сколько-нибудь сложную проблему, требующую вмешательства в код. В этом случае ваш дистрибутив никто никогда не установит на важные системы, потому что ему нельзя доверять.
ЧЕЛОВЕЧЕСКИЕ РЕСУРСЫ. Для того, чтобы создать ведущий дистрибутив, недостаточно как-нибудь участвовать в разработке. Невозможно нанять 500 любых разработчиков и стать лидером, потому что эти люди до данного момента не участвовали в каких-либо проектах. Для того, чтобы определять развитие продуктов, необходимо иметь с своем штате «ключевых» разработчиков. Но большинство этих людей уже работают в крупных корпорациях, таких как Google и Red Hat. Таким образом, после того как вы наймете несколько сотен разработчиков, вам придется очень постараться, чтобы они вошли в команды разработки ключевых проектов хотя бы в ближайшие 3 года. Мы сейчас не говорим о том, чтобы возглавить эти проекты, неплохо будет, если они хотя бы войдут в число основных разработчиков. Особая история – разработчики ядра. Они необходимы в команде, если мы говорим о серьезном дистрибутиве, и их сложнее всего найти. И не забывайте – вам придется платить им все эти годы.
СЕРТИФИКАЦИИ. До тех пор, пока вы не подниметесь на определенный уровень, вы не станете частью «экосистемы». Дело в том, что операционная система сама по себе – одна из наименее привлекательных вещей в мире. Без ПО под нее она не стоит вообще ничего. А так как вы не являетесь ведущей компанией, то назовите хотя бы одну причину, по которой независимым разработчикам, таким как Oracle, IBM, SAP и т.д. стоит прикладывать усилия и поддерживать свои приложения на вашем дистрибутиве? Для них гораздо рациональнее работать с признанным корпоративным стандартом, таким как, например, Red Hat. Точно так же обстоит дело с поставщиками оборудования. Вам потребуется как завоевать определенную техническую репутацию, так и занять заметную часть рынка, прежде чем станет возможным сотрудничать с ведущими компаниями.
Часть 4. Мне все же нужен “Мой личный Linux”.
Итак, мы примерно выяснили, какие проблемы придется преодолеть, чтобы добиться признания на рынке и в сообществе и сделать свой дистрибутив одним из ведущих.
Давайте оценим, во сколько минимально обойдется этот процесс. В качестве примера успешной Linux-компании мы возьмем Red Hat. Относится к Red Hat можно по разному, но Red Hat – это признанный мировой стандарт в области корпоративного Linux. Также мы сделаем оптимистичное предположение, что вы успешно пройдете все этапы, уложившись в намеченные сроки.
В Red Hat около 700 разработчиков, которые создают около 10% кода, входящего в итоге дистрибутив. Так как мы ставим цель стать сильным дистрибутивом, но не обязательно лидером, то мы можем ограничиться 500. Ниже опускаться уже просто опасно – можно потерять контроль над продуктом.
Типичный квалифицированный разработчик стоит около $3000 в месяц. Мы не будем здесь подсчитывать налоги, стоимость инфраструктуры и т.д. - при желании вы можете добавить эти расходы самостоятельно.
Как упоминалось выше, потребуется некоторый срок, прежде чем разработчики начнут в достаточной степени влиять на проекты, в которых они участвуют. Таким образом мы получаем некоторое «мертвое время», в которое компания уже работает и требует денег на содержание, но еще не является значимым игроком на рынке. Оптимистичная оценка этого времени – 3 года. Таки образом, это «мертвое время» обойдется как минимум в $54 000 000. При этом нет, вообще говоря, никакой гарантии, что после этого компания заработает.
На этой стадии, пожалуй, стоит задать себе вопрос – готовы ли вы потратить $55 000 000 на работу, которая УЖЕ сделана, не имея при этом НИКАКИХ гарантий, что в итоге получится хоть что-то новое и значимое?
Кроме того, существует множество рисков, которые невозможно строго учесть – в конце концов, сообщество может не принять ваш дистрибутив лишь потому, что им не понравится ваша политика или логотип. К тому же, мир появление еще одного дистрибутива явно не изменит. Таким образом, затраты на то, чтобы стать «вторым лучшим» оказываются велики, а выгода весьма сомнительна.
Часть 5. План действий.
Основные этапы создания “Моего Личного Linux”:
Определить, что же будет вашим дополнением к технологии – лучший сервис, более удобный интерфейс, поддержка решений? На этом этапе важно не сделать типичной ошибки – не делать основной особенностью дистрибутива лишь его “национальность”. Этим вы ничего не добавите, а лишь отнимете. Основное преимущество open source – его открытость, порождающая очень быстрый темп инноваций. Постановка любых границ лишит ваш продукт этого преимущества.
Договориться о сотрудничестве с одной из ведущих компаний, чтобы получить доступ к “закрытой” части их работы.
Создать команду, пользуясь опытом ведущей компании. Для этого обучить сначала техническую поддержку, затем программистов (вплоть до разработчиков ядра). В лучшем случае это займет около 3 лет (см. выше).
Имея готовую команду должного уровня, можно либо создавать свой дистрибутив с нуля, либо сотрудничать с ведущими разработчиками. В этом случае дистрибутив имеет множество «точек опоры» (собственная команда разработки и поддержки, сотрудничество с командой «дружественного» дистрибутива, взаимодействие с независимыми разработчиками), и за счет этого никакие локальные проблемы не ведут к провалу проекта в целом. В конечном итоге такой подход порождает УСТОЙЧИВЫЙ дистрибутив.
Вывод
Создание “Моего Личного Linux” - крайне сложный и дорогой проект с весьма сомнительными коммерческими перспективами. Единственными разумными причинами создания такого дистрибутива могут быть безопасность и независимость.
Следовательно, компания-разработчик не может быть просто “сборщиком пакетов”. Компания, ставящая своей целью обеспечить высочайшую безопасность, должна быть активным участником сообщества разработчиков, причем ее сотрудники должны быть вовлечены в работу над основными компонентами системы.
Создание такой компании – задача решаемая, хотя и необходимо сразу отдавать себе отчет, что это крайне долгий и довольно рискованный проект.