Južni teden v Sankt Peterburgu se bo odvijal IT festival . Eden od govorcev bo Richard Stallman. se prav tako udeležuje festivala, in seveda nismo mogli prezreti teme odprtokodnosti. Zato se ena naših predstavitev imenuje . Namenjena bo zgodovini razvoja Embox kot odprtokodnega projekta. V tem članku želim spregovoriti o glavnih idejah, ki po mojem mnenju vplivajo na razvoj odprtokodnih projektov. Članek, tako kot predstavitev, temelji na osebnih izkušnjah.
Začnimo s preprostim, s definicijo pojma odprtokoden. Očitno je, da odprtokodni projekt predstavlja projekt, ki ima eno od licenc, ki omogočajo dostop do izvorne kode projekta. Poleg tega odprti projekt implicira možnost sprememb s strani zunanjih razvijalcev. Torej, če neka podjetje ali razvijalec objavi kodo svojega proizvoda, delno ali v celoti, to še ne pomeni, da je ta izdelek odprtokodni projekt. Nazadnje, vsaka projektna dejavnost mora privedeti do nekega rezultata, pri čemer odprtost projekta pomeni, da ta rezultat uporabljajo ne le sami razvijalci.
Težav odprtih licenc se ne bomo dotaknili. To je prevelika in zapletena tema, ki zahteva globoko razumevanje. O tej temi je napisanih kar veliko dobrih člankov in materialov. Ker pa sam nisem strokovnjak na področju avtorskih pravic, bom le rekel, da mora licenca ustrezati ciljem projekta. Na primer, za Embox izbira BSD licence namesto GPL licence ni bila naključna.
Dejstvo da otvoreni projekat treba da omogući izmenu i uticaj na razvoj otvorenog projekta podrazumeva da je projekat distribuiran. Upraviti njime, očuvati celovitost i funkcionalnost je daleko složenije u poređenju sa projektom koji ima centralizovano upravljanje. Postavlja se razuman pitanje zašto uopšte raditi otvorene projekte. Odgovor leži u oblasti komercijalne isplativosti, za određenu klasu projekata korist od takvog pristupa nadmašuje troškove. Odnosno, ne za sve projekte je otvoreni pristup primenljiv i uopšte dozvoljen. Na primer, teško je zamisliti razvoj sistema upravljanja elektranama ili avionima zasnovanog na otvorenom principu. Ne, naravno da u sastav takvih sistema treba uključiti module zasnovane na otvorenim projektima, jer to donosi niz prednosti. Ali neko mora odgovarati za konačni proizvod. Čak i ako je sistem potpuno zasnovan na kodu otvorenih projekata, developer, pakovanje svega u jedan sistem i pravljenje specifičnih buildova i podešavanja, suštinski zatvara sistem. Kod može ostati javno dostupan.
Za ove sisteme takođe postoji mnogo prednosti od stvaranja otvorenih projekata ili učešća u njima. Kao što sam već rekao, kod konačnog sistema može ostati javno dostupan. Zašto, jer je očigledno da teško da će iko imati isti avion kako bi testirao sistem. To je istina, ali može se naći neko ko želi da proveri određene delove koda, ili na primer, neko može otkriti da korišćena biblioteka nije potpuno korektno konfigurisana.
Še boljša korist se pojavi, če podjetje določi del osnovnega sistema kot ločen projekt. Na primer, knjižnica za podporo določenemu protokolu izmenjave podatkov. V tem primeru, tudi če je protokol specifičen za to področje, lahko stroške vzdrževanja tega dela sistema delimo z drugimi podjetji iz te panoge. Poleg tega strokovnjakom, ki se lahko seznanijo s tem delom sistema v odprtem dostopu, potrebujejo bistveno manj časa za učinkovito uporabo. In končno, dodelitev dela v samostojno entiteto, ki jo uporabljajo zunanjih razvijalci, omogoča, da postane ta del bolj kakovosten, saj je treba ponuditi učinkovite API-je in pripraviti dokumentacijo, niti ne govorim o izboljšanju testne pokritosti.
Podjetje lahko pridobi tudi komercialne koristi, ne da bi ustvarjalo odprte projekte, dovolj je, da njihovi strokovnjaki sodelujejo v zunanjih projektih, ki se uporabljajo v podjetju. Saj vse koristi ostanejo: zaposleni bolje poznajo projekt, kar pomeni, da ga učinkoviteje uporabljajo, podjetje lahko vpliva na smer razvoja projekta, in seveda, uporaba pripravljenega in odprtega kode očitno zmanjšuje stroške podjetja.
Na teh prednostih ustvarjanja opensource projektov še ni konec. Vzemimo tako pomembno sestavino poslovanja kot je trženje. To je zelo dobra peskovnik, ki omogoča učinkovito oceno zahtev tržišča.
In seveda ne smemo pozabiti, da je opensource projekt učinkovit način, da se izkažeš kot nosilec neke specializacije. V nekaterih primerih je to sploh edini način za vstop na trg. Na primer, Embox se je začel kot projekt za ustvarjanje OSRV. Verjetno ni treba razlagati, da obstaja veliko konkurentov. Brez ustvarjanja skupnosti preprosto ne bi imeli dovolj virov, da bi projekt pripeljali do končnega uporabnika, da bi ga lahko uporabljali zunanji razvijalci.
Skupnost je ključna v opensource projektu. Omogoča znatno zmanjšanje stroškov upravljanja projekta, razvija in podpira projekt. Lahko rečemo, da brez skupnosti sploh ni opensource projekta.
O tem, kako ustvariti in upravljati skupnost projekta z odprto kodo, je bilo napisanih veliko gradiv. Da ne bi ponavljal že znanih dejstev, bom poskušal poudariti izkušnje Embox. Na primer, zelo zanimivo vprašanje je proces ustvarjanja skupnosti. Mnogi govorijo o tem, kako upravljati obstoječo skupnost, vendar se trenutki njegovega ustvarjanja pogosto spregledajo, saj jih smatrajo za samoumevne.
Glavno pravilo pri ustvarjanju skupnosti opensource projekta je, da ni nobenih pravil. Imenujem to univerzalnih pravil, ne obstaja, prav tako kot ni srebrne krogle, vsaj zato, ker so projekti zelo različni. Težko je uporabiti ista pravila pri ustvarjanju skupnosti za knjižnico za beleženje na js in nek poseben gonilnik. Še več, na različnih stopnjah razvoja projekta (in posledično tudi skupnosti) se pravila spreminjajo.
Embox se je začel kot študentski projekt, saj je bil dostop do študentov oddelka za sistemsko programiranje. V bistvu smo vstopili v neko drugo skupnost. Udeležence te skupnosti, študente, smo lahko pritegnili s kakovostno industrijsko prakso s svojega področja, znanstvenimi deli s področja sistemskega programiranja, seminarskimi in diplomskimi nalogami. Torej smo izpolnili eno od osnovnih pravil organizacije skupnosti, udeleženci skupnosti morajo nekaj pridobiti, pri čemer mora biti ta cena v skladu s prispevkom udeleženca.
Naslednja stopnja za Embox je bilo iskanje zunanjih uporabnikov. Zelo pomembno je razumeti, da so uporabniki polnopravni člani opensource skupnosti. Uporabnikov je običajno več kot razvijalcev. Da bi želeli postati prispevalec projekta, ga najprej na takšen ali drugačen način začnejo uporabljati.
Prvi korisnici za Embox bila je katedra Teorijske Kibernetike. Predložili su izradu alternativnog firmvera za Lego Mindstorm. Iako su to još bili lokalni korisnici (s njima smo se mogli sastati lično i razgovarati o tome što žele), to je svakako bio veoma dobar iskustvo. Na primer, razvili smo demonstracije koje smo mogli pokazati drugima, jer roboti su zabavni i privlače pažnju. Na kraju, dobili smo prave eksterne korisnike koji su počeli pitati što je Embox i kako to koristiti.
U ovoj fazi, morali smo razmišljati o dokumentaciji, o sredstvima komunikacije s korisnicima. Naravno da smo razmišljali o tim važnim stvarima i ranije, ali to je bilo prerano i nije imalo pozitivan učinak. Učinak je bio više negativan. Navešću nekoliko primera. Koristili smo googlecode, čija je wiki podržavala više jezika. Napravili smo stranice na nekoliko jezika, ne samo na engleskom i ruskom, na kojima smo mogli komunicirati, nego i na nemačkom i španskom. Kao rezultat, izgledalo je veoma smešno kada su postavljana pitanja na tim jezicima, a mi nismo mogli odgovoriti. Ili smo uveli pravila za pisanje dokumentacije i komentarisanje, ali pošto se API veoma često i značajno menjao, naša dokumentacija je postajala zastarjela i više je zbunjivala nego što je pomagala.
Na kraju, svi naši napori, čak i oni netačni, doveli su do toga da se pojave eksterne korisnike. Čak je došao i komercijalni klijent koji je želeo da mu razvijemo sopstveni OSR. I razvili smo ga, pošto imamo iskustva i neki radovi. Treba napomenuti i dobre i loše aspekte. Počeću s lošima. Budući da su mnogi developeri bili angažovani na ovom projektu na komercijalnoj osnovi, zajednica koja je ionako bila prilično nestabilna je podeljena, što je, naravno, uticalo na razvoj projekta. Dodatni faktor je bio taj što je pravac projekta određivao jedan komercijalni klijent, a njegov cilj nije bio dalji razvoj projekta. Bar ovaj cilj nije bio glavni.
S druge strane, bilo je nekoliko pozitivnih aspekata. Dobijeni su stvarni korisnici. To nisu bili samo klijenti, već i oni za koje je ovaj sistem bio namenjen. Motivacija za učestvovanje u projektu je porasla. Kada se može zaraditi na nečemu zanimljivom, to je uvek prijatno. I najvažnije, čuli smo jedno želju klijenata koja nam se tada činila apsurdnom, ali koja je sada osnovna ideja Embox-a, a to je korišćenje već razvijenog koda u sistemu. Danas je osnovna ideja Embox korišćenje Linux softvera bez Linux-a. Dakle, glavni pozitivan aspekt koji je doprineo daljem razvoju projekta je svest o tome da projekt koriste spoljni korisnici, i on mora rešavati njihove probleme.
U to vreme, Embox je već izašao iz okvira studentskog projekta. Glavni faktor koji koči razvoj projekta po studentskom modelu je motivacija učesnika. Studenti učestvuju dok su učenja, a kada diplomiraju, mora se pojaviti druga motivacija. Ako motivacija ne dođe, student jednostavno prestaje da učestvuje u projektu. Ako uzmemo u obzir da je studente prvo potrebno obučiti, dolazi do zaključka da postaju dobri stručnjaci tek na dan diplomiranja, a njihov doprinos projektu, zbog neiskustva, nije baš velik.
Uglavnom, pređimo na glavni aspekt koji omogućava da govorimo o stvaranju opensource projekta — stvaranju proizvoda koji rešava probleme svojih korisnika. Kao što sam ranije objasnio, osnovna karakteristika opensource projekta je njegova zajednica. A članovi zajednice su pre svega korisnici. Ali, odakle oni dolaze ako nemaju šta da koriste? I tako, kao i kod ne-opensource projekta, treba se fokusirati na razvoj MVP-a (minimalno održivog proizvoda), i ako on zainteresuje korisnike, okol njega će se formirati zajednica. Međutim, ako se zajednica pokušava izgraditi samo putem PR-a, pisanjem wiki na svim jezicima sveta, ili pravilnim git workflow-om na github-u, teško da će to imati značaj u ranim fazama projekta. Naravno, na odgovarajućim fazama to su ne samo važni, već i neophodni koraci.
Na kraju, želim da navedem , po mojem mnenju odraža pričakovanja uporabnika od opensource projekta:
Resno razmišljam o prehodu na ta operacijski sistem (vsaj ga preizkusiti. Tako aktivno ga razvijajo in ustvarjajo odlične stvari).
P. S. Na imamo kar tri predavanja. Eno o odprti kodi in dve o vgrajenih sistemih (pri čemer je eno praktično). Na stojnici bomo izvedli delavnico o programiranju mikrokrmilnikov s pomočjo . Tradicionalno bomo prinesli naprave in jih omogočili za programiranje. Še vedno bo iskalna igra in druge aktivnosti. Pridite na festival in na našo stojnico, zabavno bo.
Izvor: habr.com
