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

    Уже на этой неделе в Санкт-Петербурге пройдет 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. Традиционно привезем железки и дадим их попрограммировать. Будет еще квест и другие активности. Приходите на фестивать и на наш стенд, будет весело.
    Embox
    41,54
    Открытая и свободная ОС для встроенных систем
    Поделиться публикацией

    Похожие публикации

    Комментарии 12

      +1

      А какая ниша и цель у Embox? IoT, security, critical safety?


      В GSoC не пробовали участвовать? Я вот сейчас сам в рамках GSoC пытаюсь добавить поддержку xen на Beagleboard-x15. Оно там вроде как и не нужно, 32битный процессор же, а сами разработчики xen говорят, что виртуализация на arm32 это либо хобби, либо IoT. Вот интересно, в какую степь Вы шагаете.

        0
        А какая ниша и цель у Embox? IoT, security, critical safety?

        IoT, security, critical safety :)

        Вообще текущий лозунг «Embox main idea is using Linux software without Linux.»
        Из последних достижений запустили Qt и OpenCV на микроконтроллерах STM32F7-Discovery.

        Более поднобно можно посмотреть о наших идеях в статьях: «Многообразный мир embedded systems и место Embox в нем» и «Железячники vs. Программисты»

        В GSoC не пробовали участвовать?

        Да, но это было очень давно, на начальном этапе проекта. Планируем еще раз попытаться, может даже в этом году подадимся.

        Я вот сейчас сам в рамках GSoC пытаюсь добавить поддержку xen на Beagleboard-x15

        Круто!

        Xen тоже занимались и занимаемся, но тоже пока из хобби (или ресерча) не вылезло. Идея сделать unikernel, в принципе у нас все есть, и концепция единственного приложения и включение функциональности только для этого приложения.

        Вот интересно, в какую степь Вы шагаете.

        Как уже сказал, ищем ниши на пересечении Linux и embedded
          +1
          Embox mission

          Embox main idea is using Linux software without Linux

          Вот тут и начинаются первые непонятки. К примеру, миссия подменяется понятием идеи. А ведь миссия это то, как продукт или компания будут помогать людям. Я вот прочитал описание Вашего продукта и так и не понял, для чего он нужен.

            0
            Наверное соглашусь с Вами.

            Как Вам такая миссия?
            Миссия Embox сделать разработку ПО для встроенных систем такой же удобной, как для обычных дестопов.

              0

              Тут уж я оценить не могу — это задача компании создавать миссию. Лично мне в миссиях не нравятся сравнения — каждый их воспринимает по-своему, они привязывают к какому-то ориентиру и тем самым ограничивают. А вдруг кому-то в embox удастся сделать удобной разработку, но используя подход не принятый в десктопе. Обычно четкие ориентиры нужны в целях компании.
              Но лично мне не сильно важна миссия компании. Гораздо интереснее знать, чем мне может помочь продукт, как я могу его использовать, какие границы применимости. Мне понятно, что Вам хочется уметь всё и сразу, но мне непонятно какое направление является приоритетным. Вроде как FreeRTOS — для простейших задач с малым потреблением всего, RTEMS — для более тяжелых задач с POSIX обвязкой + возможность писать программы для Ada. А в embox? Если я хочу построить сеть IoT, там уже есть наиболее популярные протоколы? Если мне нужно сертифицироваться по стандарту безопасности, есть ли уже документация для подачи на стандарт, может быть в платной версии? Если оно у Вас поддерживает security, то есть ли библиотеки для ГОСТов на эл. кривых?

                0
                Вам хочется уметь всё и сразу

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

                Гораздо интереснее знать, чем мне может помочь продукт, как я могу его использовать, какие границы применимости.

                Согласен, это самое интересное. Так вот, я об этом и говорю. Мы например показали принципиальную возможность создать SIP телефон (на базе проекта pjsip) на базе микроконтроллера stm32f7. наверное не нужно объяснять, что использование готовой библиотеки принципиально снижает сложность разработки. Эта библиотека прекрасно используется на Linux. Но в микроконтроллер Linux не влезет по объему памяти. Можно взять более мощьную платформу, но это сразу удорожание железа. В нашем же случае мы позволили, с одной стороны сократить затраты на разработку, с другой стороны не усложнять сам экземпляр железки.

                В приведенных Вами примерах видны типичные задачи и существующие подходы. Мы предлагаем для определенных сегментов задач пересмотреть эти подходы. Приведу еще пример. Вот Вы пишите
                Если оно у Вас поддерживает security, то есть ли библиотеки для ГОСТов на эл. кривых?

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

                  0

                  Вот мне ниша и непонятна. Те, кому нужна серьезная сертификация, обычно не используют библиотеки Linux с самого старта. Те, кто хочет использовать Linux, использует Linux. У меня хобби-проект следующий будет либо на Linux, либо на FreeRTOS. Смысла большого в использовании embox я не могу найти. Это не претензия, я очень рад, что embox существует, просто я не понимаю, где он мог бы быть полезен сообществу. Я думаю, многие хоббисты, которые хотят использовать библиотеки Linux, они просто использую RPi или то, что под рукой.

                    0
                    Ну какие тут могут быть претензии :)
                    Если Вам достаточно Linux, конечно используйте Linux, если достаточно FreeRTOS, используйте его :)
        +1

        Вы рискуете попасть в большую беду, ставя рядом Ричарда Столлмана и "Open Source". Почитайте про его отношение к этому термину, чтобы избежать возможного конфуза, или более осторожно связывайте эту фигуру со своими мыслями ;-)

          0
          Спасибо.
          Вы совершенно правы. Поэтому мы старались не ставить и враза звучит
          Одним из спикеров будет Ричард Столлман. Embox тоже участвует в фестивале, и конечно мы не могли обойти вниманием тему СПО

          То есть не open source (открытое), а free source (свободное). Но поскольку лицензия у нас BSD, то правильнее говорить об открытом ПО:)
          Так что конфуза надеемся избежать. А выбор лицензии и всех терминов был не случайный :)
            +1
            «мы не могли обойти вниманием тему СПО» — почему-то мне утром показалось, что написано было иначе…

            Кстати, «Free Software», а не free source. И с:

            поскольку лицензия у нас BSD, то правильнее говорить об открытом ПО

            … не могу согласиться, поскольку лицензированное под BSD программное обеспечение является свободным. А сама лицензия одобрена FSF.

            Наконец, «открытое ПО» — плохая формулировка на русском языке, т.к. слишком общая и вовсе не обязывает соответствовать Open Source Definition.

            Но хватит, а то мы далеко уходим от темы. Удачи! ;-)
              0
              Со всеми уточнениями согласен. Спасибо!

              Удачи! ;-)

              Спасибо!

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое