Perjantaina 20.1.2017

Miksi edes pohtia, valitseeko avoimen vai suljetun lähdekoodin julkaisujärjestelmän?

Viime vuoden puolella kirjoitin vastineen avoimen lähdekoodin WordPressiä ja suljetun koodin ProcessWireä vertailevalle blogaukselle. Tällöin keskityin lähinnä kumoamaan vääriä väittämiä sekä olettamuksia WordPressistä. Tällä kertaa aion kirjoittaa yleisemmin avoimen ja suljetun lähdekoodin järjestelmien eroista, kumoten Whitestonen blogissa esitettyjä väittämiä sekä tuomalla niihin toista näkökulmaa. On toki syytä muistaa, että Whitestonen päätuote on toteutukset heidän oman […]

Tämä kirjoitus saattaa sisältää vanhentunutta tietoa, sillä se on julkaistu yli 7 vuotta sitten.

Viime vuoden puolella kirjoitin vastineen avoimen lähdekoodin WordPressiä ja suljetun koodin ProcessWireä vertailevalle blogaukselle. Tällöin keskityin lähinnä kumoamaan vääriä väittämiä sekä olettamuksia WordPressistä.

Tällä kertaa aion kirjoittaa yleisemmin avoimen ja suljetun lähdekoodin järjestelmien eroista, kumoten Whitestonen blogissa esitettyjä väittämiä sekä tuomalla niihin toista näkökulmaa. On toki syytä muistaa, että Whitestonen päätuote on toteutukset heidän oman suljetun järjestelmän päälle ja Duden päätuote taasen laadukkaasti toteutetut sivustot sekä verkkokaupat avoimen WordPressin päälle.

Yleisesti lienee syytä sanoa, että mielestäni suljetun lähdekoodin järjestelmiä pitäisi välttää mahdollisuuksien mukaan kuin ruttoa.

Suljetun lähdekoodin järjestelmän kanssa olet toimittajalukossa, ja voin kertoa että se lukko ei tunnu hyvälle. Olet poikkeuksetta täysin riippuvainen järjestelmän toimittajasta ja hänen tahtotilastaan kyseisen järjestelmän kanssa. Usein myös maksat siitä että asioita ei kehitetä jatkuvasti, vaan järjestelmää käytetään pelkästään rahantekokoneena kalliiden lisenssi- ja/tai tukimaksujen ”ansiosta”.

Kaikkihan tuntee surullisen kuuluisat Tiedon, Accenturen ja muiden vastaavien isojen toimijoiden epäonnistuneet ja kustannuksiltaan kohonneet suljettujen järjestelmien projektit. Avoimen lähdekoodin järjestelmien kanssa näitä ongelmia on hyvin harvoin.

Sitten sukelletaan väittämiin joihin on jotain sanomista, pitäkää penkeistänne kiinni.

Suljetun lähdekoodin keskeisimmiksi eduiksi listattiin mm.

Tietoturvariskien ja muiden haavoittuvuuksien hallitseminen johtuen juuri siitä, että lähdekoodi ei ole avoin kaikille tutkittavaksi.

Ei pidä laisinkaan paikkaansa. Suurin osa järjestelmien haavoittuvuuksista löydetään, vaikka lähdekoodista ei ole nähty pätkääkään. Järjestelmissä on aina erilaisia rajapintoja ja muita liikkuvia osia, joita sinnikkäästi tai onnekkaasti kokeilemalla löytää toisinaan helpostikkin haavoittuvuuden.

Koska ihminen on erehtyväinen, jokaiseen järjestelmään jää luonnollisesti aina haavoittuvuuksia ja tietoturvariskejä. Sen takia ei tule liiaksi tarkastella kuinka paljon niitä löytyy, vaan kuinka niiltä pyritään välttymään ja miten toimitaan kun sellainen löydetään tai raportoidaan.

