Gemilo Oy

Avoin lähdekoodi ei tarkoita ilmaista tai automaattisesti hyvää

Katri Lietsala // Avoin lähdekoodi ei ole sama asia kuin hyvä, toimiva palvelu automaagisesti. Se ei ole synonyymi ilmaiselle, halvalle tai rahan säästämiselle. Avoimuus ei takaa, että avointa lähdekoodia kehittäviä toimijoita olisi tarpeeksi kehittämässä valittua ratkaistua tai että avoin lähdekoodi olisi vaivatta ja järkevin kustannuksin käytettävissä uuteen käyttötarkoitukseen ilman poikkeuksia (reusability).

Entäpä avoimen lähdekoodin tietoturva-aukot? Niin ihana kuin ajatus kaikkien yhdessä tuumin kehittämästä koodista on, mahtuu joukkoon aina niitä, jotka joko vahingossa tai tahallaan aiheuttavat haavoittuvaisuuksia järjestelmään. Kehittäjän tulee avoimen lähdekoodin osalta tukkia paitsi varsinaisesta järjestelmästä, myös sen liitännäisistä mahdolliset tietoturva-aukot. Liitännäistä saattaa tehdä kehittäjä-kollegaani lainatakseni “pari jamppaa“, jotka aikansa pulattuaan saattavat jättää työn niikseen, koska joku muuhan sen voi sitten korjata – avointa, kun on.

Ei silti. Minä pidän avoimesta koodista, älkää käsittäkö väärin. Meidän järjestelmämme toimivat Linuxilla, hyödynnämme Pythonin avoimen lähdekoodin komponentteja, toiminnassa on  myös memcached, Shibboleth ja LAMP-ympäristö. Wysiwyg-editori on avointa koodia sekin. Maailmassa on paljon hienoja avoimen lähdekoodin toteutuksia. Silti Gemilon teknologia (Gemilo Platform) ei ole avointa.

Koodi ja käyttöliittymä hienoine ominaisuuksineen on meidän kilpailuetumme isoja jättejä vastaan. Se on meidän itse tekemää, omilla resursseilla. Toki asiakkaiden rahoituksella, mutta vastineeksi asiakkaat ovat saaneet sen, mitä pyysivät ja mistä maksoivat. Jos meiltä ostetaan järjestelmän käyttöoikeuksia ja toteutuksia, tuetaan suomalaista työtä ja suomalaista yritystä. Missä kohtaa tästä tuli jotenkin väärää ja sellaista, mitä julkishallinnossa pitäisi välttää?

Joonas Pekkanen (Avoin ministeriö) ehdottaa [korjaus 16.4.2012 ehdotus on Joonaksen eikä Avoimen ministeriön kanta], että julkishallinnon hankkimien ohjelmistojen tulisi olla avointa koodia. Pidän tärkeämpänä vapaata kilpailua kuin että lakiin kirjoitettaisiin julkishallinnolle pakoksi käyttää avointa lähdekoodia. Avoimessa lähdekoodissa on välillä filosofinen/poliittinen eetos, joka joskus muistuttaa melkein uskonnollista vakaumusta.

Sen sijaan, että tuijotetaan, onko ratkaisu avointa lähdekoodia vai ei, kannattaisi katsoa tarkemmin, miten paljon kuluu aikaa ja sitä kautta resursseja:

  • toimituksen kokoonpanoon,
  • käytön oppimiseen,
  • ratkaisun soveltamiseen
  • laajennettavuuteen
  • sekä tilaajalta itseltään että tekijöiltä.

Lisäksi on se kaikista tärkein mittari: Toimiiko palvelu, kuten halutaan ja täyttääkö ne toiminnalliset tavoitteet, joita sille on asetettu? Joko heti tai kehittämistyön jälkeen. Jos täyttää ja on budjetin mukainen, niin kannattaa tilata, olipa avointa tai suljettua koodia.

Joskus avoin lähdekoodi voi olla hyvinkin edullinen ja toimiva ratkaisu, mutta on myös tapauksia, joissa väitän, että julkishallinto olisi säästänyt pitkän pennin ottamalla valmiin ratkaisun, joka on suljettua koodia, mutta toimii ja olisi ollut valmiina ajat sitten.

Be Sociable, Share!

