Open Source ja runsaudenpula

Open Source ja runsaudenpula

tammi 27, 2014 Anders Innovations

Avoimen lähdekoodin ohjelmat tarjoavat organisaatioille hienoja mahdollisuuksia. Selkeän kuvan muodostaminen tarjolla olevista vaihtoehdoista ja digitaalisten jyvien erottaminen akanoista ei aina ole aivan yksinkertaista.

Open Source on hieno konsepti ja mahdollistaa monimutkaisten projektien toteutuksen yhteisöllisesti, eikä kukaan voi kiistää, ettei avoimen lähdekoodin maailmasta löytyisi loistavia toteutuksia lähestulkoon jokaiseen tarpeeseen. Haasteet alkavat, jos halutaan rakentaa ympäristö useammasta Open Source -komponentista, joiden pitäisi toimia hyvin yhteen ja palvella tarkoitustaan pitkälle tulevaisuuteen. Kun toivottujen toimintojen lista on ensin kasattu ja yleinen arkkitehtuuri piirretty auki, voidaan siirtyä valitsemaan varsinaisia palasia.

Ensimmäinen vaihe arvioinnissa on monesti lähteä hakemaan verkosta potentiaalisia tuotteita, sopivilla hakusanoilla ja tarkistaa olisiko joku jo aikaisemmin tehnyt vastaavaa. Pikainen haku antaakin tuloksia tyyliin "10 Free Open Source  Tools that Kick Ass". Hienoa! Joku on jo käynyt aikaisemmin läpi vastaavaa tapausta ja kirjoittanut ylös omia kokemuksiaan. Varsin usein kyseessä on kuitenkin vain listaus kyseiseen aihealueeseen liittyvistä palveluista, lyhyellä kuvauksella.

Blogin kommenteista voi lukea satunnaisten käyttäjien omia kokemuksia listatuista tuotteista. Näistä suurin osa on kuitenkin kommentteja tietyn tuotteen tiettyihin ominaisuuksiin, eikä kirjoittaja ole välttämättä tutustunut muihin kuin omassa organisaatiossaan käytössä olevaan pakettiin. Kommentteja, joiden kirjoittaja on tarkasti tutustunut useampiin tuotteisiin, tulee vastaan valitettavasti harvemmin.

Enterprise vs. Community

Kun alustava lista potentiaalisista tuotteista on tehty ja on aika aloittaa tarkempi tarkastelu, käy selväksi, että selkeän kuvan muodostaminen ei olekaan aivan niin helppoa. Nopeasti tulee huomatuksi myös se, että monet tuotteet onkin itse asiassa jaettu kahteen eri osaan – maksulliseen "Enterprise Editioniin" ja maksuttomaan "Community Editioniin". Alkuperäinen kymmenen tuotteen lista on voitu tässä vaiheessa karsia viiteen sopivimpaan vaihtoehtoon, mutta nyt päädytään takaisin lähtötilanteeseen. Seuraavaksi pitää arvioida, miten Community- ja Enterprise-versiot eroavat toisistaan.

Seuraavaksi tarkistuslistalla on se, kuinka aktiivisesti kutakin projektia on viime aikoina kehitetty. Todennäköisesti haku, joka alun perin tehtiin, on antanut ainakin osittain linkkejä ja arvosteluja vanhoihin projekteihin. Pahimmillaan niihin ei ole kommitoitu yhtään riviä viimeiseen pariin vuoteen. Tai vaihtoehtoisesti huomaa, että kyseinen yhteisö on ollut niin ahkera, että projekti on forkattu pariin uuteen kehityshaaraan, jolloin joudut arvioimaan kuinka kypsä uusi haara on verrattuna alkuperäiseen.

Kun viimein lista on karsiutunut kahteen tai kolmeen parhaaseen vaihtoehtoon, on edessä varsinainen työ. Kaikki arviointiin valitut tuotteet pitäisi asentaa ja testata. Pelkkään asennukseen saa todennäköisesti kulumaan useammankin rattoisan hetken, dokumentaatio kun tunnetusti on se jokaisen avoimen lähdekoodin projektin vahvin puoli. Tämän jälkeen valittuja tuotteita pitäisi myös opetella käyttämään, ainakin auttavasti, jotta pystyy muodostamaan itse käsityksen tuotteiden käytössä olevista ominaisuuksista. Jossain välissä pitäisi pystyä myös hahmottamaan, minkälaiset API:t kussakin ratkaisuun vaadittavassa tuotteessa on ja miten niitä voi käyttää hyödyksi toimintojen laajentamisessa.

Itse tekeminen ei ole itsetarkoitus

Kuten huomataan, niin aluksi yksinkertaiselta tuntuva tuotevalinta paisuu nopeasti, kuin pullataikina ja työmäärä räjähtävät helposti käsiin.

Omassa tapauksessani kun työnä on koota yrityksen infran ylläpitoon tarvittavaa työkalusettiä, on komponenttien määrä varsin suuri. Hyvään lopputulokseen ei riitä, että valitsee näennäisesti parhaat yksittäiset tuotteet, vaan pitää pystyä arvioimaan, miten helposti tuotteet voidaan integroida toisiinsa – tai jo olemassa oleviin järjestelmiin. Valintakriteerinä ei voi myöskään olla tuotteen monipuolisuus, vaan myös helppokäyttöisyys näyttelee merkittävää roolia, jottei kokonaisuuden hahmottaminen ja hallinta jäisi vain yhden henkilön taakse.

Itse pyrin tukeutumaan valintoja tehdessä mahdollisimman pitkälle valitun käyttöjärjestelmäversion mukana tuleviin ohjelmistopaketteihin. Vaikka pakettien löytyminen käyttöjärjestelmän omista perusrepoista ei olekaan mikään lopullinen helpotus, voin kuitenkin olla suhteellisen varma, että joku muukin on projektia arvioinut, koska kyseinen ohjelma on distribuutioon valittu mukaan. Varmaa on myös, että esimerkiksi tietoturvapäivitykset löytyvät automaattisesti, ilman että itse joutuu kahlaamaan läpi projektifoorumeita.

Kokemukseni mukaan lähestulkoon kaiken voi tehdä, jos niin haluaa. Purkalla saa kasaan yllättävän hienojakin kokonaisuuksia. Kaiken tekeminen itse mielestäni ei kuitenkaan saa olla itsetarkoitus, vaan tässä kohtaa vertauskuvallisesti Volvo vie monesti voiton Ferrarista. Ei se Volvo ehkä ole niin hieno, eikä se kulje aivan yhtä lujaa, mutta voit olla varma, että se kestää kulutusta. Ja kun se menee rikki, siihen löytyy takuuvarmasti helposti varaosia.

Kirjoittaja työskentelee Solutions Architectina Anders Innolla.