Ovog će se tjedna u St. Petersburgu održati IT festival . Jedan od govornika bit će Richard Stallman. također sudjeluje na festivalu, a naravno nismo mogli zaobići ni temu slobodnog softvera. Zato se jedna od naših reportaža zove . Bit će posvećena povijesti razvoja Emboxa kao open source projekta. U ovom članku želim govoriti o glavnim idejama koje, po mom mišljenju, utječu na razvoj opensource projekata. Članak, kao i izvješće, temelji se na osobnom iskustvu.
Počnimo s nečim jednostavnim, s definicijom pojma opensource. Očito, projekt otvorenog koda je projekt koji ima jednu od licenci koja dopušta pristup izvornom kodu projekta. Osim toga, otvoreni projekt znači da programeri trećih strana mogu unositi promjene. Odnosno, ako neka tvrtka ili programer objavi kod svog proizvoda, djelomično ili u potpunosti, to još ne čini ovaj proizvod opensource projektom. I na kraju, svaka projektna aktivnost mora dovesti do nekog rezultata, a otvorenost projekta podrazumijeva da taj rezultat koriste ne samo sami programeri.
Nećemo se doticati problema otvorenih licenci. Ovo je prevelika i složena tema koja zahtijeva dubinsko istraživanje. O ovoj temi napisano je dosta dobrih članaka i materijala. No, budući da nisam stručnjak za autorsko pravo, reći ću samo da licenca mora zadovoljiti ciljeve projekta. Na primjer, za Embox izbor BSD umjesto GPL licence nije bio slučajan.
Činjenica da projekt otvorenog izvornog koda treba pružiti mogućnost unošenja izmjena i utjecaja na razvoj projekta otvorenog koda podrazumijeva da je projekt distribuiran. Upravljanje njime, održavanje integriteta i performansi puno je teže u usporedbi s projektom s centraliziranim upravljanjem. Postavlja se razumno pitanje: zašto uopće otvarati projekte? Odgovor leži u području komercijalne izvedivosti; za određenu klasu projekata, koristi ovog pristupa nadilaze troškove. Odnosno, nije prikladan za sve projekte i otvoreni pristup općenito je prihvatljiv. Na primjer, teško je zamisliti razvoj upravljačkog sustava za elektranu ili zrakoplov koji se temelji na otvorenom principu. Ne, naravno, takvi sustavi trebaju uključivati module temeljene na otvorenim projektima, jer će to pružiti niz prednosti. Ali netko mora biti odgovoran za konačni proizvod. Čak i ako je sustav u potpunosti baziran na kodu otvorenih projekata, programer, nakon što je sve upakirao u jedan sustav i napravio specifične buildove i postavke, u biti ga zatvara. Kod može biti javno dostupan.
Također postoje mnoge prednosti za ove sustave od stvaranja ili doprinosa projektima otvorenog koda. Kao što sam već rekao, kod krajnjeg sustava može ostati javno dostupan. Zašto, jer očito je da je malo vjerojatno da će itko imati istu letjelicu za testiranje sustava. To je istina, ali možda postoji netko tko želi provjeriti određene dijelove koda ili, na primjer, netko može otkriti da biblioteka koja se koristi nije sasvim ispravno konfigurirana.
Još veća korist javlja se ako tvrtka neki osnovni dio sustava izdvoji u zaseban projekt. Na primjer, knjižnica koja podržava neku vrstu protokola za razmjenu podataka. U tom slučaju, čak i ako je protokol specifičan za određeno predmetno područje, možete podijeliti troškove održavanja ovog dijela sustava s drugim tvrtkama iz tog područja. Osim toga, stručnjacima koji mogu proučavati ovaj dio sustava u javnoj domeni potrebno je mnogo manje vremena da ga učinkovito koriste. I konačno, odvajanje dijela u neovisnu cjelinu koju koriste programeri trećih strana omogućuje nam da ovaj dio učinimo boljim, jer moramo ponuditi učinkovite API-je, izraditi dokumentaciju, a da i ne govorim o poboljšanju pokrivenosti testom.
Tvrtka može dobiti komercijalnu korist bez stvaranja projekata otvorenog koda; dovoljno je da njezini stručnjaci sudjeluju u projektima trećih strana koji se koriste u tvrtki. Na kraju krajeva, sve prednosti ostaju: zaposlenici bolje poznaju projekt, stoga ga učinkovitije koriste, tvrtka može utjecati na smjer razvoja projekta, a korištenje gotovog, debugiranog koda očito smanjuje troškove tvrtke.
Prednosti stvaranja projekata otvorenog koda tu ne završavaju. Uzmimo tako važnu komponentu poslovanja kao što je marketing. Za njega je ovo vrlo dobar sandbox koji mu omogućuje učinkovitu procjenu zahtjeva tržišta.
I naravno, ne smijemo zaboraviti da je opensource projekt učinkovit način da se deklarirate kao nositelj bilo koje specijalizacije. U nekim slučajevima to je jedini način ulaska na tržište. Na primjer, Embox je započeo kao projekt za stvaranje RTOS-a. Vjerojatno ne treba posebno objašnjavati da ima jako puno konkurenata. Bez stvaranja zajednice jednostavno ne bismo imali dovoljno resursa da projekt dovedemo do krajnjeg korisnika, odnosno da programeri trećih strana počnu koristiti projekt.
Zajednica je ključna u opensource projektu. Omogućuje značajno smanjenje troškova upravljanja projektom, razvoj i podršku projektu. Možemo reći da bez zajednice uopće nema opensource projekta.
Puno je materijala napisano o tome kako stvoriti i upravljati projektnom zajednicom otvorenog koda. Kako ne bih prepričavao već poznate činjenice, pokušat ću se fokusirati na iskustvo Emboxa. Na primjer, proces stvaranja zajednice je vrlo zanimljivo pitanje. Odnosno, mnogi govore kako upravljati postojećom zajednicom, ali ponekad se zanemaruju trenuci njenog stvaranja, smatrajući to danim.
Glavno pravilo pri stvaranju opensource zajednice projekta je da nema pravila. Mislim, nema univerzalnih pravila, baš kao što ne postoji srebrni metak, makar samo zato što su projekti vrlo različiti. Malo je vjerojatno da možete koristiti ista pravila kada stvarate zajednicu za biblioteku js zapisivanja i neki visoko specijalizirani upravljački program. Štoviše, u različitim fazama razvoja projekta (a time i zajednice), pravila se mijenjaju.
Embox je započeo kao studentski projekt jer je imao pristup studentima s odjela za programiranje sustava. Zapravo, ulazili smo u neku drugu zajednicu. Sudionike ove zajednice, studente, mogli bismo zainteresirati za dobru industrijsku praksu u njihovoj specijalnosti, znanstveni rad u području sistemskog programiranja, kolegije i diplome. Odnosno, slijedili smo jedno od osnovnih pravila organiziranja zajednice: članovi zajednice moraju nešto dobiti, a ta cijena mora odgovarati doprinosu sudionika.
Sljedeća faza za Embox bila je potraga za korisnicima trećih strana. Vrlo je važno razumjeti da su korisnici punopravni sudionici opensource zajednice. Obično ima više korisnika nego programera. A da bi htjeli postati suradnici na nekom projektu, prvo ga počnu koristiti na ovaj ili onaj način.
Prvi korisnici Emboxa bili su Zavod za teorijsku kibernetiku. Predložili su stvaranje alternativnog firmvera za Lego Mindstorm. I premda su to još uvijek bili lokalni korisnici (mogli smo se osobno sastati s njima i razgovarati o tome što žele). Ali svejedno je to bilo jako dobro iskustvo. Na primjer, razvili smo demonstracije koje bismo mogli pokazati drugima, jer su roboti zabavni i privlače pažnju. Kao rezultat toga, dobili smo doista korisnike treće strane koji su se počeli pitati što je Embox i kako ga koristiti.
U ovoj fazi morali smo razmišljati o dokumentaciji, o načinima komunikacije s korisnicima. Ne, naravno, razmišljali smo o tim važnim stvarima i prije, ali to je bilo prerano i nije dalo pozitivan učinak. Učinak je bio prilično negativan. Dat ću vam nekoliko primjera. Koristili smo googlecode, čiji je wiki podržavao višejezičnost. Napravili smo stranice na nekoliko jezika, ne samo na engleskom i ruskom, na kojima smo jedva komunicirali, već i na njemačkom i španjolskom. Kao rezultat toga, izgleda vrlo smiješno kada se pita na ovim jezicima, ali ne možemo uopće odgovoriti. Ili su uveli pravila o pisanju dokumentacije i komentiranju, ali kako se API dosta često i značajno mijenjao, pokazalo se da je naša dokumentacija zastarjela i da je više zavaravala nego pomagala.
Kao rezultat toga, svi naši napori, čak i oni pogrešni, doveli su do pojave vanjskih korisnika. Čak se pojavio i komercijalni kupac koji je želio da se za njega razvije vlastiti RTOS. I razvili smo ga jer imamo iskustva i neke temelje. Ovdje treba razgovarati i o dobrim i o lošim trenucima. Počet ću s lošima. Budući da su mnogi programeri bili uključeni u ovaj projekt na komercijalnoj osnovi, zajednica je već bila prilično nestabilna i podijeljena, što naravno nije moglo ne utjecati na razvoj projekta. Dodatni faktor bio je i to što je smjer projekta odredio jedan komercijalni kupac, a njegov cilj nije bio daljnji razvoj projekta. Barem to nije bio glavni cilj.
S druge strane, bilo je i niz pozitivnih strana. Imamo doista korisnike treće strane. Nije to bio samo kupac, već i oni kojima je ovaj sustav namijenjen. Motivacija za sudjelovanje u projektu je porasla. Uostalom, ako možete zaraditi i od zanimljivog posla, uvijek je lijepo. I što je najvažnije, čuli smo jednu želju kupaca, koja nam se tada činila suludom, ali koja je sada glavna ideja Emboxa, naime, koristiti već razvijen kod u sustavu. Sada je glavna ideja Emboxa koristiti Linux softver bez Linuxa. Odnosno, glavni pozitivni aspekt koji je doprinio daljnjem razvoju projekta bila je spoznaja da projekt koriste korisnici trećih strana, te bi trebao riješiti neke od njihovih problema.
Embox je tada već izašao iz okvira studentskog projekta. Glavni ograničavajući čimbenik u razvoju projekta prema studentskom modelu je motivacija sudionika. Studenti sudjeluju dok studiraju, a kad diplomiraju treba biti drugačija motivacija. Ako se motivacija ne pojavi, student jednostavno prestaje sudjelovati u projektu. Ako uzmemo u obzir da studente prvo treba osposobiti, ispada da do diplome postaju dobri stručnjaci, ali njihov doprinos projektu, zbog neiskustva, nije velik.
Općenito, glatko prelazimo na glavnu točku koja nam omogućuje da govorimo o stvaranju projekta otvorenog koda - stvaranju proizvoda koji bi riješio probleme svojih korisnika. Kao što sam gore objasnio, glavno svojstvo opensource projekta je njegova zajednica. Štoviše, članovi zajednice prvenstveno su korisnici. Ali odakle dolaze kad se nema što koristiti? Tako ispada da se, baš kao i kod non-opensource projekta, morate usredotočiti na stvaranje MVP-a (minimum viable product), a ako to zainteresira korisnike, tada će se oko projekta pojaviti zajednica. Ako ste uključeni u stvaranje zajednice samo kroz PR zajednice, pisanje wikija na svim jezicima svijeta ili ispravan tijek rada git na githubu, malo je vjerojatno da će to biti važno u ranim fazama projekta. Naravno, u odgovarajućim fazama to nisu samo važne, već i potrebne stvari.
U zaključku bih želio istaknuti , po mom mišljenju, odražava očekivanja korisnika od opensource projekta:
Ozbiljno razmišljam o prelasku na ovaj OS (barem pokušajte. Oni to aktivno traže i rade super stvari).
PS uključeno Imat ćemo čak tri izvješća. Jedan o otvorenom kodu i dva o ugrađenom (a jedan je praktičan). Na štandu ćemo održati master tečaj programiranja pomoću mikrokontrolera . Kao i obično, donijet ćemo hardver i prepustiti vam da ga programirate. Bit će tu i potrage i drugih aktivnosti. Dođite na festival i naš štand, bit će zabavno.
Izvor: www.habr.com