Avoimen lähdekoodin kompastuskiviä
Avoimen lähdekoodin kehitys puhuttaa taas. Toronton Yliopiston opiskelija ja tutkija, Michelle Levesque on listannut artikkelissaan Fundamental issues with open source software development (via ./) viisi keskeistä asiaa, jotka hänen mielestään jarruttavat avoimen lähdekoodin yleistymistä arkikäytössä. Levesquen mielestä näihin lukeutuu 1. Käyttöliittymät, 2. Dokumentaatio, 3. Ominaisuuksien lisäämiseen keskittyvä kehitys, 4. Itselle tekeminen ja 5. "Uskonnollinen sokeus".
Juttu liittyy samaan aiheeseen, jota olen pureskellut täälläkin jo ainakin pariin otteeseen. Käyttöliittymien merkitystä ja suunnittelun vaikeutta on jo puitu moneen otteeseen aikaisemminkin, mutta artikkelin muut väitteet ovat mielenkiintoisia. Dokumentaation puutettakin olen muutamaan otteeseen kritisoinut, etenkin siinä valossa, että avoimen lähdekoodin dokumenteissa käyttäjän yleensä odotetaan osaavan esimerkiksi kääntää ohjelma ajettavaan muotoon tai muokata asetustiedostoja käsin. Suurin osa käyttäjistä ei kuitenkaan edes tiedä mitä kääntäminen tarkoittaa, joten ongelma on tässä mielessä aivan ilmeinen. Ei ole myöskään järkevä olettaa käyttäjän etsivän ohjelman käyttöön apua uutisryhmistä tai netin keskustelufoorumeilta jos saman asian voi kirjoittaa käyttöoppaaseen.
Ominaisuuksien lisäämiseen keskittyvän kehityksen osalta rohkenen olla hieman eri mieltä Levesquen kanssa. Kokemukseni mukaan avoimen lähdekoodin projektit jakaantuvat tässä mielessä kahteen tai useampaan leiriin: osa on hyvinkin tarkkoja uusien ominaisuuksien lisäämisestä, toisissa projekteissa taas ei juuri muuta tehdäkään kuin lisätään ominaisuuksia ominaisuuksien perään.
Käyttäjän kannalta tilanne on siinä mielessä ongelmallinen, että monesti pitäisi osata valita suuresta joukosta se itselle sopivin vaihtoehto. Saattaa olla vaikeaa löytää sellaista ohjelmaa, jossa olisi juuri tarvittavat ominaisuudet eikä mitään ylimääräistä. Useimmiten jotain jää kuitenkin pienemmistä projekteista puuttumaan ja silloin turvaudutaan suurempiin ohjelmiin, mutta käytetään niiden ominaisuuksista vain pientä osaa. Tästä hyvänä esimerkkinä OpenOffice.org, josta en itse tarvitse käytännössä kuin Writer-ohjelmaa, ja siitäkin vain murto-osaa sen ominaisuuksista. OOo on kuitenkin kaikkine ominaisuuksineen niin raskas softa, että tiedän ihmisiä jotka ovat asentaneet sen koneelleen, mutta käyttävät silti MS Officea, koska se on paljon nopeampi ja helppokäyttöisempi. Tässä suhteessa olen kirjoittajan kanssa samaa mieltä: ohjelmistoihin pitäisi kehittää vain ominaisuuksia joita todella tarvitaan, eikä ominaisuuksia mitä olisi "kiva olla".
Artikkelin neljättä argumenttia en näe kovinkaan pahana ilmiönä avoimen lähdekoodin leviämisen tai yleisen hyväksynnän kannalta. Useimmat avoimen lähdekoodin projektithan lähtevät nimenomaan vaihtoehtojen etsimisestä ja luomisesta. Jollain on aluksi halu ja kyky tehdä ohjelma, joka tyydyttäisi jonkun tarpeen paremmin kuin nykyiset vaihtoehdot. Kun ohjelma on tehty ja julkaistu avoimen lähdekoodin alla, sitä voidaan alkaa kehittämään myös muille sopivaksi mikäli suurempi joukko osaavia ihmisiä kiinnostuu sen kehittämisestä. Nörteiltä nörteille -ongelma on olemassa aina kun ajateltu kohdeyleisö ei ole riittävän hyvin selvillä, mutta nähdäkseni suuri osa avoimen lähdekoodin pienemmistä projekteista on tarkoitettu nimenomaan tiettyjen spesifien tehtävien ratkomiseen, eli tällöin kohdeyleisönkin voi olettaa ymmärtävän ojhelman toimintaa ainakin jonkin verran. Isompien projektien kanssa tätä ongelmaa ei voi ratkaista kuin huomioimalla mahdollisimman paljon käyttäjien "mitä tämä tarkoittaa"-kommentteja ja pyrkimällä sekä käyttöliittymässä että dokumentaatiossa mahdollisimman yleistajuiseen sanastoon välttäen teknisiä termejä ja huonoja analogioita.
Viimeinen väittämä, "uskonnollinen sokeus", on erittäin voimakasta etenkin monissa Linux-projekteissa. Kompastun itsekin tähän monesti -- jonkun gurun idea tai tekele on aina automaattisesti parempi kuin erilainen malli, eikä muuta edes hyväksytä. Haluaisin mielelläni nähdä vaikkapa KDE ja Gnome -projektien ottavan tosissaan oppia esimerkiksi Mac OS X:n ja Windows XP:n käyttöliittymien parhaista puolista ja apinoimalla niitä ennemmin kuin kehittämällä omia variaatioita, jotka eivät ole läheskään niin hyviä. Apinoimisella en tässä yhteydessä tarkoita toimintojen suoraviivaista kopioimista vaan ajatuksella adoptoimista niin, että ne sulautuisivat olemassaolevaan järjestelmään mahdollisimman hyvin. Niinhän se menee, että "Good artist copies, great artist steals".
Utu — Kuulumisia yliopistolta
© Ville Säävuori
