Head-to-head: avoin lähdekoodi vs. kaupallinen ratkaisu

Oletko vannoutunut avoimen lähdekoodin kannattaja vai suositko kaupallisia tuotteita? Omaa poteroa ei kannata kaivaa liian syväksi, sillä molemmilla vaihtoehdoilla on paikkansa, kirjoittaa Tero Niemistö.

avoin-versus-kaupallinen

Janne Korhonen julkaisi taannoin Linkedinissä artikkelin, johon toivoi mm. allekirjoittaneen näkemystä. Aiheena oli avoin lähdekoodi vs. kaupallinen ratkaisu. Aiheesta on keskusteltu, ja kiistelty, IT-alalla lähes 20 vuotta. Molempien puolesta ja vastaan esitetään argumentteja, jotka eivät sisällöllisesti ole muuttuneet kovinkaan paljon vuosien saatossa.

Olen itse työskennellyt eri IT-toimittajaorganisaatioissa koko 20-vuotisen työurani ja ollut osallisena sekä nähnyt läheltä onnistuneita (ja epäonnistuneita) toimituksia sekä avoimella lähdekoodilla, että kaupallisilla ratkaisuilla. Koetan tässä blogissa jakaa kokemuksien kautta opittuja asioita tähän argumenttiin, sekä antaa oman näkemykseni siitä, kumpaa kannattaa ostaa.

Ennen analyysia on syytä kerrata pääargumentit kummankin vaihtoehdon puolesta:

Pääargumentit Kaupallisen ratkaisun puolesta:

  1. Tuki ja ylläpito.
  2. Varmuus ostamisessa. Asiakas tietää, minne lähettää reklamaatiolaskun, jos homma ei toimi. Tästä kulkee alalla myös urbaani legenda: ”kukaan IT-päällikkö, joka on ostanut IBM:ää, ei ole saanut potkuja” .

Pääargumentit Avoimen lähdekoodin puolesta:

  1. Avoin lähdekoodi on ilmainen. Tai ainakin paljon edullisempi kuin kaupallinen ratkaisu.
  2. Avoin lähdekoodi on paras keino estää toimittajaloukku, koska jatkokehityksen voi ottaa haltuunsa kuka tahansa.

Avoin lähdekoodi on riskitön, vai onko?

Äkkiseltään voisi kuvitella avoimen lähdekoodin olevan näistä se kannattavampi vaihtoehto ja näin ajattelin myös itsekin useita vuosia. Onhan se ilmainen ja lähdekoodi kenen tahansa katsottavissa, joka jo yksinään toimii vahvana laadunvarmistajana (kuka sitä spagettikoodia haluaisi julkaista koko maailmalle!). Avoin lähdekoodi ratkaisuna ei kuitenkaan ole oikotie onneen ja sisältää useita riskejä, jotka on syytä tiedostaa ennen päätöksentekoa.

Avoimen lähdekoodin ilmaisversio ei riitä

Monet avoimen lähdekoodin projekteista ovatkin itse asiassa kaupallisen yrityksen omistamia. Nämä yritykset tarjoavat ns. ”yhteisöversiota” avoimena lähdekoodina ilmaiseksi. Heidän liiketoimintamalli on kuitenkin se, että tuo yhteisöversio sisältää ominaisuuksiltaan hyvin riisutun version ratkaisusta toimien ikään kuin sisäänheittäjänä. Käykin hyvin nopeasti ilmi, että yhteisöversion ratkaisu ei riitä alkuunkaan projektin tarpeisiin vaan tarvitaan maksullinen versio, joka usein on hinnoittelultaan täysin verrattavissa mihin tahansa vastaavaan kaupalliseen versioon. Lisäongelman tuo vielä se, että usein näissä tapauksissa tuotteen tuki on heikkoa ja dokumentaation taso huono verrattuna kaupalliseen ratkaisuun.

Saastuttavat lisenssit

Tässä kohtaa yritysten kannattaa olla hyvin varuillaan. Osa avoimen lähdekoodin lisensseistä ovat hyvin ”saastuttavia” eli mikäli projekti hyödyntää kyseistä avoimen lähdekoodin komponenttia, on koko ratkaisu julkaistava avoimena lähdekoodina. Yksi tällainen lisenssi on AGPL, jolla mm. hyvin suosittua noSQL -tietokantaa MongoDB julkaistaan. Muistakin lisensseistä löytyy ongelmia, jotka on syytä selvittää tapauskohtaisesti lakiosaston kanssa. Mikäli avointa lähdekoodia haluaa käyttää, ovat kaikkein turvallisimmat lisenssit Apache 2.0 sekä MIT.

