У Санкт Петербургу ће ове недеље бити одржан ИТ фестивал . Један од говорника биће Рицхард Сталлман. такође учествује на фестивалу, а наравно нисмо могли да занемаримо тему слободног софтвера. Зато се зове један наш извештај . Биће посвећен историји развоја Ембок-а као пројекта отвореног кода. У овом чланку желим да говорим о главним идејама које, по мом мишљењу, утичу на развој пројеката отвореног кода. Чланак је, као и извештај, заснован на личном искуству.
Почнимо са нечим једноставним, са дефиницијом појма опенсоурце. Очигледно, пројекат отвореног кода је пројекат који има једну од лиценци која омогућава приступ изворном коду пројекта. Поред тога, отворени пројекат значи да програмери треће стране могу да уносе промене. То јест, ако нека компанија или програмер објави код свог производа, делимично или у потпуности, то још увек не чини овај производ пројектом отвореног кода. И на крају, свака пројектна активност мора довести до неке врсте резултата, а отвореност пројекта подразумева да овај резултат не користе само сами програмери.
Нећемо се дотицати проблема отворених лиценци. Ово је превелика и сложена тема која захтева дубинско истраживање. На ову тему написано је доста добрих чланака и материјала. Али пошто ни сам нисам стручњак за област ауторских права, рећи ћу само да лиценца мора да испуњава циљеве пројекта. На пример, за Ембок избор БСД уместо ГПЛ лиценце није био случајан.
Чињеница да пројекат отвореног кода треба да пружи могућност уношења промена и утицаја на развој пројекта отвореног кода подразумева да је пројекат дистрибуиран. Управљање њиме, одржавање интегритета и перформанси је много теже у поређењу са пројектом са централизованим управљањем. Поставља се разумно питање: зашто се уопште отварају пројекти? Одговор лежи у области комерцијалне изводљивости; за одређену класу пројеката, предности овог приступа су веће од трошкова. Односно, није погодан за све пројекте и отворени приступ је генерално прихватљив. На пример, тешко је замислити развој система управљања за електрану или авион на отвореном принципу. Не, наравно, такви системи треба да садрже модуле засноване на отвореним пројектима, јер ће то пружити низ предности. Али неко мора бити одговоран за коначни производ. Чак и ако је систем у потпуности заснован на коду отворених пројеката, програмер, након што је све спаковао у један систем и направио одређене буилд-ове и подешавања, у суштини га затвара. Код може бити јавно доступан.
Такође има много користи за ове системе од креирања или доприноса пројектима отвореног кода. Као што сам већ рекао, код крајњег система може остати јавно доступан. Зашто, јер је очигледно да је мало вероватно да ће неко имати исту летелицу за тестирање система. Ово је тачно, али можда постоји неко ко жели да провери одређене делове кода, или, на пример, неко може открити да библиотека која се користи није сасвим исправно конфигурисана.
Још већа корист се јавља ако компанија издвоји неки основни део система у посебан пројекат. На пример, библиотека која подржава неку врсту протокола за размену података. У овом случају, чак и ако је протокол специфичан за дату предметну област, можете поделити трошкове одржавања овог дела система са другим компанијама из ове области. Поред тога, стручњацима који могу да проучавају овај део система у јавном домену је потребно много мање времена да га ефикасно користе. И на крају, раздвајање дела у независну целину коју користе програмери трећих страна омогућава нам да овај део учинимо бољим, јер морамо да понудимо ефикасне АПИ-је, креирамо документацију, а ја чак и не говорим о побољшању покривености тестом.
Компанија може добити комерцијалне користи без креирања пројеката отвореног кода, довољно је да њени стручњаци учествују у пројектима трећих страна који се користе у компанији. На крају крајева, све предности остају: запослени боље познају пројекат, стога га ефикасније користе, компанија може утицати на правац развоја пројекта, а употреба готовог, дебагованог кода очигледно смањује трошкове компаније.
Предности креирања пројеката отвореног кода се ту не завршавају. Узмимо тако важну компоненту пословања као што је маркетинг. За њега је ово веома добар сандбок који му омогућава да ефикасно процени захтеве тржишта.
И наравно, не смемо заборавити да је пројекат отвореног кода ефикасан начин да се декларирате као носилац било које специјализације. У неким случајевима, ово је једини начин за улазак на тржиште. На пример, Ембок је започео као пројекат за креирање РТОС-а. Вероватно нема потребе објашњавати да има много конкурената. Без стварања заједнице, једноставно не бисмо имали довољно ресурса да пројекат доведемо до крајњег корисника, односно да програмери треће стране почну да користе пројекат.
Заједница је кључна у пројекту отвореног кода. Омогућава вам да значајно смањите трошкове управљања пројектом, развијете и подржите пројекат. Можемо рећи да без заједнице уопште нема пројекта отвореног кода.
Много је материјала написано о томе како креирати и управљати заједницом пројеката отвореног кода. Да не бих препричавао већ познате чињенице, покушаћу да се фокусирам на искуство Ембок-а. На пример, процес стварања заједнице је веома интересантно питање. Односно, многи говоре како управљати постојећом заједницом, али се моменти њеног настанка понекад занемарују, сматрајући то датим.
Главно правило при креирању заједнице пројеката отвореног кода је да нема правила. Мислим, не постоје универзална правила, као што не постоје сребрни метак, макар само зато што су пројекти веома различити. Мало је вероватно да можете користити иста правила када креирате заједницу за јс библиотеку евиденције и неки високо специјализовани драјвер. Штавише, у различитим фазама развоја пројекта (а самим тим и заједнице), правила се мењају.
Ембок је почео као студентски пројекат јер је имао приступ студентима са одсека за системско програмирање. У ствари, улазили смо у неку другу заједницу. Учеснике ове заједнице, студенте, могли бисмо заинтересовати за добру индустријску праксу у њиховој специјалности, научни рад у области системског програмирања, курсеве и дипломе. Односно, поштовали смо једно од основних правила организовања заједнице: чланови заједнице морају нешто да добију, а ова цена мора одговарати доприносу учесника.
Следећа фаза за Ембок била је потрага за корисницима трећих страна. Веома је важно схватити да су корисници пуни учесници заједнице отвореног кода. Обично има више корисника него програмера. А да би пожелели да постану сарадник пројекта, прво почну да га користе на овај или онај начин.
Први корисници Ембок-а били су Катедра за теоријску кибернетику. Предложили су стварање алтернативног фирмвера за Лего Миндсторм. И мада су то још увек били локални корисници (могли смо да се састанемо са њима лично и разговарамо о томе шта желе). Али то је ипак било веома добро искуство. На пример, развили смо демо снимке који би могли да се покажу другима, јер су роботи забавни и привлаче пажњу. Као резултат тога, добили смо заиста кориснике трећих страна који су почели да се питају шта је Ембок и како да га користе.
У овој фази смо морали да размишљамо о документацији, о средствима комуникације са корисницима. Не, наравно, размишљали смо о овим важним стварима и раније, али то је било преурањено и није дало позитиван ефекат. Ефекат је био прилично негативан. Дозволите ми да вам дам пар примера. Користили смо гооглецоде, чија вики подржава вишејезичност. Направили смо странице на неколико језика, не само на енглеском и руском, на којима смо тешко могли да комуницирамо, већ и на немачком и шпанском. Као резултат тога, на овим језицима изгледа веома смешно, али ми уопште не можемо да одговоримо. Или су увели правила о писању документације и коментарисању, али пошто се АПИ прилично често и значајно мењао, испоставило се да је наша документација застарела и да је више обмањивала него што је помогла.
Као резултат тога, сви наши напори, чак и погрешни, довели су до појаве спољних корисника. Чак се појавио и комерцијални купац који је желео да се за њега развије сопствени РТОС. И развили смо га јер имамо искуство и неку основу. Овде треба причати и о добрим и о лошим тренуцима. Почећу са лошим. Пошто су многи програмери били укључени у овај пројекат на комерцијалној основи, заједница је већ била прилично нестабилна и подељена, што наравно није могло да не утиче на развој пројекта. Додатни фактор је био то што је правац пројекта одредио један комерцијални купац, а његов циљ није био даљи развој пројекта. Ово барем није био главни циљ.
С друге стране, постојао је низ позитивних аспеката. Имамо заиста кориснике трећих страна. Није то био само купац, већ и они којима је овај систем био намењен. Појачана је мотивација за учешће у пројекту. На крају крајева, ако можете да зарадите и од занимљивог посла, увек је лепо. И што је најважније, од купаца смо чули једну жељу, која нам се тада чинила сулудом, али која је сада главна идеја Ембок-а, наиме, да се у систему користи већ развијен код. Сада је главна идеја Ембок-а да користи Линук софтвер без Линука. Односно, главни позитивни аспект који је допринео даљем развоју пројекта била је спознаја да пројекат користе трећи корисници и да би то требало да реши неке њихове проблеме.
У то време, Ембок је већ изашао из оквира студентског пројекта. Главни ограничавајући фактор у развоју пројекта по студентском моделу је мотивација учесника. Студенти учествују док уче, а када дипломирају треба да постоји другачија мотивација. Ако се мотивација не појави, ученик једноставно престаје да учествује у пројекту. Ако узмемо у обзир да студенте прво треба обучити, испада да до дипломирања постају добри специјалисти, али њихов допринос пројекту, због неискуства, није велики.
Генерално, глатко прелазимо на главну тачку која нам омогућава да говоримо о креирању пројекта отвореног кода - креирању производа који би решио проблеме својих корисника. Као што сам горе објаснио, главно својство пројекта отвореног кода је његова заједница. Штавише, чланови заједнице су првенствено корисници. Али одакле долазе када нема шта да се користи? Тако се испоставило да, баш као и код пројекта који није отвореног кода, морате да се фокусирате на креирање МВП-а (минимално одрживог производа), а ако то занима кориснике, онда ће се око пројекта појавити заједница. Ако се бавите стварањем заједнице само путем ПР-а у заједници, писања вики-ја на свим језицима света или исправног гит тока рада на гитхубу, онда је мало вероватно да ће то бити важно у раним фазама пројекта. Наравно, у одговарајућим фазама то нису само важне, већ и неопходне ствари.
У закључку желим да истакнем , по мом мишљењу, одражава очекивања корисника од пројекта отвореног кода:
Озбиљно размишљам о преласку на овај ОС (барем покушајте. Они га активно прате и раде сјајне ствари).
ПС Он Имаћемо чак три извештаја. Један о отвореном коду и два о уграђеном (а један је практичан). На штанду ћемо одржати мајсторску класу о програмирању употребе микроконтролера . Као и обично, донећемо хардвер и дозволити вам да га програмирате. Биће ту и потрага и друге активности. Дођите на фестивал и наш штанд, биће забавно.
Извор: ввв.хабр.цом