Uskallan väittää, että avoimen lähdekoodin järjestelmissä on vähemmän haavoittuvuuksia ja tietoturvaongelmia kuin suljetuissa järjestelmissä – ja juurikin koska lähdekoodi on kaikkien tutkittavissa. Tämän ansioista kymmenet, ellei sadat, silmät käy lähdekoodia läpi jo testausvaiheessa ja iso joukko huomaa mahdolliset riskit todennäköisemmin. Suljetun järjestelmän koodia saattaa pahimmillaan käydä läpi yhdet silmät. Eikä ole muuten kerta tai kaksi, kun olen kuullut tutuiltani heidän löytäneen vakavan haavoittuvuuden suljetusta koodista ja kehittämisestä vastaavan yrityksen painaneen asian villaisella. Toisinaan jopa yli puolen vuoden jatkuvan haavoittuvuudesta muistuttelun jälkeen.

Avoimen lähdekoodin järjestelmään jääneet haavoittuvuudet huomataan myös suuremmalla todennäköisyydellä, koska käyttäjä- ja kehittäjäkunta on suurempi. Löydetyt haavoittuvuudet tulee myös korjatuksi nopeammin, koska se ei ole kiinni kenenkään työajan riittävyydestä ja mukana on useampi kehittäjä tekemässä korjausta samanaikaisesti.

Tiivis kumppanuus järjestelmätoimittajan kanssa, yhdessä asetetut pitkän ja lyhyen matkan tavoitteet. Palvelun räätälöinti ja toteuttaminen asiakkaan yksilöllisten toiveiden sekä tarpeiden mukaisesti.

Ohjelmistolisenssiin kuuluu virallinen palvelun ylläpito ja muut tukipalvelut.

Avoimen lähdekoodin järjestelmä ei sulje mitään näistä pois, vaan usein jopa mahdollistaa ne paremmin. Toteutus avoimella koodilla ei tarkoita sitä, että lopputulos hylätään projektin valmistumisen jälkeen. Esimerkiksi me Dudella teemme jatkuvasti tiivistä yhteistyötä asiakkaittemme kanssa sivustojen sekä verkkokauppojen jatkokehityksen suhteen. Tarjoamamme ylläpito näkyy harvoin asiakkaalle, sillä kaikki tapahtuu taustalla automaattisesti meidän toimesta. Asiakkaan tarvitessa tukea, vastaamme 90% tapauksista alle puolessa tunnissa.

Räätälöinti ja jatkokehittäminen voi olla suljetussa järjestelmssä hyvinkin hankalaa, jos alkuperäistä koodipohjaa kehittäessä ei ole otettu huomioon tulevaisuuden laajennustarpeita. Harmillisen usein ei ole otettu ja tällöin kustannukset voivat nousta suuremmiksi kuin räätälöinnillä ja jatkokehittämisellä saavutetut edut. Suljetut järjestelmät on usein sidottu myös sitä kehittävän yrityksen palvelininfrastuktuuriin, jolloin huonosta ympäristöstä johtuvan järjestelmän hitauden sekä kaatuilun korjaaminen on hidasta tai jopa olematonta. Avoimen koodin järjestelmän voi siirtää huonolta palveluntarjoajalta toiselle täysin vapaasti.

Suljetun lähdekoodin järjestelmiä toimittavien yritysten asiakaspalvelusta en sano muuta, kuin totean sen olevan usein ala-arvoista. Huonolla tuurilla saat Postiltakin parempaa palvelua.

Avoimen lähdekoodin haasteina nähtiin mm.

Omat tai kolmannen osapuolen järjestelmään tekemät muutokset, jotka aiheuttavat palvelun toimimattomuutta tai aiheuttavat tietoturvariskin.

Täysin sama ongelma on suljetun lähdekoodin järjestelmissä. Ihminen on jälleen erehtyväinen, ja suljetun järjestelmän koodaaja voi källätä rikkoen koko järjestelmän tai huomaamattaan tehdä uuden haavoittuvuuden toteuttaessa uutta ominaisuutta. Oikeastaan asia mikä tässä ratkaisee, on yrityksessä työskentelevien kehittäjien ammattitaito – täysin riippumatta siitä onko lähdekoodi avointa vai suljettua.

