Avoimen lähdekoodin ohjelmistokehitys
Avoimen lähdekoodin ohjelmistojen (Open Source Software, OSS) lähdekoodi on vapaasti saatavilla, jaettavissa sekä muokattavissa. Lähdekoodin vapaa muokattavuus mahdollistaa ohjelmiston käyttäjien tekemät korjaukset ja lisäykset ohjelmistoon. Kehitys on lisäksi hajautettua, eli kehittäjät voivat sijaita fyysisesti kaukana toisistaan ympäri maapalloa, jolloin kommunikointi tapahtuu pääasiallisesti internetin välityksellä. Avoimen lähdekoodin ohjelmistot ovat laadukkaita ja menestyneitä perinteiseen ohjelmistokehitykseen nähden omalaatuisesta ohjelmistokehitysmallista huolimatta. Avoimen lähdekoodin ohjelmistot ovat tämän menestyksen myötä herättäneet myös kaupallisten toimijoiden kiinnostuksen. Suosion taustalla on ohjelmistojen halpuuden ja helpon saatavuuden lisäksi niiden korkea laatu. OSS-tuotteita on käytössä laajasti useilla teollisuuden aloilla ja enenevässä määrin myös julkishallinnoissa.
Avoimen lähdekoodin ohjelmistokehitys on muuttanut menetelmiä, joilla ohjelmistoja kehitetään, ylläpidetään ja päivitetään. Suljetun lähdekoodin ohjelmistoihin kehitysmalleihin verrattuna avoimen lähdekoodin ohjelmistokehitys on tyypillisesti hyvin löyhästi organisoitua. Projekteilla ei usein ole yleistason suunnitelmaa kehitykselle tai aikataulua uusille ohjelmistoversioille. Muutoksia tehdään ad hoc -periaatteella kehittäjää kulloinkin kiinnostavaan kohtaan ohjelmistoa eikä kehittäjiä määrätä tiettyihin tehtäviin. Usein OSS-projekteilla ei ole testaussuunnitelmaa eikä testaustyökaluja käytetä. Myöskään laadunvarmistusta ei yleensä tehdä. Ongelmien löytäjillä on mahdollisuus korjata löytämänsä virhe tai puuttuva ominaisuus itse – mikäli hänellä on tarvittava tekninen osaaminen – tai vain raportoida ongelmista kehittäjille ja toivoa, että ongelma korjataan. Tässä kirjoituksessa tarkastellaan sellaisia tyypillisiä pieniä ja keskisuuria OSS-projekteja, joissa ei ole mukana kaupallista organisaatiota tai säätiötä.
Käytettävyys avoimen lähdekoodin ohjelmistokehityksessä
Käytettävyyden aseman avoimen lähdekoodin ohjelmistokehityksessä tekee ongelmalliseksi se, ettei OSS-projekteissa juuri koskaan ole mukana käytettävyyden asiantuntijoita. Avoimen lähdekoodin ohjelmistokehitys lähtee usein kehittäjien omasta tarpeesta. OSS-järjestelmien laatu nojaakin pitkälti kehittäjien ammattitaitoon, yhteistyöhön ja asiantuntemukseen kehitettävästä tuotteesta. Suljetun lähdekoodin kehityksestä poiketen OSS-projekteissa ei yleensä ole pelkän asemansa turvin suuntaa sanelevaa auktoriteettia. Kehitystyötä hallinnoidaan sen sijaan useimmiten meritokratiana; yhteisössä saatu arvostus tuo päätöksenteossa tarvittavaa arvovaltaa. Lähdekoodin omistajuus ja hyvän koodin tuoma arvovalta perustuukin oletukseen alkuperäisen kehittäjän hyvästä asiantuntemuksesta ja siten meritokraattiseen valtaan.
Käytettävyyden asema OSS-kehityksessä on kuitenkin tällä hetkellä ongelmallinen, sillä kehittäjät eivät enää vastaa tyypillisiä loppukäyttäjiä, käytettävyysammattilaiset eivät osallistu OSS projekteihin, projekteilla ei ole resursseja tehdä korkealuokkaista käytettävyystyötä ja toiminnallisuuksiin keskittyvän iteroimisen prosessit eivät välttämättä sovi käyttöliittymien iteroimiseen. Erityisesti tämä tulee ilmi, kun OSS-ohjelmistoja käyttävät yhä enemmän ei-tekniset käyttäjät, jotka eivät ole tietoteknisiltä tiedoiltaan ja taidoiltaan läheskään yhtä asiantuntevia verrattuna perinteiseen kehittäjistä koostuvaan OSS-käyttäjäkuntaan.
Menestyneiden avoimen lähdekoodin sovellusten tuoma käyttäjämäärien kasvaminen on johtanut OSS-käyttäjäkunnan laajenemiseen kehitykseen osallistuvista tehokäyttäjistä tavallisiin tietoteknisiltä taidoiltaan rajoittuneempiin peruskäyttäjiin. Kehittäjät eivät enää tee ohjelmistoa vain omaan käyttöönsä, jolloin myös taitotasoltaan normaalimpi käyttäjäkunta tulisi ottaa kehitystyössä huomioon. Taitotasoltaan normaalimpi käyttäjäkunta olettaa tuotteen toimivan ongelmitta jo heti alusta lähtien. Suurin osa OSS-tuotteiden käyttäjistä on tällaisia passiivisia, ei-teknisiä käyttäjiä, jotka eivät halua toimia enää ohjelmiston testaajina eivätkä raportoida kohtaamiaan ongelmia. Tämä asettaa korkeammat vaatimukset OSS-tuotteiden käytettävyydelle. Raportit eivät enää sisällä tarpeeksi olennaista tietoa tai ne ovat toisintoja jo raportoiduista virheistä.
Avoimen lähdekoodin kehittäjäyhteisöt toimivat hallinnollisesti tavallisesti niin sanotun sipulimallin mukaan, jossa yhteisön päätöksenteko on jakautunut eri kerroksissa toimivien henkilöiden kesken. Mitä ulompana yhteisön jäsenen asema sipulin kuorella on, sitä vähemmän hänellä on vaikutusvaltaa kehitettävää ohjelmistoa ja kehittäjäyhteisöä koskevassa päätöksenteossa. Eniten vaikutusvaltaa käyttävät sipulin ytimessä toimivat projektin vetäjät eli pääkehittäjät. Pääkehittäjistä seuraavina sipulin kerroksella ovat kehittäjät, joilla on lähdekoodiin suora luku- ja kirjoitusoikeus, mutta joiden tulee kysyä pääkehittäjiltä lupa suurempiin muutoksiin. Seuraavalla, toiseksi uloimmalla kerroksella, toimivat kehittäjät, jotka tekevät pienempiä korjauksia ja muutosehdotuksia, mutta joilla ei ole kirjoitusoikeuksia lähdekoodiin. He joutuvat hyväksyttämään muutokset vaikutusvaltaisimmilla kehittäjillä ja toivomaan, että muutokset julkaistaisiin. Vähiten vaikutusvaltaa kehittäjäyhteisössä on loppukäyttäjillä, eivätkä he yleensä aktiivisesti osallistu kehitystyöhön.
Vielä nykyäänkin käytettävyys ja käyttöliittymän suunnitteluprosessit ovat harvinaisia avoimen lähdekoodin projekteissa. Usein OSS-kehittäjät eivät tunne käytettävyyttä käsitteenä lainkaan, tai mieltävät käytettävyyden usein pelkäksi lisäominaisuudeksi, joka voidaan helposti lisätä mekaanisesti seuraavaan ohjelmistoversioon. Käytettävyyttä saatetaan usein myös virheellisesti pitää pelkästään subjektiivisena ominaisuutena tai vain käyttöliittymän ulkoasuun liittyvinä piirteinä. Käytettävyyden eri tekijöitä ei oteta huomioon tasapuolisesti varsinkaan silloin, kun kehitettävä ohjelmisto on tarkoitettu tavallisille käyttäjille. Tavalliset käyttäjät eivät yleensä osallistu avoimen lähdekoodin ohjelmistokehitykseen millään tavoin, eivätkä kehittäjät ole usein juuri kiinnostuneita ei-teknisten käyttäjien mielipiteistä. Hajautetussa ja yhteistyöllä toimivassa avoimen lähdekoodin projektissa käytettävyys muodostuu pääasiallisesti viiden tärkeän tekijän kautta: yhteistyöhenkinen ympäristö ja erilaiset työkalut vahvistavat projektin sidosryhmien välistä kommunikaatiota; hierarkkinen, tarkkaan määritelty päätöksenteko, joka helpottaa viestintää; luottamukseen perustuva suhde kehittäjien, käyttäjien ja käytettävyysasiantuntijoiden välillä; aikaisiin suunnittelupäätöksiin kykenevä aloitteentekijä ja käyttäjälähtöisen suunnittelun periaatteet hallitseva käytettävyysasiantuntija. Käytettävyyden tulisikin olla osa prosessia heti alusta alkaen, mutta OSS-projektin tullessa tunnetummaksi ja houkutellessa ei-teknisiä käyttäjiä, kehitystä on ehditty tehdä jo paljon ja käyttöliittymäratkaisut ovat syntyneet ilman suunnittelua tai käytettävyysmenetelmiä.
Käytettävyysasiantuntijat avoimen lähdekoodin ohjelmistokehityksessä
Jotta käytettävyyden asemaan voitaisiin parantaa avoimen lähdekoodin ohjelmistoissa, tulisi kehitysprojekteissa olla mukana henkilöitä, joilla on tarvittavat tiedot ja taidot käytettävyydestä. Ohjelmistokehittäjillä ei tyypillisesti kuitenkaan ole näitä tarvittavia tietoja ja taitoja, eivätkä käytettävyysasiantuntijat tavallisesti osallistu avoimen lähdekoodin ohjelmistokehitykseen. Varsinkin suurissa OSS-projekteissa osallistumaan pyrkivien käytettävyysasiantuntijoiden suurimpia haasteita on tehdä itsensä tunnetuiksi yhteisön sisällä. Tärkeimpiä tavoitteita on, että yhteisössä ymmärretään, kuinka käytettävyysasiantuntijat voivat auttaa projektissa, kouluttaa yhteisön jäseniä käytettävyydestä ja antaa palautetta ohjelman nykyisestä käytettävyydestä. Tämä on erityisen haasteellista pienissä ja keskisuurissa OSS-projekteissa, joiden kehittäjillä ei välttämättä ole mitään tietoa siitä, mitä käytettävyys on.
Avoimen lähdekoodin ohjelmistot koostuvat tavallisesti pienistä, erillään kehitettävistä osasista, joten käytettävyyteen liittyvien muutosten tekeminen voi olla haasteellista varsinkin, kun kehitystyö tehdään pääasiassa vapaaehtoisvoimin. Samaan tapaan käytettävyystoimien suunnittelu on hajautetussa ympäristössä vaikeaa puutteellisten työmenetelmien ja infrastruktuurin takia. Yksi olennaisimmista haasteista on se, että käytettävyysasiantuntijoiden on joskus vaikea ottaa osaa käytännön kehitystyöhön ja saada sitä kautta arvostusta, koska avoimen lähdekoodin kulttuurissa arvostetaan perinteisesti lähdekoodin tuottamista ansiota tuovana tekijänä. Käytettävyysasiantuntijoiden on vaikeaa saada ääntänsä kuuluviin kehittäjäyhteisöissä. Kehittäjät eivät usein tunnista, mitä arvoa käytettävyydeltään hyvä ohjelmisto tarjoaa. Yhteisössä pitäisi olla tieto siitä, mitä ylipäätään voitaisiin tehdä paremman käytettävyyden hyväksi. Yhtenä ratkaisuna voisi olla erilaisia käytettävyyttä parantavia menetelmiä sisältävä ohjeistus erityisesti OSS-kehittäjiä varten.
Avoimen lähdekoodin kehittäjäyhteisöissä kehittäjien välinen verkostoituminen ja luottamus ovat tärkeitä tekijöitä yhteisön menestymisen ja yhteisössä toimimisen kannalta. Käytettävyysasiantuntijoiden onkin vaikea saada kehittäjien luottamusta, sillä he eivät yleensä tuota OSS-kehittäjien arvostamaa lähdekoodia. Yhteisön hyväksyntä tapahtuu ajallaan, ja se vaatii yhteisön ja myös sekä kyseisen OSS-projektin historian että sen sosiaalisten käytäntöjen ymmärtämistä ja kykyä näyttää omaa osaamistaan räätälöiden omat toimintatapansa kyseiseen yhteisöön parhaiten sopiviksi. Vaikka internet mahdollistaa osallistumisen avoimen lähdekoodin projekteihin monista lähtökohdista ja taustoista huolimatta, voi erilaisten osallistujien määrä aiheuttaa haasteita suunnittelulle yhteisen näkemyksen puuttuessa. Lähes kaikki käytettävyysasiantuntijoiden avoimen lähdekoodin kehittäjien kanssa kohtaamat ongelmat johtuvat luottamuksen ja meriitin puutteesta. Käytettävyyteen liittyvät ansiot eivät välttämättä näytä niin tärkeältä muiden kehittäjien silmissä kuin algoritmisten tai koodausteknisten ongelmien ratkaiseminen. Koska kehittäjät usein vastaavat koko ohjelmiston kehittämisestä, he mieltävät koodin omakseen ja käyttöliittymään ehdotetut muutokset saattavat aiheuttaa vastustusta, vaikka ne olisivatkin käytettävyyttä parantavia. Käytettävyysasiantuntijoiden on toisaalta oltava läheisessä yhteistyössä pääkehittäjien kanssa, jotta tarvittavat käytettävyysparannukset toteutuisivat, mutta toisaalta pidettävä kuitenkin etäisyyttä, jotta riittävä objektiivisuus ja käyttäjäkeskeisyys säilyisivät. Käytettävyysasiantuntijoiden pääsy OSS-yhteisöjen tasavertaisiksi jäseniksi onkin erityisen tärkeää, mutta haastavaa. OSS-projektit tarjoavat käytettävyysasiantuntijoille ja -tutkijoille jatkossakin paljon haasteita, mutta myös ainutlaatuisen mahdollisuuden parantaa maailmaa käyttöliittymä kerrallaan.
Lähteitä
- Rajanen, M., Iivari, N. (2015) Power, Empowerment and Open Source Usability. In the Proceedings of the ACM SIGCHI Annual Conference on Human Factors in Computing Systems (CHI 2015). Seoul, South Korea. DOI: 10.1145/2702123.2702441
- Rajanen, M., Iivari, N., Keskitalo, E. (2012) Introducing Usability Activities into Open Source Software Development Projects – a Participative Approach. In Proceedings of the 7th Nordic Conference on Human-Computer Interaction (NordiCHI 2012). Copenhagen, Denmark. pp 683-692. ISBN: 978-1-4503-1482-4, DOI: 10.1145/2399016.2399120
- Rajanen, M., Iivari, N., Anttila, K. (2011). Introducing Usability Activities into Open Source Software Development Projects – Searching for a Suitable Approach. Journal of Information Technology Theory and Application (JITTA), 12(4), pp 5-26.
- Rajanen, M. (2011) Applying Usability Cost-Benefit Analysis – Explorations in Commercial and Open Source Software Development Contexts. PhD Dissertation. Acta Universitatis Ouluensis Series A 587. University of Oulu.
Mikko Rajanen, FT, työskentelee yliopisto-opettajana Oulun yliopistossa