Iso yritys ostaa avoimen lähdekoodin ratkaisun

On hyvin tavallista, että iso kaupallinen yritys ostaa avoimen lähdekoodin projektin, erityisesti mikäli näkee sen kilpailijana omalle tuotteelleen. Aiemmin on nähty, että avoimen lähdekoodin projektit ovat voineet muuttua merkittävästi tällaisten ostojen jälkeen. Hyvin usein ostaneet yritykset tekevät tuotteesta aiemmin mainitun ”yhteisöversion” minimaalisilla ominaisuuksilla, ja joskus saattavat jopa kokonaan poistaa avoimen lähdekoodin version ja korvata sen ”ilmaisversiolla”, joka kuitenkin sisältää yrityksen omat käyttöehdot (jotka on syytä käydä HYVIN tarkalla kammalla läpi lakiosaston kanssa).

Avoimen lähdekoodin ehtoja tai sisältöä muutetaan

Tästä paras esimerkki viime ajoilta on Docker. Docker oli Apache 2.0 -lisenssillä julkaistu avoimen lähdekoodin konttiratkaisu. Vuosi sitten Docker muutti tuotteensa siten, että julkaisevat sitä nykyään omilla käyttöehdoillaan, joita voi muuttaa milloin tahansa ja miten tahansa. Sen lisäksi Docker on jatkuvasti karsinut ilmaisversion ominaisuuksia siirtäen niitä kaupallisiin versioihin. Samaan aikaan kaupallisen ratkaisun hinnat ovat nousseet merkittävästi viime vuoden aikana. Ei siis ihme, että Kubernetes on tällä hetkellä enemmän kehittäjien huulilla kuin Docker.

Tietoturva

Mikäli avoimen lähdekoodin tuotteella ei ole tuotetukea, on tuotteen tietoturva ja sen jatkuva ylläpito täysin tuotetta tarjoavan toimittajan vastuulla. Kaupalliset versiot tarjoavat tuotetukea tietoturvapaikkoineen. GDPR:n myötä tietoturvan merkitystä ratkaisuissa ei ole syytä vähätellä. Sen laiminlyönti on verrattavissa venäläisen ruletin pelaamiseen.

Osaaminen

Puhutaan, että avoimen lähdekoodin ratkaisu ehkäisee toimittajaloukun. Kuten Janne Korhonen artikkelissaan toteaa, ei asia ole ihan niin yksinkertainen. Spagettikoodia ei voi ylläpitää kukaan muu kuin sen luonut tiimi, ihan sama onko kyseessä avoin lähdekoodi vai kaupallinen ratkaisu.

Onko kaupallinen sitten parempi vaihtoehto?

Kun ollaan tekemässä valintaa avoimen lähdekoodin ratkaisun ja kaupallisen välillä, on lukuisia asioita, joita ostajan tulee punnita vaakakupissa. Pelkkään lisenssihintaan tuijottaminen ei todellakaan riitä. Monilta unohtuu se, että tuotteen päälle tehtävä työ ei ole ilmaista. Ostajana kehotan kiinnittämään huomiota lisenssihinnan lisäksi myös seuraaviin asioihin:

1. Kuinka nopeasti teknologia-alustan päälle saa tehtyä toteutuksia?

Tämä on yksi kriittisimpiä mittareita. Jos saman ominaisuuden tekeminen kaupallisen ratkaisun päälle on 3 kertaa nopeampaa, maksaa lisenssihinta itsensä takaisin hyvin nopeasti. Ja moninkertaisesti.

2. Teknologian oppimisnopeus

Kuinka nopeasti uudet kehittäjät kykenevät omaksumaan uuden teknologian?

3. Dokumentaation taso

Mikä on kummankin tuotteen dokumentaation taso? Kuinka ajantasoinen dokumentaatio on? Kuinka hyvin tuotteen rajapinnat on kuvattu? Onko tuotteella ylipäänsä kattavat rajapinnat vai onko se musta laatikko? Mustan laatikon hankkimista en voi suositella kuin erityistapauksissa.

