Vaba tarkvara arendusprotsess ja selle eripärad
Kuidas vaba tarkvara arendada?
Ehkki ESR tuntud "Katedraal ja turg" rõhutab just vabalt muutuva arenduskogukonna mudelit ("turg"), ei ole olemas üht ja ainsat vaba tarkvara arendamise viisi. Mõned näited:
- Apache - suur ja arvukas kogukond, koordineeriv sihtasutus; kõik soovijad võivad liituda
- Linuxi tuum - mitmekihiline arenduskogukond, palju eri toetajaid; liituda võivad kõik, ent olulisi otsuseid teeb tuumikmeeskond, kus omakorda on viimase sõna õigus kogu projekti algatajal Linus Torvaldsil
- MySQL - põhitegijad töötavad ühes firmas, suur osa arendusest toimub sisemiselt ning alles valmis tulemused avaldatakse
- paljud väiksemad projektid (Sourceforge, Freshmeat) - kogukonda ei pruugi üldse olemas olla; arendaja(d) tegelevad tarkvara arendamisega ja panevad selle allalaadimiseks välja, tagasiside võib toimuda e-posti, meililisti või veebilehe kaudu.
Üldiselt, mida enam projekt soodustab terve arendus- ja kasutajakogukonna omavahelist suhtlemist, seda mõistlikum vaba tarkvara mudeli kasutamine selle juures on. Väga oluline on tagada kõigi liikmete võrdne osalus ja ligipääs. Eriti tähtsaks muutub see rahvusvahelise, ülemaailmse kogukonnaga projekti juures. Näiteks võib arendajate suhtlus olla rajatud IRC kanali põhjal - sel juhul aga peab silmas pidama, et nõupidamine kanalil keskpäeval Greenwichi aja järgi võib olla üsna ebamugav USA-s elavatele osalejatele, kelle jaoks on sügav ööaeg.
Üks suurimaid vigu, mida vaba tarkvara projekt võib teha, on tõmmata piir kasutajate ja arendajate vahele. Isegi kui reaalne arendusmudel võimaldab neid eristada (näiteks Ubuntu Linuxi juures Canonicali või Fedora puhul Redhati töötajad), tuleb püüelda kasutajate võimalikult suure kaasamise poole - mõlemad eespoolmainitud Linuxi distrod toetuvad lisaks firmale ka kasutajakogukonnale (UbuntuForums.org, Fedora kogukonnad).
Mida vaja läheb
Tüüpiline vaba tarkvara projekt sisaldab kindlasti avalikku koodivaramut, dokumentatsiooni nii kasutajatele kui arendajatele, meililiste, uudisegruppe ja muid arutelukeskkondi, veahaldussüsteemi ning muidugi seda kõike kooshoidvat veebilehte.
Koodivaramu
Ligipääs programmikoodile on vaba tarkvara esmaseid nõudeid - see peab olema kättesaadav kõigile huvilistele. Põhilistele koodiüksustele (moodulid, alamprogrammid) määratakse enamasti kindel koodihaldur (suurema projekti või tüki puhul mitu), kel on õigus muudatusi teha otse koodi. Ülejäänud osalejad saadavad oma täiendused ja parandused halduri(te)le, kes need koodi sisse viib. Koodi haldamine võib olla üsna suur töö ning koodihaldurid kuuluvad reeglina arendusmeeskonna tuumikusse.
Lähtekoodi eri väljalasked (build) peaks olema sagedased (kui võimalik, siis igapäevased). Sageli pakutakse paralleelselt kaht väljalaset - 'viimase peal' verivärsket ning mõnd vanemat, läbiproovitud ja stabiilset varianti. Esimene on eeskätt mõeldud arendajatele, teine lõppkasutajatele.
Koodivaramu paindlikuks haldamiseks on kasulik versioonihaldustarkvara nagu CVS (Concurrent Versioning System) või Subversion. Meie kasutame näitena Trac'i, mida saab siduda Subversioniga. Versioonihaldus võimaldab koostada väljalaskeid eri arendusmomentidest ning vajadusel "tagurdada" vanema versiooni juurde. Versioonihaldustarkvara puhul tuleks kindlasti kasutada vabasid vahendeid - enamik arenduses osalejaid ei ole huvitatud osa võtmast, kui nad peavad selle eest peale maksma (olgugi et tööriistade eest).
Vajalikud tegevused versioonihalduse juures on näiteks versioonihaldustarkvara hooldamine (N: Trac'i haldamine), päevaste väljalasete koostamine ja testimine (ning vajadusel vigadest teatamine vastava töölõiguga tegelevale arendajale), samuti kogukonnalt laekunud paranduste ja täienduste lisamine koodibaasi.
= Dokumentatsioon
Tavaline kasutajadokumentatsioon on ilmselt vajalik mistahes tarkvaraprojekti juures, kuid sisemise dokumentatsiooni osatähtsus on vaba projekti korral suurem - arendusmeeskond on hajusam ning võib tihedamini muutuda, samuti on paljudel arendajatel päevas ehk vaid pool tundi aega, mida projektile pühendada (seepärast ei tohi seda kõrvaliste asjade peale kulutada). See peab aitama värsketel arendajatel "järje peale saada" ja koodis orienteeruda - mida lihtsam on uuel tulijal liituda, seda rohkem tulijaid on (ja ka vastupidi - kehv dokumentatsioon peletab huvilisi eemale).
Koodi dokumenteerimine autorite poolt on väga tähtis, veelgi tähtsam on aga kõrgtaseme arendusdokumentatsioon (kasutajalood, spetsifikatsioonid jne) ja tarkvaradisain. Samuti on oluline nn roadmap ehk kogu projekti ja selle tähtsamate osade arenduskava. Arenduskava koostamisel kasutatakse erinevate tagasisidekanalite (listid, uudisegrupid, IRC) kaudu saadud infot. Kasutajate jaoks tasub luua "soovinimekirjad" (nii kogu projektile kui ka suurematele moodulitele eraldi), mille kaudu kogutakse uusi arendusideid.
Kasutajadokumentatsioon on samuti väga oluline. Alustada võiks erinvatest tagasisidekanalitest kogutud KKK-dokumendiga (FAQ). Dokumentatsiooni puhul kasutatakse haldureid sarnaselt koodibaasiga - dokumentatsioonil ja selle põhiosadel on oma haldurid, kes seda kogukonnalt laekunud info alusel täiendavad. Dokumentatsiooni puhul võib aga anda kasutajatele ka rohkem õigusi - näiteks realiseerida osa dokumentatsioonist wikina. Dokumentatsioon peab olema avatud vormingus - eelistatavalt tavateksti või HTMLina (mõned tuntud projektid kasutavad ka Docbooki).
Veahaldus
Veahaldussüsteem on eluline osa arendusest. See peab olema arendajatele võimalikult lihtne kasutada - mõned eelistavad e-postipõhiseid rakendusi, teised veebipõhiseid. Vigadest teatamine peab olema lihtne ja lollikindel - tuleb tähele panna, et juba viga ise on tihti tekitanud kasutajale paksu pahandust (töö läks kaotsi) ja kui nüüd ka sellest teatamine käib suure mässamisega, saab ta tõenäoliselt kurjaks. Kasutajate vearaportisüsteem võiks olla ka lihtsam kui arendajate oma - sel juhul peaks kasutajaraportitega tegelema omaette inimene, kes eraldab vead valehäiretest ning "söödab" need arendajatele ette. Võib ka teha eraldi listi vearaportite jaoks, mille haldur teeb pidevalt vigadest koondeid ning edastab need arendajatele.
Listid ja teised arutelukeskkonnad
Arutelu peaks igal tasandil olema võimalikult avalik. Kui osa seltskonnast sulgeb oma arutelud kinniste uste taha, siis tekib taas "esimese ja teise järgu inimeste" probleem ning kõrvalejäetud võivad üldse projektist lahkuda. Kindlasti tuleb hoida kogukonda kursis toimuvaga - see puudutab eriti planeeritavaid suuremaid muudatusi. Näiteks kui mingi koodilõigu haldur otsustab muuta dokumenteerimisviisi ja teeb seda hoobilt ilma eelneva hoiatuse ja konsulteerimiseta, on tulemuseks suur segadus ja palju pahandust.
Projekti veeb
Veebileht peaks ideaaljuhul täitma portaali rolli, pakkudes ligipääsu kõigile projekti aspektidele - alates spetsifikatsioonidest ning lõpetades lõppkasutaja dokumentatsiooniga ja allalaetava tarkvaraga (lähtekood, sageli aga ka binaarkujul "pakid" eri süsteemide jaoks). Leht peaks andma ka selge pildi projekti arenguastmest, vajatavatest spetsialistidest, kogukonna rollist (kas see on arendus- või kasutajakogukond või mõlemat) jne.
Väikesele projektile piisab paarist leheküljest, suure puhul on vaja märksa mahukamat materjali (sh eraldi sektsioonid suurematele moodulitele). Enamasti on veebi haldamine omaette ülesanne, suure projekti puhul võib olla vajalik ka eraldi veebitoimetaja.
Uurida ja analüüsida
- R. Goldman, R.P. Gabriel. Innovation Happens Elsewhere. http://dreamsongs.com/IHE/IHE.html, ERITI AGA 6. PEATÜKK: http://dreamsongs.com/IHE/IHE-52.html#pgfId-956749
Lugeda
- E.S. Raymond. The Cathedral and the Bazaar. http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/
- N. Bezroukov. Open Source Software Development as a Special Type of Academic Research (Critique of Vulgar Raymondism). http://www.firstmonday.dk/issues/issue4_10/bezroukov/index.html
- E.S. Raymond. A Response to Nikolai Bezroukov. http://www.catb.org/~esr/writings/response-to-bezroukov.html
- N. Bezroukov. A Second Look at the Cathedral and the Bazaar. http://www.firstmonday.dk/issues/issue4_12/bezroukov/