Како да креирате проект со отворен код

Оваа недела во Санкт Петербург ќе се одржи ИТ фестивал TechTrain. Еден од говорниците ќе биде Ричард Сталман. Ембокс учествува и на фестивалот, а секако не можевме да ја игнорираме и темата за слободен софтвер. Затоа се вика еден од нашите извештаи „Од студентски занаети до проекти со отворен код. Искуство со Embox“. Ќе биде посветен на историјата на развојот на Embox како проект со отворен код. Во оваа статија сакам да зборувам за главните идеи кои, според мое мислење, влијаат на развојот на проекти со отворен код. Написот, како и извештајот, се заснова на лично искуство.

Да почнеме со нешто едноставно, со дефиницијата на поимот opensource. Очигледно, проект со отворен код е проект кој има една од лиценците што овозможува пристап до изворниот код на проектот. Покрај тоа, отворен проект значи дека програмерите од трети страни можат да прават промени. Односно, ако некоја компанија или развивач го објави кодот на својот производ, делумно или целосно, ова сè уште не го прави овој производ проект со отворен код. И, конечно, секоја проектна активност мора да доведе до некој вид резултат, а отвореноста на проектот подразбира дека овој резултат се користи не само од самите програмери.

Нема да ги допираме проблемите со отворените лиценци. Ова е преголема и сложена тема која бара длабинска истрага. На оваа тема се напишани доста добри написи и материјали. Но, бидејќи јас самиот не сум експерт во областа на авторските права, само ќе кажам дека лиценцата мора да ги исполнува целите на проектот. На пример, за Embox изборот на BSD наместо GPL лиценца не беше случаен.

Фактот дека проектот со отворен код треба да обезбеди можност за правење промени и влијание врз развојот на проектот со отворен код подразбира дека проектот е дистрибуиран. Управувањето со него, одржувањето на интегритетот и перформансите е многу потешко во споредба со проект со централизирано управување. Се поставува разумно прашање: зошто воопшто се отвораат проекти? Одговорот лежи во областа на комерцијалната изводливост; за одредена класа на проекти, придобивките од овој пристап ги надминуваат трошоците. Односно, не е погоден за сите проекти и отворениот пристап е општо прифатлив. На пример, тешко е да се замисли развој на контролен систем за електрана или авион врз основа на отворен принцип. Не, се разбира, таквите системи треба да вклучуваат модули засновани на отворени проекти, бидејќи тоа ќе обезбеди голем број на предности. Но, некој мора да биде одговорен за финалниот производ. Дури и ако системот е целосно заснован на кодот на отворените проекти, развивачот, откако спакувал сè во еден систем и направил специфични градби и поставки, во суштина го затвора. Кодот може да биде јавно достапен.

Исто така, има многу придобивки за овие системи од создавањето или придонесот за проекти со отворен код. Како што веќе реков, крајниот системски код може да остане јавно достапен. Зошто, затоа што е очигледно дека е малку веројатно дека некој ќе го има истиот авион за тестирање на системот. Ова е точно, но можеби има некој што сака да провери одредени делови од кодот или, на пример, некој може да открие дека библиотеката што се користи не е конфигурирана сосема правилно.

Уште поголема придобивка се појавува доколку компанијата распредели некој основен дел од системот во посебен проект. На пример, библиотека за поддршка на некој вид протокол за размена на податоци. Во овој случај, дури и ако протоколот е специфичен за дадена предметна област, можете да ги споделите трошоците за одржување на овој дел од системот со други компании од оваа област. Покрај тоа, специјалистите кои можат да го проучуваат овој дел од системот во јавниот домен бараат многу помалку време за ефективно да го користат. И, конечно, одвојувањето на парче во независен ентитет што го користат програмерите од трети страни ни овозможува да го подобриме овој дел, бидејќи треба да понудиме ефективни API, да креираме документација, а јас дури и не зборувам за подобрување на покриеноста на тестовите.

