Kirjoitin artikkelin kuukausi sitten reaktiona mielipidepalstoilla ja blogeissa käytyyn ohjelmistojen immateriaalioikeuksista käytyyn keskusteluun. Kuten usein käy, kirjoitus jäi luonnosten sekaan eikä ehtinyt julki. Itse keskustelu on käyty siis tovi sitten mutta asia ei vanhene. Päin vastoin: pienenä vastakaneettina juuri äsken tuli tietooni, että tästä eteenpäin Helsinki julkaisee ostamansa ohjelmakoodin avoimena lähdekoodina, ellei perustellusta syystä toisin kannata tehdä.

Maaliskuussa kaksi ohjelmistoyritysten edustajaa esittivät Helsingin sanomissa huolestuneen kannanottonsa siitä, että ohjelmistojen oikeuksien antaminen asiakkaalle tekisi ohjelmistobisneksestä kannattamatonta ja ajaisi yrityksiä konkurssiin. Tähän julkaistiin myöhemmin mm. Codenton ja Vincitin vastine, jossa nämä yritykset kertoivat, ettei heille ole koskaan ollut taloudellista haittaa oikeuksien antamisesta eteenpäin.

Ajatus siitä, että ohjelmiston ostajalla ei olisi oikeuksia sovellukseen, on hyvin vanhakantainen. Se perustuu ehkä enemmän käsitykseen ohjelmistosta hyödykkeenä, päivittäistavarakaupan tuotteena kuin ohjelmistojen todelliseen hankintatapaan. Edelleenkin on toki mahdollista ostaa itselleen monta hienoa ohjelmistoa ja peliä – Photoshop, Civilization V tai Halo, näin muutamia mainitakseni. Julkisella puolella vastaava saattaa olla vaikkapa suun terveydenhuollon valmisohjelmisto. Nämä valmisohjelmat, vaikka vaatisivatkin pientä räätälöintiä, ovat kuitenkin eri asia kuin suurin osa tilaustyönä ostetuista ohjelmistoista.

Ohjelmiston hankinta ei ole aivan yksinkertainen ongelma. Tämä on havaittu karvaasti julkisella puolella, mutta ei ohjelmistojen hankinta ole aivan putkeen usein mennyt myöskään yksityisellä sektorilla. Jälkimmäisistä mokista vain ei puhuta niin paljoa. Käyttäjätarpeita on hyvin erilaisia, ja vaikka tavoitteena olisikin löytää toimiva valmisohjelmisto, yhtään monimutkaisempaan tai erikoistuneempaan toimintaan on hyvin vaikea löytää valmisohjelmistoa.

Useimmissa tapauksissa paperilla hyvältä vaikuttanutkin valmisohjelmisto on osoittautunut sudeksi, minkä olen saanut työurani aikana usein kokea – vaikkapa silloin, kun yritykseni on palkattu tekemään sutta korvaava räätälöity ohjelma. Ohjelmiston hankkimista voisi rajatuilta osin ehkä verrata talon tekemiseen – kun maasto on vaikeaa ja tarpeet epätyypilliset, edes pakettitalosta ei ole iloa. On parempi palkata kerralla kunnollinen arkkitehti ja ottaa asiakkaan tarpeet ja toiveet alusta pitäen huomioon.

Ohjelmistoista tekee talonrakennusprosessia monimutkaisemman se, että toisin kuin talo, ne eivät ole oikeastaan koskaan kerralla valmiita. Arkkitehdin rakennuspiirustukset ovat talolle se viimeinen sana, mutta ohjelmistonkehityksessä ne ovat vasta lähtölaukaus. Muutostarpeita ilmenee koko elinkaaren ajan, ja erityisesti liiketoiminnalle kriittisistä sovelluksista tulee saada myös ulos dataa sekä saada eri järjestelmät keskustelemaan toistensa kanssa. Näitä tarpeita ei voi aina ennakoida, ja liiketoiminnan muuttuessa myös sovelluksen tulee voida reagoida muutoksiin.

Tästä päästäänkin sovelluksen pullonkaulaan. Jos olet rakentanut talon, lisäsiiven tekeminen tai kylpyhuoneen remontointi on suhteellisen yksinkertaista. Urakoitsijan ei tarvitse olla sama joka talon on rakentanut, ja hinta- ja aikatauluarvioita pystyy vertaamaan järkevästi toisiinsa. Vanhalta rakennuttajalta ei tarvitse kysellä lupaa siihen, voisiko alkuperäiset kasarinsiniset kaakelit jo mahdollisesti rapsutella pois.

Ohjelmistoissa näin ei ole. Toimittajaloukku on todellinen uhka, joka tarkoittaa, että lisäominaisuuksia ei voi tilata toiselta toimittajalta tai dataa ei saadakaan siirtymään vanhasta sovelluksesta uuteen, joka haluttaisiin saada saumattomasti liittymään muihin sovelluksiin.

