Avoimeen lähdekoodiin perustuvien komponenttien jakelu julkishallinnossa

Transkriptio

1 Avoimeen lähdekoodiin perustuvien komponenttien jakelu julkishallinnossa

2 Sisällysluettelo Sisällysluettelo... 2 Julkishallinnon avointen ohjelmistokomponenttien ja rajapintojen hallinta... 3 Taustamateriaalin keruu... 3 Yhteenveto ja kehitysehdotukset... 3 Liite 1: Haastattelut... 5 Valtori, Kristiina Puharinen ja Taina Hagelberg sekä CSC:ltä Stina Westman ja Mikko Koho... 5 Maanmittauslaitos (MML), Jani Kylmäaho... 5 Navinova, Antti Rainio... 6 HSL, Tuukka Hastrup... 7 Finto, Osma Suominen... 7 Muut keskustelut ja tapaamiset... 7

3 Julkishallinnon avointen ohjelmistokomponenttien ja rajapintojen hallinta Nykyisessä avoimiin ohjelmistoihin käyttöön ja kehitykseen suuntautuvan toimintatavan tukemiseen tarvitaan tätä tukevia työkaluja. Tässä selvityksessä pureudutaan avointen ohjelmistotuotteiden ja avoimeen ohjelmistokehitykseen nojautuvien palveluiden nykytilanteeseen sekä tuodaan esille olemassa olevia tarpeita ja toiveita. Selvityksen päätarkoituksena on löytää ehdotus sellaisten avoimeen lähdekoodiin perustuvien komponenttien hallinnalle hallinnalle, jotka ovat syntyneet julkishallinnon toimesta tai aloitteesta. Keskeisiä asioita selvityksessä on erityisesti avoimen tuotteen hallintamalli jota voidaan pyrkiä hyödyntämään aiotuissa ratkaisuissa. Erityisesti avoimen tuotteen hallintamallin tuotteenhallintasuunnitelma pitää sisällään asioita, joita sivutaan tässä selvityksessä. Taustamateriaalin keruu Taustatietoa on haettu mahdollisimman monipuolisista lähteistä niin, että samalla on myös pyritty rakentamaan perustietoutta julkishallintoon liittyvästä ohjelmistokehityksestä. Tieto on kerätty haastattelemalla erilaisia avointen ohjelmistojen kanssa tekemisissä olevia ihmisiä. Materiaalia on kerätty lisäksi osallistumalla erinäisiin tilaisuuksiin, jossa on kuulunut kerralla useampi katsantokanta, kuten 6Aikahankkeen Dataportaalikokous ja CKAN meetup. Yhteenveto ja kehitysehdotukset Yleisesti avoimessa kehityksessä käytetään ja/tai halutaan käyttää GitHubia, tällä hetkellä ehkä paremman puutteessa. Haastatellut henkilöt eivät kaipaa keskitettyä lähdekoodivarantoa: esimerkiksi GitHubin osalta organisaatio-ominaisuudet nähdään kömpelönä tai jo olemassa olevaa lähdekoodia ei haluta siirtää minnekään. Läheskään kaikkia tuotteita ei paketoida valmiiksi tuotteiksi, jolloin lopputuotteen jako asennustiedostona ei ole validi asia tai lähdekoodia jaetaan tarkoituksella sellaisenaan sen helppouden vuoksi myös ohjelmistopäivityksen näkökulmasta. Jos tuotetta jaetaan, sen jakamiselle on oma tahonsa, kuten yhteisön sivut tai muut ohjelmiston latauspalvelut. Toivottiin kuitenkin, että lähdekoodikomponentit voisi olla hyvä olla listattuna jossain keskitetyssä palvelussa. Dokumentaatio on tällä hetkellä joko yhteisön sivulla, lähdekoodissa/lähdekoodin yhteydessä tai omin voimin ylläpidetyssä dokumentaatiopalvelussa, kuten Confluence. Keskitetystä dokumentaatiopalvelusta ei varsinaisesti tullut toiveita. Tällainen palvelu olisi ylläpidettävyydeltään luultavasti hankala ja voisi johtaa vanhentuneeseen tai kuolleeseen dokumentaatioon, jolloin palvelun arvo olisi kyseenalainen. Julkinen tai keskitetty tikettienhallintajärjestelmä (issue tracker) nähtiin useasti toivottavana asiana. HSL:llä julkinen tikettienhallintajärjestelmä oli osittain jo toteutettuna waffle.io-palvelussa (integroi GitHub:n issue trackerin), Fintolla taas suoraan GitHubin tikettienhallintajärjestelmän toimesta. CKAN-kehittäjäyhteisö käyttää pääasiassa JIRAa, jota myös Finto aikoo tulevaisuudessa hyödyntää. Toiveita olisi ainakin CKANkehittäjäyhteisössä kuitenkin avoimelle tikettiseurannalle, joista esimerkkinä annettiin GitHub:n oman tikettienhallintajärjestelmän käyttö. Tämä muutos katsottiin nykytilanteessa kuitenkin vielä epärealistiseksi. CKAN-kehittäjäyhteisön osalta esimerkiksi päällekkäisen kehitystyön minimoiminen voisi olla hallittavissa avoimella ratkaisulla, kuten Trello-palvelulla. MML:n toiveena taas keskitetty tikettijärjestelmä, kuten JIRA,

