Ужо на гэтым тыдні ў Санкт-Пецярбургу пройдзе IT-фестываль . Адным са спікераў будзе Рычард Столман. таксама ўдзельнічае ў фестывалі, і вядома мы не маглі абысці ўвагай тэму ВПЗ. Таму адзін з нашых дакладаў называецца . Ён будзе прысвечаны гісторыі развіцця Embox як праекту з адкрытым кодам. У дадзеным артыкуле я жадаю распавесці аб асноўных ідэях, якія па маім меркаванні ўплываюць на развіццё opensource праектаў. Артыкул, як і даклад, заснаваны на асабістым вопыце.
Пачнём з простага, з вызначэння тэрміна opensource. Відавочна, што праект з адчыненым кодам гэта праект які мае адну з ліцэнзій, якія дазваляюць атрымліваць доступ да зыходнага кода праекту. Акрамя таго, адкрыты праект мае на ўвазе магчымасць унясення змяненняў іншымі распрацоўшчыкамі. Гэта значыць, калі нейкая кампанія або распрацоўшчык, апублікуе код свайго прадукта, часткова ці цалкам, то гэта яшчэ не робіць гэты прадукт 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 праекта:
Я сур'езна задумваюся аб пераходзе на гэтую АС (прынамсі, паспрабаваць. Ужо вельмі яе актыўна пілуюць і стромкія штукі робяць).
PS На у нас будзе ажно тры даклады. Адзін пра open source і два пра embedded (прычым адзін практычны). На стэндзе правядзем майстар клас па праграмаванні мікракантролераў з дапамогай . Традыцыйна прывязем жалязякі і дадзім іх папраграмаваць. Будзе яшчэ квэст і іншыя актыўнасці. Прыходзьце на фестываць і на наш стэнд, будзе весела.
Крыніца: habr.com