Компанијата може да добие комерцијални придобивки без создавање проекти со отворен код; доволно е нејзините специјалисти да учествуваат во проекти од трети страни што се користат во компанијата. На крајот на краиштата, сите придобивки остануваат: вработените подобро го познаваат проектот, затоа го користат поефикасно, компанијата може да влијае на насоката на развојот на проектот, а употребата на готов, дебагиран код очигледно ги намалува трошоците на компанијата.

Придобивките од креирањето на проекти со отворен код не завршуваат тука. Ајде да земеме толку важна компонента на бизнисот како што е маркетингот. За него, ова е многу добар песок што му овозможува ефективно да ги процени барањата на пазарот.

И, се разбира, не смееме да заборавиме дека проектот со отворен код е ефикасен начин да се декларирате како носител на која било специјализација. Во некои случаи, ова е единствениот начин да се влезе на пазарот. На пример, Embox започна како проект за создавање RTOS. Веројатно нема потреба да се објаснува дека има многу конкуренти. Без создавање заедница, едноставно немаше да имаме доволно ресурси за да го доведеме проектот до крајниот корисник, односно програмерите од трети страни да почнат да го користат проектот.

Заедницата е клучна во проектот со отворен код. Тоа ви овозможува значително да ги намалите трошоците за управување со проекти, да го развиете и поддржите проектот. Можеме да кажеме дека без заедница воопшто не постои проект со отворен код.

Напишан е многу материјал за тоа како да се создаде и управува со проектна заедница со отворен код. За да не прераскажувам веќе познати факти, ќе се обидам да се фокусирам на искуството на Embox. На пример, процесот на создавање заедница е многу интересно прашање. Односно, многумина кажуваат како да управуваат со постоечката заедница, но моментите на нејзиното создавање понекогаш се занемаруваат, сметајќи дека ова е дадено.

Главното правило при креирање на заедница на проекти со отворен код е дека нема правила. Мислам дека нема универзални правила, исто како што не постои сребрен куршум, само затоа што проектите се многу различни. Малку е веројатно дека можете да ги користите истите правила кога креирате заедница за библиотека за js логирање и некој високо специјализиран двигател. Покрај тоа, во различни фази од развојот на проектот (а со тоа и заедницата), правилата се менуваат.

Ембокс започна како студентски проект бидејќи имаше пристап до студенти од одделот за програмирање на системи. Всушност, влегувавме во некоја друга заедница. Учесниците на оваа заедница, студенти, би можеле да ги заинтересираме за добра индустриска практика во нивната специјалност, научна работа од областа на системско програмирање, предмети и дипломи. Односно, следевме едно од основните правила за организирање заедница: членовите на заедницата мора да добијат нешто, а оваа цена мора да одговара на придонесот на учесникот.

Следната фаза за Embox беше пребарувањето за корисници од трети страни. Многу е важно да се разбере дека корисниците се целосни учесници во заедницата со отворен код. Обично има повеќе корисници отколку програмери. И за да сакаат да станат соработници на некој проект, тие прво почнуваат да го користат на еден или друг начин.

Првите корисници на Ембокс беа Одделот за теоретска кибернетика. Тие предложија да се создаде алтернативен фирмвер за Lego Mindstorm. И иако тие сè уште беа локални корисници (можевме лично да се сретнеме со нив и да разговараме што сакаат). Но, сепак беше многу добро искуство. На пример, развивме демо снимки што може да им се прикажат на другите, бидејќи роботите се забавни и привлекуваат внимание. Како резултат на тоа, добивме вистински корисници од трети страни кои почнаа да прашуваат што е Embox и како да го користат.

Во оваа фаза требаше да размислуваме за документација, за средства за комуникација со корисниците. Не, секако, претходно размислувавме за овие важни работи, но тоа беше прерано и не даде позитивен ефект. Ефектот беше прилично негативен. Дозволете ми да ви дадам неколку примери. Користивме googlecode, чие вики поддржуваше повеќејазичност. Создадовме страници на повеќе јазици, не само англиски и руски, на кои тешко можевме да комуницираме, туку и германски и шпански. Како резултат на тоа, изгледа многу смешно кога ќе се праша на овие јазици, но воопшто не можеме да одговориме. Или воведоа правила за пишување документација и коментирање, но бидејќи API се менуваше доста често и значително, се покажа дека нашата документација е застарена и повеќе погреши отколку што помогна.

