Avoin koodi julkisissa hankinnoissa

Kirjoitin oheisen tekstin Voiman avoin koodi-liitteeseen (Voima 6/2010, Heinä-elokuu). Samaisessa liitteessä tekstejä mm. Tomi Toiviolta (joka kasasi jutut ja kirjoitti suurimman osan nimettömistä artikkeleista, kaikki kunnia hänelle), Mjr:ltä, Kemppiseltä ja ties keneltä. Kemppisen teksti on tajunnanvirtaa ohi aiheen, mutta kannattaa lukea, jos saa liitteen käsiinsä.

Oma tekeleeni tuntuu nyt suoraan sanottuna hiukan raskaalta ja kömpelöltä. Jotenkin julkaiseminen paperilla "pakotti" tylsän viralliseen asiatekstilajiin ilman itseironiaa ja vihjailua, ja yleisön aliarviointi sitten taas kömpelöön ilmaisuun. No, onneksi liitteen taitto ja painojälki oli sen verran huonoa, ettei tekstiä siitä jaksa kukaan lukea.

Aiempia kirjoituksiani aiheesta tämän linkin takana


------------------------------------------

Avoin koodi julkisissa hankinnoissa

Avoimen koodin käytöstä julkisella sektorilla on puhuttu jo pitkään. Yleensä ajatellaan vain olemassa olevien ohjelmien, kuten Linuxin ja OpenOfficen käyttöä kouluissa ja virastoissa. Avoimen koodin lisenssit voivat kuitenkin hyödyttää julkista sektoria toisellakin tavalla, julkiselle tahoille kehitetyissä ja räätälöidyissä järjestelmissä.

Ohjelmistojen ostaminen on ammattilaisillekin vaikeaa. Vaatimukset ovat monimutkaisia, eivätkä yleensä täysin tunnettuja, vaihtoehdot eivät ole vertailukelpoisia ja laatu parhaimmillaankin vaihtelevaa. Julkisiin ostoihin tuo lisävaikeutensa hankintalain tiukat säädökset
kilpailutuksesta ja ostoprosessista. Ei ole mikään ihme, että IT-hankintojen ongelmia puidaan säännöllisesti eduskuntaa myöten. Tunnetuimpia ovat terveydenhuoltoalan järjestelmäongelmat, mutta samoja ongelmia esiintyy kaikkialla muuallakin. Seurauksena julkiset tietojärjestelmät ovat yleensä raskaita ylläpitää ja muokata, sekä vaikeita käyttää. Avoin koodi voi auttaa tässä kolmella tavalla.

Ensimmäinen ongelma: Alkuperäisen järjestelmän tehnyt yritys omistaa siihen oikeuksia, tai ainakin ei-julkista tietotaitoa. ohjelmiston toimittajan vaihtaminen on todella kallista, ja monopolimyyjän hinnoittelu sen mukaista. Näin ollen järjestelmän parannukset ja varsinkin yhteensopivuusmuutokset jäävät usein tekemättä.

Ratkaisu: Jos tietojärjestelmien koodi olisi avointa, kuka tahansa voisi tehdä integrointityön, eikä riippuvuutta pääsisi syntymään. Osa avoimuuden hyödystä saadaan jo sillä, että koodi on ostajan vapaasti käytettävissä. Ostajalla ei kuitenkaan usein ole omaa osaamista koodin tutkimiseen, jolloin täysi avoimuus on hyödyllisempää.

Toinen ongelma: Vanhoihin järjestelmiin on yleensä raskasta integroida uusia osia, koska niitä ei ole suunniteltu sitä varten, eikä integroijilla ole usein pääsyä muuttamaan vanhaa järjestelmää yhteensopivammaksi.

Ratkaisu: Jos järjestelmien koodi olisi vapaata, integrointityö voitaisiin kohdistaa sinne, missä se on tarkoituksenmukaisinta tehdä. Myös vaihtoehtojen tutkiminen ja ratkaisujen testaaminen olisi oleellisesti helpompaa.

Kolmas ongelma: Julkisten ohjelmistohankintojen prosessit ovat yleensä raskaita, ja niihin osallistuminen on pienille yrityksille erittäin vaikeaa. Yksi syy tähän on, että hankeet kytkeytyvät yleensä vanhoihin järjestelmiin, ja tämän integraation vaatimaa työmäärää on erittäin
vaikea arvioida.

Ratkaisu: Jos hankkeeseen liittyvien järjestelmien lähdekoodi olisi tarjoajien saatavilla, pienemmätkin yritykset voisivat arvioida, onko niillä realistisia mahdollisuuksia suoriutua hankkeesta esimerkiksi kymmenesosalla perinteisen tarjoajan kustannuksista.

Lisäksi avoimuudesta syntyisi vahva verkostovaikutus. Jos vaikka Tampereen yliopistollinen sairaala on hankkinut hyvän potilastietojärjestelmän, miksei Helsingin yliopistollinen sairaala
saisi ottaa sitä käyttöön myös? Miksi heidän pitäisi tuottaa omansa? Tai jos HYKS haluaa tehdä omansa, ainakin TAYSiltä voisi omaksua rajapinnat ja soveltuvat osat. Yhden kunnan tai sairaanhoitopiirin säästö ei ole toiselta pois, päin vastoin.

