U Sankt Peterburgu će ove sedmice biti održan IT festival . Jedan od govornika će biti Richard Stallman. također učestvuje na festivalu, a naravno nismo mogli zanemariti ni temu slobodnog softvera. Zato se zove jedan od naših izvještaja . Biće posvećen istoriji razvoja Embox-a kao projekta otvorenog koda. U ovom članku želim govoriti o glavnim idejama koje, po mom mišljenju, utiču na razvoj opensource projekata. Članak je, kao i izvještaj, zasnovan na ličnom iskustvu.
Počnimo s nečim jednostavnim, s definicijom pojma opensource. Očigledno, projekat otvorenog koda je projekat koji ima jednu od licenci koja omogućava pristup izvornom kodu projekta. Osim toga, otvoreni projekt znači da programeri treće strane mogu unositi promjene. To jest, ako neka kompanija ili programer objavi kod svog proizvoda, djelomično ili u potpunosti, to još ne čini ovaj proizvod projektom otvorenog koda. I konačno, svaka projektna aktivnost mora dovesti do neke vrste rezultata, a otvorenost projekta podrazumijeva da ovaj rezultat ne koriste samo sami programeri.
Nećemo se doticati problema otvorenih licenci. Ovo je prevelika i složena tema koja zahtijeva dubinsko istraživanje. Na ovu temu napisano je dosta dobrih članaka i materijala. Ali pošto ni sam nisam stručnjak za oblast autorskih prava, 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 projekat otvorenog koda treba da obezbedi mogućnost da se promene i utiče na razvoj projekta otvorenog koda podrazumeva da je projekat distribuiran. Upravljanje njime, održavanje integriteta i performansi mnogo je teže u poređenju sa projektom sa centralizovanim upravljanjem. Postavlja se razumno pitanje: zašto se uopće otvaraju projekti? Odgovor leži u području komercijalne izvodljivosti; za određenu klasu projekata, prednosti ovog pristupa su veće od troškova. Odnosno, nije pogodan za sve projekte i otvoreni pristup je općenito prihvatljiv. Na primjer, teško je zamisliti razvoj sistema upravljanja za elektranu ili avion na otvorenom principu. Ne, naravno, takvi sistemi bi trebali uključivati module zasnovane na otvorenim projektima, jer će to pružiti niz prednosti. Ali neko mora biti odgovoran za konačni proizvod. Čak i ako je sistem u potpunosti baziran na kodu otvorenih projekata, programer, nakon što je sve spakovao u jedan sistem i napravio određene build-ove i postavke, u suštini ga zatvara. Kod može biti javno dostupan.
Postoje i mnoge prednosti za ove sisteme od kreiranja ili doprinosa projektima otvorenog koda. Kao što sam već rekao, kod krajnjeg sistema može ostati javno dostupan. Zašto, jer je očigledno da je malo verovatno da će neko imati istu letelicu za testiranje sistema. Ovo je tačno, ali možda postoji neko ko želi da proveri određene delove koda, ili, na primer, neko može otkriti da biblioteka koja se koristi nije sasvim ispravno konfigurisana.
Još veća korist se pojavljuje ako kompanija izdvoji neki osnovni dio sistema u poseban projekat. Na primjer, biblioteka koja podržava neku vrstu protokola za razmjenu podataka. U ovom slučaju, čak i ako je protokol specifičan za datu predmetnu oblast, možete podijeliti troškove održavanja ovog dijela sistema sa drugim kompanijama iz ove oblasti. Osim toga, stručnjacima koji mogu proučavati ovaj dio sistema u javnom domenu je potrebno mnogo manje vremena da ga efikasno koriste. I konačno, razdvajanje dijela u nezavisnu cjelinu koju koriste programeri trećih strana omogućava nam da ovaj dio učinimo boljim, jer moramo ponuditi efikasne API-je, kreirati dokumentaciju, a o poboljšanju pokrivenosti testom čak i ne govorim.
Kompanija može dobiti komercijalne koristi bez kreiranja projekata otvorenog koda, dovoljno je da njeni stručnjaci učestvuju u projektima trećih strana koji se koriste u kompaniji. Na kraju krajeva, sve prednosti ostaju: zaposleni bolje poznaju projekat, stoga ga efikasnije koriste, kompanija može uticati na pravac razvoja projekta, a upotreba gotovog, debagovanog koda očigledno smanjuje troškove kompanije.
Prednosti kreiranja opensource projekata se tu ne završavaju. Uzmimo tako važnu komponentu poslovanja kao što je marketing. Za njega je ovo veoma dobar sandbox koji mu omogućava da efikasno proceni zahteve tržišta.
I naravno, ne smijemo zaboraviti da je opensource projekat efikasan način da se deklarirate kao nosilac bilo koje specijalizacije. U nekim slučajevima, ovo je jedini način za ulazak na tržište. Na primjer, Embox je započeo kao projekt za kreiranje RTOS-a. Vjerovatno ne treba objašnjavati da ima puno konkurenata. Bez kreiranja zajednice jednostavno ne bismo imali dovoljno resursa da projekat dovedemo do krajnjeg korisnika, odnosno da programeri treće strane počnu da koriste projekat.
Zajednica je ključna u projektu otvorenog koda. Omogućava vam značajno smanjenje troškova upravljanja projektom, razvoj i podršku projekta. Možemo reći da bez zajednice uopšte nema projekta otvorenog koda.
Mnogo je materijala napisano o tome kako kreirati i upravljati projektnom zajednicom otvorenog koda. Da ne bih prepričavao već poznate činjenice, pokušaću da se fokusiram na iskustvo Embox-a. Na primjer, proces stvaranja zajednice je vrlo zanimljivo pitanje. Odnosno, mnogi govore kako upravljati postojećom zajednicom, ali momenti njenog nastanka se ponekad zanemaruju, smatrajući to datim.
Glavno pravilo pri kreiranju zajednice projekata otvorenog koda je da nema pravila. Mislim, ne postoje univerzalna pravila, kao što ne postoji srebrni metak, makar samo zato što su projekti veoma različiti. Malo je vjerovatno da možete koristiti ista pravila kada kreirate zajednicu za js biblioteku evidencije i neki visoko specijalizirani drajver. Štaviše, u različitim fazama razvoja projekta (a samim tim i zajednice), pravila se mijenjaju.
Embox je započeo kao studentski projekat jer je imao pristup studentima sa odsjeka za sistemsko programiranje. U stvari, ulazili smo u neku drugu zajednicu. Učesnike ove zajednice, studente, mogli bismo zainteresovati za dobru industrijsku praksu u njihovoj specijalnosti, naučni rad u oblasti sistemskog programiranja, kurseve i diplome. Odnosno, poštovali smo jedno od osnovnih pravila organizovanja zajednice: članovi zajednice moraju nešto da dobiju, a ova cena mora odgovarati doprinosu učesnika.
Sljedeća faza za Embox bila je potraga za trećim korisnicima. Veoma je važno shvatiti da su korisnici puni učesnici zajednice otvorenog koda. Obično ima više korisnika nego programera. A da bi poželeli da postanu saradnik projekta, prvo počnu da ga koriste na ovaj ili onaj način.
Prvi korisnici Emboxa bili su Katedra za teorijsku kibernetiku. Predložili su stvaranje alternativnog firmvera za Lego Mindstorm. I iako su to još uvijek bili lokalni korisnici (mogli smo se sastati s njima lično i razgovarati o tome šta žele). Ali to je ipak bilo jako dobro iskustvo. Na primjer, razvili smo demo snimke koje bi mogli pokazati drugima, jer su roboti zabavni i privlače pažnju. Kao rezultat toga, dobili smo zaista korisnike treće strane koji su počeli da se pitaju šta je Embox i kako ga koristiti.
U ovoj fazi morali smo razmišljati o dokumentaciji, o načinima komunikacije sa korisnicima. Ne, naravno, razmišljali smo o ovim važnim stvarima i ranije, ali to je bilo prerano i nije dalo pozitivan efekat. Učinak je bio prilično negativan. Dozvolite mi da vam dam par primjera. Koristili smo googlecode, čija wiki podržava višejezičnost. Napravili smo stranice na nekoliko jezika, ne samo na engleskom i ruskom, na kojima smo teško komunicirali, već i na njemačkom i španskom. Kao rezultat toga, na ovim jezicima izgleda vrlo smiješno, ali mi uopće ne možemo odgovoriti. Ili su uveli pravila o pisanju dokumentacije i komentarisanju, ali kako se API dosta često i značajno mijenjao, ispostavilo se da je naša dokumentacija zastarjela i da je više zavaravala nego što je pomogla.
Kao rezultat, svi naši napori, čak i 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 mi smo ga razvili jer imamo iskustvo i neku osnovu. Ovdje treba razgovarati i o dobrim i o lošim trenucima. Počeću sa lošim. Budući da su mnogi programeri bili uključeni u ovaj projekat na komercijalnoj osnovi, zajednica je već bila prilično nestabilna i podijeljena, što naravno nije moglo a da ne utiče na razvoj projekta. Dodatni faktor je to što je pravac projekta odredio jedan komercijalni kupac, a njegov cilj nije bio dalji razvoj projekta. To barem nije bio glavni cilj.
S druge strane, postojao je niz pozitivnih aspekata. Imamo zaista korisnike treće strane. Nije to bio samo kupac, već i oni kojima je ovaj sistem bio namijenjen. Pojačana je motivacija za učešće u projektu. Uostalom, ako možete zaraditi i od zanimljivog posla, uvijek je lijepo. I što je najvažnije, od kupaca smo čuli jednu želju koja nam se tada činila suludom, ali koja je sada glavna ideja Embox-a, a to je korištenje već razvijenog koda u sistemu. Sada je glavna ideja Embox-a korištenje Linux softvera bez Linuxa. Odnosno, glavni pozitivni aspekt koji je doprinio daljem razvoju projekta bila je spoznaja da projekat koriste treći korisnici, te da bi to trebalo riješiti neke njihove probleme.
U to vrijeme, Embox je već izašao iz okvira studentskog projekta. Glavni ograničavajući faktor u razvoju projekta po studentskom modelu je motivacija učesnika. Studenti učestvuju dok studiraju, a kada diplomiraju, treba da postoji drugačija motivacija. Ako se motivacija ne pojavi, učenik jednostavno prestaje da učestvuje u projektu. Ako uzmemo u obzir da studente prvo treba obučiti, ispada da do diplomiranja postaju dobri specijalisti, ali njihov doprinos projektu, zbog neiskustva, nije veliki.
Općenito, glatko prelazimo na glavnu stvar koja nam omogućava da razgovaramo o kreiranju opensource projekta - kreiranju proizvoda koji bi riješio probleme svojih korisnika. Kao što sam gore objasnio, glavno svojstvo opensource projekta je njegova zajednica. Štaviše, članovi zajednice su prvenstveno korisnici. Ali odakle dolaze kada nema šta da se koristi? Tako se ispostavilo da, baš kao i kod projekta koji nije otvorenog koda, morate se fokusirati na kreiranje MVP-a (minimalno održivog proizvoda), a ako to zanima korisnike, onda će se oko projekta pojaviti zajednica. Ako se bavite stvaranjem zajednice samo putem PR-a u zajednici, pisanja wikija na svim jezicima svijeta ili ispravnog git toka posla na githubu, onda je malo vjerovatno da će to biti važno u ranim fazama projekta. Naravno, u odgovarajućim fazama to nisu samo važne, već i neophodne stvari.
U zaključku želim da istaknem , po mom mišljenju, odražava očekivanja korisnika od opensource projekta:
Ozbiljno razmišljam o prelasku na ovaj OS (barem pokušajte. Oni ga aktivno prate i rade super stvari).
PS On Imaćemo čak tri izvještaja. Jedan o otvorenom kodu i dva o ugrađenom (i jedan je praktičan). Na štandu ćemo održati majstorsku klasu o programiranju korištenja mikrokontrolera . Kao i obično, mi ćemo donijeti hardver i pustiti vam da ga programirate. Održat će se i potraga i druge aktivnosti. Dođite na festival i naš štand, bit će zabavno.
izvor: www.habr.com