Avoimen lähdekoodin strategiat ohjelmistoyrityksille, osa 3



Tämän sarjan edellisessä osassa kävimme läpi viisi tapaa rakentaa kannattava ohjelmistoyritys avoimen lähdekoodin avulla siten, että tuotettu koodi leviää laajalle. Viimeisessä osassa käymme läpi vastakkaisia vaihtoehtoja. Sarjan aiemmat osat näet täältä: 1. osa, 2. osa.

Nämä mallit ovat pahojen poikien liiketoimintamalleja monien avoimen lähdekoodin kannattajien ja puolestapuhujien mielestä. Koodin laajaa leviämistä yritetään estää erilaisin keinoin, sinänsä koodiin liittyviä lisenssiehtoja kuitenkaan rikkomatta.

Asiakkaalle myös tällaiset yritykset voivat olla ihan mainioita kumppaneita, mutta heidän ympärilleen ei pääse muodostumaan ekosysteemiä, eikä ekosysteemin mukana tulevaa yritystä suurempaa kehittäjäjoukkoa.

Itse asiakkaana suhtautuisin tällaisiin alihankkijoihin pienellä varauksella ja heidän puheisiinsa erityisen varauksellisesti.

1. Hyvän palvelun lempikonsultti

Helpoin tapa pitää kiinni hyvistä asiakkaista ja kerätä uusia asiakkaita on hyvän palvelun kautta. Julkishallinto haluaa ihan yksityisen puolen tavoin hankkeensa onnistuvan ja nauttii siitä, kun saa tehdä töitä sellaisten ammattilaisten kanssa, jotka ymmärtävät ja arvostavat heidän työtään.

Alan huonommin tuntevat luulevat helposti, että julkisella puolella on pakko valita halvin toimittaja. Tämä ei pidä paikkaansa missään määrin. IT-alan kilpailutuksissa, joita asiakkaan on järjestettävä aika ajoin, käytössä on useimmiten kokonaistaloudellisesti edullisimman valinta.

Kun asiakas on tyytyväinen tuttuun konsulttiin, valitaan kilpailutuksen kriteerit niin, ettei muilla alan toimijoilla ole osaa eikä arpaa tulla valituiksi; “Montako vuotta yrityksellä on kokemusta Liekki-järjestelmän ja ministeriön IT-kehitysmallin käytöstä?” Tyytyväistä asiakasta ei julkishallinnossakaan saa vaihtamaan toimittajaa, eikä avoin lähdekoodi juuri pääse tähän vaikuttamaan.

Malli on tavallaan neutraali. Ostaja ja myyjä avaavat koodin, mutta liiketoimintamallin kannalta tuo on ihan samantekevää, kun kilpakumppanit eivät kuitenkaan pääse tähän väliin vaikuttamaan.

2. Viime vuoden vuosimalli

Lähdekoodi on JIT-ehdotusten vedoksen mukaan avattava vasta hankkeen päätyttyä. Pitkissä julkishallinnon hankkeissa on mahdollista tehdä töitä olympiaadi tai pitempään myöhemmin avattavan koodin kimpussa ilman, että tuota koodia tarvitsee vielä näyttää muille asiakkaille tai kilpakumppaneille. Viiden vuoden etumatkan aikana yritys voi luoda niin vahvan otteen alasta, että avoimellakaan lähdekoodilla on vaikea kilpailla kaikkien kaverien ja jokaisen projektin osaajan kanssa.

Tässä ei välttämättä ole kyse aina edes piinkovasta strategiasta. Vain harvat kehittäjät nauttivat koodinsa julkistamisesta, ennen kuin se on ihan loppuun saakka tehty. Kehittäjien introversio voi tuottaa kaupallisen mahdollisuuden.

3. Omintakeiset työkalut

Hyviä järjestelmiä voi kehittää mitä ihmeellisimmillä työkaluilla, ja usein paras vaihtoehto ei vielä ole kovin laajalti tunnettu. Erlang, Cassandra ja Freebsd-pohjainen järjestelmä tuskin muuttuu kilpakumppaneiden lempilapseksi, sillä siihen oppimisen investointi olisi huimaa.

Joskus yritykset onnistuvat tässä vähän liiankin hyvin. Siinä missä tavallisesti yritykset valitsevat samat ohjelmointikielet kuin muutkin alalla, saattaa avoimella puolella olla suurempi intressi valita työkaluja tai niiden yhdistelmiä, joiden käytössä juuri kyseinen firma on kokeneempi kuin muut. Näin jatkokehityksessä yrityksellä on etulyöntiasema työkaluja vasta opetteleviin verrattuna.