4 jonkin kolmannen osapuolen tarjoamana, joten JIRAn tarjoamisesta osana JulkICTLabia voisi olla hyödyllistä. Fintolla taas toiveena oli jokin JIRAa yksinkertaisempi tarjottu tikettijärjestelmä kolmannen osapuolen tarjoamana, mutta tällaisen löytäminen voi olla haasteellista. Yleisesti ottaen, julkinen kehityskohteiden seuranta olisi oleellista avoimen kehityksen kannalta, jotta kehitys on läpinäkyvää ja oikeasti avointa, se houkuttaisi kontribuutioon, sekä vältettäisiin mahdollisia päällekkäistä kehitystä. Nykyiset hajautetut ja suljetut ratkaisut hankaloittavat selkeästi projektien välistä kommunikointia. Taustana: JIRA on tikettijärjestelmänä ehkä se kaikkein monipuolisin, mutta sen heikkoutena ovat maksullisuus sekä jopa liiat ominaisuudet. JIRAn lähin vastine lienee JulkICTLabissa jo nyt tarjottu vapaa Redmine-ohjelmisto. Yleisesti tätä kartoitusta hallitsivat selkeät kehittäjäyhteisöt sekä toisaalta yleiskuvan mukainen käyttäjäyhteisöjen rakentaminen tuotteen tai tuoteperheen päälle. Kehittäjäyhteisöihin panostaminen voisi olla edistettävä asia ja tätä voitaisiin edistää myös JulkICTLabissa, esim. tarjoamalla tukea sopivan kehittäjäyhteisön löytämiseen tai vaikkapa uuden rakentamiseen, joka on työnä haastava vaatien monipuolista osaamista ja tietoutta. Esimerkkejä kehittäjäportaaleista ovat oskari.org ja ckan.org, jotka ovat web-palveluja joista käy ilmi mm. sosiaalisen median osoitteet ja muu kehitykseen ja palveluun oleellisesti liittyvä tieto. Tietoutta tuotteiden olemassaolosta voisi jakaa keskitetysti ja luonnollisesti esimerkiksi keskitetyn APIlistauksen kautta. Esimerkiksi paikkatietomaailmassa on olemassa jo kansallinen Paikkatietohakemisto, johon on koottuna yhteneväisiä, määrämuotoisesti kuvattuja rajapintoja. Toisaalta on olemassa yleisempi apisuomi.fi, jonka status on kuitenkin epäselvä. Huomion arvoista on, että tieto API:sta voi parhaimmillaan johdattaa myös tuotteen muihin tietoihin. Toisaalta, jotta tämä johdatus voi tapahtua, olisi kaikissa avoimissa tuotteissa pyrittävä siihen että data tarjoillaan myös avoimen rajapinnan kautta. JulkICTLabin tarjoama kehitysympäristö nähdään jo nyt toimivana ratkaisuna joihinkin avoimen kehityksen pulmiin. Parhaillaan infrastruktuuri tarjoaa erityisesti yhteisöllisen kehityksen mahdollistavan virtuaalipalvelinalustan, jonka järjestäminen voi joissain tapauksissa olla haastavaa toimijoille itselleen. JulkICTLabille toivotaan erityisesti pysyvyyttä ja pitkäaikaista jatkoa.

