Riina kogemised

Kirjutada: kahe vaba projekti võrdlus (eeskätt arenduse vaatenurgast)

Olles ise teataval määral blogimise fänn ja alates 2004-st aastast vaikselt sellega toimetanud, tulidki esimesena võrdlemiseks pähe Movable Type ja Wordpress, mille kohta väike ülevaade koostada.

Movable Type Open Source (edaspidi MTOS) on paljude entusiastide koostöös loodud blogimootor. Projekti juhib Six Apart, kes hoolitseb selle eest et MTOS-i ikka edasi ehitataks ja hooldataks. MTOS on kõikidele soovijatele tasuta saadaval, et seda muuta, edasi levitada ja kasutada, milleks iganes soovitakse.

WordPress (edaspidi WP) on täielikult avatud koodiga projekt ja sajad inimesed üle maailma tegutsevad selle arendamise nimel ja on kõikidele tasuta kättesaadaval milleks iganes seda kasutada soovitakse.

MTOS filosoofia arendusprotsessi osas on selline, et arendajate kogukond saab teha nii suuremaid kui väiksemaid platvormi muudatusi ja parendusi ning võimaldab kiirelt väljastpoolt projekti tulnud innovaatilisi ideid toote tuumikule lisada. Samal ajal jälgitakse stabiilselt ja ennustatavat versioonide väljastamiste plaani. MTOS arendustiimi eesmärgiks on igas kvartalis üks stabiilne versioon väljastada. WP arendajad otsustasid pärast 2.1 release’i, et edaspidiseks väljastamise tsükliks on regulaarselt 3-4 kuu tagant release väljastada, sellesse on siis lisatud ideed, mis on peamiselt kasutajate poolt esitatud ja hääletatud.

MTOS arenduste protsess koosneb kahenädalastest tsüklitest, mille ajal kontrollitakse ja testitakse muudatusi erinevatel tasemetel. Iga tsükli lõpus väljastatakse build, mis on vähemalt Six Apart QA meeskonna poolt testitud. Need buildid tehakse selleks, et kvaliteet toote arendamise käigus tagada ja anda kõrvaltvaatajatele võimalus hetke olukorrast veidi stabiilsem pilt saada progressist stabiilse release’i suunas.

Kui arenduseesmärgid ühe release’i jaoks täidetakse ja aeg muudatusteks hakkab ümber saama, muudetakse testimise suunda rohkem väljapoole ehk siis väljastatakse beeta versioon. Beeta versiooni käigus on arendusmeeskonnal nädalane väljastustsükkel, selleks et kasutajaid täiendustega kursis hoida.

Enne uue suure arenduse ja release’i tsükli alustamist vaatavad projekti eestvedajad listide arhiivid, vearaportid ja uute arenduste ettepanekud wikist üle ja koostavad neist pikemaajalised strateegilised eesmärgid. Selle protsessi tulemused esitatakse kogukonnale aruteluks ja ülevaatamiseks. Kui konsensus saavutatakse ja otsused on tehtud, algab release’i arendus. Uute arenduste planeerimise protsess on tegelikult järjepidev ja pidevalt täienev protsess.

Six Apartil on QA insenerid üle maailma, kes on pühendunud järjepidevale testimisele ja MT toote kvaliteedi tagamisele. Neil on väga oluline roll iga build’i osas, mille meeskond toodab (välja arvatud öised build’id). Stabiilse build’i kandidaadile tehakse suur hulk teste, kasutatakse erinevaid veebibrausereid, andmebaase, operatsioonisüsteeme jne. Selle protsessi eesmärgiks on leida võimalikult palju probleeme, mis võivad toote kasutamisel ette tulla. Vastavalt tulemustele otsustatakse, kas release hilineb, et olulisi muudatusi veel sisse viia. Kui see iganes võimalik on, tehakse minimaalseid teste ka beeta versioonidele ja ülenädalastele arenduse ettapidele. See tagab, et ükski kriitiline funktsionaalsus ei oleks tõsiselt viga saanud ega muudetud (nt sisse/väljalogimine, uue postituse lisamine, avaldamine, kommenteerimine, jne). Vigade jälgimiseks kasutab MTOS FogBugz-i, koodihalduseks trac-i.

