Уже на этой неделе в Санкт-Петербурге пройдет IT-фестиваль TechTrain. Одним из спикеров будет Ричард Столлман. Embox тоже участвует в фестивале, и конечно мы не могли обойти вниманием тему СПО. Поэтому один из наших докладов называется “От студенческой поделки до opensource проекта. Опыт Embox”. Он будет посвящен истории развития Embox как проекта с открытым кодом. В данной статье я хочу поведать об основных идеях, которые по моему мнению влияют на развитие opensource проектов. Статья, как и доклад, основана на личном опыте.
Начнем с простого, с определения термина opensource. Очевидно, что проект c открытым кодом это проект имеющий одну из лицензий, которые позволяют получать доступ к исходному коду проекта. Кроме того, открытый проект подразумевает возможность внесения изменений сторонними разработчиками. То есть, если какая-то компания или разработчик, опубликует код своего продукта, частично или полностью, то это еще не делает этот продукт opensource проектом. И наконец, любая проектная деятельность должна приводить к появлению какого то результата, причем открытость проекта подразумевает, что этот результат используют не только сами разработчики.
Проблемы открытых лицензий трогать не будем. Это слишком большая и сложная тема, которая требует глубокого разбирательства. По данной теме написано довольно много хороших статей и материалов. Но поскольку сам я не являюсь специалистом в области авторского права, то скажу только, что лицензия должна отвечать целям проекта. Например, для Embox выбор BSD, а не GPL лицензии не был случайным.
Тот факт, что открытый проект должен давать возможность вносить изменения и влиять на развитие открытого проекта, подразумевает, что проект распределенный. Управлять им, сохранять целостность и работоспособность гораздо сложнее по сравнению с проектом имеющим централизованное управление. Возникает резонный вопрос зачем вообще делать открытые проекты. Ответ лежит в области коммерческой целесообразности, для определенного класса проектов выгода от такого подхода перевешивает затраты. То есть не для всех проектов подходит и вообще допустим открытый подход. Например, сложно представить разработку системы управления электростанцией или самолетом, основанную на открытом принципе. Нет, конечно в состав подобных систем стоит включать модули на основе открытых проектов, ведь это даст ряд преимуществ. Но за конечный продукт должен кто-то отвечать. Даже если система полностью основана на коде открытых проектов, разработчик, упаковав все в одну систему и сделав конкретные сборки и настройки, по сути дела закрывает ее. Код при этом может находиться в публичном доступе.
Для этих систем также существует куча преимуществ от создания открытых проектов или участия в них. Как я уже сказал, код конечной системы может остаться в публичном доступе. Зачем, ведь очевидно, что вряд ли у кого то найдется такой же самолет, чтобы протестировать систему. Это правда, но ведь вполне может найтись желающий проверить отдельные участки кода, или например, кто-то может обнаружить, что используемая библиотека не совсем корректно сконфигурирована.
Еще большая выгода появляется, если компания, выделяет некоторую базовую часть системы в отдельный проект. Например, библиотеку по поддержке какого-то протокола обмена данными. В этом случае, даже если протокол специфичный для данной предметной области, можно разделить расходы на поддержание данного куска системы с другими компаниями из этой области. Кроме того, специалистам, которые могут изучить данный кусок системы в открытом доступе, требуется гораздо меньше времени для эффективного его использования. Ну и наконец, выделение куска в самостоятельную сущность, которую используют сторонние разработчики, позволяет сделать эту часть более качественной, ведь нужно предложить эффективные API, сделать документацию, я даже не говорю про улучшение тестового покрытия.
Коммерческую выгоду компания может получить и не создавая открытых проектов, достаточно чтобы ее специалисты участвовали в сторонних проектах, применяемых в компании. Ведь все выгоды остаются: сотрудники лучше знают проект, следовательно эффективнее его используют, компания может влиять на направление развития проекта, ну и использование готового отлаженного кода, очевидно сокращает расходы компании.
На этом преимущества от создания opensource проектов не заканчиваются. Возьмем такую важную составляющую бизнеса как маркетинг. Для него это очень хорошая песочница, которая позволяет эффективно оценить требования рынка.
И конечно, не нужно забывать, что opensource проект является эффективным путем заявить о себе как носителе какой либо специализации. В некоторых случаях это вообще единственный путь выхода на рынок. Например, Embox начинался как проект по созданию ОСРВ. Наверное не нужно объяснять, что существует куча конкурентов. Без создания сообщества, у нас просто не хватило бы ресурсов довести проект до конечного пользователя, то есть, чтобы проектом стали пользоваться сторонние разработчики.
Сообщество является ключевым в opensource проекте. Оно позволяет существенно сократить затраты на управление проектом, развивает и поддерживает проект. Можно сказать, что без сообщества вообще нет opensource проекта.
О том как создать и управлять сообществом проекта с открытым кодом написано множество материалов. Я, чтобы не пересказывать уже известные факты, постараюсь сделать акцент на опыте Embox. Например, очень интересным вопросом является процесс создания сообщества. То есть, многие рассказывают как управлять существующим сообществом, но вот моменты его создания, порой упускают из виду, считая это данностью.
Главное правило при создании сообщества opensource проекта — нет никаких правил. Я имею в виду универсальных правил не существует, так же как серебрянной пули, хотя бы потому, что проекты очень сильно разные. Вряд ли можно одними и теми же правилами пользоваться при создании сообщества для библиотеки логирования на js и какая нибудь узкоспециализированный драйвер. Более того на разных стадиях развития проекта (а следовательно и сообщества) правила меняются.
Embox начинался как студенческий проект, поскольку был доступ к студентам кафедры системного программирования. По сути дела мы заходили в какое то другое сообщество. Участников этого сообщества, студентов, мы могли заинтересовать хорошей промышленной практикой по их специальности, научными работами в области системного программирования, курсовыми и дипломами. То есть мы выполняли одно из основных правил организации сообщества, участники сообщества должны что-то получить, причем эта цена должна соответствовать вкладу участника.
Следующей стадией для Embox стал поиск сторонних пользователей. Очень важно понимать, что пользователи это полноценные участники opensource сообщества. Пользователей обычно больше чем разработчиков. И чтобы захотеть стать контрибьютором проекта, сначала так или иначе его начинают использовать.
Первыми пользователями для Embox стала кафедра Теоретической Кибернетики. Они предложили создать альтернативную прошивку для Lego Mindstorm. И хотя это все еще были локальные пользователи (мы с ними могли встретиться лично, и обсудить что они хотят). Но все равно это был очень хороший опыт. Например, мы разработали демки, которые можно было показать другим, ведь роботы это весело и притягивает внимание. В итоге у нас появились по настоящему сторонние пользователи, которые стали спрашивать, что Embox и как этим пользоваться.
На этой стадии, нам пришлось задумываться о документации, о средствах коммуникации с пользователями. Нет конечно мы задумывались об этих важных вещах и раньше, но это было преждевременно и не давало положительного эффекта. Эффект был скорее отрицательный. Приведу пару примеров. Мы использовали googlecode, wiki которого поддерживало мультиязычность. Мы сделали страницы на нескольких языках, причем не только английский и русский, на которых худо бедно могли коммуницировать, но и немецкий и испанский. В результате очень нелепо выглядело, когда спрашивают на этих языках, но мы вообще не можем ответить. Или вводили правила про написание документации и комментирования, но поскольку API менялось довольно часто и существенно, получалось, что наша документация устаревала, и вводила в заблуждение больше чем помогала.
В итоге все наши усилия, даже не правильные, привели к тому, что появились внешние пользователи. И даже появился коммерческий заказчик, который хотел, чтобы для него разработали собственную ОСРВ. И разработали мы поскольку у нас есть опыт и какие то наработки. Тут нужно рассказать и о хороших моментах и о плохих. Начну с плохих. Так как многие разработчики были привлечены к данному проекту на коммерческой основе, сообщество и так довольно неустойчивое, разделилось, что конечно не могло не сказаться на развитии проекта. Дополнительным фактором, было то, что направление проекта задавалось, одним коммерческим заказчиком, а его целью было не дальнейшее развитие проекта. По крайней мере эта цель не была основной.
С другой стороны, был ряд положительный моментов. Мы получили действительно сторонних пользователей. Это был не только заказчик, но и те для кого эта система предназначалась. Мотивация участвовать в проекте выросла. Ведь если на интересном деле можно еще и заработать, это всегда приятно. И главное, мы услышали одно желание заказчиков, которое на тот момент, казалось нам бредовым, но которое сейчас является основной идей Embox, а именно, использовать в системе уже разработанный код. Сейчас основная идея Embox это использование ПО Linux без Linux. То есть, основным положительным моментом способствующим дальнейшему развитию проекта было осознание, что проект используют сторонние пользователи, и он должен решать какие то их проблемы.
На тот момент, Embox уже вышел за рамки студенческого проекта. Основным сдерживающим фактором развития проекта по студенческой модели является мотивация участников. Студенты участвуют пока они учатся, а когда они выпустились, должна появиться другая мотивация. Если мотивация не появляется, студент просто перестает участвовать в проекте. Если принять во внимание, что студентов сначала нужно обучить, то получается что хорошими специалистами они становятся к моменту выпуска, но вклад в проект, в силу неопытности, не очень большой.
В общем мы плавно переходим к основному моменту позволяющему говорить о создании opensource проекта, — созданию продукта, который бы решал проблемы его пользователей. Как я уже пояснил выше, основное свойство opensource проекта, это его сообщество. Причем участники сообщества это прежде всего пользователи. Но откуда им взяться пока не чем пользоваться? Вот и получается, что так же как и с не opensource проектом, нужно сосредоточиться на создании MVP (минимальным жизнеспособным продукте), и если он заинтересует пользователей, то вокруг проекта появиться сообщество. Если же заниматься созданием сообщества только через пиар сообщества, написанием wiki на всех языках мира, или правильным git workflow на github, то вряд ли это будет иметь значение, на ранних стадиях проекта. Конечно, на соответствующих стадиях это не только важные, но и необходимые вещи.
В заключение хочу привести комментарий, на мой взгляд отражающий ожидания пользователя от opensource проекта:
Я всерьез задумываюсь о переходе на эту ОС (по крайней мере, попробовать. Уж очень ее активно пилят и крутые штуки делают).
P. S. На TechTrain у нас будет аж три доклада. Один про open source и два про embedded (причем один практический). На стенде проведем мастер класс по программированию микроконтроллеров с помощью Embox. Традиционно привезем железки и дадим их попрограммировать. Будет еще квест и другие активности. Приходите на фестивать и на наш стенд, будет весело.
Автор: Антон Бондарев