Kolmannen osapuolen tekemät muutokset testataan luonnollisesti aina kehitysympäristössä, juurikin sen takia että asiakkaan varsinaista järjestelmää ei hajoteta toimimattomaksi. Jos kehitysympäristössä tulee ongelmia kolmannen osapuolen muutosten takia, ratkaistaan ne joko muuttamalla omaa koodia, tekemällä korjaava fork kolmannen osapuolen koodista sekä raportoimalla ongelma sen kehittäjälle. Ongelma ei pääse missään vaiheessa heijastuman asiakkaalla käytössä olevaan järjestelmään.

Avoimen lähdekoodin mahdollistamat haavoittuvuudet/tietoturvariskit ja niiden aiheuttamat mahdolliset lisä- ja/tai ylläpitokustannukset.

Edellä mainitsemistani syistä, avoimen lähdekoodin järjestelmässä haavoittuvuudet ja riskit on todennäköisesti korjattu jo ennen kuin asiakas edes kuulee niistä. Mikä on hyvä asia – se kertoo korjaamisen nopeudesta. Koska lähdekoodi on kaikkien vapaasti käytettävissä, saa nuo yhteisön tekemät korjaukset käyttöönsä täysin ilmaiseksi. Nimenomaan suljetuissa järjestelmissä päivityksistä voi joutua maksamaan, riippuen toimittajan kanssa tehdystä sopimuksesta.

Avoimen lähdekoodin palvelun kehityksen loppuminen, palvelun suosion, kiinnostuksen tai tekijöiden siirtyessä muualle.

Jos avoimen lähdekoodin järjestelmän kehitys loppuu, voit jatkaa sitä itse – vaikka todennäköisesti järjestelmän suuresta yhteisöstä nousee useampikin henkilö tekemään sitä eikä sinun tarvitse. Suljetun lähdekoodin järjestelmän kanssa olet suoraan sanottuna kusessa, jos sit kehittävä yritys menee konkurssiin tai päättää keskittyä toisen suljetun järjestelmän kehittämiseen. Silloin joudut vaihtamaan koko järjestelmän uuteen, mikä on raskas ja kallis projekti.

Palvelun versioiden yhteensopivuus edellisten versioiden kanssa, koska kehitys on helposti suosion perusteella ohjautunutta.

Varsinkin suosituimmissa avoimen lähdekoodin järjestelmissä versioiden taaksepäin yhteensopivuutta pidetään suuressa arvossa. WordPressin historiasta tulee mieleeni ainoastaan muutama tapaus, jolloin taaksepäin yhteensopivuus on jouduttu hajoittamaan tietoisesti – tällöinkin muutoksista on kerrottu hyvissä ajoin ja isosti, jotta kehittäjillä on aika valmistautua muutokseen. Suljetun koodin järjestelmissä esimeriksi integraatiorajapinnat voivat muuttua mielivaltaisesti lyhyelläkin varoitusajalla ilman varoitusta kehittäjille, tällä voi olla vaikutusta esimerkiksi verkkokaupan maksuväylien toimivuuteen.

Maksulliset lisä- ja tukipalvelut.

On ne lisä- ja tukipalvelut maksullisia suljetunkin koodin järjestelmissä, usein jopa kalliimpia. Yritykset jotka markkinoivat suljettua järjestelmää lisä- ja tukimaksuttomana, ovat leiponeet kyseiset kustannukset kalliisiin lisenssi- ja/tai kuukausimaksuihin.

Sitä paitsi, usein avoimen lähdekoodin järjestelmillä on hyvin aktiivinen yhteisö josta voi saada neuvoa ja tukea etenkin pienemmissä asioissa. Esimeriksi WordPressillä on lukuisia yhteisön ylläpitämiä kanavia tuen tarjoamiseen.

Loppukaneettina todettakoon, että avoin lähdekoodi voitti taistelun jo aikapäiviä sitten.