Како резултат на тоа, сите наши напори, дури и погрешни, доведоа до појава на надворешни корисници. Па дури и се појави комерцијален клиент кој сакаше да му се развие сопствен RTOS. И го развивме затоа што имаме искуство и одредена основа. Тука треба да зборувате и за добрите и за лошите моменти. Ќе почнам со лошите. Бидејќи многу програмери беа вклучени во овој проект на комерцијална основа, заедницата веќе беше прилично нестабилна и поделена, што секако не можеше, а да не влијае на развојот на проектот. Дополнителен фактор беше тоа што насоката на проектот беше поставена од еден комерцијален клиент, а неговата цел не беше понатамошен развој на проектот. Барем тоа не беше главната цел.

Од друга страна, имаше голем број на позитивни аспекти. Добивме вистински корисници од трети страни. Не беа само клиентите, туку и оние за кои беше наменет овој систем. Зголемена е мотивацијата за учество во проектот. На крајот на краиштата, ако можете да заработите пари и од интересен бизнис, секогаш е убаво. И што е најважно, слушнавме една желба од клиентите, која во тоа време ни изгледаше луда, но која сега е главната идеја на Embox, имено, да користиме веќе развиен код во системот. Сега главната идеја на Embox е да користи софтвер Линукс без Линукс. Односно, главниот позитивен аспект кој придонесе за понатамошен развој на проектот беше сознанието дека проектот го користат трети корисници и треба да реши некои од нивните проблеми.

Во тоа време, Ембокс веќе излезе од опсегот на студентски проект. Главниот ограничувачки фактор во развојот на проектот според студентскиот модел е мотивацијата на учесниците. Студентите учествуваат додека студираат, а кога дипломираат треба да има поинаква мотивација. Ако мотивацијата не се појави, ученикот едноставно престанува да учествува во проектот. Ако се земе предвид дека студентите прво треба да се обучат, излегува дека тие стануваат добри специјалисти до дипломирањето, но нивниот придонес во проектот, поради неискуството, не е многу голем.

Генерално, непречено преминуваме на главната поента која ни овозможува да зборуваме за создавање проект со отворен код - создавање производ што би ги решил проблемите на неговите корисници. Како што објаснив погоре, главната сопственост на проектот со отворен код е неговата заедница. Покрај тоа, членовите на заедницата се првенствено корисници. Но, од каде доаѓаат кога нема што да се користи? Така, излегува дека, исто како и со проект без отворен код, треба да се фокусирате на создавање на MVP (минимум остварлив производ), и ако тоа ги интересира корисниците, тогаш ќе се појави заедница околу проектот. Ако сте ангажирани во креирање заедница само преку ПР на заедницата, пишување вики на сите јазици во светот или правилен работен тек на git на github, тогаш тоа веројатно нема да биде важно во раните фази на проектот. Се разбира, во соодветните фази тоа не се само важни, туку и неопходни работи.

Како заклучок, би сакал да истакнам коментар, според мое мислење, како одраз на очекувањата на корисниците од проект со отворен код:

Сериозно размислувам да се префрлам на овој ОС (барем обидете се. Тие активно го следат тоа и прават кул работи).

PS Вклучено TechTrain Ќе имаме дури три извештаи. Еден за отворен код и два за вграден (а еден е практичен). На штандот ќе спроведеме мастер клас за програмирање на микроконтролери со користење Ембокс. Како и обично, ќе го донесеме хардверот и ќе ви дозволиме да го програмирате. Ќе има и потрага и други активности. Дојдете на фестивалот и на нашиот штанд, ќе биде забавно.

Извор: www.habr.com