Lähtölaukaus Opinderiin

Kuvakaappaus tämänhetkisestä Opinderista.

Helsingin yliopiston ja Codenton yhteistyö Opinder-sovelluksen toteuttamiseksi on käynnistynyt ja molemmat osapuolet ovat projektista innoissaan. ”Tosi hyvät fiilikset. On myös tosi odottava olo, kun olemme päässeet tuotantoversion kehitykseen. Juuri tänään tapasimme kehitystiimin kanssa, ja hyvältä näyttää,” kommentoi Pauliina Kupila, Opinderin tuoteomistaja.

Opiskelijoilta opiskelijoille

Helsingin yliopisto on innokas löytämään uusia verkkopalveluita. Idea ja konsepti Opinderiin, eli ’opiskelijoiden Tinderiin’, lähti Ohjelmistotekniikan menetelmät –kurssin harjoitusten opiskelijaryhmältä. Kyseessä ei kuitenkaan ole opiskelijoiden deittisivusto, vaan opiskeluseuran hakemiseen suunnattu sovellus. Opinderin ajatus on luoda näppärä palvelu, jonka avulla opiskelijat voivat helposti löytää saman kurssin muut osallistujat, olla yhteydessä toisiinsa, kysyä toisiltaan tarvittaessa apua kurssin tehtäviin ja muodostaa lukupiirejä. Myös opettajat voivat ilmoittaa Opinderissa vapaista vastaanottoajoistaan, ja opiskelijat puolestaan pääsevät varaamaan aikoja lyhyelläkin varoitusajalla. Valmiin Opinder-sovelluksen voi ladata sovelluskaupasta omaan matkapuhelimeensa tai käyttää sitä selaimella.

Toteutus avoimella lähdekoodilla

Opinder toteutetaan avoimen lähdekoodin projektina. Kuka tahansa julkishallinnon toimija voi siis tulevaisuudessa ottaa lähdekoodin omaan käyttöönsä, ja ryhtyä kehittämään siitä omaa sovellustaan. Sitä kautta sovellus toivottavasti leviää myös muihin yliopistoihin. ”On erinomaisen innostavaa päästä tekemään uutta sovellusta, joka on lähtenyt opiskelijoiden omasta ideasta. Julkaisu avoimena lähdekoodina ja käyttäjälähtöinen toteutustapa tekevät projektista erityiskiinnostavan,” iloitsee Tommi Ullgrén, Codenton julkishallinnon asiakkuusvastaava.

Pauliina Kupila Opinderin lumoissa
Pauliina Kupila Opinderin lumoissa.

Liikkeelle käyttäjälähtöisellä pilotilla

Opinder-projekti käynnistettiin tuottamalla ensin käyttäjälähtöinen pilottisovellus, joka oli käytettävissä verkossa, ja myöhemmin myös matkapuhelimessa. Yliopiston väki on päässyt vapaasti katselemaan ja kokeilemaan prototyyppisovellusta. Samalla on kuulosteltu, miten se otetaan vastaan. Suhtautuminen on ollut myönteistä. ”Hirveän positiivisesti tämä on otettu vastaan. Aiemmin piti oikein toppuutella, kun emme olleet vielä varmoja toteutuksesta. Nyt on sitten päästy sanomaan, että pian pääsette käyttämään tätä,” Kupila kertoo. ”Osa valmistuvista opiskelijoista on harmitellut, ettei tällaista sovellusta ollut heidän opiskeluaikanaan.” Tilausta sovellukselle on siis ollut jo pidemmän aikaa.

Ketterää kehitystä

Maaliskuussa päätettiin, että Opinder etenee varsinaiseen tuotantoon. Projektin toteutus kilpailutettiin Helsingin yliopiston ketterän kehityksen puitesopimuksen kautta ja toimittajaksi valittiin Codento. Projekti toteutetaan luonnollisesti ketterästi; Helsingin yliopistolla on tuoteomistaja, Codentolla taas Scrum Master ja kehitystiimi. He etenevät yhdessä resurssi- ja aikataulupainotteisen työskentelyn kautta kohti valmista lopputulosta. Ensin tehdään ja julkaistaan MVP (Minimum Viable Product), ja siitä saadun palautteen pohjalta viimeistellään varsinainen sovellus. ”Olen ollut aikaisemmin vesiputous-hankkeessa projektipäällikkönä, ja henkilökohtaisesti pidän tästä työskentelytavasta enemmän. On hienoa, kun pääsee nopeasti näkemään kädenjäljen, testaamaan sitä käyttäjillä ja saa heiltä heti palautetta,” Kupila sanoo.

Opinder on Helsingin yliopiston ensimmäinen mobiilisovellushanke. Siksi yliopistolla joudutaan tekemään paljon selvitystyötä liittyen tietoturvaan ja -suojaan, sekä miettimään, mihin sovelluskauppoihin Opinder julkaistaan. ”Tämä on senkin puolesta uutta ja jännittävää. Tätä projektia en antaisi pois,” Kupila toteaa hymyillen.

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.

Aamiaisseminaarin antia: tietojärjestelmien omistusoikeudet – Codenton uutiskirje 06/2015

Hei!

Jos et päässyt osallistumaan aamiaisseminaariimme, joka käsitteli tietojärjestelmien omistusoikeuksia, tai jos olit paikalla ja kaipailet jotain tiettyä esitystä, pääset tutustumaan seminaarin antiin jälkikäteen! Tässä uutiskirjeessä:

  • Petri Aukian (Codento) ja Kerkko Vanhasen (HSL) puheenvuorot videolla sekä SlideSharessa
  • Video: Mitä IT-ostajan pitää ymmärtää tietojärjestelmien omistusoikeuksista?
  • Uusia ajatuksia ohjelmistojen omistamisesta

Petri Aukian (Codento) ja Kerkko Vanhasen (HSL) puheenvuorot videolla sekä SlideSharessa

Tietojärjestelmien omistusoikeuksissa kannattaa panostaa strategisesti tärkeimpiin, kilpailukykyä luoviin järjestelmiin, sanoi Petri Aukia (Codento) puheenvuorossaan. Kerkko Vanhanen (HSL) taas esitteli uutta, avoimeen lähdekoodiin perustuvaa Reittiopasta. Nämä puheenvuorot ovat nähtävissä kokonaisuudessaan. PowerPoint-diat Aukian esitykseen löydät täältä, ja Vanhasen esitykseen taas täältä.

Video: Mitä IT-ostajan pitää ymmärtää tietojärjestelmien omistusoikeuksista?

Kannattaa myös vilkaista puhujien tiivistykset esitystensä parhaista opeista, sekä kävijöiden kommentit ja mielenkiintoisimmat oivallukset.

Uusia ajatuksia ohjelmistojen omistamisesta

Konsulttimme Matti Kinnunen kirjoittaa huomioitaan seminaarin sisällöstä blogissamme. Blogiartikkelissa kerrotaan mm. siitä, miten tärkeää on pitää olennainen arkkitehtuuriosaaminen omissa käsissä ja ostaa useilta eri toimittajilta toimittajaloukun välttämiseksi. Tämä huomionarvoinen poiminta on Hannu Kokon (Basware) puheenvuorosta, jonka diat näet täällä.

Jos seminaarin aiheista herää kysyttävää, ota rohkeasti yhteyttä Petri Aukiaan (petri.aukia@codento.com, puh. 0400 438 610).

Mukavaa kesän jatkoa!

Petri ja koko Codento-tiimi

Haluatko tutustua muihin uutiskirjeisiimme?

Jos haluat lukea muita uutiskirjeitämme, tässä linkit muutamaan niistä.

Leanillä tehoa liiketoimintaan (12/2015)
Lisenssit ja avoin lähdekoodi (09/2015)
Tiedolla johtaminen tuo parempia tuloksia (08/2014)
Inspiraatiota uuden IT:n päättäjille (06/2014)
Uutiset IT:n päättäjille (03/2014)

Jos taas haluat saada tulevat uutiskirjeemme ensimmäisten joukossa suoraan sähköpostiisi, voit liittyä uutiskirjeemme tilaajaksi vaivattomasti blogimme sivupalkissa olevalla lomakkeella.

Avoimen lähdekoodin strategiat ohjelmistoyrityksille – Osa 2

Toisessa osassa kolmiosaista sarjaa avoimen lähdekoodin liiketoimintamalleista käsittelen niitä malleja, joissa yritys tekee kaikkensa saadakseen sovelluksen leviämään laajalle. Yritykset yrittävät levittää koodia laajalti ja ovat löytäneet tapoja hyötyä tästä taloudellisesti. Ensimmäisen osan voit lukea täältä, viimeisen osan taas täältä.

1. Kansainvälinen succée

Kansainvälisesti onnistuneista avoimen lähdekoodin hankkeista ensimmäisenä mieleen nousevat Vaadin, MySQL, SSH, Linux ja IRC. Jokainen näistä valitsi haastavan, vaikeasti ratkaistavan ongelman, ja kehitti siihen maailmanluokan ratkaisun. Esimerkkiyrityksistä MySQL onnistui loistavasti, Vaadin ja SSH näyttävät lupaavilta ja IRC:in ja Linuxin ympärille ei muodostunut kotimaista ohjelmistoteollisuutta.

Seuraavan sukupolven julkisissa hankkeissa voi olla seuraavan kansainvälisesti menestyvän suomalaisen yrityksen siemen. Julkisten hankkeiden kautta voi löytyä joku, joka ratkoo niin tärkeän ongelman, että yrityksestä tulee oman alansa markkinajohtaja, kuten kävi yllä mainituilla esimerkkiyrityksillemme.

Tällä tavalla menestyvälle yritykselle kotimaanmarkkinat ovat aivan liian pienet ja voi olla, että yritys itse ei edes osallistu kotimaisiin kisoihin, vaan jättää tuotteensa paikallisten jakelijoiden tarjottavaksi.

2. Palvelupohjainen toimintamalli

Moni avoimen lähdekoodin kanssa paiskiva yritys on löytänyt tavan laskuttaa tukipalveluista tavallistakin paremmin. IT-alan salainen todellisuus on, että myynti ja markkinointi on todella kallista. Oraclen kaltaisilla kansainvälisillä yrityksillä se on niin tyyristä, että koko lisenssistä saatava tulo menee myyntikulujen korvaamiseen. Jos siis avoin lähdekoodi myy itse itsensä, yritys voi olla jopa kannattavampi kun se keskittyy laadukkaan tuen myymiseen.

Avoimen lähdekoodin tuki kun ei ole sen halvempaa, kuin suljetun lähdekoodin tuki. Alan parhaat yritykset voivat veloittaa vaativien ongelmien ratkaisemisesta useita tuhansia euroja henkilötyöpäivää kohti. Avoin lähdekoodi ei ole hyväntekeväisyyttä.

3. Kruununjalokiven kaappaus

IT-alan suurimmat toimijat käyttävät avointa lähdekoodia härskisti pahimpien kilpailijoidensa liiketoimintamallien tuhoamiseksi. Troijan hevosen kaltaiset ilmaiset sovellukset, kuten Googlen erittäin menestynyt Android-käyttöjärjestelmä tai Applen Safari-selain tekevät kilpakumppanin kruununjalokivistä nopeasti arvottomia. Onnistuessaan ne muuttavat markkinoita niin, että johtoasema arvioidaan uudestaan. Erinomainen esimerkki on myös virolainen x-road, joka kulkee Suomessa kansallisen palveluväylän nimellä.

Suomalaiset markkinat ovat pienet, mutta en ihmettelisi, vaikka Tiedon tai Logican kaltaiset jättiyritykset harkitsisivat toistensa asemiin hyökkäämistä avoimen lähdekoodin keinoin.

4. Pakotetaan muutkin avaamaan koodinsa

Avoimen lähdekoodin lisensseissä on kaksi valtavirtaa. Niin sanottu MIT-lisenssi ja sen kaltaiset muut lisenssit mahdollistavat uusien suljettujen ohjelmistojen tekemisen avoimen lähdekoodin pohjalta. GPL-lisenssi ja muut ns. copy-left -lisenssit ovat pirullisempia. GPL-sovelluksen liittäminen osaksi omaa softaa pakottaa useimmiten jakamaan omankin ohjelmiston kokonaan samalla lisenssillä.

MIT-lisensoitu avoin lähdekoodi on ohjelmistoyrittäjälle kuin lahja. Sen voi ottaa vastaan ja liittää osaksi omaa sovellusta muuttamatta juuri mitään. GPL-lisenssi on tähän verrattuna kuin myrkytetty omena. Jos GPL-koodia liittää omaan sovellukseensa, pitää oma sovellus jakaa kokonaan muille samalla GPL-lisenssillä.