4. Ei avata kaikkea

JIT-ehdot mahdollistavat avoimen lähdekoodin teon suljetun ytimen ympärille. Se, mikä on jo valmiina jaetaan ihan tavallisella ohjelmistolisenssillä, ja vain uusi osuus joudutaan avaamaan avoimena lähdekoodina. Tällaisista avauksista voi toki olla hyötyä, mutta jos toimittaja haluaa tahallaan pitää avoimen koodin hyödyttömänä, ei tuo kovin vaikeaa ole.

5. Patentoidaan ja tavaramerkitään kaikki, mikä liikkuu

Avointa lähdekoodia ei voi käyttää työn pohjana, jos sen ydin on onnistuneesti patentoitu, tai jos on edes uhka siitä, että koodissa on patentoituja kohtia. Patentointi on toki vaikeaa ja kallista, mutta ei suinkaan mahdotonta, varsinkaan laajoissa ja kalliissa julkishallinnon sovelluksissa.

Helpompaa on toki hankkia tavaramerkki sovelluksen nimelle. Muutkin voivat käyttää koodia, mutta muut joutuvat jatkuvasti tekemään turhaa työtä muuttaessaan sovelluksesta niitä osia, joiden käyttö sellaisenaan on tavaramerkein kiellettyä.

6. Siirrytään SaaS-malliin

Jos tuote on lähes sama kaikilla asiakkailla, voi olla helpompaa siirtyä lisensointimaailmasta verkon kautta tarjottavien ohjelmistojen maailmaan. Julkishallinnolla on omat SaaS-sopimuksensa, joiden kautta ohjelmistoja hankittaessa oikeudet lähdekoodiin jätetään toimittajalle.

SaaS-palvelussa samaan sopimukseen on niputettu sovellus, palvelimet ja niiden käyttöpalvelu. Joskus pakettiin kuuluu jopa järjestelmän käyttämien tietoaineistojen osittainen luonti tai ylläpito.

2 kommenttia artikkeliin ”Avoimen lähdekoodin strategiat ohjelmistoyrityksille, osa 3

  1. Kiitos hyvästä artikkelisarjasta. Minua jäi tässä häiritsemään sellainen seikka, kun puhutaan julkishallinnon räätälöityjen ratkaisujen lähdekoodin julkaisemisesta kilpailijoille, että nuo hyötykohdat voivat jäädä hyvin rajallisiksi silloin, kun järjestelmän potentiaalisina käyttäjinä toimii vain yksi organisaatio. Tässäkin lähinnä se, että substanssiosaaminen, jonka järjestelmän ensimmäinen tekijä saa, nopeuttaa myös järjestelmän muutostöitä, joita ei välttämättä muilla toimijoilla vielä ole.

    Toisaalta, jos tehdään järjestelmää, jolla voi potentiaalisesti olla lukuisia muitakin käyttäjiä, niin silloin luulisi käytettävän jo jotain valmista ohjelmistoa tai palvelua. Tällaisten järjestelmien teettäminen ei minusta ole kovin järkevää.

    • Kiitos Juhani,

      itse näen tilanteen toisin. Näennäisen ainutlaatuiset järjestelmät, joihin itse törmäämme ovat liikuttavan samankaltaisia toisten ministeriöiden, kuntien tai sairaanhoitopiirien yhtä ainutlaatuisten järjestelmien kanssa. Ja jopa sellaiset järjestelmät, joita ei muualla ole käytössä, kuten nyt vaikkapa VM:n kansantalouden laskentajärjestelmä tai Ilmatieteenlaitoksen mallintamisjärjestelmät voisivat olla hyödyllisiä kaupallisille toimijoille, ainakin jos ne saisi käytöön ilman erilliskustannuksia.

      Valmisohjelmistojen osalta kyse taas on jatkuvasta evoluutiosta. Moneen ratkaisuun, jota nyt tehdään verkkosovelluksena, on tehty aikanaan toimivat reikäkortti-, pääte-, client-server ja windows-ratkaisut. Avoin lähdekoodi on yksi tapa pakottaa ala uudistumaan tilanteessa, jossa olemassaolevat toimittajat ovat löytäneet mukavia monopolin tai kartellinomaisia toimintatapoja niihin kuuvine hinnoittelumalleineen.

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *