Šią savaitę Sankt Peterburge vyks IT festivalis . Vienas iš pranešėjų bus Richardas Stallmanas. taip pat dalyvauja festivalyje, ir, žinoma, negalėjome ignoruoti nemokamos programinės įrangos temos. Štai kodėl vienas iš mūsų ataskaitų vadinamas . Jis bus skirtas „Embox“ kaip atvirojo kodo projekto kūrimo istorijai. Šiame straipsnyje noriu pakalbėti apie pagrindines idėjas, kurios, mano nuomone, turi įtakos atvirojo kodo projektų plėtrai. Straipsnis, kaip ir pranešimas, paremtas asmenine patirtimi.
Pradėkime nuo kažko paprasto, nuo atvirojo kodo termino apibrėžimo. Akivaizdu, kad atvirojo kodo projektas yra projektas, turintis vieną iš licencijų, leidžiančių pasiekti projekto šaltinio kodą. Be to, atviras projektas reiškia, kad trečiųjų šalių kūrėjai gali atlikti pakeitimus. Tai yra, jei kuri nors įmonė ar kūrėjas iš dalies ar visiškai paskelbia savo produkto kodą, tai dar nepadaro šio produkto atvirojo kodo projektu. Ir galiausiai, bet kokia projekto veikla turi vesti prie kažkokio rezultato, o projekto atvirumas suponuoja, kad šiuo rezultatu naudojasi ne tik patys kūrėjai.
Atvirųjų licencijų problemų neliesime. Tai per didelė ir sudėtinga tema, kurią reikia nuodugniai ištirti. Šia tema parašyta nemažai gerų straipsnių ir medžiagos. Bet kadangi aš pats nesu autorių teisių srities ekspertas, pasakysiu tik tiek, kad licencija turi atitikti projekto tikslus. Pavyzdžiui, Embox BSD, o ne GPL licencijos pasirinkimas nebuvo atsitiktinis.
Tai, kad atvirojo kodo projektas turėtų suteikti galimybę atlikti pakeitimus ir daryti įtaką atvirojo kodo projekto plėtrai, reiškia, kad projektas yra platinamas. Jį valdyti, išlaikyti vientisumą ir našumą yra daug sunkiau, palyginti su projektu su centralizuotu valdymu. Kyla pagrįstas klausimas: kodėl apskritai atidaromi projektai? Atsakymas slypi komercinio pagrįstumo srityje; tam tikrai projektų klasei šio metodo nauda yra didesnė už išlaidas. Tai yra, jis netinka visiems projektams ir atviras požiūris apskritai yra priimtinas. Pavyzdžiui, sunku įsivaizduoti elektrinės ar lėktuvo valdymo sistemos kūrimą atviru principu. Ne, žinoma, tokiose sistemose turėtų būti modulių, paremtų atvirais projektais, nes tai suteiks nemažai privalumų. Tačiau kažkas turi būti atsakingas už galutinį produktą. Net jei sistema yra visiškai pagrįsta atvirų projektų kodu, kūrėjas, viską supakavęs į vieną sistemą ir atlikęs konkrečius statymus bei nustatymus, iš esmės ją uždaro. Kodas gali būti viešai prieinamas.
Be to, kuriant atvirojo kodo projektus arba prisidedant prie jų, šioms sistemoms suteikiama daug naudos. Kaip jau sakiau, galutinis sistemos kodas gali likti viešai prieinamas. Kodėl, nes akivaizdu, kad vargu ar kas turės tą patį orlaivį sistemai išbandyti. Tai tiesa, tačiau gali būti, kad kažkas nori patikrinti tam tikras kodo dalis arba, pavyzdžiui, kas nors gali pastebėti, kad naudojama biblioteka sukonfigūruota netinkamai.
Dar didesnė nauda atsiranda, jei įmonė tam tikrą pagrindinę sistemos dalį skirsto į atskirą projektą. Pavyzdžiui, biblioteka, skirta palaikyti tam tikrą duomenų mainų protokolą. Tokiu atveju, net jei protokolas yra specifinis tam tikrai dalykinei sričiai, galite pasidalinti šios sistemos dalies priežiūros išlaidomis su kitomis šios srities įmonėmis. Be to, specialistams, galintiems tyrinėti šią sistemos dalį viešoje erdvėje, reikia daug mažiau laiko efektyviai ja naudotis. Ir galiausiai, atskirdami gabalą į nepriklausomą subjektą, kurį naudoja trečiųjų šalių kūrėjai, galime patobulinti šią dalį, nes turime pasiūlyti efektyvias API, kurti dokumentaciją ir net nekalbu apie testų aprėpties gerinimą.
Įmonė gali gauti komercinės naudos nekurdama atvirojo kodo projektų, jos specialistams pakanka dalyvauti įmonėje naudojamuose trečiųjų šalių projektuose. Juk išlieka visa nauda: darbuotojai geriau išmano projektą, todėl efektyviau jį naudoja, įmonė gali daryti įtaką projekto vystymo krypčiai, o jau paruošto, derinamo kodo naudojimas akivaizdžiai mažina įmonės kaštus.
Atvirojo kodo projektų kūrimo privalumai tuo nesibaigia. Paimkime tokį svarbų verslo komponentą kaip rinkodara. Jam tai labai gera smėlio dėžė, leidžianti efektyviai įvertinti rinkos reikalavimus.
Ir, žinoma, neturime pamiršti, kad atvirojo kodo projektas yra veiksmingas būdas paskelbti save bet kokios specializacijos nešėja. Kai kuriais atvejais tai yra vienintelis būdas patekti į rinką. Pavyzdžiui, „Embox“ prasidėjo kaip RTOS kūrimo projektas. Turbūt nereikia aiškinti, kad konkurentų daug. Nesukūrę bendruomenės tiesiog nebūtume turėję pakankamai resursų pristatyti projektą galutiniam vartotojui, ty trečiųjų šalių kūrėjams pradėti naudoti projektą.
Bendruomenė yra pagrindinė atvirojo kodo projekto dalis. Tai leidžia ženkliai sumažinti projekto valdymo išlaidas, plėtoti ir palaikyti projektą. Galime pasakyti, kad be bendruomenės nėra atvirojo kodo projekto.
Apie tai, kaip sukurti ir valdyti atvirojo kodo projektų bendruomenę, parašyta daug medžiagos. Kad neperpasakočiau jau žinomų faktų, pasistengsiu sutelkti dėmesį į Embox patirtį. Pavyzdžiui, bendruomenės kūrimo procesas yra labai įdomus klausimas. Tai reiškia, kad daugelis pasakoja, kaip valdyti esamą bendruomenę, tačiau kartais pamirštamos jos sukūrimo akimirkos, atsižvelgiant į tai.
Pagrindinė taisyklė kuriant atvirojo kodo projektų bendruomenę yra ta, kad nėra taisyklių. Turiu omenyje, kad nėra universalių taisyklių, kaip ir nėra sidabrinės kulkos, jei tik todėl, kad projektai labai skirtingi. Mažai tikėtina, kad galėsite naudoti tas pačias taisykles kurdami js registravimo bibliotekos ir labai specializuotos tvarkyklės bendruomenę. Be to, skirtinguose projekto (taigi ir bendruomenės) vystymosi etapuose taisyklės keičiasi.
„Embox“ prasidėjo kaip studentų projektas, nes turėjo prieigą prie studentų iš sistemų programavimo skyriaus. Tiesą sakant, mes įėjome į kitą bendruomenę. Galėtume sudominti šios bendruomenės dalyvius, studentus, gerąja pramonės praktika pagal savo specialybę, moksliniais darbais sistemų programavimo srityje, kursiniais darbais ir diplomais. Tai yra, laikėmės vienos iš pagrindinių bendruomenės organizavimo taisyklių: bendruomenės nariai turi kažką gauti, o ši kaina turi atitikti dalyvio indėlį.
Kitas „Embox“ etapas buvo trečiųjų šalių vartotojų paieška. Labai svarbu suprasti, kad vartotojai yra visaverčiai atvirojo kodo bendruomenės dalyviai. Paprastai yra daugiau vartotojų nei kūrėjų. O norėdami tapti projekto dalyviu, pirmiausia pradeda vienaip ar kitaip juo naudotis.
Pirmieji Embox vartotojai buvo Teorinės kibernetikos katedra. Jie pasiūlė sukurti alternatyvią „Lego Mindstorm“ programinę-aparatinę įrangą. Ir nors tai vis dar buvo vietiniai vartotojai (galėjome su jais susitikti asmeniškai ir aptarti, ko jie nori). Bet tai vis tiek buvo labai gera patirtis. Pavyzdžiui, sukūrėme demonstracines versijas, kurias būtų galima parodyti kitiems, nes robotai yra linksmi ir pritraukia dėmesį. Dėl to sulaukėme tikrai trečiųjų šalių vartotojų, kurie pradėjo klausti, kas yra „Embox“ ir kaip ją naudoti.
Šiame etape turėjome galvoti apie dokumentaciją, apie bendravimo su vartotojais priemones. Ne, žinoma, apie šiuos svarbius dalykus galvojome anksčiau, bet tai buvo per anksti ir nedavė teigiamo efekto. Poveikis buvo gana neigiamas. Pateiksiu porą pavyzdžių. Naudojome googlecode, kurio wiki palaikė daugiakalbystę. Sukūrėme puslapius keliomis kalbomis – ne tik anglų ir rusų, kuriomis sunkiai susikalbėdavome, bet ir vokiškai, ispaniškai. Dėl to atrodo labai juokingai, kai klausiama šiomis kalbomis, bet mes niekaip negalime atsakyti. Arba įvedė dokumentacijos rašymo ir komentavimo taisykles, bet kadangi API keitėsi gana dažnai ir ženkliai, paaiškėjo, kad mūsų dokumentacija buvo pasenusi ir labiau klaidina, nei padėjo.
Dėl to visos mūsų pastangos, net ir netinkamos, lėmė išorinių vartotojų atsiradimą. Ir netgi atsirado komercinis klientas, kuris norėjo, kad jam būtų sukurtas nuosavas RTOS. Ir mes tai sukūrėme, nes turime patirties ir tam tikrą pagrindą. Čia reikia kalbėti ir apie geras, ir apie blogas akimirkas. Pradėsiu nuo blogųjų. Kadangi daugelis kūrėjų šiame projekte dalyvavo komerciniais pagrindais, bendruomenė jau buvo gana nestabili ir susiskaldžiusi, o tai, žinoma, negalėjo neturėti įtakos projekto plėtrai. Papildomas veiksnys buvo tai, kad projekto kryptį nustatė vienas komercinis užsakovas, o jo tikslas nebuvo tolimesnė projekto plėtra. Bent jau tai nebuvo pagrindinis tikslas.
Kita vertus, buvo ir nemažai teigiamų aspektų. Turime tikrai trečiųjų šalių vartotojų. Tai buvo ne tik klientas, bet ir tie, kuriems ši sistema buvo skirta. Išaugo motyvacija dalyvauti projekte. Galų gale, jei jūs taip pat galite užsidirbti pinigų iš įdomaus verslo, tai visada malonu. O svarbiausia – iš klientų išgirdome vieną norą, kuris tuo metu mums atrodė beprotiškas, o dabar yra pagrindinė Embox idėja – panaudoti sistemoje jau sukurtą kodą. Dabar pagrindinė „Embox“ idėja yra naudoti „Linux“ programinę įrangą be „Linux“. Tai yra, pagrindinis teigiamas aspektas, prisidėjęs prie tolimesnės projekto plėtros, buvo suvokimas, kad projektu naudojasi trečiųjų šalių vartotojai ir jis turėtų išspręsti kai kurias jų problemas.
Tuo metu „Embox“ jau buvo peržengusi studentų projekto ribas. Pagrindinis ribojantis veiksnys kuriant projektą pagal studento modelį yra dalyvių motyvacija. Studentai dalyvauja studijuodami, o baigus mokslus turėtų būti kitokia motyvacija. Jei neatsiranda motyvacijos, mokinys tiesiog nustoja dalyvauti projekte. Jei atsižvelgsime į tai, kad studentus pirmiausia reikia apmokyti, išeitų, kad jau baigę mokslus jie tampa gerais specialistais, tačiau jų indėlis į projektą dėl nepatyrimo nėra labai didelis.
Apskritai, sklandžiai pereiname prie pagrindinio dalyko, leidžiančio kalbėti apie atvirojo kodo projekto kūrimą – produkto, kuris išspręstų jo vartotojų problemas, sukūrimą. Kaip paaiškinau aukščiau, pagrindinė atvirojo kodo projekto savybė yra jo bendruomenė. Be to, bendruomenės nariai pirmiausia yra vartotojai. Bet iš kur jie atsiranda, kai nėra ko naudoti? Taigi paaiškėja, kad, kaip ir ne atvirojo kodo projekte, reikia sutelkti dėmesį į MVP (minimalus gyvybingas produktas) kūrimą ir, jei jis sudomins vartotojus, aplink projektą atsiras bendruomenė. Jei kuriate bendruomenę tik per bendruomenės viešąjį ryšį, rašote wiki visomis pasaulio kalbomis arba koreguojate „git“ darbo eigą „github“, tai mažai tikėtina, kad tai bus svarbu ankstyvosiose projekto stadijose. Žinoma, atitinkamuose etapuose tai ne tik svarbūs, bet ir reikalingi dalykai.
Baigdamas norėčiau pabrėžti , mano nuomone, atspindi vartotojo lūkesčius iš atvirojo kodo projekto:
Aš rimtai galvoju apie perėjimą prie šios OS (bent jau pabandykite. Jie aktyviai to siekia ir daro šaunius dalykus).
PS Įjungta Turėsime net tris ataskaitas. Vienas apie atvirąjį kodą ir du apie įterptąjį (ir vienas yra praktiškas). Stende pravesime mikrovaldiklių programavimo meistriškumo klasę . Kaip įprasta, mes atsinešime techninę įrangą ir leisime jums ją programuoti. Taip pat bus ieškoma ir kitos veiklos. Ateikite į festivalį ir mūsų stendą, bus smagu.
Šaltinis: www.habr.com