Avoin lähdekoodi Helsingin yliopistossa – miten linjataan, miten käytetään?

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.

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 lähdekoodi (open source) liittyy tietokoneohjelmistojen kehittämiseen ja jakamiseen. Avoin lähdekoodi on kenen tahansa luettavissa (läpinäkyvyys) ja muokattavissa (räätälöinti). Oikeudet jatkokäyttöön määritellään lisensseissä (esim. MIT- tai GPL-lisenssit).
  • Avoin lähdekoodi erotetaan kaupallisista ohjelmistoista, joiden käytöstä ja kehittämisestä päättävät yritykset.
  • Avoin lähdekoodi mahdollistaa laaja-alaisen kehitysyhteistyön ja suuren käyttäjäkunnan, joiden tarjoama tuki voi parantaa ohjelmistojen laatua, tietoturvaa ja ohjelmien yhteentoimivuutta.
  • Organisaation näkökulmasta avoin ohjelmisto voi tuoda säästöä (lisenssimaksuista) ja riippumattomuutta ulkomaisista suuryrityksistä.
  • Avoimen lähdekoodin ongelmina on tuotu esiin kehitystyön jatkuvuuden takaaminen, kun se perustuu vapaaehtoisuuteen – aktiivisia kehittäjiä ei aina ole riittävästi.
  • Tunnettuja avoimen lähdekoodin ohjelmia ovat Firefox-selain, LibreOffice- ohjelmisto ja Linux-käyttöjärjestelmä, jonka kehitystyön Linus Torvalds aloitti 30 vuotta sitten Helsingin yliopistossa.

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

  • Palvelinalusta = fyysinen tai virtuaalinen palvelinlaitteisto käyttöjärjestelmineen, jossa sovellusta suoritetaan. Tietotekniikkakeskuksen konesaleissa on noin 260 Intelin suoritinarkkitehtuuriin perustuvaa fyysistä palvelinta sekä VMware-virtualisointialustalla 850 kpl virtuaalipalvelimia. Palvelimista noin 2/3 on avoimella Linux-käyttöjärjestelmällä ja 1/3 Windows-palvelimia.
  • Varusohjelmisto = palvelimessa tarvitaan käyttöjärjestelmän ja varsinaisen sovelluksen lisäksi erilaisia varusohjelmia kuten www-palvelin Apache tai Nginx, php-kielen ympäristö, Java-sovelluspalvelin ja MariaDB-tietokantapalvelin.
  • Infrastruktuuri = palvelinalustan ja varusohjelmistojen muodostama kokonaisuus. Se voi sijaita omassa konesalissa tai pilvipalveluna (IaaS = Infrastucture as a Servive) Googlen, Amazonin, Microsoftin CSC:n konesalissa.
  • Tietojärjestelmä (vs. palvelu) = tietotekniikkapalvelu koostuu yleensä palvelimessa toimivasta tietojärjestelmästä sekä siihen liittyvistä tuki- ja neuvontapalveluista. Yhdessä ne toteuttavat jotakin yliopiston toimintaprosessia. Esimerkiksi sähköpostipalvelu muodostuu Microsoftin pilvipalveluna toteutusta sähköpostijärjestelmästä, jota täydentää yliopiston omilla palvelimilla roskapostin suodatuksen sekä esimerkiksi postilistojen hallinnan järjestelmät. Palvelu muodostuu järjestelmien lisäksi ohjeistuksesta, helpdeskin tarjoamasta käyttäjätuesta sekä yliopiston sähköpostin käyttöpolitiikoista.
  • Ekosysteemi = ekosysteemiksi kutsutaan varusohjelmien sekä sovelluskehitysympäristön muodostamaa kokonaisuutta, johon on kustannustehokasta toteuttaa IT-palveluita sen jälkeen, kun ekosysteemi on kerran otettu käyttöön. Yliopisto on valinnut käyttöönsä useita ekosysteemejä, joista osa rakentuu avoimen koodin järjestelmien varaan, osa on kaupallisia. Kaupallisista ekosysteemeistä esimerkkejä ovat Microsoft Office 365 sekä asiakkuudenhallinnassa käytetty Salesforce.

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.

Kuvalähde: Unimaterial Bank (Helsingin yliopisto)

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.

4 vastausta artikkeliin “Avoin lähdekoodi Helsingin yliopistossa – miten linjataan, miten käytetään?”

  1. 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.

    1. 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ä.

  2. 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ä!

  3. Juttu painottui niihin järjestelmiin ja palveluihin, joita tarjotaan jokseenkin keskitetysti. Moni niistä liittyy toki suoraan opetukseen ja tutkimukseen (mm. R, ceph, lustre, Moodle, TestMyCode, …).

    Eri tieteenalojen, tutkimusryhmien ja koulutusohjelmien omat käytännöt avoimen koodin käytöstä ja opetuksesta olisivat ihan oman selvityksen ja juttunsa aihe (vinkkinä blogin toimittajille). Opetuksen avoimeen lähdekoodiin on blogissa otettukin aiemmin kantaa: https://blogs.helsinki.fi/thinkopen/avoin-opetus-ohjelmistot/

    Kiitos CC-lisenssiä koskevasta kommentista. Blogissa (ja HY:n suosituksessa?) näyttää olevan virhe. CC ei tosiaan sovi hyvin ohjelmistoille.

Kommentit on suljettu.