Хабрахабр

Как создать open source проект

Уже на этой неделе в Санкт-Петербурге пройдет IT-фестиваль TechTrain. Одним из спикеров будет Ричард Столлман. Embox тоже участвует в фестивале, и конечно мы не могли обойти вниманием тему СПО. Поэтому один из наших докладов называется “От студенческой поделки до opensource проекта. Опыт Embox”. Он будет посвящен истории развития Embox как проекта с открытым кодом. В данной статье я хочу поведать об основных идеях, которые по моему мнению влияют на развитие opensource проектов. Статья, как и доклад, основана на личном опыте.

Очевидно, что проект c открытым кодом это проект имеющий одну из лицензий, которые позволяют получать доступ к исходному коду проекта. Начнем с простого, с определения термина opensource. То есть, если какая-то компания или разработчик, опубликует код своего продукта, частично или полностью, то это еще не делает этот продукт opensource проектом. Кроме того, открытый проект подразумевает возможность внесения изменений сторонними разработчиками. И наконец, любая проектная деятельность должна приводить к появлению какого то результата, причем открытость проекта подразумевает, что этот результат используют не только сами разработчики.

Это слишком большая и сложная тема, которая требует глубокого разбирательства. Проблемы открытых лицензий трогать не будем. Но поскольку сам я не являюсь специалистом в области авторского права, то скажу только, что лицензия должна отвечать целям проекта. По данной теме написано довольно много хороших статей и материалов. Например, для Embox выбор BSD, а не GPL лицензии не был случайным.

Управлять им, сохранять целостность и работоспособность гораздо сложнее по сравнению с проектом имеющим централизованное управление. Тот факт, что открытый проект должен давать возможность вносить изменения и влиять на развитие открытого проекта, подразумевает, что проект распределенный. Ответ лежит в области коммерческой целесообразности, для определенного класса проектов выгода от такого подхода перевешивает затраты. Возникает резонный вопрос зачем вообще делать открытые проекты. Например, сложно представить разработку системы управления электростанцией или самолетом, основанную на открытом принципе. То есть не для всех проектов подходит и вообще допустим открытый подход. Но за конечный продукт должен кто-то отвечать. Нет, конечно в состав подобных систем стоит включать модули на основе открытых проектов, ведь это даст ряд преимуществ. Код при этом может находиться в публичном доступе. Даже если система полностью основана на коде открытых проектов, разработчик, упаковав все в одну систему и сделав конкретные сборки и настройки, по сути дела закрывает ее.

Как я уже сказал, код конечной системы может остаться в публичном доступе. Для этих систем также существует куча преимуществ от создания открытых проектов или участия в них. Это правда, но ведь вполне может найтись желающий проверить отдельные участки кода, или например, кто-то может обнаружить, что используемая библиотека не совсем корректно сконфигурирована. Зачем, ведь очевидно, что вряд ли у кого то найдется такой же самолет, чтобы протестировать систему.

Например, библиотеку по поддержке какого-то протокола обмена данными. Еще большая выгода появляется, если компания, выделяет некоторую базовую часть системы в отдельный проект. Кроме того, специалистам, которые могут изучить данный кусок системы в открытом доступе, требуется гораздо меньше времени для эффективного его использования. В этом случае, даже если протокол специфичный для данной предметной области, можно разделить расходы на поддержание данного куска системы с другими компаниями из этой области. Ну и наконец, выделение куска в самостоятельную сущность, которую используют сторонние разработчики, позволяет сделать эту часть более качественной, ведь нужно предложить эффективные API, сделать документацию, я даже не говорю про улучшение тестового покрытия.

Ведь все выгоды остаются: сотрудники лучше знают проект, следовательно эффективнее его используют, компания может влиять на направление развития проекта, ну и использование готового отлаженного кода, очевидно сокращает расходы компании. Коммерческую выгоду компания может получить и не создавая открытых проектов, достаточно чтобы ее специалисты участвовали в сторонних проектах, применяемых в компании.

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

В некоторых случаях это вообще единственный путь выхода на рынок. И конечно, не нужно забывать, что opensource проект является эффективным путем заявить о себе как носителе какой либо специализации. Наверное не нужно объяснять, что существует куча конкурентов. Например, Embox начинался как проект по созданию ОСРВ. Без создания сообщества, у нас просто не хватило бы ресурсов довести проект до конечного пользователя, то есть, чтобы проектом стали пользоваться сторонние разработчики.

Оно позволяет существенно сократить затраты на управление проектом, развивает и поддерживает проект. Сообщество является ключевым в opensource проекте. Можно сказать, что без сообщества вообще нет opensource проекта.

Я, чтобы не пересказывать уже известные факты, постараюсь сделать акцент на опыте Embox. О том как создать и управлять сообществом проекта с открытым кодом написано множество материалов. То есть, многие рассказывают как управлять существующим сообществом, но вот моменты его создания, порой упускают из виду, считая это данностью. Например, очень интересным вопросом является процесс создания сообщества.

Я имею в виду универсальных правил не существует, так же как серебрянной пули, хотя бы потому, что проекты очень сильно разные. Главное правило при создании сообщества opensource проекта — нет никаких правил. Более того на разных стадиях развития проекта (а следовательно и сообщества) правила меняются. Вряд ли можно одними и теми же правилами пользоваться при создании сообщества для библиотеки логирования на js и какая нибудь узкоспециализированный драйвер.