5 Liite 1: Haastattelut Liiteosiossa on kirjatut muistiinpanot tehdyistä haastatteluista. Osa haastatteluista on tehty kirjallisena sähköpostin välityksellä, osa taas luonnollisina keskusteluina esimerkiksi puhelimen välityksellä. Valtori, Kristiina Puharinen ja Taina Hagelberg sekä CSC:ltä Stina Westman ja Mikko Koho Kristiina Puharinen ja Taina Hagelberg vetävät avoindata.fi -projektia, joka tarjoaa palvelun avoimen tiedon löytämiseksi ja avaamiseksi. Stina Westman on etsin.avointiede.fi -palvelun tuoteomistaja ja Etsin-palvelu tarjoaa palvelun avoimen tutkimustiedon löytämiseksi ja avaamiseksi. Mikko Koho on Etsin-palvelun ohjelmistokehittäjä. Valtorin edustajien kanssa käydyissä keskusteluissa on keskitytty CKAN:iin, josta Valtorin edustajat ovat myös toteuttamassa avoimen tuotteen hallintamalliin liittyviä asioita. Aihe on hyvin keskeinen myös raportin tekijälle, joten tämä on toiminut vahvana lähtökohtana jatkotyölle, ja tämä osio sisältää runsaasti tietoutta, jota ei ole tarvinnut käsitellä itse tapaamisessa vaan on raportin tekijän omaa taustatietoa. Tapaamisessa oli mukana myös etsin.avointiede.fi:n edustajia, jotka toivat mukaan erityisesti Opetus- ja kulttuuriministeriön alla olevan portaalin (etsin.avointiede.fi) näkemyksiä. CKAN on avoimen lähdekoodin Python-kielellä toteutettu dataportaaliohjelmisto, jota tuotetaan okf:n toimesta. Ohjelmistoon perustuvia palveluita on Suomessa useita (avoindata.fi, hri.fi, etsin.avointiede.fi) ja kehittäjäyhteisö on hyvin tietoinen toisistaan suhteellisen aktiivisen kanssakäymisen johdosta. Jokaisen portaalin lähdekoodi on avointa ja se löytyy GitHubista toisistaan riippumattomista paikoista. Avoindata.fi:n ja etsin.avointiede.fi:n osalta erityisesti myös perusohjelmistoon on viety parannuksia, jolloin yhteistoiminta koko kehittäjäyhteisön skaalalla on ollut verrattain aktiivista. Tapaamisessa kävi ilmi, että lähdekoodien löytäminen oli kohtalaisen hankalaa, vaikka tietoa lähdekoodeista oli huomattavan paljon. Tapaamisessa ei juurikaan otettu kantaa siihen, mitä tehdään tulevaisuudessa, vaan käytiin läpi enimmäkseen nykytilannetta. Samaten mainittiin että lähdekoodien jakamiseen on olemassa myös CKAN:n oma palvelu, johon voi viedä muille CKAN-kehittäjille/käyttäjille löydettäväksi CKAN:iin tehdyt lisäosat, eli ekstensiot ( Tapaamisessa päätettiin, että CSC:n edustaja (raportin tekijä) selvittää nyt ainakin aluksia edellä mainitun palvelun käyttöä ja keskustelua asian tiimoilta jatketaan myöhemmin. Rajapintoja ei tapaamisessa käsitelty, mutta niistä on käytännössä mainintaa palveluiden sivuilla ja lisäksi CKAN itsessään tarjoaa rajapinnan (RESTful API), joka periytyy suoraan ohjelmistoa käyttäviin palveluihin. Maanmittauslaitos (MML), Jani Kylmäaho Jani Kylmäaho on muun muassa ollut mukana asiantuntijana JulkICTLabin paikkatiedon ekosysteemin kokonaisuuden piloteissa. Maanmittauslaitoksen edustajan kanssa käydyssä keskustelussa keskityttiin erityisesti Maanmittauslaitoksen avoimen koodin nykytilaan hakien osittain tyyppiesimerkkiä olemassa olevasta aktiivista kehitystä tekevän viranomaistahon ohjelmistokehityksen maailmasta. Keskeisin tapaamisessa läpikäyty ohjelmisto on Oskari.org. Oskari.org on avoimeen lähdekoodiin perustuva ohjelmisto, joka tarjoaa mahdollisuuden esimerkiksi omien karttanäkymien lisäämiseen palveluun yhdistettynä tilastotiedolla. Lisäksi keskustelussa tutustuttiin tiedostopalveluun sekä sivuttiin kansainvälisiä hankkeita ja JulkICTLab:n pilotteja.

6 Oskarin lähdekoodi on jaossa GitHubissa, repositoriossa nls-oskari, jossa nls tulee sanoista National Land Survey of Finland. Maanmittauslaitokselta on GitHubissa jaossa myös tiedostopalvelun lähdekoodit, Maanmittauslaitoksen omassa repositoriossa Lähdekoodin suhteen MML:ssa on vastaisuudessa tarkoituksena tuottaa se avoimena. Nykytilanne on se että osa lähdekoodista on vielä suljettuna. Oskari tulee tarjoamaan myös avoimen rajapinnan, josta löytyy tietoa oskari.org-palvelussa muita rajapintoja ei tapaamisessa tullut ilmi. Versionhallintajärjestelmän osalta MML:n osalta on huomattava että heillä on siirrytty SVN:stä Git:n käyttöön. Tapaamisessa keskusteltiin vapaasti myös julkisen sektorin koodien olinpaikasta. Yhtenä ideana MML:n edustaja näki esimerkiksi jonkinlaisen sateenvarjo-repositorion. Olemassa olevia lähdekoodeja ei haluta siirtää nykyisestä olinpaikasta. Taustatiedon keräämistä varten MML:n edustaja antoi tiedoksi henkilöitä, joilla voisi olla kiinnostusta tai näkemystä asiaan. Näihin otettiin yhteyttä myöhemmin. Lisäksi haluttiin antaa viestiä JulkICTLabille, että tarjottu ympäristö on hyvä kehitystyöhön ja sille toivotaan pitkää jatkuvuutta. Julkinen kehitysympäristö voi tarjota lisämahdollisuuksia muun muassa yhteiskehitykseen, kun kehitysympäristö voidaan pitää omasta suljetusta ympäristöstä erillään. Navinova, Antti Rainio Antti Rainion tausta liittyy muun muassa paikkatietoon ja yleisesti laajemman kuvan hallitsemiseen selvityksen alla olevan asian osalta. Keskustelu käytiin hyvin vapaamuotoisena puhelinkeskusteluna, jolloin omille näkemyksille oli runsaasti sijaa. Tässä osiossa kerrotut asiat ovat monesti tuon keskustelun innoittamia. Keskitetty ratkaisu esimerkiksi koodin ja muiden komponenttien hallinnassa ei välttämättä ratkaise kaikkea. Pahimmillaan tämä ratkaisu voi johtaa sekalaiseen varastoon, jossa mikään ei liity toisiinsa. Tällöin tarkoitukseltaan hyvä ratkaisu ei tuo ollenkaan tai lähes ollenkaan lisäarvoa. Parempi ratkaisu olisi sitoa komponentit lähelle niihin liittyviä muita komponentteja tai aihealuetta. Normaalitilanne kun on että etsitään käsiteltävään asiaan liittyviä materiaaleja sen sijaan että haluttaisiin esimerkiksi listaus hyvin sekalaisesta kokoelmasta komponentteja. Avoin kehitys - ja sitä myöten avoin lähdekoodi hyötyy avoimuudesta erityisesti, jos tuotteen ympärille voidaan tämän avulla luoda yhteisö. Tällöin ideaalitapauksessa koodin kehitystä alkaa tulla myös ulkopuolelta, joka tuottaa parhaimmillaan esimerkiksi kustannussäästöjä. Avoin kehitys, joka pitää sisällään myös avointa tietoa tulevista kehityskohteista, voi estää saman asian toteuttamista usean toimijan toimesta. Kehitystä pitäisi pyrkiä laajentamaan myös kansainvälisesti, esimerkiksi luomalla tai liittymällä globaaleihin ekosysteemeihin. Pyrittäessä kansainvälisyyteen on tärkeää ylläpitää käytäntöjä, joissa dokumentaatio ja muu oheismateriaali tarjotaan suomen lisäksi englanniksi. Keskustelussa puhuttiin myös rajapinnoista avoimen datan lähtökohdista. Avoin data tulisi aina tarjota myös avoimen käyttörajoittamattoman rajapinnan kautta, muutoin voi jopa kyseenalaistaa, onko data oikeasti avointa. Ilman rajapintaa oleva avoin data on myös hyvin vaikeasti hyödynnettävissä ja jopa palveluna osittain turha, jos sopivan rajapinnan saadakseen joutuu jopa kopioimaan datat. Olisi syytä miettiä suositusta siitä että milloin ja miten on tarjottava avoimia rajapintoja.

7 HSL, Tuukka Hastrup HSL:n edustajan kanssa käytiin keskustelua sähköpostin välityksellä. HSL:ään liittyvän ohjelmistokehityksen keskeisin ilmiö lienee HSL:n kehittäjäyhteisö dev.hsl.fi. Tässä palvelussa on runsaasti materiaalia, kuten tietoa tuotteista, dokumentaatiota sekä tietoa asiaan liittyvistä palveluista. Lähdekoodit ovat jaossa GitHubissa, Ohjelmistoilla on olemassa myös kansainvälisiä kytköksiä. Erityisesti Hastrup mainitsi Avoin reittiopas -projektin. Tämän kehitys on jakautunut esimerkiksi useampaan GitHub-projektiin, mutta kehityksen avoimuus ja yhdistely on mahdollisestettu Waffle-palvelun avulla ( Hastrup huomautti myös että GitHub:n organisaatioihin liittyvät rajoitteet ovat ongelmallisia: esimerkiksi projekteja ei voi järjestää eikä korostaa ja kuvauskin on maksimissaan 140 merkkiä. Finto, Osma Suominen Finton edustajan kanssa käytiin keskustelua sähköpostin välityksellä. Lisäksi Finto oli selvityksen tekijälle kohtalaisen tuttu ennalta. Hän vastasi kyselyyn Kansalliskirjaston/Finton/Skosmoksen osalta. Jaettava ohjelmistokomponentti Kansalliskirjastolla on käytännössä Skosmos, johon Finto siis perustuu. Ohjelmistoa jaetaan GitHubista ( koska ohjelmiston jakelu on helppoa GitHubin ominaisuuksien ansiosta (teknisesti release = tag) ja jakelu jatkokäyttäjille hoidetaan ohjeistamalla kloonaamaan lähdekoodi. Mahdollisuutta jakaa lähdekoodi zip-pakettina nähdään huonona ratkaisuna sekä GitHubissa että vaihtoehtoisessakin jakelupalvelussa. Finto-palvelun dokumentaatiota löytyy suomeksi, ruotsiksi ja englanniksi julkisesta wikistä (tekninen dokumentaatio käyttäjädokumentaatio Dokumentaatiopalveluiden katsotaan palvelevan hyvin kohderyhmäänsä, joten dokumentaatioon ei kaivata muutoksia. Yhteisösivustoakin Skosmoksen ympärille on suunniteltu, mutta se toteutettaisiin luultavasti niin että sivu olisi staattinen ovimattosivu, josta löytyisi esim. linkki GitHubin wikiin. Edellä mainittujen lisäksi API-dokumentaatiolle on olemassa erillinen ovimattosivunsa ( joka linkkautuu GitHubin wikissä olevaan API-dokumentaatioon. Apihakemistojen osalta mainittiin API-Suomi-rajapintahakemiston olemassa olo, ja muistutettiin että uutta tuskin tarvitaan jos on jo olemassa olevia vastaavia palveluita. Skosmoksen kehityksessä käytetään GitHubin tiketinhallintajärjestelmää. Tämä on ollut ihan riittävä tähän mennessä. Laajempaan projektin ja palvelun tehtävien seuraamiseen kehityksessä ollaan ottamassa käyttöön Kansalliskirjaston JIRAn. JIRAa helppokäyttöisemmälle tikettijärjestelmälle voisi olla Kansalliskirjaston osalta kysyntää. Muut keskustelut ja tapaamiset Tässä osiossa on tiivistettynä ideoita, joita on tullut aiemmin mainituista tapahtumista. API-umbrella (avointa lähdekoodia, käytössä mm. Api.data.gov), lähde 6Aika dataportaalikokous Avoin kehitys: issue trackerit suljettuja. GitHub:n issue trackerkin voisi toimia.