Tulisi siis säätää laki, jonka mukaan kaikki julkisille tahoille tehtävät uudet ohjelmistot tulee julkaista avoimen lähdekoodin lisenssillä, esimerkiksi Creative Commons cc-by-sa:lla. Ratkaisu pitää tehdä lailla, koska hankintaprosesseja yleensä konsultteina valmistelevat suuret IT-talot tuskin ovat kiinnostuneita sahaamaan omaa oksaansa. Eivätkä yksittäiset ostajatkaan välttämättä ymmärrä, miksi avoimuus hyödyttä heitä, vaikka ensimmäisen oston hinta nousisikin.

Yhteiskunnan kannalta julkisen sektorin koodin avoimuudella on useita etuja, eikä juurikaan haittoja. Moraaliselta kannalta voidaan myös kysyä, miksi meidän kaikkien verovaroilla ostettu ohjelmisto ei olisi meidän kaikkien vapaassa käytössä?

9 thoughts on “Avoin koodi julkisissa hankinnoissa”

  1. No mikä ettei open sourcea, mutta minusta nuo mainitsemasi ongelmat on kyllä dokumentointiongelmia. Se ei paljon lohduta että koodi on saatavilla jos ei siitä saa mitään tolkkua.

    Tuo toimittajariippuvaisuus on semmoinen ongelma jonka kanssa tapellaan jatkuvasti. Jotta toimittaja voi vaihtaa jouhevasti niin asiakkaalla pitää olla dokumentaatio (ml. prosessit, ei pelkkä softa) hyvässä kunnossa, samoin omaa osaamista. Se riippuvuus ei minusta niinkään synny omistussuhteista vaan ihan vaan sitä että toimittaja tuntee asiakkaan, ja tämä on toisaalta positiivinenkin asia.

    Itse olen haistellut että inhouse koodaus tekee paluuta vaikkei sitä siksi ehkä kutsutakaan, pointti on että toimittajaketjun hallinta on jopa vaikeampaa kuin ohjelmistoprojektin hallinta, eli miksei saman tien tee itse… Ja kaikki vanha on taas uutta.

  2. Teemu: viimekätinen dokumentaatio on aina koodi itse, mikään muu dokumentaatio ei koskaan voi korvata sitä, vaikka toki paremmasta dokumentoinnista voisi usein olla hyötyä.

    Toki siitä, että tilaajalla on itsellään varmistetut oikeudet koodiin ja kunnollinen dokumentaatio, on jo paljon hyötyä. Mutta sillä ei saada sitä hyötyä, että toiset julkiset tahot (tai miksei yksityisetkin) voivat käyttää jo tehtyjä ratkaisuja osina tulevissa. Eikä myöskään sitä hyötyä, että potentiaaliset tarjoajat voivat perehtyä systeemiin omaksi ilokseen ilman (raskasta) tarjouskilpailuprosessia ja miettiä sitten, voisivatko tarjota jotain.

    Eli en näe, että dokumentointi yksi riittäisi, eikä edes dokumentointi + hyvin tehdyt sopimukset. Avoimuuskaan ei tietenkään riitä yksin, mutta se olisi nähdäkseni merkittävä askel oikeaan suuntaan.

  3. Suomenkielistä avoimen lähdekoodin dokumentaatiotahan tarjoaa esimerkiksi FLOSS Manuals: http://fi.flossmanuals.net/lue

    FLOSS Manualsiin kaivataan edelleenkin kovasti kirjoittajia: wikiä on jo nykyisellä tarjonnalla täysin mahdotonta pitää ajan tasalla ilman jonkinlaista Wikipedia-efektiä, jossa ihmiset tekevät päivityksiä, korjauksia ja lisäyksiä huomatessaan ne tarpeelliseksi.

    Tietenkin FLOSS Manuals tarjoilee nykyisellään dokumentaatiota lähinnä loppukäyttäjille, ei niinkään ylläpitäjille tai kehittäjille. Mikään ei kuitenkaan estä käyttämästä FLOSS Manualsia mihin tahansa avoimen lähdekoodin dokumentaatioprojektiin.

    Nimenomaan se asenne, että loppukäyttäjän pitäisi lukea koodia on ollut eräänä suurena syynä FLOSS Manualsin perustamiseen. 🙂

    Avoin Koodi -liite meni mielestäni pilalle taittovirheiden ja anonyymien artikkelien vuoksi. Erittäin turhauttavaa.

  4. liite on näemmä saatu vihdoin nettiin, http://www.scribd.com/doc/35830754/Avoin-Koodi.

    Tomi: ei se siitä taitosta pilalle ole mennyt, vaikka kyllä siinä parantamisen varaa tosiaan oli. Paperilehden liite ei ehkä vaan muutenkaan ole se paras mahdollinen media vapaan koodin käsittelyyn.

    FLOSS manualsin suurin ongelma on hampaidenhoitoon viittaava nimi. FLOSS-termiä käytetään vain akateemisessa tutkimuksessa, ei missään muualla.

  5. Tuossa kommenttikentän alla näyttäisi olevan ”tilaa sähköpostitse” -linkki. En tiedä kuinka hyvin se toimii, mutta kannattanee kokeilla.

    Sen lisäksi uusimmat 6 kommenttia näkyvät oikeassa sivupalkissa, että voi katsoa mistä on uutta keksustelua. Valitettavasti plugari ei näytä niiden artikkelia tai aikaleimaa.

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *