Riina kogemised

Mm, ei ole üldse toredad need kevadised hetked siin :D

K09 IFI7007 Uurimismeetodid

• 5 st 4 st 2 puudutud seminari eest kodused tööd
• 1 uurimisplaani skeem
• 1 uurimisplaan essee vormis

K09 PSO7100 Organisatsiooniteooriad

• 1 essee, mille tähtaeg oli liigagi ammu
• Eksam/arvestus [04.06.09 kl 17 @ U-134]

K09 IFI7013 Infotehnoloogia strateegiline juhtimine

• Ettevõtte IT strateegiline plaan, võib-olla tuleb teha ettekanne
• Eksam [31.05.09 kl 14 @ P-416]

K09 IFI7105 Avatud lähtekoodil põhinev arendusmudel

• Lugeda [L] S. Levy Hackersi 2 esimest peatükki ja kirjutada ajaveebi enda arvamus/hinnang
• Kirjutada 1-2 lk juhtumikirjeldus/edulugu ühest edukast vaba tarkvara projektist (omal valikul)
• Lugeda läbi [L] Innovation Happens Elsewhere (kui kõike ei jõua, siis vähemalt algus ja 6. peatükk) ja kirjutada ajaveebi enda arvamus/hinnang
• Kirjutada: kahe vaba projekti võrdlus (eeskätt arenduse vaatenurgast)
• Lugeda ja kommenteerida: (1) Eben Moglen, “Anarchism Triumphant” (saadaval ka siin); (2) 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”)
• ühe teise meeskonna kampaania retsenseerimine (individuaalselt ajaveebis)
• Kirjutada: GPL ja BSD litsentsi võrdlus kahe vaba projekti näitel
• Lugeda ja kommenteerida: Eric S. Raymond, “Kuidas saada häkkeriks” või sama asi originaalis

K09 PSO7012 Reklaami ja mõjustamise psühholoogia

• Kirjalik arvestus [28.05.09 kl 17 @ K-114]

Tulemus: 41 AP tehtud, 4 AP tegemata

Praktilise arendustööna loome ca 3 missiooniga mängukampaania ühele tuntumale vabatarkvaralisele strateegiamängule [L] The Battle for Wesnoth. Arendamise juures üritame järgida reaalsete vaba tarkvara projektide metoodikat. [1]

Koduülesanne: ühe teise meeskonna kampaania retsenseerimine (individuaalselt ajaveebis) [2]

Olles natuke hädas teiste meeskondade kampaaniate ülevaatamisega, lähenen etteantud teemale veidi teise nurga alt. Nimelt tundub mulle, et ka meie, st roheliste rühma projekt, vajaks veidi kriitilise pilguga ülevaatamist ja seda mitte ainult kampaania osas vaid ka projekti läbiviimise osas.

Lugesin suht värskelt avatud lähtekoodi projektide arendamise raamatut “Innovation happens elsewhere” [3] ja seal olid peatükis 6 välja toodud avatud koodiga projektide arenduse põhimõtted, mida võiks jälgida.

1) Avaliku koodi arhiiv

Täitsa olemas, koodi jaoks kasutasime trac süsteemi

2) Projekti dokumentatsioon

Tegemist oli küll väga väikese projektiga, aga sellegipoolest oleks tulnud tähelepanu pöörata ka dokumentatsioonile. Seda siis nii lõppkasutaja kui ka arenduse poolelt.

3) Vigade andmebaas

Vigade haldamiseks oli võimalus trac-is olemas

4) Loo kirjade vahetamiseks list või uudisgrupp

Kuna meid oli vähe, polnud listi moodustamisel mõtet, uudisgrupi tegemisel veel vähem. Täiesti piisavaks suhtluskanaliks olid Skype, Gmail ja MSN. Samas on selliseid vahendeid kasutades see negatiivne külg, et informatsioon ei talletu ühte kohta ja võib ette tulla olukordi, kus tagantjärele pole võimalik enam üles leida, kes kellele mida ja kus öelnud on.

5) Projekti veebileht

Veebilehe rolli täitis trac-is olev wiki lehekülg, kuhu said kirja meeskonna liikmed ja kampaania lugu. Seda lehte oleks saanud kasutada ka muu info talletamiseks (vt punkti 2 ja 4)