7 kommenttia viestiin “Avoin lähdekoodi ei tarkoita ilmaista tai automaattisesti hyvää”

  1. Joonas Pekkanen:

    Tärkeitä pointteja Katri. Tarkennuksena vain, että kenellekään ei jää väärinkäsitystä: ehdotus Islannin mallisesta avoimen lähdekoodin ensisijaisuudesta julkisissa it-hankinnoissa on omani – EI siis Avoimen Ministeriön ehdotus. Kaikki avoinministerio.fi-palvelussa esitetyt ideat ovat kirjoittajien omia ehdotuksia, sillä Avoin Ministeriö ei (tyypillisesti eikä tähän menessä) ole ottanut organisaationa kantaa yksittäisiin ehdotuksiin. ;)

  2. Joonas Pekkanen:

    Tässä vielä linkki ehdotukseeni avoinministerio.fi:ssä:

    http://www.avoinministerio.fi/ideat/julkisten-it-hankintojen-pitaisi-olla-lahtokohtaisesti-avointa-lahdekoodia

    Sivulle voi jättää puolesta ja vastaan kommentteja. Ajatushan on, että ideat jalostuvat kommenttien ja keskustelun myötä yhdessä työstäen. Voihan olla, että päädymme siihen, ettei Suomessa ole järkeä lähteä Islannin tielle?

  3. Tarmo Toikkanen:

    Pääongelma suljetuissa ohjelmistohankinnoissa on ns. “vendor lock-in”. Jos toimittaja myöhemmin nostaa tukipalvelujensa hintaa tai vaikka päättää tuotteen tuen lopettamisesta, ei asiakkaalla ole mitään vaihtoehtoja. Avoimen lähdekoodin ohjelmistojen osalta asiakas voi tehdä ylläpitosopimuksen niin pitkäksi aikaa kuin haluaa ja tarvittaessa vaihtaa toimittajaa.

    Suljetun lähdekoodinkin projektit voidaan tehdä ilman vendor-lukkoa, kun sopimukseen kirjoitetaan selvästi ne ehdot, joiden mukaisesti (ja millä hinnalla) tukea ja jatkokehitystä tulevaisuudessa tarjotaan, ja että jos toimittaja ei tähän kykene, on asiakkaalla oikeus hankkia toinen toimittaja tuotetta tukemaan. Tähän tilanteeseen tietenkin kuuluu jonkinlaisen lähdekooditason lisenssin siirtyminen asiakkaalle. Ongelma vain on, että mistään muualta kuin alkuperäiseltä suljetun lähdekoodin tekijältä tuskin löytyy intoa antaa tukea tällaiseen tuntemattomaan järjestelmään. Sen sijaan avoimeen lähdekoodiin perustuvissa yleisissä ratkaisuissa on todellinen kilpailumahdollisuus.

  4. Katri Lietsala:

    Tarmo, mihin perustat väitteen: “tuskin löytyy intoa”? Totta kai on intoa, jos löytyy rahaa, tilaaja ja on koodaustaitoa, jota tarjota. Niinhän markkinat toimivat: jos on ostaja, on yleensä aina myös joku, joka myy ja toimittaa. Asiakas ja asiakkaan tarpeet sekä asiakkaan resurssit rahoittaa tilattu työ varmasti vaikuttavat motivaatioon, haluaako jatkaa kehitystyötä vai ei.

    Minusta asiakkaiden kannattaisi keskittyä palveluiden jatkokehittämiseen, ei koodin tilaamiseen, sillä ohjelmointikieletkin kehittyvät, saattavat ajan myötä jopa vaihtua toiseksi. Siinä vielä yksi liikkuva osa lisää.

    Avointa ja suljettua pitäisi tarkastella toimivuuden näkökulmasta ja verrata, mitä palvelut maksavat. Väitän, että avoin lähdekoodi ei suinkaan ole edullisin ratkaisu eikä välttämättä edes paras, mutta ikävä kyllä osa valitsee sen enemmän aatteellisten syiden kuin todellisten konkreettisten etujen vuoksi. Osassa kilpailutuksiahan ei ole edes tehty vertailua suljettuihin järjestelmiin. Miten silloin voitaisiin tietää, oliko avoin todellakin niin hyvää, kun sitä ei ole kriittisesti verrattu muihin?

  5. Jaakko Salonen:

    Olen Katrin kanssa hyvin samoilla linjoilla.

    Mielestäni on täysin päätöntä vaatia, että julkisten IT-hankintojen pitäisi olla lähtökohtaisesti avointa lähdekoodia. Vaatimus on mielestäni verrattavissa siihen, että vaadittaisiin lähtökohtaisesti kaikkia valtion virkamiehiä käyttämään viestinnässä sinetöityjä kirjekuoria. Teknologia on lähtökohtaisesti työväline, joka pitää valita tarvelähtöisesti — rajaus avoimeen lähdekoodiin jättää valintojen ulkopuolelle monia potentiaalisesti tehokkaampia välineitä.

    Myöskään islannin mallissa avointa lähdekoodia ei tarkastella vaatimuksena. Ilmaisen ja avoimen lähdekoodin hyödyntäminen ilmenee kirjauksessa ainoastaan yhtenä mahdollisena keinona vendor lock-in:n torjumiseen.

    Avointa lähdekoodia tärkeämpiä ovat ehdottomasti järjestelmiin tallennettavan tiedon avoimuus ja järjestelmien käyttämien standardien avoimuus.

  6. Mika Tapojärvi:

    Katri:

    > Avoin lähdekoodi ei ole sama asia kuin hyvä, toimiva palvelu automaagisesti. Se ei ole synonyymi ilmaiselle, halvalle tai rahan säästämiselle.

    Ei, kuten ei suljettu vastinekkaan.

    > Avoimuus ei takaa, että avointa lähdekoodia kehittäviä toimijoita olisi tarpeeksi kehittämässä valittua ratkaistua tai että avoin lähdekoodi olisi vaivatta ja järkevin kustannuksin käytettävissä uuteen käyttötarkoitukseen ilman poikkeuksia (reusability).

    Ei tuotakaan, mutta toki myös avoimen softan ratkaisujen valinnassakin pitäisi jonkinlaista maalaisjärkeä soveltaa. Jos sovelletaan, ja sieltä puolelta aitaa fiksu ratkaisu löytyy, niin siihen fiksuuteen silloin on sisältynyt myös se, että ratkaisussa on joko riittävästi joukkovoimaa kehittäjäyhteisössä takana tai löytynyt sovellus on kohtuullisesti ylläpidettävissä ja kehitettävissä käyttäjän toimesta. Ei tämä nyt aivan rakettitekniikkaa ole, ja “järkevä kustannus” on yhtä tilannespesifinen määritelmä sekä avoimelle että suljetulle softalle. Väittäisin kyllä kuitenkin oman kokemukseni perusteella, että helpompi on hyvinkin moni avoimen softan sovellus löytää ja sovittaa uusiinkin tilanteisiin verrattuna yhden vendorin suljettuu ratkaisuun. Your mileage may vary.

    > Liitännäistä saattaa tehdä kehittäjä-kollegaani lainatakseni “pari jamppaa“, jotka aikansa pulattuaan saattavat jättää työn niikseen, koska joku muuhan sen voi sitten korjata – avointa, kun on.

    Kollegallesi suosittelisin, että ellei sitä sitten ole valmis tosiaan itse kehittämään, niin a) katselee paremman pluginin – it’s free (as in “freedom”) b) ottaa yhteyttä jamppoihin ja tekee ehdotuksen, josta ei voi kieltäytyä. On täysin väärin väittää, että free/open source software (FOSS) -maailmasta ei löydy kontaktipistettä tai tukea, tai toisaalta että jokainen FOSS-projekti on samanlainen kehityksen ryhdikkyyden tai laadun kannalta.

    a) > Ei silti. Minä pidän avoimesta koodista, älkää käsittäkö väärin.

    …ja…

    b) > Avoimessa lähdekoodissa on välillä filosofinen/poliittinen eetos, joka joskus muistuttaa melkein uskonnollista vakaumusta.

    a) Hienoa, b) Kyllä, ja sinä tunnut olevan vielä hieman heikko uskossasi. Free softwaren filosofista pointtia tuskin kannattaa edes yrittää kieltää: esim. softa on käytettävämpää myös oppimateriaalina, tai sitä voi halutessaan itse muuttaa, jos se ei toimi, niinkuin haluat. Kun minä lapsilleni opetan ohjelmointia ja haluan esim. näyttää, miten jokin softalla tehty platform hommaansa hoitaa, niin voinko minä käyttää siihen Gemilo Platformia?

    Poliittinen osuus tulee sitten varmaan siitä, että käytetäänkö niitä yhteisiä rahoja siten, että niillä rahoilla aikaansaatu hyöty on a) suljetun softan suljetussa piirissä ja pahimmillaan ehkä vaan yhdessä sovelluskohteessa vai b) avoimessa ympäristössä, ja jopa yksityisten ihmisten omaa elämää tai pienten yritysten kivista polkua tukemassa?

    Kumpaanko sinä suomalaisten rahat pistäisit – noin kategorisesti?

  7. Katri Lietsala:

    Mika, yritin nimenomaan sanoa, että vältettäisiin uskon kysymyksiä, kun tilataan palveluja. Jos olen siis mielestäsi “heikko uskossani”, niin se on oikein hyvä asia. Vastauksena kysymykseesi, ostaisinko suljettua vai avointa, mielestäni olen jo vastannut tähän blogipostauksessa, mutta selvennetään vielä, kun erikseen kysytään. Laittaisin suomalaisena rahani sellaiseen palveluun, joka a) toimii, b) vastaa niitä tarpeita, joita tilaaja on toiminnanmäärittelyssään katsonut tarvitsevansa ja c) jotka toivon mukaan ovat myös niitä toiminnallisuuksia, joista on oikeasti loppukäyttäjille hyötyä. Tarkistaisin tilaajana, mikä toimittajien järjestelmistä vastaa parhaiten tarpeeseen ja missä on edullisimmat kulut. Huom! Näitä kahta – toimivuutta ja taloudellisuutta – katsoisin siis rinnakkain.

    Kuten itsekin kommentissasi toit esiin: ““järkevä kustannus” on yhtä tilannespesifinen määritelmä sekä avoimelle että suljetulle softalle”. Kiitos kiteytyksestä. Olen kanssasi tästä samaa mieltä.

    Jos paras ratkaisu olisi avoin lähdekoodi, ottaisin sen. Jos paras ratkaisu olisi suljettu lähdekoodi, ottaisin sen. Pitäisin kilpailun reiluna eli hankinta kilpailutettaisiin ottamatta kantaa, onko järjestelmän koodi suljettua vai avointa. En edes listaisi järjestelmää tarjouspyynnössä, koska hankintaa tekevänä en voisi tietää, onko markkinoilla mahdollisesti jotain uutta ja vielä parempaa jo tarjolla kuin ne järjestelmät, joista olen itse jotain kautta saanut kuulla – tai joita tietohallinto mahdollisesti “pakottaa” valitsemaan jostain tietystää tuoteperheestä. En laittaisi lakia, jossa rajattaisiin järjestelmiä ulos vain siksi, että koodi on suljettua. Eikö avoimen koodin pitäisi kaikessa joukon voimassaan pärjätä upeasti ilman sellaista lakiakin – sentään kaikilla mahdollisuus kehittää eteenpäin, kuten mainoslause kuuluu..

    Käytämme Gemilossa ohjelmointikieliä, joita voi kuka tahansa opiskella, jos vain haluaa. Ei se ole mitään salatiedettä, vaikka järjestelmän koodi itsessään onkin suljettua. Pythonin ja pylonsin pystyy siis opettamaan lapsilleen tai itselleen hienosti ilman Gemilon koodiakin! Tosin luulen, että on pedagogisesti järkevämpää antaa lapsen ensin opetella koodauksen ja tietoarkkitehtuurin alkeet kuin katsoa, miten Gemilo platform on koodattu. Ihan siksikin, että meillä järjestelmää koodaavat diplomi-insinöörit, joilla on usean vuoden ammattiosaaminen koulutuksensa lisäksi. Olisi aikamoinen märkä pyyhe paitsi työntekijöilleni, myös teknisen yliopiston suuntaan väittää, että samaan pystyisi kuka tahansa. Kiitos kuitenkin ajatuksesta, että joku haluaisi lapselleen opettaa nimenomaan minun yritykseni koodilla, miten järjestelmät toimivat tai miten koodataan. Uudet työntekijämme ovat kohtuullisen nopeasti omaksuneet kyllä, miten järjestelmää kehitetään, joten ei sitä tarvitse lapsesta asti opetella. Onneksi sentään.

    Gemilon platform ja sen koodi on kehitetty yrittäjän riskillä, jotta voimme helpottaa työpaikkojen ja koulujen arkea, työllistää ihmisiä Suomessa ja toivottavasti jopa jonain kauniina päivänä hyötyä myös yrityksen omistajina rahallisesti siitä, että tästä tarinasta tulee jotain vielä isompaa. Kilpailuetumme on tarjota sellaista, mitä muilla ei ole. En keksi millä muulla sen voisi suojata kuin suljetulla koodilla tilanteessa, jossa pienenä yrityksenä kilpailemme varsin isojen toimittajien kanssa samoilla markkinoilla.

    Mitä tulee pienten yritysten kivisiin polkuihin: Vaikka järjestelmämme koodi on suljettu, helpotamme oikein mielellämme myös pienten yritysten arkea. Gemilon järjestelmä mahdollistaa edullisen tavan hoitaa esimerkiksi tehtävä- ja projektihallinnan, dokumentit ja sisäisen viestinnän samassa järjestelmässä pienin kuluin. Ota yhteyttä minuun, niin kerron lisää. Mitä tulee omaan yritykseeni, kiviä on polulla ihan riittämiin ilman, että valtio vielä lailla vaikeuttaisi yritystoimintaa.

Kommentoi