4. Google Trends

Ja lopuksi vielä: vilkaise tuotteiden suosio Google Trendsin avulla. Oikeasti. Onko tuote laskeva vai nouseva? Laskevan trendin omaavat teknologiat eivät juuri koskaan ole historiallisesti palanneet nouseviksi. On toisaalta myös fakta, että ei voi mitenkään ennustaa onko nousevan trendin omaava tuote jatkamassa nousuaan vai saavuttanut juuri lakipisteensä, josta lasku alkaa.

Yhteenveto

Valinta avoimen lähdekoodin ja kaupallisen välillä ei ole yksinkertainen. On lukuisia elementtejä mitä valinnassa on syytä punnita. Hyvin yleisellä tasolla oma suositukseni on, että kaupallinen ratkaisu on useimmiten suositellumpi jos:

  • Ratkaisun elinkaari on hyvin pitkä eli ostaja haluaa mennä samalla tuotteella minimissään 5+ vuotta.
  • Ratkaisun on tarkoitus palvella lukuisia erilaisia käyttäjärooleja, joilla kaikilla eri tarpeet.
  • Ratkaisun tietoturva on laatukriteereistä se tärkein.

Avoimeen lähdekoodiin kannattaa yleensä kallistua jos:

  • Ratkaisu toteutetaan mikropalveluarkkitehtuurilla.
  • Ratkaisu toteutetaan aidolla ketterällä mallilla.
  • Ratkaisua lähdetään rakentamaan eksperimentoinnin kautta.

Nämä näkemykset ovat siis vain kokemuksen tuomia yleistyksiä, poikkeustilanteita löytyy varmasti. Hyvin usein nuo toiveet menevät keskenään ristiin, jolloin tilanne riippuu kontekstista.

Kun ratkaisu on tehty ja tuote implementoidaan käytännössä, on edessä vielä tärkein elementti mikäli ostaja haluaa välttää toimittajaloukun: arkkitehtuurin ja teknisen velan hallinta. Mikäli tuotetta käytetään arkkitehtuurillisesti oikealla tavalla ja tekninen velka pidetään jatkuvasti hallittuna, laskee toimittajaloukku merkittävästi.

Toinen avaintekijä teknisen velan lisäksi on rajapinnat. Panostus avoimiin rajapintoihin mahdollistaa jatkossa tuotteen vaihtamisen lennossa ilman mittavaa koko järjestelmän uusimista. Ilman rajapintoja järjestelmän tuotteet ovat ”naimisissa” keskenään, jolloin erosta tulee hyvin riitaisa. Huolehtikaa siis niistä rajapinnoista, ne ovat avain oikeanlaiseen arkkitehtuuriin.


Tilaa blogikirjoitukset sähköpostiisi

ohjelmistokehitys




Tero Niemistö | Tiimiesimies, teknologia-johtaja

Tero Niemistö | Tiimiesimies, teknologia-johtaja

Tero on ”managerisoitunut” pitkän linjan arkkitehti. Noin 14 teknisen vuoden jälkeen Tero siirtyi esimiesrooliin tahtonaan johtaa alan huippuasiantuntijoita kuten itseään haluaa johdettavan. ”Esimiehen tärkein tehtävä on mahdollistaa alaistensa onnistuminen”, Tero sanoo. Teron johtamisfilosofiassa esimies ei ole perinteisen hierarkisen mallin mukaisesti joukkojen yläpuolella vaan tukee heidän päivittäistä työtä alhaalta. Hän haluaa olla läsnä ja kiinnostunut alaistensa arjesta sekä tukea heitä sparraamalla ja valmentamalla niin usein kuin mahdollista. Kun Tero laittaa ns. haalarit päälle ja kädet saveen, niin hänet löytää usein julistamassa DevOps-kulttuurin ilosanomaa ja rakentamassa sovelluskehityshankkeisiin täysin automatisoitua jatkuvan julkaisun putkea.

Kirjoittajan kaikki blogitekstit

Tilaa blogikirjoitukset sähköpostiisi


Viimeisimmät kirjoitukset



Seuraa meitä somessa

LinkedIn Twitter Facebook YouTube YouTube