6) Planeerimine ja otsuste tegemine

Esimesel koosolekul sai plaan tehtud ja otsused vastu võetud. Kampaania loomise käigus võeti otsuseid vastu vastavalt vajadusele, eraldi koosolekuid selle jaoks ei toimunud. Ka plaan ja otsused oleksid võinud kajastuda eelmises puntkis mainitud kohas.

7) Testimine ja versiooni väljastamine

Jällegi kuna tegemist on väikse projektiga, siis pärast vajalike testide tegemist said väljatulnud vead operatiivselt parandatud ja versioon sai suht ruttu välja.

As you can see, lots of work is needed for an open-source project to be successful. Here is a list of some of the jobs that you must commit resources to:

Evangelist/community coordinator to encourage and coordinate developers, get publicity for the project, increase community involvement, host mailing lists, and in general just keep the project moving along. (We say more about these activities in the section on creating a community of developers.)

Module owners to be responsible for the development of the code and to integrate contributions and bug fixes from other developers. They also need to participate on the project mailing lists.

Infrastructure support for the CVS archive, mailing lists, bug database, and website.

Website editor to keep the website alive with new content.

People to document the system architecture and record reasons for design decisions.

Buildmaster to oversee the build process and fix problems with broken builds.

Release manager to coordinate release activities. [3]

Kokkuvõttes on selle projekti haldamisel nii häid külgi kui ka parandust vajavaid tegevusi. Väga hea võimalus oli kogu teoreetiline loetud ja loengus kuuldud jutt läbi teha sellise projekti käigus, millel on tegelikult ka täiesti reaalne tulemus. Teiste meeskondade hinnanguid [4] arvesse võttes saime täitsa hästi hakkama ja olen täitsa kindel, et meie meeskond saaks ka suuremate projektidega täitsa edukalt hakkama kui eelnevaid õppepunke arvesse võtame.

———–

[1] http://akadeemia.kakupesa.net/ALKA/

[2] http://akadeemia.kakupesa.net/ALKA/loengud/

[3] http://dreamsongs.com/IHE/IHE-52.html

[4] http://www.andrisreinman.com/2009/05/rohelise-meeskonna-mang/,

http://www.acxe12.net/blog/?p=30,

http://battlefieldofwesnoth.blogspot.com/2009/05/roheliste-kampaania.html,

http://margus-wesnoth.blogspot.com/2009/05/roheliste-kampaania-arvustus.html

Lugeda ja kommenteerida: (1) Eben Moglen, “Anarchism Triumphant” (saadaval ka siin);

Autor on päris põhjalikult selgitanud tagamaid, kust pärineb tarkvara litsentseerimise vajadus. Näited nii IBM-i, Microsofti kui Linuxi maailmast lisavad tema arutlustele kaalu ja aitavad jõuda artikli põhilise sõnumini – kui omanduse teema tee pealt eest saada ja paljude inimestega koos tegutseda, on võimalik väga kiirelt ja väga kaugele areneda, sest loomingulisus tuleb sellisel moel just kõige ehedamini esile.

Artikkel oli küll suhteliselt keerulises keeles kirjutatud ja nii mõnigi lõik tuli mitu korda üle lugeda, siiski oli see väga põnev lugemine eriti just toodud näidete osas. See artikkel kuulub vaieldamatult selle aine lugemisvara komplekti.

Ahjaa, Tarmo ülevaade artiklist oli ka täitsa hea lugemine ;)

Kirjutada: GPL ja BSD litsentsi võrdlus kahe vaba projekti näitel

Wikipedia: The [BSD] licenses have few restrictions compared to other free software licenses such as the GNU General Public License or even the default restrictions provided by copyright, putting it relatively closer to the public domain.

The BSD License allows proprietary commercial use, and for the software released under the license to be incorporated into proprietary commercial products. Works based on the material may be released under a proprietary license or as closed source software. This is the reason for widespread use of the BSD code in commercial products, ranging from Juniper Networks routers to Mac OS X. It is possible for something to be distributed with the BSD License and some other license to apply as well. This was in fact the case with very early versions of BSD itself, which included proprietary material from AT&T.

