Već ovog tjedna u Sankt Peterburgu održat će se IT festival . Jedan od govornika bit će Richard Stallman. također sudjeluje na festivalu, i naravno, nismo mogli zanemariti temu otvorenog softvera. Stoga se jedan od naših izlaganja naziva . Bit će posvećeno povijesti razvoja Embox-a kao projekta s otvorenim kodom. U ovom članku želim podijeliti osnovne ideje koje, po mom mišljenju, utječu na razvoj open source projekata. Članak, kao i izlaganje, temelji se na osobnom iskustvu.
Počet ćemo s jednostavnim, s definicijom termina open source. Očigledno je da je projekt s otvorenim kodom projekt koji ima neku od licenci koja omogućava pristup izvornoj kodu projekta. Osim toga, otvoreni projekt podrazumijeva mogućnost izmjene od strane drugih programera. To znači da, ako neka tvrtka ili programer objavi kod svog proizvoda, djelomično ili potpuno, to ne čini taj proizvod open source projektom. I konačno, svaka projektna aktivnost trebala bi dovesti do pojave nekog rezultata, pri čemu otvorenost projekta podrazumijeva da taj rezultat koriste ne samo sami programeri.
Nećemo se baviti problemima otvorenih licenci. To je prevelika i složena tema koja zahtijeva duboko razmatranje. O ovoj temi napisano je prilično mnogo dobrih članaka i materijala. No, budući da nisam stručnjak za autorska prava, reći ću samo da licenca trebala odgovarati ciljevima projekta. Na primjer, za Embox izbor BSD, a ne GPL licence nije bio slučajan.
Činjenica da otvoreni projekti moraju omogućiti promjene i utjecati na razvoj tih projekata podrazumijeva da je projekt distribuiran. Upravljati njime, održavati cjelovitost i funkcionalnost puno je teže u usporedbi s projektima koji imaju centralizirano upravljanje. Postavlja se razumno pitanje zašto uopće kreirati otvorene projekte. Odgovor leži u komercijalnoj isplativosti; za određenu klasu projekata koristi takvog pristupa nadmašuju troškove. Drugim riječima, otvoreni pristup nije prikladan niti dopušten za sve projekte. Na primjer, teško je zamisliti razvoj sustava upravljanja elektranom ili avionom temeljenog na otvorenom principu. Naravno, kao dio takvih sustava trebali bismo uključiti module temeljenje na otvorenim projektima, jer to donosi niz prednosti. No, za konačni proizvod netko mora preuzeti odgovornost. Čak i ako je sustav potpuno zasnovan na otvorenom kodu, programer, pakirajući sve u jedan sustav i radeći konkretne verzije i postavke, u suštini zatvara taj sustav. Kod pritom može ostati javno dostupan.
Za ove sustave također postoji niz prednosti od stvaranja otvorenih projekata ili sudjelovanja u njima. Kao što sam već rekao, kod konačnog sustava može ostati javno dostupan. Zašto, kad je očigledno da vjerojatno nitko nema isti avion kako bi testirao sustav? To je točno, no sasvim je moguće da se netko želi provjeriti određene dijelove koda, ili, na primjer, da netko otkrije da korištena biblioteka nije baš ispravno konfigurirana.
Još veća dobit se pojavljuje kada tvrtka izdvaja određeni osnovni dio sustava u poseban projekt. Na primjer, knjižnicu za podršku određenom protokolu razmjene podataka. U ovom slučaju, čak i ako je protokol specifičan za određeno područje, troškovi održavanja tog dijela sustava mogu se podijeliti s drugim tvrtkama iz tog područja. Osim toga, stručnjacima koji mogu proučiti taj dio sustava javno, potrebno je mnogo manje vremena za učinkovitu upotrebu. Na kraju, izdvajanje dijela u samostalnu cjelinu koju koriste vanjski programeri omogućuje da ta komponenta postane kvalitetnija, jer je potrebno ponuditi učinkovite API-je, izraditi dokumentaciju, a ne govorim o poboljšanju testne pokrivenosti.
Komercijalnu korist tvrtka može ostvariti i ne stvarajući otvorene projekte, dovoljno je da njezini stručnjaci sudjeluju u vanjskim projektima koji se koriste unutar tvrtke. Sve koristi ostaju: zaposlenici bolje poznaju projekt, a samim tim ga učinkovitije koriste, tvrtka može utjecati na smjer razvoja projekta, a korištenje gotovog, isprobanog koda očigledno smanjuje troškove tvrtke.
Na ovome se prednosti stvaranja opensource projekata ne završavaju. Uzmimo u obzir važan aspekt poslovanja kao što je marketing. Za njega je to vrlo dobra igralište koja omogućuje učinkovito procjenjivanje zahtjeva tržišta.
I naravno, ne smijemo zaboraviti da je opensource projekt učinkovit način da se istaknemo kao nositelji neke specijalizacije. U nekim slučajevima, to je jedini put izlaska na tržište. Na primjer, Embox je započeo kao projekt za stvaranje OSRV. Vjerojatno nije potrebno objašnjavati da postoji mnoštvo konkurencije. Bez stvaranja zajednice, jednostavno ne bi imali resurse da dovršimo projekt za krajnje korisnike, odnosno da projekt koriste vanjski programeri.
Zajednica je ključna u opensource projektu. Ona značajno smanjuje troškove upravljanja projektom, razvija i podržava projekt. Može se reći da bez zajednice uopće nema opensource projekta.
O tome kako stvoriti i upravljati zajednicom projekta s otvorenim izvorom napisano je mnogo materijala. Kako ne bih ponavljao već poznate činjenice, pokušat ću naglasiti iskustvo Emboxa. Na primjer, jako zanimljivo pitanje je proces stvaranja zajednice. Mnogi pričaju o upravljanju postojećom zajednicom, ali često izostavljaju trenutke njenog osnivanja, smatrajući to datostima.
Glavno pravilo pri stvaranju zajednice opensource projekta — nema nikakvih pravila. Mislim, ne postoje univerzalna pravila, baš poput srebrne metkice, barem zato što su projekti vrlo različiti. Teško da je moguće koristiti ista pravila prilikom stvaranja zajednice za biblioteku za logiranje na js i nekakav usko specijalizirani driver. Štoviše, na različitim stadijima razvoja projekta (a time i zajednice) pravila se mijenjaju.
Embox je započeo kao studentski projekt, budući da je bio pristup studentima s katedre za sustavno programiranje. U suštini, ulazili smo u neku drugu zajednicu. Sudionike te zajednice, studente, mogli smo zainteresirati dobrom industrijskom praksom u njihovoj struci, znanstvenim radovima u području sustavnog programiranja, te završnim radovima. Dakle, ispunjavali smo jedno od osnovnih pravila organizacije zajednice, sudionici zajednice moraju nešto dobiti, pri čemu ta cijena mora odgovarati doprinosu sudionika.
Sljedeća faza za Embox bila je traženje vanjskih korisnika. Važno je razumjeti da su korisnici punopravni sudionici opensource zajednice. Korisnika obično ima više nego programera. I da bi netko poželio postati doprinositelj projekta, prvo ga nekako počinju koristiti.
Prvi korisnici za Embox bili su katedra Teorijske Kibernetike. Predložili su izradu alternativnog firmware-a za Lego Mindstorm. Iako su to još uvijek bili lokalni korisnici (mogli smo se osobno sastati s njima i razgovarati o njihovim željama), to je bio vrlo dobar iskustvo. Na primjer, razvili smo demonstracije koje smo mogli prikazati drugima, jer su roboti zabavni i privlače pažnju. Na kraju smo dobili prave vanjske korisnike koji su počeli pitati što je Embox i kako se koristi.
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 preuranjeno i nije imalo pozitivan učinak. Učinak je bio zapravo negativan. Donijet ću nekoliko primjera. Koristili smo googlecode, čija je wiki podržavala višejezičnost. Napravili smo stranice na nekoliko jezika, uključujući ne samo engleski i ruski, na kojima smo se na neki način mogli komunicirati, već i njemački i španjolski. Kao rezultat toga, izgledalo je vrlo smiješno kada su pitali na tim jezicima, a mi nismo mogli odgovoriti. Ili smo postavili pravila o pisanju dokumentacije i komentiranju, ali budući da se API često i značajno mijenjao, naša dokumentacija postajala je zastarjela i više je zbunjivala nego pomagalo.
Na kraju su svi naši napori, čak i oni neispravno usmjereni, rezultirali time da su se pojavili vanjski korisnici. Čak se pojavio i komercijalni klijent koji je želio da mu razvijemo vlastiti OSRV. I razvili smo ga budući da imamo iskustva i neka saznanja. Ovdje treba pričati i o dobrim i lošim stvarima. Počet ću s lošim. Kako su mnogi programeri bili angažirani na ovom projektu na komercijalnoj osnovi, zajednica koja je ionako bila prilično nestabilna podijelila se, što naravno nije moglo ne utjecati na razvoj projekta. Dodatni faktor bio je taj što je smjer projekta postavljao jedan komercijalni klijent, a njegov cilj nije bio daljnji razvoj projekta. Barem, taj cilj nije bio glavni.
S druge strane, bilo je nekoliko pozitivnih trenutaka. Dobili smo stvarno strane korisnike. To nisu bili samo klijenti, već i oni za koje je ovaj sustav bio namijenjen. Motivacija za sudjelovanje u projektu je porasla. Na kraju krajeva, ako se na zanimljivom poslu još može i zaraditi, to je uvijek ugodno. I najvažnije, čuli smo jedno želju klijenata, koja nam se tada činila besmislenom, a koja je sada ključna ideja Emboxa, a to je korištenje već razvijenog koda u sustavu. Danas je glavna ideja Emboxa korištenje Linux softvera bez Linuxa. Drugim riječima, glavni pozitivni aspekt koji je pridonio daljnjem razvoju projekta bila je spoznaja da sustav koriste strani korisnici i da on treba rješavati njihove probleme.
U to vrijeme, Embox je već izašao iz okvira studentskog projekta. Glavni faktor koji ograničava razvoj projekta prema studentskom modelu je motivacija sudionika. Studenti sudjeluju dok uče, a kada završe, mora se pojaviti druga motivacija. Ako motivacije nema, student jednostavno prestaje sudjelovati u projektu. Ako se uzme u obzir da se studente prvo treba obučiti, dolazimo do zaključka da postaju dobri stručnjaci tek na kraju studija, ali njihov doprinos projektu, zbog niskog iskustva, nije osobito velik.
Uglavnom, polako prelazimo na glavni trenutak koji nam omogućava govoriti o stvaranju open source projekta — stvaranje proizvoda koji bi rješavao probleme njegovih korisnika. Kao što sam već pojasnio, osnovna karakteristika open source projekta je njegova zajednica. A sudionici zajednice su prije svega korisnici. No, odakle bi oni mogli doći dok još nemaju što koristiti? Tako dolazimo do zaključka da baš kao i kod ne-open source projekta, treba se usredotočiti na stvaranje MVP-a (minimalno održivog proizvoda), i ako on zainteresira korisnike, oko projekta će se stvoriti zajednica. Međutim, ako se zajednica stvara samo kroz marketing zajednice, pisanjem wiki na svim jezicima svijeta ili pravilnim git radnim tokom na githubu, malo je vjerojatno da će to imati značaj u ranim fazama projekta. Naravno, u odgovarajućim fazama to su ne samo važni, već i nužni aspekti.
Na kraju, želim citirati , po mom mišljenju, odražava očekivanja korisnika od open source projekta:
Ozbiljno razmišljam o prelasku na ovaj operativni sustav (barem da probam. Previše ga aktivno razvijaju i rade sjajne stvari).
P. S. Na imamo čak tri izlaganja. Jedno o open source-u i dva o ugrađenim sustavima (uz to, jedno praktično). Na štandu ćemo održati radionicu o programiranju mikrokontrolera pomoću . Tradicionalno ćemo donijeti opremu i dati vam priliku da programirate. Bit će i kviz i druge aktivnosti. Dođite na festival i na naš štand, bit će zabavno.
Izvor: habr.com
