Moni myy avointa koodia, mutta ei ole itse valmis sitä jakamaan

Avoimesta koodista on tullut iso juttu IT-alalle, ja vaikka erilaiset saas-tuotteet nostavatkin päätään, on tulevaisuus avoimen koodin johtaville tuotteille varmasti ruusuinen. Esimerkiksi web-alalla ei ole mitään merkkejä siihen suuntaan, että WordPressin ja Drupalin valta-asemat olennaisesti heiluisivat.

Siksi on myös syntynyt paljon toimistoja, jotka vannovat avoimen koodin ohjelmistojen nimeen, ja aktiivisesti myyvät asiakkailleen nimenomaan avoimen koodin ohjelmistojen tuomia etuja. Yleensä puhutaan esimerkiksi jaetun koodin paremmasta laadusta, toimittajariippumattomuudesta, isosta ekosysteemistä ja laajojen käyttäjäkuntien testauksen tuomista eduista. Moni WordPressillä tai Drupalilla tekevä toimisto myös ylpeänä korostaa sitä todellisuutta, että kyse on aidoista avoimen lähdekoodin projekteista, eli kyse ei ole mistään kokeiluversioista tai jonkun kaupallisen kokonaisuuden pienestä osasta – eli asiakkaat saavat aidosti käyttöönsä hyvän järjestelmän ilman vahvaa sidosta kehenkään.

Ylpeistä lähtökohdista huolimatta, etenkin WordPress-markkinassa on ollut jo pidempään outo ilmiö, jossa toimistot rakentavat erilaisia omia tuotteita ja palikoita, ja myyvät niitä asiakkaille erittäin aktiivisesti, ja usein vieläpä korostaen näiden olevan avointa lähdekoodia, ”kuten WordPressikin”. Tällainen intohimoinen tuotekehitys ja omien erityisratkaisujen tekeminen kuulostaa tietysti yleensä todella hyvältä asiakkaan korvaan, että ”onpa siinä osaava ja innostunut toimisto, kun oikein näyttää mallia muille alalla”.

Asiakkaana näissä kohdissa pitäisi kuitenkin aina kysyä: ”onko tämä teidän hieno palikka julkaistu avoimesti, kuten WordPressikin?”. Erityisesti tämä kysymys korostuu, jos kyse on palikasta, jolla on jo referenssiasiakkaita kymmenittäin ja kyse on tuolle toimistolle hyvin leimallisesta tavasta tehdä asioita. Tällöinhän pitäisi olla itsestäänselvää, että toimisto on julkaissut tuon kyseisen palikan, koska näinhän avoimen lähdekoodin yhteisön johtavat toimijat toimivat. Eikö niin?

No näinhän asia ei tietenkään mene. Varmasti yli 90 prosenttia tämän maan WordPress-toimistojen omista palikoista ei koskaan näe päivänvaloa. Ne pysyvät toimistojen omissa ympäristöissä, auttaen myyjiä korostamaan oman toimiston erikoisuutta ja helpottavat omien kehittäjien työtä projekteissa – ja osa toki auttaa myös olennaisesti asiakkaita esimerkiksi editoimaan sivustoa ketterämmin kuin WordPressin perusratkaisut. Joukossa on siis paljon aidosti hyviä ratkaisuja, mutta usein nämä hyvätkään ratkaisut eivät ole oikeasti avoimia, eivätkä tule koskaan olemaankaan.

Ilmiössä on kyse monesta eri asiasta.

Ehkä se isoin syy omien palikoiden olemassaoloon on se, että aina ei todellakaan löydy maailmalta sopivaa lisäosaa tai laajennusta, joka hoitaisi asian, ja siksi omien palikoiden tekeminen voi olla joskus perusteltua. WordPress-yhteisö on laajuudestaan huolimatta erittäin heterogeeninen, ja moni suosittu lisäosa keskittyy erittäin pienten sivustojen ongelmien ratkaisuun, ja esimerkiksi astetta isommissa projekteissa ei välttämättä ole samalla tavalla tarjontaa hyvistä lisäosista.

Täten on luontevaa, että etenkin isommilla toimistoilla on erilaisia omia lisäosia ja paketoituja ”temppuja”, joilla he ratkovat etenkin isompien palveluiden erityisongelmia tai helpottavat omien kehittäjiensä työtä. Tällaista kehitystyötä tapahtuu käytännössä lähes kaikissa ohjelmistofirmoissa, ainakin sellaisissa, jotka tekevät projekteja asiakkailleen ja näin tavoittelevat tehokkuutta tekemisessään. Tätä kannattaa siis pitää hyvänä ilmiönä.

Esimerkiksi henkilöstövuokraukseen erikoistuneet ohjelmistofirmat eivät yleensä ole kovin aktiivisia tällaisissa asioissa, koska näissä eri tiimit saavat työskennellä yleensä paljon vapaammin, eikä yrityksellä ole liiketoiminnallista intressiä sisäiseen tuotekehitykseen.

Jännittää julkaista koodia koko maailman katsottavaksi

Ehkä se yleisin perustelu palikoiden julkaisemattomuudelle on korkeat sisäiset laatustandardit. Oma koodi hävettää, tavalla tai toisella. Moni kehittäjä ajattelee, että ei kehtaa julkaista sellaista tavaraa, mikä ei edusta täydellisyyttä omasta mielestä. Täten jos julkaisu ei ole yritykselle prioriteetti, vaan enemmänkin kehittäjien harrastuneisuudesta kiinni, ehtivät palikat monesti vanhentua toiminnallisesti ennenkuin kehittäjät saavat palikan hiottua mielestään julkaisukelpoiseksi. Usein näissä keskusteluissa mainitaan myös osallistumisen kynnys, jos koodi on julkisesti jaossa. Jotkut toimistot kehittävätkin palikoita sisäisesti pääosin, ja julkiseen versioon tehdään päivityksiä projektimaisesti kerran-pari vuodessa.

”Salaiset palikat” voivat toimia myynnissä yllättävän hyvin

Kaupallinen näkökulma voi myös toimia julkaisemista vastaan. Jos palikat ovat kaikkien saatavilla, ei myyntivaiheessa saa samalla tavalla luotua vaikutelmaa ainutlaatuisesta mahdollisuudesta. Täten myyntiosastolta ei yleensä tule minkäänlaista painetta palikoiden julkaisemiseen, jopa päinvastoin, koska julkaisu vie osan magiikasta. Ostajien psykologia voi myös aidosti toimia siten, että toimiston ”oma salainen palikka” kuulostaa myyntivaiheessa paremmalta kuin avoimesti julkaistu projekti. Tämä tietysti kertoo myös osaansa alan ostajien kokemuksesta ja ammattitaidosta, mutta epäilen monen tunnistavan tämän ilmiön varsin hyvin.

Paras motivaatio lienee rekrytointiprofiilin kirkastaminen

Kenties konkreettisin hyöty toimistoille koodin julkaisemisesta liittyy rekrytointiin. Moni kehittäjä arvostaa työpaikkoja, joissa panostetaan avoimen koodin projekteihin tai julkaistaan omaa koodia muiden käyttöön. Julkaistu koodi antaa myös ulkopuolisille mahdollisuuden arvioida toimiston tuottaman koodin tasoa, käytänteitä ja aktiivisuutta. Moni toimisto suhtautuukin julkiseen koodin jakamiseen nimenomaan työnantajamielikuvan kehittämisenä ja ylläpitämisenä.

Asiakkaille koodin julkaisemisesta ei välttämättä ole hyötyä

Asiakkaiden näkökulmasta palikoiden julkaisemisella avoimesti on myös hyvin vähän merkitystä käytännössä. Avoin koodin julkaisu helposti nostaa koodin tuotantokustannuksia ja voi näin jopa toimia asiakkaan etuja vastaan.

Käytännössä hyvä ostaja vaatii myös itselleen aina laajat käyttöoikeudet ja jopa edelleenluovutusoikeudet, kun ostaa räätälöityjä ohjelmistoja. Täten yksittäisen asiakkaan kannalta on yleensä ihan yksi ja sama, onko kyseessä aidosti avoin lähdekoodi, vai toimiston oma projekti, kun asiakas saa kuitenkin laajat jatkokehitysoikeudet kyseiseen koodiin.

Tietysti ideaalimaailmassa avoimesti julkaistu projekti mahdollistaisi asiakkaalle myös päivitykset kyseiseen palikkaan, jopa toisen kumppanin avustuksella, mutta jostain syystä tämä logiikka, joka toimii WordPressin ja Drupalin eduksi, ei aina ulotu näihin toimistojen omiin palikoihin.

Loogisesti toimiva ostajahan pyrkisi aina nojaamaan mahdollisimman laajasti käytettyihin ratkaisuihin, jos sellaisia on tarjolla. Tässä kohtaa monet toimistot kuitenkin myös aktiivisesti sekoittavat asiakkaiden päätä haukkumalla lisäosien ekosysteemiä ja kertomalla miten epäluotettavia ja hankalia monet lisäosat ovat. Viesti on usein todella ristiriitainen: ”luottakaa WordPressiin, mutta älkää WordPress-ekosysteemissä julkaistuihin lisäosiin – mutta luottakaa kuitenkin meidän kahden koodarin tekemään aivan mahtavaan (julkaisemattomaan) palikkaan”.

Moni toimisto ei edes itse ymmärrä tätä ristiriitaa omassa viestinnässään, ja jos heiltä kyselee vaihtoehtoisista, enemmän standardeista ratkaisuista, saattavat toimistot olla aidosti yllättyneitä, eivätkä näe mitään ongelmaa näissä omien palikoiden käyttämisessä.

Esimerkiksi Microsoft-maailmassa asiakkaat ovat huomattavasti tarkempia valittavan toimiston osaamisesta liittyen Microsoftin ekosysteemiin. Tekijäksi ei haluta toimistoa, joka virittelee omia erikoisratkaisujaan, vaan hyvältä toimistolta odotetaan aktiivista osallistumista ekosysteemin toimintaan ja kykyä suositella hyviä täydentäviä ratkaisuja. Tässä voi toki olla kysymys myös historiasta, Microsoft-puolella ostajilla on ehkä enemmän kokemusta siitä, mitä haasteita toimistojen omien palikoiden käyttämisestä voi syntyä.

Elinkaarikestävyys ei aina kiinnosta asiakkaita, eikä toimistoja

Ainakin web-projektien saralla on valitettavan harvinaista, että ostaja osaa kysellä ratkaisunsa eri osa-alueiden kestävyydestä. Moni ajattelee, että ”ihan sama, palvelu koodataan uusiksi kuitenkin muutaman vuoden päästä”, ja voi olla ihan oikeassakin tässä. Toimistot taas ovat aina keskittyneitä projektitehokkuuteen, eikä heitä kiinnosta yleensä ylläpidon aikainen tehokkuus ja toimivuus. Lisäksi esimerkiksi web-ala on resetoinut itseään niin usein 2000-luvulla, että ratkaisujen kestävyydestä puhuminen tuntuu joskus jopa koomiselta, kun tapoja ja teknologioita vaihdetaan niin usein.

Tämä asiantila tuskin kuitenkaan kestää loputtomiin, ja aina on niitä palveluita, joissa kestävyydellä on väliä. Kaikilla ei ole rahaa uudistaa palveluitaan kolmen vuoden välein, ja joskus palveluiden terve elinkaari täytyy olla vaikkapa kymmenen vuotta. Fiksut asiakkaat myös pyrkivät aina välttämään tilanteita, joissa ajaudutaan uudistamaan palvelua sen takia, että alkuperäinen toteuttajatoimisto on myyty, tai kyseinen toimisto on keksinyt uuden palikan, jonka päälle tehdä palveluita.

Omien palikoiden tekeminen on fiksua toimistoille, mutta niiden käyttö voi olla lyhytnäköistä asiakkaiden kannalta

Tämän kaiken seurauksena, on etenkin isommille toimistoille kannattavaa kehittää omia ratkaisuja, jotka parantavat asiakastyytyväisyyttä, tehostavat projekteja ja edistävät myyntiä – ja lukitsevat asiakkaita toimistojen asiakkaiksi tiukemmin kuin standardiratkaisuja tekemällä. Käytännössähän tällaiset omat palikat ovat toimistoille erittäin hyvä keino saada parannettua asiakkaiden pysyvyyttä, koska jos ratkaisu perustuu olennaisin osin yksittäisen toimiston omiin ratkaisuihin, on kynnys vaihtaa kumppania erittäin korkea.

Kumppanin vaihtaminen voi käytännössä olla myös hyvin haastavaa, koska toimistot eivät mielellään koske muiden tekemiin erikoispalikoihin. Täten asiakkaiden kannalta toimistojen omiin ratkaisuihin nojaaminen on aina riski, joka voi laueta jopa muutaman vuoden sisällä, jos sukset menevät valitun toimittajan kanssa ristiin. Tässä ilmiössä eivät auta sopimusehdot, eivät avoimen koodin lisenssit, eivät mitkään lupaukset. Jos kyse on yksittäisen toimiston omasta erikoisratkaisusta, siihen ei mielellään kukaan muu koske.

Näin puhtaasti inhorealistisen kaupallisen näkökulman kautta asiaa tarkastellen, omat palikat ja omat tavat tehdä asioita, ovat erittäin hyvä malli isoille toimistoille, jos näihin perustuvia ratkaisuja onnistutaan myymään asiakkaille. Parhaimmillaan niiden tekeminen on kehittäjien mielestä todella kiinnostavaa ja motivoivaa hommaa, myynti rakastaa puhua omista palikoista, ja johtoporras kyllä ymmärtää tiukemman lukon edut pitkällä tähtäimellä.

Ovatko palikat yhtä hyvä diili asiakkaille? Eivät juuri koskaan. Parhaimmatkaan toimistojen omat palikat eivät yleensä tuota hyötyjä kovin pitkään, mutta ne lähes varmasti aiheuttavat ongelmia ratkaisun kehittämisessä myöhemmin.

Ehkä siksi juuri asiakkaiden kannattaisi kysyä useammin se kysymys, että onko niitä palikoita julkaistu, ja käyttääkö niitä kukaan muu. Jos kyse on aidosti myös asiakkaita hyödyttävästä palikasta, leviää sellainen palikka todennäköisesti muidenkin käyttöön, koska sillä on todellisia myyntiargumentteja puolellaan. Jos taas toimisto ei ole palikkaa julkaissut, kertoo se ensisijaisesti siitä, että palikan tuottamat hyödyt ovat toimiston itsensä puolella enemmän kuin asiakkaiden puolella.

Asiakkaiden kannattaisi myös painottaa toimistovalinnoissa toimistojen ymmärrystä valitsemastaan ekosysteemistä. Jos toimisto on valinnut avoimen koodin tuotteita omaan palvelutarjontaansa, tulisi toimiston tuntea kyseisestä ekosysteemistä muitakin osa-alueita kuin vain se ydinjärjestelmä. Jos toimisto käyttää esimerkiksi WordPressiä, mutta ei tunne sen ekosysteemiä ja lisäosia laajasti, päätyy se todennäköisesti juurikin tekemään omia ratkaisuja, jotka eivät välttämättä ole asiakkaiden etujen mukaisia.

Toimistot kehittävät omia palikoitaan kilpaa

Asiakkaiden ei ole kuitenkaan helppoa vältellä näitä toimistojen erikoisratkaisuja, koska jonkinlaisia erikoisratkaisuja löytyy niin monilta. Jos kaikki isot toimistot tarjoavat jotain omia erikoisuuksiaan, eivätkä ole kiinnostuneita vaihtamaan standardimalleihin (etenkin jos sellaisia ei edes oikein ole), eivät asiakkaat pysty välttämään näitä toimistojen omia ratkaisuja. Tällöin pitää vain hyväksyä se riski, mikä syntyy ratkaisun sitoutuessa yksittäisen toimiston omiin palikoihin.

Sama ilmiö löytyy monesta muustakin ohjelmistojen kehittämisen markkinasta

Tämä sama ilmiö löytyy myös erilaisine vivahteineen monesta muustakin markkinasta. Esimerkiksi Drupal-kentässä toimittajat eivät ehkä koodaile omia palikoita samalla innostuksella, mutta jotkut kyllä myyvät aktiivisesti varsin omintakeisia headless-malleja asiakkaille, ja nämä diilit ovat joskus hieman samantyyppisiä – eli toimistojen edut ovat erittäin merkittävät, asiakkaiden edut huomattavasti pienemmät, etenkin syntyvään toimittajalukkoon verrattuna. Tosin Drupal-markkinan eduksi pitää kyllä sanoa, että siellä ei todellakaan ole samaa omien erityisratkaisujen kehittelyn kulttuuria, vaan erottumista haetaan ensisijaisesti palikoilla, jotka ovat laajasti käytössä ympäri maailman.

Myös Microsoft-markkinassa tämä omien palikoiden kehittely on ollut ajoittain voimissaan. Esimerkiksi SharePointin päälle on tehty Suomessakin todella monenlaisia tuotteita ja omia teemapaketointeja. Näissäkin ristiriita on samantyyppinen. Asiakas valitsee usein Microsoftin ekosysteemin, koska se on laajasti käytössä ympäri maailman ja kumppanikenttä on monipuolinen. Toimittajat taas pyrkivät sitomaan asiakkaan itseensä omilla ratkaisuillaan. Microsoft-maailmassa tätä ehkä ymmärretään kuitenkin paremmin, kun kyse on kuitenkin pääosin erittäin kaupallisten tuotteiden käyttämisestä. Tosin Microsoft-markkinassakin on nähty toimittajia, jotka ovat ottaneet kilpailuedukseen standardiratkaisuilla toteuttamisen, erottuakseen omia tuotteita väkertävistä kilpailijoista. Tällä hetkellä tämä omien tuotteiden ilmiö ei ole Microsoft-maailmassa tosin kovin vahva, koska Microsoft on itse ryhtynyt panostamaan enemmän tuotekehitykseen, mutta ehkä osasyynä tähän on ollut juurikin markkinan sirpaloituminen, joka ei ole ollut enää asiakkaiden näkökulmasta terveellinen tilanne.

Täysin räätälöityjen ratkaisujenkin markkina tuntee tämän saman ilmiön. Suomessakin on toimistoja, jotka ovat jossain vaiheessa koodailleet omia Javascript-kirjastojaan, ja edelleen monelta räätälifirmalta löytyy erilaisia omia palikoita. Tämä ilmiö on tosin viime vuosina rauhoittunut hieman, kun monet yritykset ovat keskittyneet henkilövuokraus-tyyppiseen liiketoimintaan, jossa firman omilla malleilla ja menetelmillä ei ole niin paljon merkitystä. Laajojen räätälöityjen ratkaisujen kohdalla asiakkaat ehkä myös paremmin tiedostavat toimittajalukon riskin, jos valittu toimittaja saa täysin vapaasti suunnitella arkkitehtuurin ja valita itselleen mieluisat palikat. Tällä alueella fiksut ostajat yleensä suunnittelevat arkkitehtuuria ja teknologiavalintoja enemmän etukäteen, ja arvioivat valintojen vaikutusta elinkaareen ja saatavilla olevaan toimittaja- ja osaajakenttään.

Toimittajat pelaavat omaa peliään, asiakkaiden kannattaa itse huolehtia omista eduistaan

Suurin osa avoimen koodin tuotteilla tekevistä toimistoista suhtautuukin näihin tuotteisiin aivan samoin kuin asiakkaat. Käyttäminen kyllä kiinnostaa, mutta jakaminen yhteisölle ei. Ja jos on mahdollisuus kehittää jotain omia tuotteita, joilla asiakkaat saadaan hurmattua myyntivaiheessa ja tiukemmin lukittua toimiston asiakkaaksi, nämä tilaisuudet yleensä käytetään.

Asiakkaiden kannattaakin muistaa, että on yleensä aina toimistojen kannalta erittäin järkevää tehdä omia malleja ja ”tuotteita”, on todella paljon harvinaisempaa että samat kuviot olisivat asiakkaiden kannalta kestäviä ja fiksuja valintoja. Siksi, jos mahdollista, asiakkaiden kannattaa aina valita standardiratkaisuja kannattava toimisto, sen omia salaisia palikoita kehittelevän toimiston sijasta.

Lue lisää: Web-sovellukset ja räätälöidyt tietojärjestelmät – kaikki artikkelit Vierityspalkissa

PS. Jos kaipaat riippumatonta asiantuntijan näkemystä mobiili- tai verkkopalvelun jatkokehitykseen, uudistukseen tai teknologian vaihtamiseen, kannattaa tutustua North Patrolin konsultointipalveluihin. North Patrol tuntee web- ja mobiilikehityksen teknologiat ja auttaa lukuisia asiakkaitaan uudistuksissa ja erilaisten digipalveluiden jatkokehityksen suunnittelussa.