Saveti za deljenje projekata

Autor: Nikola Hardi

Lepota slobodnog softvera leži u deljenju rešenja i saradnji. Zbog toga je poželjno da negujemo kulturu deljenja koda. Naravno, kod je uvek bolje podeliti nego ga samo sačuvati, ali sam kod ne znači mnogo. Projekat je uspeo tek onda kada se oko njega stvori zajednica korisnika i programera, a da bismo došli do tog stadijuma potrebni su neki preduslovi. Evo nekoliko dobrih saveta.

Kao što smo već rekli, kod je uvek bolje objaviti nego ga čuvati samo za sebe. Ako kažemo sebi da ćemo kod objaviti tek kada on bude završen, to najčešće znači da nikada neće biti objavljen. Softverski projekti gotovo nikada nisu završeni. Postoji nekoliko kontraprimera (Doker, Android…) gde su velike kompanije odlučile da svoj kod ne objave odmah. To su izuzeci koji su opravdani kod velikih kompanija koje žele da ubrzaju plasiranje svog proizvoda.

Nakon što ste objavili kod, potrudite se da ga i održavate. Ukoliko imate sreće i neko se zainteresuje za parče softvera koje ste stvorili, taj neko će prvo pogledati kada je postavljena poslednja izmena. U slučaju da je projekat napušten, korisnici ga najčešće neće ni isprobati. Dakle, objavljujte izmene tempom kojim ih i činite, a ne odjednom u paketu. Grupišite izmene u verziju ili izdanje, ako je to potrebno.

Svaki projekat teži ka tome da ima neki svoj interni kodeks. Ukoliko i osnivač projekta i njegovi najbliži saradnici krše ta (nepisana) pravila, onda će to raditi i korisnici i drugi programeri. Važno je da se greške uvek prijavljuju na jednom mestu, dokumentacija skuplja na drugom, a sugestije prihvataju na trećem mestu. Makar se dopisivali sami sa sobom, zapišite poruku o grešci. Možda će to neko primetiti i poslati ispravku čak i pre vas!

Važno je imati velike ciljeve, ali je još važnije imati bilo kakve rezultate. Bolje je imati jednu skromnu funkcionalnost nego nijednu od deset najmodernijih. Zbog toga se teži da se što pre stigne do neke funkcionalnosti, kako bi što pre počela da se gradi zajednica koja će slati povratne informacije i pomoć.

„Tresla se gora, rodio se miš.” Ako ne obećavate mnogo, onda vas niko neće optuživati da svoja obećanja niste ispunili i ceniće se bilo šta što napravite. Zbog toga je najpametnije hvaliti se samo urađenim stvarima i u vestima objavljivati ono šta je do sada napravljeno, a ne ono šta je planirano da bude urađeno. LiBRE! je sjajno mesto da se pohvalite svojim projektom, ali tek kada imate nešto da pokažete.

Projekat koji nema ni *rid-mi* (eng. readme) fajl će u startu odbiti i prve korisnike (eng. early adopters). Naglašavamo, prvi korisnici su ti koji će rad na projektu učiniti lakšim i zanimljivijim. Dokumentacija ne mora da bude opširna. Neki profesori se šale i kažu da opširna dokumentacija može čak da bude i presudan faktor pri izboru softverskog rešenja po principu: što teža dokumentacija (u kilogramima), to je softver bolji. Naravno, to je samo šala i dokumentacija pre svega treba da bude upotrebljiva, ažurna i pouzdana. Treba da obuhvata opis funkcionalnosti koje su implementirane, primer upotrebe, način kako se može testirati, kako instalirati i kako se uključiti u projekat. Ovo je prvi kontakt sa budućim korisnicima i rid-mi mora da bude sažet, ali sadržajan.

Odlučite kako želite da prihvatite nečiju pomoć i dajte primere kakva vam je sve pomoć potrebna. Pomoć može biti u obliku testiranja, pisanja dokumentacije, reklamiranja, prevoda, pa sve do same implmentacije. Neki projekti očekuju izmene na određenoj imejl adresi u obliku zakrpe (eng. patch), a neki drugi na dopisnim listama, sistemima za praćenje problema (eng. bug/issue tracker) ili u obliku zahteva za uključenje izmena (eng. pull request). Kažite jasno kako očekujete izmene jer neko neodlučan može da odluči da produži svojim putem umesto da doprinese projektu.

Korisnike zanima kako mogu da isprobaju vaše parče softvera. Redosled je uglavnom sledeći:

• želim da pročitam šta projekat radi;
• želim da na snimku ekrana vidim kako to izgleda;
• želim da isprobam demo (u slučaju veb-aplikacija);
• želim da preuzmem kod i isprobam ga na svojem računaru.

Potrudite se da proces preuzimanja koda, kompajliranja, pokretanja i eventualno instalacije bude automatizovan i dobro opisan. Postoje standardizovani alati u zavisnosti od izabrane tehnologije kao što su Pajton setaptuls, Nod pakidž menadžer, C-mejk, Autotuls… Ideje za organizaciju koda i podešavanje tzv. bild sistema (eng. build system) je uvek otvorena tema i vrlo je specifična u zavisnosti od izabrane tehnologije. Svakako zaslužuje poseban tekst u našem časopisu.

I programeri su u prvi mah korisnici. Oni će prvo želeti da pokrenu i koriste vaš program a tek onda pokušati da ga unaprede. Dobra praksa je da projekat sadrži i skup testova kojim će programeri moći da provere da nisu svojim izmenama nešto pokvarili. Osim testova, tu su i postavljanje razvojnog okruženja (baza podataka, biblioteke zavisnosti…). Moderno je taj teret skinuti sa leđa programera i proces podešavanja radnog okruženja automatizovati pomoću alata kao što su Vagrant, Papet (eng. Puppet), Šef (eng. chef) i Ansibl ili Doker, o kojima je već bilo reči. Sve u svemu, pokušajte da se postavite u situaciju novog člana svog tima. Šta on sve mora da uradi nakon što klonira git repozitorijum? Da li možete taj deo posla da automatizujete? Ako možete, uradite to.

Open-sors model razvoja softvera je vrlo neobičan. Građenje zajednice je jedan od prioriteta. Dobra zajednica će i od lošeg koda napraviti nešto korisno. Dobar kod bez zajednice umire. Ne postoje neki jasni šabloni kako se stvara zajednica, ali možemo da preporučimo nekoliko knjiga koje se bave tim problemom.

• Open Advice http://open-advice.org/
• The Art of Community http://www.artofcommunityonline.org/