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

Perttu Tolvanen

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.

PS. Tilaa Vierityspalkin kerran kuukaudessa ilmestyvä uutiskirje, joka koostaa artikkelit, linkkivinkit, työpaikat ja julkaisut (uutiskirjeellä on jo yli 900 tilaajaa).

Digitoimistot Vierityspalkissa – viimeisimpiä juttuja:

Kommentit

  1. Timi Wahalahti says:

    Hyvä kirjoitus, kiitos tästä Perttu!

    “[…] ehtivät palikat monesti vanhentua toiminnallisesti ennenkuin kehittäjät saavat palikan hiottua mielestään julkaisukelpoiseksi.”

    Omasta mielestä kaikki on julkaisukelpoista ja vanhentunutta koodia ei tarvitse hävetä! Parhaimmillaan muut toimistot alkavat käyttämään, tai ainakin testaavat, avoimena julkaistuja palikoita ja osallistuvat niiden parantamiseen. On meilläkin firman Githubissa vaikka kuinka julkisena vanhentuneita, arkistoituja, palikoita sekä työkaluja.

    “Toimistot taas ovat aina keskittyneitä projektitehokkuuteen, eikä heitä kiinnosta yleensä ylläpidon aikainen tehokkuus ja toimivuus.”

    Hieman kärjistäen, kun keskittyy projektitehokkuuteen. ylläpitovaiheessa voi rahastaa asiakasta asioista jotka olisi pitänyt hoitaa projektissa kuntoon ;) Kyseinen tapa on omasta mielestä todella epäeettinen ja lyhytnäköinen. Tokikaan kaikki toimistot ei näin toimi. Onneksi.

    Hyvä asiakkuus- sekä toimiva ylläpitosuhde muodostuu hoitamalla asiat mallikkaasti jo projektivaiheessa. Vaikka se tarkoittaisi hieman pienempää katetta projektissa. Yleensä se korvautuu sitten myöhemmin ylläpidossa, kun ei olekkaan niin paljoa työsarkaa sillä puolella.

    “Jos toimisto on valinnut avoimen koodin tuotteita omaan palvelutarjontaansa, tulisi toimiston tuntea kyseisestä ekosysteemistä muitakin osa-alueita kuin vain se ydinjärjestelmä.”

    Spot on! Liian usein näkee omia palikoita jotka sinänsä toimii sekä on käynyt ja kukkunut jo vaikka kuinka pitkään, mutta ei hyödynnä ytimen logiikkoja ja toimintatapoja. Jos useampi toimisto tekisi hieman enemmän standardinmukaisesti palikoita, olisi myös asiakkaan helpompi löytää uusi kumppani jos tulee vastaan tilanne että toisen toimiston pitäisi ottaa koodipohjasta koppia.

    Jos jotakuta WordPress-toimiston tyyppiä joka sattuu lukemaan tämän, kiinnostaa jutella miten lähteä etenemään oman koodin julkaisun kanssa tai ylipääntänsä muuten yhteisöön kontribuoimisen osalta niin ottakaa rohkeasti yhteyttä! Juttelen aiheesta mielelläni ja autan eteenpäin.

  2. Rami Lappalainen says:

    Ehkä hieman kärjistävä asettelu kirjoituksessa, josta syystä minäkin haluan kommentoida – well done siis :)

    On sanomattakin selvää että kaikilla alan toimijoilla on “omaa pääomaa”, joka koostuu tietotaidosta ja custom-toiminnallisuuksista, joita nyt sitten voisi palikoiksi sanoa.

    Minä käsitän “avoimen lähdekoodin” niin että se johtaa myös sopimuksiin. Täysi toimittajariippumattomuus on se tärkein asia mitä asiakkaan tulee odottaa sopimuksissa. Se ja “avoin lähdekoodi” eli yleisesti käytössä oleva ei suljettu systeemi, muodostaa turvan ja pitkän elinkaaren. Tähän päälle riittävä dokumentaatio custom-toiminnallisuuksista niin asiakas voi jatkaa kehitystä kenen kanssa tahansa. Tämä taas pakottaa toimijat kilpailukykyiseen hinnoitteluun ja hyvään asiakaspalveluun.

    Ymmärrän kyllä että olisihan se moraalisesti ja vastuullisesti oikein julkaista yhteisön käyttöön “palikoita”, joista muutkin voivat hyötyä. Mutta näin ei taida markkinatalous kuitenkaan toimia, ainakaan lokaalissa pienemmässä markkinassa.

    Hyvää kesää kaikille!

    Rami
    Alfons Education & Mediapool

  3. Perttu Tolvanen says:

    Kiitos Timi ja Rami kommenteista.

    Historiallisestihan avoin lähdekoodi on noussut vastaliikkeenä suljetulle koodille ja juurikin toimistojen omille palikoille. Nyt vain vaikuttaa siltä, että kun WordPressin ympäriltä on hävinnyt se suljettujen järjestelmien kilpailu, niin moni toimisto on keksinyt samat temput uudestaan, tai vähän uudella tavalla paketoituna. Että ei sidota enää sopimuksellisesti, mutta sidotaan käytännössä, kun toimitetaan projektit niin omaleimaisella tavalla ja omilla palikoilla, että kukaan muu ei käytännössä halua koskea syntyvään kokonaisuuteen.

    Ihan tällainen klassinen oman haudan kaivaminenhan tässä on kyseessä, mutta yksittäinen digitoimisto (tässä voisi käyttää vaikka sitä klassista sammakko kattilassa -vertausta) ei tätä tietysti hahmota, koska näkee omat palikat vain hyvänä kilpailutaktiikkana.

    Jos tämä suunta jatkuu, niin WordPress menee kohti jonkinlaista ”avoin ydin / open core” -mallia, jossa se perustuote on kyllä avoin, mutta käytännössä isommissa projekteissa aina tarvitaan lisäosia ja räätälöityjä palikoita, jotka sitten sitoutuvat tiettyyn toimistoon. Yleensä tällaisessa avoin ydin -mallissa tosin ne lisäosat ovat kaupallisia, ja kenen tahansa käytettävissä, mutta WordPressin kohdalla lisenssi estää rahan pyytämisen ja lisenssin vaihtamisen, joten päädytäänkin tällaiseen outoon avoin ydin + erittäin suljetut ja salaiset lisäosat -malliin (joka on paljon huonompi tilanne kaikkien kannalta kuin se, että lisäosista voisi pyytää rahaa ja tämä kannustaisi toimistoja julkaisemaan ne).

    Et kun tätä toimistojen touhua katselee, niin on ainakin ihan selvää, että ei tämä WordPressin maailmanvalloitus tule jatkumaan samalla tavalla enää jatkossa. Riippuu toki kilpailijoista, ja asiakkaista, mutta jos tämä ilmiö laajenee nykyisellä tahdilla, niin musiikki loppuu jossain vaiheessa.

  4. Rami Lappalainen says:

    Perttu, sulla toki todella laaja ja pitkä kokemus aiheesta. Mutta itse firman puolesta ainakin pidän huolen että asiakkaalla ei ole mitään ongelmaa siirtyä koodin kanssa eteenpäin ja dokumentaatio mukana. Me ollaan hävitty tää peli jo siinä vaiheessa kun asiakas lähdössä.

  5. Perttu Tolvanen says:

    Ja sehän onkin ehdottomasti parantunut avoimen koodin yleistymisen myötä, että harvassa on enää ne toimistot, jotka eivät luovuta asiakkaille oikeuksia palikoihin, kun asiakas siirtyy eteenpäin. Hyvä näin.

    Asiakashan valitsee sen WordPressin yleensä juuri siksi, että saa standardin ja laajasti käytetyn ratkaisun, mutta entä kun ratkaisu sitten käytännössä nojaakin johonkin yksittäisen toimiston tekemään erikoisratkaisuun? Sopimuksellisesti kaikki voi olla ok, ja uusi toimittaja saa kaiken koodin käyttöönsä ja ehkä jopa vähän dokumentaatiota, mutta käytännössähän on kyse täysin räätäliratkaisusta, kun joku toinen toimisto ryhtyy sitä ihmettelemään.

    Ehkä se mun peruspointti on vain se, että tuo ei ole mitään ”avointa koodia”, se on vain räätälikoodia, jota saa kehittää eteenpäin jonkun toisen tahon kanssa. Ihan ok taso sinänsä, mutta ei vielä samalla tasolla kuin vaikkapa WordPress. Kuten Duden herrat Twitterissä hyvin kiteytti, vain julkisen repositoryn koodi on avointa. Kaikki muu on jotain muuta.

    Toinen teemahan tässä asiassa on se toimistojen kulttuuri. Jos toimisto on kulttuuriltaan räätäliratkaisujen tekijä, heille yleensä riittää se, että asiakas saa kaikki oikeudet kaikkeen tekemiseen. Jos taas kulttuuri on aidosti avoimen koodin toimisto, on se palikoiden julkaiseminen keskeinen osa toimintaa, ja myyntiargumentti on asiakkaille se, että syntyvä toimittajariippumattomuus on vielä sitä reilusti pelaavaa räätälitoimistoa korkeammalla tasolla.

    Ja näitä aitoja avoimen koodin toimistoja ei tässä maassa ole vielä montaa. Niitä toimistoja, jotka hyödyntävät avoimen koodin tuotteita, tekevät paljon räätälikoodia ja luovuttavat niiden oikeudet laajasti asiakkailleen… näitä toimistoja on toki paljon.

Jätä kommentti