Monilla markkinoilla koodin jakaminen GPL-lisenssillä riittää pitämään kilpailijat loitolla. Muut yritykset eivät voi käyttää koodia osana omaa tuotettaan, koska ovat päättäneet olla julkaisematta omia koodejaan.

5. Käenpoika

Käenpoika-nimen olen antanut strategialle, jossa pienempi yritys tarkoituksella jakaa avointa lähdekoodia isompiensa käyttöön. Liiketoimintamalli ei tässä strategiassa ole aluksi ilmeinen, mutta koodin käyttö helpottaa hankkeita niin paljon, etteivät isommat yritykset voi vastustaa kiusausta käyttää koodia.

Kun koodi on saatu levitettyä laajalle, alkaa vaihe 2, jossa markkina-asema monetisoidaan. Riittävän pienelle yritykselle tässä voi olla kyse ihan pelkästä oman yrityksen tunnetuksi tekemisestä.

Avoimen lähdekoodin strategiat ohjelmistoyrityksille – Osa 1

 

Julkishallinnon hankinnat ovat olleet tapetilla, ja aiheesta: liiketoimintaympäristö ja teknologia laukkaavat hurjaa vauhtia, ja välillä on vaikea hahmottaa, miten tilannetta tulkitsisi ja miten olisi fiksua toimia. Kirjoitan aiheesta kolmessa erässä. Tässä ensimmäinen niistä, ole hyvä! Sarjan seuraavat osat luettavissa täällä: osa 2. ja osa 3.

Suomessa julkishallinto on maamme suurimpia ohjelmistojen teettäjiä. Suuressa osassa julkishallinnolle teetetystä sovelluskannasta oikeudet uusiin sovelluksiin ovat jääneet toimittajalle, vaikka julkishallinto on maksanut niiden kehityskustannukset kokonaisuudessaan. Malli on ollut äärimmäisen kannattava niille yrityksille, jotka ovat päässeet sisäpiiriin ja löytäneet hyvän mesenaatin alkuperäiselle sovellukselle.

Julkishallinnon yleisten sopimusehtojen uusimmassa versiossa (JIT 2015) tullaan todennäköisesti räjäyttämään pankki sovellusten omistuksen suhteen. Uusien ehtojen oletusarvoksi on valittu malli, jossa sovellusten tekijänoikeudet jäävät toimittajalle, mutta toimittajan on julkaistava uusi sovellus samanaikaisesti avoimen lähdekoodin lisenssillä.

Tilanne on uusi. Aiemmin yritykset ovat itsenäisesti valinneet avoimen lähdekoodin osaksi strategiaansa ja ovat useimmiten olleet varsin hyvin tietoisia siitä, mitä tämä itse asiassa tarkoittaa. Nuorten innokkaiden kehittäjien tiimit ovat ymmärtäneet riskit ja mahdollisuudet. Nyt avointa lähdekoodia vaaditaan yrityksiltä, joiden avainosaaminen on jossain ihan muualla.

Avoin lähdekoodi itsessään ei ole liiketoimintamalli, kuten tunnettu suomalainen yritysjohtaja ja avoimen koodin puolestapuhuja Mårten Mickos usein kysyttäessä kertoo. Yrityksen pitää olla tavallista tarkempi strategisten tavoitteidensa suhteen silloin, kun avoimen lähdekoodin mallin valitsee toimittajan sijaan asiakas.

Uuden strategian aika

Avoin lähdekoodi muuttaa markkinoiden ja ohjelmistoyritysten strategioita. Effica-integraatiota voi olla vaikea myydä 100 000 euron hintaan jokaiselle kunnalle, kun kunta voi halutessaan ladata integraation lähdekoodin verkosta, tai kun kunnan IT-kumppani voi sen ladata ja asentaa halvemmalla. Ansaintamalli on keksittävä uudestaan.

Toimittajan liiketoimintamallin hyvä ymmärtäminen on tärkeää myös asiakkaalle. Kumppani, joka raottaa koodiaan väkinäisesti ja toisaalta kumppani, joka jakaa riemukkaasti koodiaan, ovat luonteeltaan hyvin erilaisia. Todellisuudessa molemmat pyrkivät tienaamaan mahdollisimman hyvin asiakaskunnallaan.

Esiin nousee kysymys: miten ohjelmistoyritys voi toimia kannattavasti tässä uudessa liiketoimintaympäristössä? Sen saat selville seuraavissa osissa!