Hesarin mielipidevastineessaan Otso Kivekäs puolusti erityisesti ohjelmistojen lähdekoodin avoimuutta. Helsinki onkin ottanut nyt ison askelen, kun valtuustossa on tehty periaatepäätös siitä, että tulevaisuudessa tilattavien ohjelmistojen lähdekoodin pitää olla lähtökohtaisesti avointa. Tärkeintä tietysti on, että immateriaalioikeudet ovat tilaajalla, jolloin toimittajaa voidaan tarvittaessa vaihtaa. Avoin lähdekoodi vie tämän jo askeleen pidemmälle: vaikka avoin lähdekoodi ei sinänsä estäkään ohjelmiston tuotteistusta ja erilaisia lisenssivariaatioita, lähtökohtaisesti koodi on paitsi kenen tahansa luettavissa myös käytettävissä.

Pelkkä ohjelmiston avoimuus ei kuitenkaan ratkaise kaikkia ongelmia. Julkisella puolella se pakottaisi muuttamaan hankintakäytäntöjä, mikä itsessään jo olisi merkittävä parannus. Jos joissain tilanteissa päädyttäisiin tilaamaan valmistohjelmisto, näiden lisenssit eivät ole yleensä avointa. Tällaisten tuotteiden puolesta puhumisena voi myös Helsingin sanomissa julkaistun mielipidekirjotuksen lukea. Mikäli varsinainen ”pelikenttä”, tilaajan toimintaympäristö, perustuu modulaariseen rakenteeseen, ei toki haittaa, jos joukossa on myös ns. off-the-shelf -tuotteita tai räätälöityjä valmisohjelmia. Käytännössä kuitenkaan suurin osa näistä tapauksista, joissa immateriaalioikeudet pysyvät tekijällä, eivät ole edes tuotteistettavissa tai niitä ei oikeasti tuotteisteta.

Olennaisinta kuitenkin on

1) saada varsinainen omistusoikeus sekä tuotteeseen että lähdekoodiin tilaajalle,

2) pilkkoa ongelmat ja tarpeet niin että järjestelmät voi rakentaa modulaarisista osista sekä

3) taata kommunikaatio ja datan liikkuminen ohjelmien välillä eli avoimet rajapinnat.

Nykyisellään nämä ovat usein mahdottomia tai kalliita: kun ohjelmiston oikeudet ovat tekijällä, koodi suljettu ja sovellus monoliittinen, vaikkapa potilastietojärjestelmään kytkeytymiseen vaadittavasta hyvin yksinkertaisesta tiedonsiirtorajapinnasta voidaan veloittaa kuusinumeroisia summia. Ylläpidostakin saadaan sievoiset rahat, kun kilpailijaa ei käytännössä ole.

Muistuttaisin, että immateriaalioikeuden omistajuus ja lähdekoodin avoimuuskaan eivät kuitenkaan vielä poista toimittajaloukkua. Usein ohjelmiston tekijällä on paras tieto siitä, miten se toimii ja dokumentoimattomaan ohjelmistoon voi olla vaikea lähteä uuden tekijän kylmiltään tekemään muokkauksia. Kuitenkin jo pelkkä tieto siitä, että ohjelmiston uudelleen kilpailutus on mahdollinen, muokkaa tekijöidenkin pelikenttää ja sitä, miten peliä oikeastaan pelataan suuntaan, jossa asiakkaalla on entistä paremmat mahdollisuudet saada rahoilleen hyvää vastinetta.

Nykyisellä työnantajallani olemme lähes poikkeuksetta antaneet sovelluksen oikeudet asiakkaallemme. Poikkeukset ovat yleensä sellaisia, joissa koko sovellus on tehty avoimena lähdekoodina ja annettu asiakkaan toiveesta vapaaseen käyttöön. Meille tämä on luonnollinen ja järkevä tapa toimia: emme ole tuotetalo vaan ohjelmistokonsulttitalo, jossa reiluus niin työntekijöitä kuin asiakkaita kohtaan on myös yrityksen kantava voima.

Tämä reiluus ei ole estänyt Futuricea olemasta yksi Suomen parhaiten kannattavia ohjelmistokonsulttitaloja. Päin vastoin, se on epäilemättä ollut yksi tekijä kannattavuuden luomisessa. Asiakkaamme voivat luottaa siihen, ettemme tee halvalla sutta ja sen jälkeen lypsä heitä vuosikausia kriittisillä bugikorjauksilla. Tarjoamme totta kai täyden elinkaaren palvelun, mutta se on konkreettista jatkokehitystä ja viilausta, ei tuloksen kiskomista keskeneräisestä liian halvalla tehdystä ohjelmistosta.

Loppuun voisikin vastata Hesarin kirjoituksessa esitettyyn väitteeseen: Voiko konsulttitalon tulos painua pakkaselle, jos se alkaisikin luovuttaa immateriaalioikeudet asiakkailleen?

Uskallan väittää, että kyllä, näin voi käydä. Mutta vain siinä tapauksessa, että yrityksen koko bisnes perustuu näiden oikeuksien hallintaan ja niillä kikkailuun.