The typical BSD license contains 3 major clauses, allowing unlimited redistribution for any purpose as long as its copyright notices and the license’s disclaimers of warranty are maintained. The license also contains a clause restricting use of the names of contributors for endorsement of a derived work without specific permission. Older versions of the BSD license however, contained an additional but controversial clause. [1]

Bruce Montague [2]

As the last paragraph of the GPL states:

“This General Public License does not permit incorporating your program into proprietary programs.”[3]

The GPL is a complex license so here are some rules of thumb when using the GPL:

• you can charge as much as you want for distributing, supporting, or documenting the software, but you cannot sell the software itself.
• the rule-of-thumb states that if GPL source is required for a program to compile, the program must be under the GPL. Linking statically to a GPL library requires a program to be under the GPL.
• the GPL requires that any patents associated with GPLed software must be licensed for everyone’s free use.
• simply aggregating software together, as when multiple programs are put on one disk, does not count as including GPLed programs in non-GPLed programs.
• output of a program does not count as a derivative work. This enables the gcc compiler to be used in commercial environments without legal problems.
• since the Linux kernel is under the GPL, any code statically linked with the Linux kernel must be GPLed. This requirement can be circumvented by dynamically linking loadable kernel modules. This permits companies to distribute binary drivers, but often has the disadvantage that they will only work for particular versions of the Linux kernel.

Due in part to its complexity, in many parts of the world today the legalities of the GPL are being ignored in regard to Linux and related software. The long-term ramifications of this are unclear.

In contrast to the GPL, which is designed to prevent the proprietary commercialization of Open Source code, the BSD license places minimal restrictions on future behavior. This allows BSD code to remain Open Source or become integrated into commercial solutions, as a project’s or company’s needs change. In other words, the BSD license does not become a legal time-bomb at any point in the development process.

In addition, since the BSD license does not come with the legal complexity of the GPL or LGPL licenses, it allows developers and companies to spend their time creating and promoting good code rather than worrying if that code violates licensing. [2]

Most popular BSD-licenced: eMule, Azareus, FileZilla, BitTorrent, WinSCP, PDFCreator, phpMyAdmin, jpt. [4]

———–

[1] http://en.wikipedia.org/wiki/BSD_licenses

[2] http://www.freebsd.org/doc/en/articles/bsdl-gpl/article.html

[3] http://www.gnu.org/licences/gpl.html

[4] http://sourceforge.net/top/topalltime.php?type=downloads

Lugeda ja kommenteerida: Eric S. Raymond, “Kuidas saada häkkeriks” või sama asi originaalis

Detailne kirjeldus selle kohta, kuidas saada häkkeriks, samalt tüübilt, kes kirjutas loo Linuxi arendamisest “bazaari” meetodil. Jällegi huvitavalt ja hästi kirjutatud. Seekord sa see mulle ka selgeks, miks see nii on. Nimelt oli ühe punktina välja toodud, et head häkkerid peaksid õppima ka hästi kirjutama. Pigem oli muidugi mõeldud seal grammatiliselt korrektse teksti kirjutamist, aga ikkagi.

Väga lihtsalt ja selgelt oli autor välja toonud nõuanded, mida peaks jälgima inimene, kes tahab häkkeriks saada. Ilmselt on neist nõuannetest nii mõnigi selline, mida võiks jälgida isegi siis, kui ei taha otseselt häkkeriks saada. Kuigi siis pole ehk nii palju motivatsiooni selleks.

Lahe oli veel see ka, et autor oli omalt poolt ka küsimused-vastused kirja pannud neile, kel suurem huvi teema vastu. Enamus küsimusi läksid küll suht ühte auku – no et kuidas siis ikkagi häkkeriks saada, aga autor oli läbi mõnusa huumoriprisma neile kõigile siiski ka head vastused kirja pannud.

Soovitan seda artiklit kindlasti neil lugeda, kel häkkerite tegevuste ja suhtumiste osas veel kahtlusi peaks olema – see aitab häkkerite tausta kindlasti lihtsamini lahti selgitada.

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.

Vabalt valitud juhtumikirjeldus/edulugu vaba tarkvara maailmast – ~ 1-2 lk