По сути дела мы заходили в какое то другое сообщество. Embox начинался как студенческий проект, поскольку был доступ к студентам кафедры системного программирования. То есть мы выполняли одно из основных правил организации сообщества, участники сообщества должны что-то получить, причем эта цена должна соответствовать вкладу участника. Участников этого сообщества, студентов, мы могли заинтересовать хорошей промышленной практикой по их специальности, научными работами в области системного программирования, курсовыми и дипломами.

Очень важно понимать, что пользователи это полноценные участники opensource сообщества. Следующей стадией для Embox стал поиск сторонних пользователей. И чтобы захотеть стать контрибьютором проекта, сначала так или иначе его начинают использовать. Пользователей обычно больше чем разработчиков.

Они предложили создать альтернативную прошивку для Lego Mindstorm. Первыми пользователями для Embox стала кафедра Теоретической Кибернетики. Но все равно это был очень хороший опыт. И хотя это все еще были локальные пользователи (мы с ними могли встретиться лично, и обсудить что они хотят). В итоге у нас появились по настоящему сторонние пользователи, которые стали спрашивать, что Embox и как этим пользоваться. Например, мы разработали демки, которые можно было показать другим, ведь роботы это весело и притягивает внимание.

Нет конечно мы задумывались об этих важных вещах и раньше, но это было преждевременно и не давало положительного эффекта. На этой стадии, нам пришлось задумываться о документации, о средствах коммуникации с пользователями. Приведу пару примеров. Эффект был скорее отрицательный. Мы сделали страницы на нескольких языках, причем не только английский и русский, на которых худо бедно могли коммуницировать, но и немецкий и испанский. Мы использовали googlecode, wiki которого поддерживало мультиязычность. Или вводили правила про написание документации и комментирования, но поскольку API менялось довольно часто и существенно, получалось, что наша документация устаревала, и вводила в заблуждение больше чем помогала. В результате очень нелепо выглядело, когда спрашивают на этих языках, но мы вообще не можем ответить.

И даже появился коммерческий заказчик, который хотел, чтобы для него разработали собственную ОСРВ. В итоге все наши усилия, даже не правильные, привели к тому, что появились внешние пользователи. Тут нужно рассказать и о хороших моментах и о плохих. И разработали мы поскольку у нас есть опыт и какие то наработки. Так как многие разработчики были привлечены к данному проекту на коммерческой основе, сообщество и так довольно неустойчивое, разделилось, что конечно не могло не сказаться на развитии проекта. Начну с плохих. По крайней мере эта цель не была основной. Дополнительным фактором, было то, что направление проекта задавалось, одним коммерческим заказчиком, а его целью было не дальнейшее развитие проекта.

Мы получили действительно сторонних пользователей. С другой стороны, был ряд положительный моментов. Мотивация участвовать в проекте выросла. Это был не только заказчик, но и те для кого эта система предназначалась. И главное, мы услышали одно желание заказчиков, которое на тот момент, казалось нам бредовым, но которое сейчас является основной идей Embox, а именно, использовать в системе уже разработанный код. Ведь если на интересном деле можно еще и заработать, это всегда приятно. То есть, основным положительным моментом способствующим дальнейшему развитию проекта было осознание, что проект используют сторонние пользователи, и он должен решать какие то их проблемы. Сейчас основная идея Embox это использование ПО Linux без Linux.

Основным сдерживающим фактором развития проекта по студенческой модели является мотивация участников. На тот момент, Embox уже вышел за рамки студенческого проекта. Если мотивация не появляется, студент просто перестает участвовать в проекте. Студенты участвуют пока они учатся, а когда они выпустились, должна появиться другая мотивация. Если принять во внимание, что студентов сначала нужно обучить, то получается что хорошими специалистами они становятся к моменту выпуска, но вклад в проект, в силу неопытности, не очень большой.

Как я уже пояснил выше, основное свойство opensource проекта, это его сообщество. В общем мы плавно переходим к основному моменту позволяющему говорить о создании opensource проекта, — созданию продукта, который бы решал проблемы его пользователей. Но откуда им взяться пока не чем пользоваться? Причем участники сообщества это прежде всего пользователи. Если же заниматься созданием сообщества только через пиар сообщества, написанием wiki на всех языках мира, или правильным git workflow на github, то вряд ли это будет иметь значение, на ранних стадиях проекта. Вот и получается, что так же как и с не opensource проектом, нужно сосредоточиться на создании MVP (минимальным жизнеспособным продукте), и если он заинтересует пользователей, то вокруг проекта появиться сообщество. Конечно, на соответствующих стадиях это не только важные, но и необходимые вещи.

В заключение хочу привести комментарий, на мой взгляд отражающий ожидания пользователя от opensource проекта:

Уж очень ее активно пилят и крутые штуки делают). Я всерьез задумываюсь о переходе на эту ОС (по крайней мере, попробовать.

P. S. На TechTrain у нас будет аж три доклада. Один про open source и два про embedded (причем один практический). На стенде проведем мастер класс по программированию микроконтроллеров с помощью Embox. Традиционно привезем железки и дадим их попрограммировать. Будет еще квест и другие активности. Приходите на фестивать и на наш стенд, будет весело.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть