За последние годы многие страны делали громкие заявления о создании национальных операционных систем на основе 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-компании мы возьмем Red Hat. Относится к Red Hat можно по разному, но Red Hat – это признанный мировой стандарт в области корпоративного Linux. Также мы сделаем оптимистичное предположение, что вы успешно пройдете все этапы, уложившись в намеченные сроки.
В Red Hat около 700 разработчиков, которые создают около 10% кода, входящего в итоге дистрибутив. Так как мы ставим цель стать сильным дистрибутивом, но не обязательно лидером, то мы можем ограничиться 500. Ниже опускаться уже просто опасно – можно потерять контроль над продуктом.
Типичный квалифицированный разработчик стоит около $3000 в месяц. Мы не будем здесь подсчитывать налоги, стоимость инфраструктуры и т.д. - при желании вы можете добавить эти расходы самостоятельно.
Как упоминалось выше, потребуется некоторый срок, прежде чем разработчики начнут в достаточной степени влиять на проекты, в которых они участвуют. Таким образом мы получаем некоторое «мертвое время», в которое компания уже работает и требует денег на содержание, но еще не является значимым игроком на рынке. Оптимистичная оценка этого времени – 3 года. Таки образом, это «мертвое время» обойдется как минимум в $54 000 000. При этом нет, вообще говоря, никакой гарантии, что после этого компания заработает.
На этой стадии, пожалуй, стоит задать себе вопрос – готовы ли вы потратить $55 000 000 на работу, которая УЖЕ сделана, не имея при этом НИКАКИХ гарантий, что в итоге получится хоть что-то новое и значимое?
Кроме того, существует множество рисков, которые невозможно строго учесть – в конце концов, сообщество может не принять ваш дистрибутив лишь потому, что им не понравится ваша политика или логотип. К тому же, мир появление еще одного дистрибутива явно не изменит. Таким образом, затраты на то, чтобы стать «вторым лучшим» оказываются велики, а выгода весьма сомнительна.
План действий.
Основные этапы создания дистрибутива «революционным» способом:
Определить, что же будет вашим дополнением к технологии – лучший сервис, более удобный интерфейс, поддержка решений? На этом этапе важно не сделать типичной ошибки – не делать основной особенностью дистрибутива лишь его “национальность”. Этим вы ничего не добавите, а лишь отнимете. Основное преимущество open source – его открытость, порождающая очень быстрый темп инноваций. Постановка любых границ лишит ваш продукт этого преимущества.
Создать команду, пользуясь опытом одной из ведущих компаний. Для этого обучить сначала техническую поддержку, затем программистов (вплоть до разработчиков ядра). В лучшем случае это займет около 3 лет (см. выше).
Имея готовую команду должного уровня, можно либо создавать свой дистрибутив с нуля, либо сотрудничать с ведущими разработчиками.
Основные проблемы.
Хотя описанный выше подход и может привести к успеху в конечном итоге, он имеет два существенных недостатка:
Крайне высокий риск провала на начальной стадии. Практически невозможно гарантировать успех столь масштабного проекта при его старте «на пустом месте». Необходимо обучить огромное количество специалистов – инженеров поддержки, разработчиков и т.д. Что более важно и сложно – необходимо интегрировать всю огромную инфраструктуру, создаваемую с нуля, в огромное количество процессов взаимодействия, имеющих мировой масштаб.
Необходимость больших вложений уже на первом этапе. Как оценено выше, «революционный» подход требует вложения десятков миллионов долларов на долгий срок. При этом неоправданно высок риск, что итоговый продукт окажется актуален лишь для очень узкого круга заказчиков, и в итоге вложения окажутся непропорционально большими.
Часть 5. Создание дистрибутива «эволюционным» способом.
Альтернативой описанному выше подходу может быть другой – «эволюционный», лишенный указанных недостатков.
Суть подхода сводится к постепенной интеграции в налаженные схемы взаимодействия, используя каналы компаний, уже давно работающих в этой области. По мере же роста количества внедрений и уровня компетенции собственных инженеров постепенно брать на себя все больше функций.
План действий.
Основные этапы создания дистрибутива «эволюционным» способом:
Достигнуть договоренности о сотрудничестве с одной из ведущих компаний, имеющей налаженные схемы взаимодействия со всеми участниками рынками. Цель – получить доступ к “закрытой” части их работы и к каналам взаимодействия.
Создать команду для включения поддержки дополнительных языков в «базовый» дистрибутив. Дело в том, что мировые дистрибутивы поддерживают только основные языки (русский, английский и т.д.) и не поддерживают локальные языки, которые могут быть нужны для использования дистрибутива в отдельных республиках. Оценочный размер команды – 5-10 человек.
Создать команду для внедрений и последующей поддержки. Инженеры этой команды решают типовые вопросы, а в сложных ситуациях, требующих взаимодействия с разработчиками или третьими компаниями, используют налаженные каналы сотрудничающей компании. Оценочный размер команды – 20-40 человек.
По мере того, как растет количество внедрений, инженеры перенимают опыт и налаживаются собственные каналы взаимодействия, можно брать на себя все больше функций, расширять команду, начинать участвовать в разработке.
При достижении «критической массы» знаний и опыта можно создавать свой дистрибутив, продолжая сотрудничество. В этом случае дистрибутив имеет множество «точек опоры» (собственная команда разработки и поддержки, сотрудничество с командой «дружественного» дистрибутива, взаимодействие с независимыми разработчиками), и за счет этого никакие локальные проблемы не ведут к провалу проекта в целом. В конечном итоге такой подход порождает УСТОЙЧИВЫЙ дистрибутив.
Комментарии.
Такой «эволюционный» подход практически устраняет риск провала проекта на начальной стадии, так как использует всю инфраструктуру и возможности компании, которая УЖЕ успешно работает в области серьезных внедрений и поддержки Linux.
Кроме того, такой подход не требует неоправданно больших начальных вложений и позволяет получать результаты сразу, на первой же стадии, а не через три года.
Вывод
Создание “Моего Личного Linux” - крайне сложный и дорогой проект с весьма сомнительными коммерческими перспективами. Единственными разумными причинами создания такого дистрибутива могут быть безопасность и независимость.
Следовательно, компания-разработчик не может быть просто “сборщиком пакетов”. Компания, ставящая своей целью обеспечить высочайшую безопасность, должна быть активным участником сообщества разработчиков, причем ее сотрудники должны быть вовлечены в работу над основными компонентами системы.
Создание такой компании – задача решаемая, хотя и необходимо сразу отдавать себе отчет, что это крайне долгий и рискованный проект, если реализовывать его «с чистого листа». Гораздо эффективнее и быстрее решать такую задачу в сотрудничестве с компанией, уже имеющей большой опыт работы в этой области.