Apache HTTP Server (ehk enamjaolt lihtsalt Apache) tundub olevat üks edukamaid projekte läbi ajaloo. Esimene versioon sai loodud Robert MaCooli poolt NCSA-s, aga ta läks 1994 keskpaigas minema ja projekt jäi pooleli. Samal ajal ringles e-mailidena suur hulk parandusettepanekuid, mida võiks teha. Brian Behlendorf, Roy T. Fielding, Rob Hartill, David Robinson, Cliff Skolnick, Randy Terbush, Robert S. Thau, Andrew Wilson moodustasid esimese Apache grupi. Esimene ametlik versioon pärast paranduste tegemist oli 0.6.2. ja avaldati 1995. aasta aprillis. Pärast seda tehti veel usinasti tööd ja viidi sisse parandusi ja Apache 1.0 avaldati 1. detsembril 1995. Grupi moodustamisest läks mööda vähem kui aasta kui server sai nr 1 serveriks internetis ja on seda tänapäevani.

10. aastat tagasi moodustati Apache Software Foundation, et serverile organisatsioonilist, legaalset ja finantsilist tuge pakkuda. Sama sihtasutuse alla kuuluvad ka paljud teised vaba tarkvara projektid.

Arendamise poolelt on moodustatud tuumik, millesse kuuluvad projekti esialgsed loojad ja aegajalt juurdevõetud eriti silmapaistvad tegelased. Tuumik juhib projekti ja lisaks neile on veel “pühendunud”, kellel on ligipääs koodi “hoidlasse” ja kes aitavad projekti ja selle dokumentatsiooni hallata. Esialgsed reeglid on tuumiku poolt määratud, aga neid võidakse projektijuhtimismeeskonna poolt ka muuta. Kõikidele on koodile ligipääs tagatud – enamusele siiski vaid lugemisõigustega. Koodimuudatused esitatakse e-maili teel ja pannakse hääletusele. Peamine suhtlusvahend ongi e-mail.

Tegijatel on suur soov, et Apachet kasutataks väga laialdaselt ja et see oleks alati tasuta kasutamiseks võimalik. Just see, et Apache tasuta saadaval on, muudab ta parimaks teiste seas, sest just nii on kasutajate ring lai ja tagasiside väga hea ja kasulik.

Apache veebilehel on lihtsalt ja mugavalt kogu vajalik informatsioon kättesaadav nii kasutajale, kes soovib toodet kasutada kui ka entusiastidele, kes soovivad oma panuse Apache arengusse anda.

Auhinnad, mille Apache on saanud ning oma veebilehele üles pannud, on küll eelmisse sajandisse jäänud, aga see ei vähenda projekti edukuse kaalu. Ka projekti toetajate nimekiri on muljetavaldav – Google, Yahoo, Microsoft ja HP, kui mainida suurimaid.

Apache on edulugu, mille sarnast ilmselt teist ei ole – 2009. aasta märtsis on Apache kasutuses 46% veebisaitidel ja 66 protsendil miljonist tihedaima liiklusega veebilehtedest (Netcrafti uuring, via Wikipedia)!

Viide: http://httpd.apache.org/

Üks kodune töö :)
Lugeda [L] S. Levy Hackersi 2 esimest peatükki ja kirjutada ajaveebi enda arvamus/hinnang.

Selle artikli lugemine lükkus muudkui edasi ja edasi. See oli mul kogu aeg arvutikotis kaasas, et sobival hetkel siis ette võtta. Ühel korral läks isegi õnneks sellest 10 lehekülge lugeda ja tõsiselt huvitav oli. Asjaolude kokkulangemise tõttu jäi aga esimese ja teise lugemise vahele liigagi pikk vahe. Mis põhimõtteliselt tähendas ainult seda, et ma siis selle esimese osa täna jälle igaks juhuks ka üle lugesin.

Artikkel oli mõnusalt positiivses toonis kirjutatud ja suhteliselt “lihtsas” keeles ka. Niiöelda jutustuse vormis on alati huvitavam sellist ajaloolist teksti lugeda, kui kuivi fakte ja igavat teooriat tuupida. Autor suutis kenasti edasi anda emotsioonid, mida need tüübid seal MIT-is läbi elasid arvutite tuleku ajal. Mulle meeldis eriti see koht, kus kirjeldati üht vimkat, mida poisid ühele valvurile viskasid. Nimelt oli IBM uhke ülikallis arvuti juurde õpilastel ligipääs keelatud ja seda valvati päris usinasti. Ükskord juhtus aga nii, et nad ilmusid valvuri juurde ühe sellise väljanägemisega jubinaga, mis justkui võis sellest suurest arvutikolakast pärit olla. Valvur oli väga šokis ja läks päris usinasti selgitusi tarvis, et ta lõpuks aru sai, et see üks nali oli, mida poisid tegid :D

