Helsingin yliopisto
Helsingin yliopiston lähtökohtana on suosia avoimia teknologioita ja avoimen lähdekoodin ratkaisuja. Käytännön tilanteissa valintoja ohjaavat avoimuuden lisäksi muutkin periaatteet, jossa punnitaan niin käytettävyyttä, ylläpitoa kuin kustannuksiakin. Eduistaan huolimatta avoin lähdekoodi ei aina ole synonyymi laadukkaalle ohjelmistotuotannolle. Tässä blogiartikkelissa kerrotaan, miten Helsingin yliopisto linjaa avoimen koodin käyttöä, mitä avoimia ohjelmistoja yliopistossa käytetään ja millaisia näkökulmia avoimeen koodiin liittyy organisaation näkökulmasta.
(This article is also available in English.)
Teksti: Hannu Toivonen, Teo Kirkinen & Minna Harjuniemi (koonnut Juuso Ala-Kyyny)
Tiedeyhteisössä on jo pitkään puhuttu tutkimuksen avoimuudesta niin artikkelien kuin datankin kohdalla. Myös avoin lähdekoodi kuuluu avoimen tieteen kokonaisuuteen, mutta sillä on rooli myös laajemmin niissä palveluissa ja työkaluissa, joita yliopistoissa käytetään päivittäin.
Helsingin yliopistossa käydään keskustelua avoimen lähdekoodin käytöstä tietojärjestelmissä, ohjelmistoissa ja kehitystyössä.
Tässä artikkelissa kerromme, miten Helsingin yliopisto linjaa avoimen koodin käyttöä, mitä avoimia ohjelmistoja yliopistossa käytetään ja millaisia näkökulmia avoimeen koodiin liittyy organisaation näkökulmasta.
Avoin lähdekoodi
|
Avoin koodi Helsingin yliopistossa lähtökohtana
Helsingin yliopiston periaatteena on tehdä avointa kehitystä sekä suosia avoimia teknologioita ja avoimen lähdekoodin ratkaisuja (ks. kokonaisarkkitehtuuriperiaatteet, kohta 2, ja teknologia-arkkitehtuuriperiaatteet, kohta 3). Avointen ohjelmistojen käyttöä perustellaan eri tavoin:
”Elinkaarinäkökulman, teknologia-arkkitehtuurin yhtenäisyyden toteuttamisen, ylläpidettävyyden parantamisen, toimittajariippumattomuuden sekä teknologia-arkkitehtuurin toimittajariippumattomuuden takaamiseksi on teknologia-valinnoissa suosittava avoimia ja yleisiä teknologioita sekä avoimen lähdekoodin ratkaisuja.” (Teknologia-arkkitehtuuriperiaatteiden kohta 3)
Käytännön tilanteissa valintoja ohjaavat avoimuuden lisäksi muutkin periaatteet, jotka saattavat olla keskenään ristiriitaisia. Näitä rajoituksia käsittelemme tuonnempana.
Joskus myös kysytään, onko yliopistolla suositusta omassa ohjelmistokehityksessä käytettävästä avoimen lähdekoodin lisenssistä. Sellainen on: ensisijaisesti suositellaan MIT-lisenssiä.
Avoimen lähdekoodin järjestelmät ja sovellukset HY:ssä
Mitä avoimen lähdekoodin järjestelmiä Helsingin yliopistossa on käytössä? Täydellistä listaa ei ole olemassa eikä aivan helposti tuotettavissa. Palvelinalustat ja varusohjelmistot ovat kuitenkin Helsingin yliopistossa pääosin avointa koodia, ellei sovellus edellytä Microsoftin alustaa. Infrastruktuurin puolella avoimen koodin järjestelmiä on valtavasti, samoin tietoliikenteen ja sen hallinnan, tietoturvan, lokituksen, järjestelmäseurannan puolella. Myös keskeisin kirjautumisjärjestelmä (login.helsinki.fi), integraatiopalvelu (ESB) ja ohjelmistorajapintojen API-hallintaväline ovat avoimen lähdekoodin järjestelmiä. Isommista järjestelmistä Helsinki.fi:n lisäksi Flamma (intranet) ja tuleva identiteetinhallintajärjestelmä, postinvälitys ja postilistat sekä hakupalveluiden indeksoijat ovat pohjimmiltaan avoimen lähdekoodin tuotteita. Erityisesti tutkimuksen tueksi tarkoitettuja avoimen lähdekoodin infrastruktuurikerroksia on tallennuspalveluissa (mm. ceph ja lustre).
Pieni IT-sanasto esimerkkeineen
|
Infrastruktuurin puolella avoimen lähdekoodin ratkaisut ovat soljahtaneet mukaan melkein kuin itsestään, koska ne tyypillisesti tehostavat hallintaa ja ovat ennustettavia. Ongelmatilanteissa asioita on mahdollista selvittää itse kooditasolle asti. Myös suljetun koodin infrastruktuurijärjestelmillä (mm. MS, Oracle) on pärjätty tähän asti hyvin, vaikka tietyissä tilanteissa ollaan riippuvaisia siitä, mitä toimittaja suvaitsee tehdä.
Yleisesti käytössä olevista avoimen lähdekoodin sovelluksista tilasto-ohjelmisto R lienee käytetyimpiä. Sen sijaan esimerkiksi Libreoffice ei ole ottanut jalansijaa vastaavalta Microsoft-tuoteperheeltä. Unitube-videopalvelun taustajärjestelmänä käytettävä Opencast-videopalvelu on laajassa käytössä oleva avoimen koodin sovellus. Tietotekniikkakeskuksen oma ohjelmistotuotanto on tehnyt siihen asiakkaille käyttöliittymän (Unitube Lataamo). Pari vuotta sitten toteutettiin pilottiprojekti, jossa verrattiin kolmea kaupallista videopalvelua mutta päädyttiin jatkamaan Unituben/Opencastin kanssa. Rajalliset kehittäjäresurssit asettavat omat haasteensa: HY:n käyttäjiltä tulee paljon hyviä kehitysehdotuksia, joita vastaavia toiminnallisuuksia on kaupallisissa palveluissa.
Valintatilanteessa punnitaan eri kriteereitä
Käytännön valintatilanteessa on tarkkaan punnittava eri vaihtoehtoja – niin avoimuuden, käytettävyyden, ylläpidon käytännöllisyyden kuin kustannustenkin näkökulmasta. Käyttäjien kannalta oleellista on palvelu, ei pelkästään sovellus, jolla palvelua tuotetaan. Kilpailutuksen kriteerit määrittelevät usein sen, mitä hankitaan – järjestelmä vai palvelua.
Palveluja hankittaessa on esimerkiksi hyvä tarkastella, saako sen valmiina pilvipalveluna, jolloin mukana on väistämättä kaupallinen toimija tuottamassa palvelua. Kaikkea ei voi tehdä itse vaan on valittava, mihin yliopistolaisten omaa asiantuntemusta käytetään. Pilvi- ja SaaS-palveluissa (Software as a Service) rajapintojen avoimuus on keskeisintä. Myös sovelluksen laatu ja kustannukset vaikuttavat valintaan.
Käyttäjien kannalta oleellista on palvelu, ei pelkästään sovellus, jolla palvelua tuotetaan. Kilpailutuksen kriteerit määrittelevät usein sen, mitä hankitaan – järjestelmä vai palvelua.
Ekosysteemit, kuten Microsoft, SAP tai Salesforce, edellyttävät jonkinasteista sitoutumista, ja sitoutumista on punnittava tarkkaan. Avoimen koodin sovellusten käyttäminen on järkevää silloin, kun yliopiston puolelta osallistutaan kehitystyöhön edes pienellä panoksella. Esimerkkinä voi mainita vaikkapa Moodlen, avoimen lähdekoodin virtuaalisen oppimisympäristön, joka liittyy yliopiston perustehtäviin ja jota on käytetty HY:ssä toistakymmentä vuotta. Vuosien varrella tullut paineita Moodlen vaihtamiseen johonkin modernimman oloiseen kaupalliseen oppimisympäristöön. Ne eivät kuitenkaan tyypillisesti ole yhtä monipuolisia, eivätkä tue akateemisessa ympäristössä kehitettyjä integraatioita (mm. TestMyCode, Stack). Pääsy Moodlen koodiin auttaa myös arvioimaan lisäosien käyttöönoton ja päivitysten tekemisen riskitasoa.
Avoimen koodin sovellusten käyttäminen varsinaiseen palvelutuotantoon edellyttää perehtymistä tuotteen kehityksen asteeseen sekä arviota tulevasta elinkaaresta. Samat asiat pätevät toki kaupallisiin sovelluksiin.
Avoin vs. kaupallinen ohjelmisto
Suljetun koodin läpinäkymättömyys huolestuttaa monia valistuneita käyttäjiä etenkin tietosuojan osalta. Ajankohtaisena esimerkkinä tästä ovat Zoom, Teams ja Skype. Monelle yliopistolaisen käyttämälle ohjelmalle on jo nyt olemassa avoimen lähdekoodin vaihtoehto, esimerkiksi: Zoom ja Teams (vaihtoehtona Jitsi), Google Chrome (Firefox, Chromium) ja OneDrive (Nextcloud). Lisäksi opiskelussa käytetään erilaisia suljettuja ohjelmistoja kuten Slack, Telegram ja Whatsapp, joille olisi myös avoimen lähdekoodin vaihtoehtoja, joita yliopisto voisi ainakin periaatteessa tarjota itse.
Jos tarkastellaan Zoomia ja Teamsia, ne sisältävät laajan infrastruktuurin, jossa palvelua pyöritetään. Kaikkea ei voi pyörittää itse, jos siihen ei ole riittävästi tekijöitä. Ei myöskään kannata tehdä sellaista itse, mikä on moneen kertaan tehty ja valmiina saatavilla. Etäopetuksessa ja -palavereissa käytettävät Zoom ja Teams ovat niin massiivisia sovelluksia ja edellyttävät niin laajaa infraa, että kaupallinen ratkaisu on tällä hetkellä ainoa realistinen ratkaisu.
Kaikkea ei voi pyörittää itse, jos siihen ei ole riittävästi tekijöitä. Ei myöskään kannata tehdä sellaista itse, mikä on moneen kertaan tehty ja valmiina saatavilla.
Avoimen koodin Nextcloudin päälle on HY:ssä toteutettu tutkimusdataan liittyviä palveluita, koska se on ollut erinomainen alusta niihin palvelutarpeisiin (ks. Datacloud-palvelusta). Sen sijaan on syytä epäillä, että yliopiston resursseilla voitaisiin toteuttaa OneDriven kaltainen palvelu kymmenille tuhansille käyttäjille. Verkkoselainten kohdalla tuettujen selainten valikoiman määrää pitkälti sovellusten tarpeet. Avoimen lähdekoodin verkkoselaimista Firefox on käytössä HY:ssä.
Osaan avoimen lähdekoodin tuotteista yliopisto on ostanut tuen, jolla toimittajalta saadaan valmiiksi tehtynä asioita ja ongelmatilanteissa ratkaisuapua. Tällaisesta esimerkkinä on Red Hat Linux-jakeluna – maksuttomien Centosin ja Debianin lisäksi – tai OpenShift konttien ajoalustana. Näissä on arvioitu, että maksettavalla summalla säästetään vähintään saman verran omaa henkilötyötä, ja lisäksi vaikeissa vikatilanteissa saadaan ulkopuolista apua. Näiden tuotteiden ympärillä on myös liiketaloudellista toimintaa, joka varmistaa jatkuvuuden.
Loppusanat
Avoimen lähdekoodin käyttö on lisääntymässä ja Helsingin yliopistokin osallistuu kehitystyössään moniin avoimen lähdekoodin hankkeisiin. Eduistaan huolimatta avoin lähdekoodi ei kuitenkaan ole synonyymi laadukkaalle ohjelmistotuotannolle. Parhaimmillaan avoin lähdekoodi tuottaa loistavia järjestelmiä, jotka ovat turvallisia ja kustannustehokkaita. Huonoimmillaan kehittäjäyhteisö rapistuu ympäriltä, ja on siirryttävä johonkin muuhun tuotteeseen. Ja aina välillä on enemmän pulaa aivoista ja käsistä kuin rahasta: joissakin tilanteissa helposti käyttöönotettava suljettu koodi on paras vaihtoehto.
Lopuksi voidaan vähän haaveilla: olisi hienoa, jos rajapintalähtöinen kehittäminen lähtisi oikeasti liitoon Helsingin yliopistossa, ja hyödyllisiä ohjelmallisia rajapintoja olisi tarjolla kehittämisestä innostuneille. Tällainen kehitys saattaa viedä vielä vuosia, mutta sitä kohti olisi hyvä määrätietoisesti mennä.
Edit: Alkuperäisessä artikkelissa oli ohjelmistojen kohdalla viittaus CC-lisensseihin: ”ensisijaisesti suositellaan MIT-lisenssiä, ellei tekijä erityisesti halua käyttää jotain Creative Commons -lisensseistä.” CC-lisenssiä ei kuitenkaan suositella ohjelmistoille (ks. kommentit).
Hannu Toivonen (TUHAT, ORCID) toimii tietojenkäsittelytieteen professorina Helsingin yliopistossa. Toivonen tutkii ja opettaa tekoälyä ja datatiedettä. Hän toimii myös matemaattis-luonnontieteellisen tiedekunnan opetusvaradekaanina kaudella 2018–21.
Teo Kirkinen toimii tietotekniikkapäällikkönä tietotekniikkakeskuksessa. Hän on tietotekniikkaratkaisut-yksikön päällikkö. Kirkinen työskentelee mm. opettamiseen liittyvien IT-palveluiden, videoviestinnän, verkkopalveluiden sekä palveluiden kehittämisen parissa.
Minna Harjuniemi toimii tietotekniikkapäällikkönä tietotekniikkakeskuksessa.
Hyvä teksti. Mielestäni Linuxin (ja Linuksen) roolia avoimen lähdekoodin ajavana voimana ei voi aliarvioida. Ilman sitä läpimurtoa, ei välttämättä tälläistä keskustelua edes käytäisi. Yliopistolla on myös oma Ubuntuun perustuva Linux-jakelu (Cubbli), jota ei tekstissä mainittu.
Olisi ollut mielenkiintoista lukea tarkemmin yliopiston siirtymisestä Microsoftin sateenvarjon alle mm. sähköpostin osalta ja kuinka tässä tapauksessa avointa ja suljettua lähdekoodia punnittiin.
En ole postiylläpitäjä, joten kommentoin asiaa tietotekniikkakeskuksesta mutta kuitenkin hieman kauempaa katsoen.
Yliopistolla oli pitkään käytössä avoimen koodin järjestelmillä toteutettu IMAP-protokollaa käyttävä sähköpostijärjetelmä. Siihen oltiin sinällään hyvin tyytyväisiä ja onhan se edelleenkin erityistarpeisssa käytössä. Sen sijaan webmail-käyttöliittymä, joka muistaakseni oli saksalainen avoimen koodin sovellus, herätti hieman ristiriitaisempia kokemuksia. Sen käyttöliittymä kehittyi myös eri suuntaan kuin toivoimme.
Saimme paljon toiveita yliopistolaisille yhteisestä kalenterijärjestelmästä. Hallinnossa oli käytössä IBM:n Lotus Notes mutta se ei lisenssisyistä ja muutenkin ehkä vanhanaikaisena soveltunut laajemmin käyttöönotettavaksi. Pilotoimme myös webmailimme ohessa erästä avoimen koodin kalenterisovellusta mutta emme päätyneet ottamaan sitä käyttöön vaan päädyimme Office 365 -pakettiin kuten moni muukin yliopisto. Kokonaispaketti ratkaisi, mukana tuli myös tiedostojen pilvitallennus (Onedrive), joka korvasi erillisen kaupallisen tiedostojentallennusraktaisun.
Yliopiston lakimiesten ja johdon kanssa kävimme myös laajalti lävitse ”pilvipostin” käyttöönottoon liittyviä kysymyksiä.
Enimmäkseen asiallista tekstiä, vaikka avoimen tieteen blogissa olisi toivonut enemmän näkökulmaa tutkimuksen ja opetuksen ohjelmistoihin hallinnon järjestelmien ja toimistosovellusten sijaan. Tähän liittyisi paljon tärkeitä kysymyksiä, kuten mitä opetetaan (esim. kaupallinen SAS/Matlab vai avoin R/Python?), minkä ympäristön päälle kirjoitetaan tutkimuskoodit, ja missä määrin tutkimus voi perustua suljetulla ohjelmistolla tehtyyn analyysiin, jonka toiminnasta ei voi tietää tarkasti.
Kirjoituksessa vihjattiin vaarallisesti, että CC-lisenssejä voisi käyttää softaan. CC itse ei tätä suosittele (https://creativecommons.org/faq/#can-i-apply-a-creative-commons-license-to-software), ja minusta yliopiston pitäisi ehdottomasti noudattaa samaa linjaa. CC-lisenssit eivät ole ohjelmistolisenssejä!