Kusagil on innovatsiooni

"Innovation Happens Elsewhere" ( Ron Goldman & Richard P. Gabriel ) on raamat mis kirjeldab seda kuidas luua ja organiseerida vabavara projekte alates ideest , tarkvara arendusest ja oma kogukonna loomisest kuni küpse toote kasvatamiseni. Antakse rida juhtnööre ja kokkuvõtteid maailma praktikast, mis on osutunud edukaks.

Olenemata sellest, kas tegemist on kommertskasutusega tarkvaraga või vabavara projektiga, on edu saavutamise kriteeriumid suures plaanis sarnased. Henry Chesbrough (Open Innovation: The New Imperative for Creating and Profiting from Technology), andmetel on traditsiooniline strateegia uue tehnoloogia loomiseks ja selle kasumiks vormimiseks baseeruv AT&T/Bell printsiipidel: a) taga see et sinu heaks töötavad parimad inimesed b) loo uusi lahendusi ja turusta need esimesena, esimesena turule viija saab võidu eelise c) kontrolli oma intellektuaalset kapitali , et keegi teine ei saaks varbale astuda astuda sarnase asjaga.

Vabavara projektid on saanud ka oluliseks osaks maailma suurimate kompaniide arendustegevuses. Juba 2002. aastal tegi Berlecon Research uuringu Euroopa Komisjoni jaoks, kus leiti et maailma 25-st suuremast tarkvara firmast osales 8 firmat suuremal või väiksemal määral open source tarkvara arendusega. Sellisteks firmadeks olid näiteks IBM, HP, SAP, Hitachi ja Sun. Uuring tehti firmade avalike pressiteadete põhjal nii et võib arvata et tegelik vabavara kasutamine firmade poolt on veelgi suurem ja on aja jooksul kasvanud.

Neljandas peatükis kirjeldatakse raamatus seda, miks üldse vabavara projekte kasutusele võetakse. Üldiselt on põhjused miks inimesed tarkvara projektidega tegelema hakkavad järgmised: 1) tarkvara mida arendatakse aitab nendel tööd paremini teha 2) nad saavad arenduses kaasa rääkida 3) nad saavad muuta koodi ja kohandada seda enda vajaduste jaoks 4) nad saavad teiste kasutajatega suhelda ja õppida teistelt kasutajatelt 5) nad saavad osaleda lahedas projektis.

Üheks olulisemaks osaks projekti kasvatamisel ja edu saavutamisel on kogukonna ( community loomine). Üldiselt võib öelda, et mida rohkem projekt ergutab osalejaid omavahel suhtlema teiste kogukonna liikmetega, seda rohkem saab kogu projekt asjast kasu. Võtmekoht vabavara projektides on see et arendusprotsess peab olema tõeliselt avatud. Kõik arendajad nii siseringis kui välised, peaksid saama ligipääsu koodile ja saama võimaluse osaleda diskussioonides ja otsustes arhitektuuri osas.

Põhiline nõue open-source projekti arendustegevusele on see, et open-source kood oleks avalikult kättesaadav. Iga arendaja, kas siseringis või väljaspool – peaks omama võimalust saada ligi viimasele versioonile koodist. Arendaja, kes on kogu mooduli valmimise eest vastutav – mooduli omanik – peaks saama teha muudatusi otse koodis.
Need osalejad, kes teevad ettepanekuid bugide likvideerimiseks ja kellele veel ei ole antud täit ligipääsu lähtekoodile, peaksid saama jooksvalt ligipääsu arhiivile. Juurde arendused koodile peaksid toimuma tihedalt ( igapäevaselt kui võimalik ) ja need peaks olema alla laaditavad nii arendajatele kui ka kasutajatele. Tavaliselt hoitakse ka kättesaadavana üks viimaseid vanemaid stabiilseid versioone, selleks et kasutajad saaksid endale igal juhul alla laadida kindalt töötava versiooni.

Mõttekas on luua wish-listid kogu projekti jaoks, kuhu kogutakse soovid ja ideed arendajatele, kes otsivad uusi asju mida arendada. Ka wish-listide loomine ise ergutab kasutajaid omavahel suhtlema ja arenduses osalema. Väga oluline on kaasata arenduse protsessi ka lõppkasutajad kui soovitakse et projekt oleks tõeliselt edukas. Lisaks on vaja ka dokumentatsiooni. See võib alguse saada ka meili listidest ja sellest FAQ koostamisest.

Kui projekt on juba küpsenud ja sellele on tekkinud kogukond siis 8. peatükk kirjeldab seda kuidas projekti esialgset edu hoida ja isegi edasi viia. Räägitakse seda, kuidas professionaalselt projekti turundada ja edasi viia. Enne kui projekt tuleb avalikkuse ette tuleks luua huvitav lugu, mis kirjeldaks sinu projekti ja mis erutaks mingil moel inimesi. Story peaks olema ligitõmbav ühtaegu nii kasutajatena kui potensiaalsete arendajatena. Kui lugu ei ole mõjuv, siis inimesed ei ole huvitatud ja ei hakka aktiivseteks osalejateks. Oluline on lahti kirjutada oma tegevuse mudel ehk ärimudel, mis äratab usaldust ja kasutajad teavad millega nad kokku puutuvad.

Lisaks muule tuuakse ka välja , milline peaks olema ühe vabavara projekti kodulehekülg. Väiksemate projekti puhul peaks kodulehel olema kirjas vähemalt alljärgnevad asjad:

- projekti kirjeldus ja eesmärgid
- ligipääs selleks et saaks alla laadida viimase versiooni tarkvarast, viimased uuendused
- selgitused selle kohta kuidas uued liitujad saaksid projektis osaleda
- tuua välja viimased projektiga seotud uudised
- näidata kuidas saab liituda meililistiga ja kuidas otsida arhiivist varasemaid postitusi
- tutuvstada võtme arendajaid ja kuidas nendega ühendust saab võtta

Suuremate projektide puhul võiks kodulehel olla veel: juhendid ja näited toote kasutamise kohta, dokumentatsioon kasutajate jaoks, dokumentatsioon arendajate jaoks, ligipääs koodi varasematele versioonidele, kuidas hallata bugisid andmebaasis, FAQ küsimused projekti kohta, iga mooduli kirjeldused, lingid projektiga seotud kommertslahendustele.

Kommentaariks võiks öelda et kuigi juriidiliselt ja omandisuhete poolest on open-source ja kommertstarkvara loomine erinevad, siis arenduse protsessi osas on nad pigem sarnased kui erinevad. Edu kriteeriumid tehniliselt kvaliteetse toote arenduseks ja selle toote jaoks kasutajaskonna/klientuuri loomiseks on vägagi sarnased. Kuna tänapäeval osalevad ka globaalsed firmad vaba tarkvara arendustöödes ja osadel vabavara projektidel on ka kommertsalustel pakutavad lisamoodulid, siis võiks arvata et piir kommertstarkvara ja vabavara arendamise vahel on aina hägustumas.