Suure tõenäosusega ei oleks tänane arvutimaailm nii kaugele arenenud, kui selliseid tüüpe poleks tol ajal eksisteerinud, kes elasid artikli lõpus toodud põhimõtete järgi. Nad uurisid ja puurisid programmikoodi, kasutasid maksimaalselt ära seda aega, mis oli võimalik arvuti juures seda torkides veeta ja seeläbi arenesid ise ja aitasid ülejäänud maailmal kõvasti edasi areneda. Täiesti hull entusiasm, viitsimine, tahtmine ja tõsine huvi selle maailma vastu on tõesti hämmastamapanev.

Ilmselt üks olulisemaid asju, mida ma sellest artiklist õppisin, on see et kui varem oli mu jaoks suht selgusetu, mis vahe on häkkeril ja kräkkeril, siis pärast sellistest häkkeritest teadasaamisest on täitsa selge, et häkkerite vastu ei ole mul küll enam mitte ühtegi halba sõna öelda. Kui nad muidugi just selle häkkerieetikaga kooskõlas toimetavad :D

Lugeda läbi [L] Innovation Happens Elsewhere (kui kõike ei jõua, siis vähemalt algus ja 6. peatükk) ja kirjutada ajaveebi enda arvamus/hinnang

Kui nüüd kõik päris ausalt ära rääkida, siis tuleb tunnistada, et vaba tarkvara loomise osas ei olnud mul enne selle raamatu kättevõtmist kohe üldse mingit aimu. Ühtteist ma ilmselt oleks osanud tuletada kui jutuks kellegagi peaks see tulema, aga siis ka väga üldises plaanis. Tüübid on hästi lihtsas ja arusaadavas keeles kirja pannud nö põhitõed, mida peaks ühe vaba tarkvara projekti puhul arvesse võtma. Alustades muidugi sellest, et mis üldse kvalifitseerub selle alla, milleks selline lähenemine hea on, kuidas projekti ette valmistada ja läbi viia jne jne.

Kõik see jutt, mis sinna kirja on saanud, on täitsa loogiline ja mis mulle eriti meeldib – näidetega varustatud! Kirjeldusi on toodud erinevatest valdkondadest – Linux, Common Lisp, Turbo Pascal, Open Office, Apache ja paljud teised. Autorid on teinud põhjaliku töö ja see annab nende kirjeldatule vaid kaalu juurde.

Peatükk 6, mis kindlasti soovitati läbi lugeda, oli äärmiselt huvitav. Selles kirjeldati suhteliselt detailselt ja üksipulgi koos põhjendustega, mida peab vaba tarkvara arendamisel silmas pidama. Muidugi võib öelda, et tegelikult on need tegevused iseenesestmõistetavad ja selle jaoks nüüd siis vaja sedasorti raamatut kirjutada. Aga on vaja! Vahel on vaja ka kõige lihtsamad asjad ühte kohta kirja panna, et oleks hea võtta, näpuga järge ajada ja kontrollida, et kõik oleks tehtud. Niiöelda check-list funktsionaalsust täidab see raamat kohe kindlasti – eriti just see mainitud peatükk.

Täitsa huvitav võrdlus tuli seda lugedes pähe hoopis teisest maailmast – ühe mittetulundusühingu tegevustest, kus tegelikult paljud tegevused ju kattuvad. Ühist koodi asendavad need mitmed dokumendid, mida ühiselt Google doc’is on vaja toimetada, kogukonnaks on vabatahtlikult tegutsevad organisatsiooni liikmed, arendajateks on ühed liikmed ja kogu organisatsioon saab sellest kõigest kasu. Täitsa veider, et sellist võrdlust on isegi tuua võimalik.

Igatahes sai see raamat mu järjehoidjatesse kirja ja kui kunagi peaks vaja olema ühte head materjali vaba tarkvaraga alustamiseks, siis tean kuhupoole pöörduda.