WP arendamisse saab panustada mitmeti – dokumentatsiooni parendamine, tõlkimine, foorumis abistamine, teiste kasutajate abistamine läbi IRC Live Chat’i, WP arendamine ja rahaliselt. WP arendamise puhul on kasutajatel võimalik planeerimises osaleda, testida, veaotsimises osaleda ning vigade parandusega tegeleda.

Kogu eelnev jutt on refereeritud wordpress.org ja movabletype.org lehtedelt. Mida ma õppisin sellest suurest WP ja MTOS lehtel surfimisest – peamiselt seda, et mõlema arendamisse on võimalik väga mitmeti panustada. Pealtnäha tundub, et MTOS-il on see süsteem natuke paremini üles ehitatud. Samas võib see tunne olla tingitud sellest, et just hiljuti on WP arendusblogisse ilmunud üleskutse arenduste edasist käitlemist parandada. Selleks oodatakse siis kasutajate tagasisidet. Ilmselt läheb mõlemal hästi, st kogukond tundub mõlemal piisavalt suur olevat, kuigi konkreetseid numbreid kuskil näha pole, et kogu seda arendamist majandada. Seni kuni entusiaste jätkub, on ka mul hea meel, sest minu blogimootor WP tahab ju ka aeg-ajalt jälle uuendamist :)

Eric S. Raymond, “The Cathedral and the Bazaar” (soovi korral võiks sealtsamast läbi lugeda ka selle järjed “Homesteading the Noosphere” ja “Magic Cauldron”)

Täitsa huvitavad artiklid on selle õppeaine kavasse valitud, ma olen siiralt üllatunud. Esialgu on kõik need tundunud kuidagi rasked, no niimoodi peale vaadates. Aga lugema hakates ei taha kuidagi enam käest panna enne kui kogu tekst läbi pole.

Katedraal ja turg, ei isegi mitte turg, bazaar on ikka kõige õigem kasutada, sest meie pole ju selliste turgudega siinmail harjunud, nagu loos kirjeldatakse. Ahjaa, see võrdlus on siis jällegi tarkvara arendamise kohta. Katedraal on võrdluseks kommertsprojektidele ja bazaar on võrdluseks vaba tarkvara ehk Linuxi maailma projektidele. Teksti autor kirjeldab, kuidas ta oli enne bazaari meetodiga tutvumist veendunud, et kõige olulisem tarkvara peab olema hoolikalt individuaalsete tegijate poolt ette valmistatud ja isolatsioonis välja töötatud ja et selle beetaversiooni ei avaldata enne kui on õige aeg. Teisalt toob autor võrdluseks Linus Torvaldsi lähenemise – bazaari – kus tarkvaraversioone antakse välja varakult ja tihti, delegeeritakse kõik tegevused, mis vähegi võimalikja ollakse kõiges väga avatud.

Autor on elavalt kirjeldanud, kuidas ta esialgu bazaari metoodikasse ei uskunud ja kuidas ta otsustas selle ühe oma projektiga siiski kasutusele võtta. Samm-sammult edasi liikudes ja jälgides Linuxi arendamise põhimõtteid, jõudis ta ka oma fetchmailiga väga kaugele. Selle protsessi käigus pani ta kirja olulisemad põhimõtted, mida järgida – neid sai kokku suisa 19.

Mulle meeldis, kuidas autor tõi mitu korda välja seda, et õigeid inimesi toetades ja tunnustades võib juhtuda nii, et ülejäänud maailm tunnustab just seda “juhti” kõikide innovaatiliste ideede eest. Sest selle “juhi” roll on ülimalt vastutusrikas – just tema peab otsustama, mis on kõige olulisem edasiarenemiseks. Sest ideid võib ju tulla paljudelt inimestelt – vahel tuleb mõned nüansid, mis endale kõige rohkem meele järele pole, vastu võtta. Teisalt tuleb olla valmis mingitest suurtest tükkidest ka loobuma. Hea võrdlus sellele oli Antoine de Saint-Exupéry tsitaat, mille järgi ideaal saavutatakse mitte siis kui enam midagi lisada pole, vaid siis, kui pole enam midagi ära võtta.

Ilmselt üks parimaid tulemusi konkreetse artikli valmimisele oli see, et Netscape otsustas oma koodi vabaks anda. Ilmselt ei oleks ka mul täna siin sellist head tööriista nagu Mozilla Firefox, kui see otsus poleks tol ajal 1998. aastal tehtud.

Igatahes jällegi üks huvitav artikkel, millest on vast igaühel midagi õppida.