Åpen kildekode vs åpent tilgjengelig kode

Målet er at all offentlig kode skal være åpent tilgjengelig (coding in the open). Kildekoden publiseres og forvaltes som åpen kildekode, og bruker den tilhørende infrastrukturen og mekanismene. Imidlertid er etablering av et langsiktig bærekraftig nettsamfunn (community) ikke nødvendig i denne sammenhengen. Ansvaret for videreutvikling og forvalting vil uansett ligge hos den offentlige virksomheten. Hvis man i tillegg klarer å etablere et åpent kildekode-nettsamfunn, er det å betrakte som en bonus.

Hva skjer i resten av verden?

I Storbritannia snakket GOV.UK allerede i 2012 om «Coding in the open», og understreket forskjellen mellom åpen kildekode og åpent tilgjengelig kode.

We tend to talk about that as Coding In The Open rather than Open Source. Partly because we're not currently in a position to build and support a community around that code, and partly because most of it's so tailored to our system that we're not sure how useful it will be to others right now. But rest assured, if you see something useful you can use it - it's published under an MIT licence

Code for America startet allerede i 2009 og forvalter flere hundre åpne produkter på GitHub. EU-kommisjonen lanserte nylig sin plan for å forvalte sine produkter som åpen kildekode. Beslutningen lener seg på en undersøkelse som peker på teknologiuavhengighet, konkurransekraft og innovasjon.

Her hjemme har Digdir ingen tydelige føringer på dette området (men flott at Altinn3 er åpen kildekode). Arkitekturprinsipp 5 - Del og gjenbruk løsninger bør komme med en tydelig anbefaling. Arkitekturprinsipp 6: Lag digitale løsninger som støtter samhandling, nevner bruk av åpen kildekode: «6.9Vurder bruk av åpen kildekode fremfor lukkede, kommersielle løsninger». Også i Digitaliseringsrundskrivet –regjeringens sammenstilling av pålegg og anbefalinger om digitalisering i offentlig sektor – glimrer åpen kildekode med sitt fravær.

NAV sørger nesten på egen hånd for at det ikke er helsvart på hjemmebane. Inspirert av GOV.UK har NAV tydelige retningslinjer for å forvalte kode åpent tilgjengelig. Det vises også godt på GitHub, der NAV IKT har over 1000 prosjekter. Skatteetaten ligger litt etter i løypa, men er på gang og lanserte nylig en rekke produkter som åpen kildekode.

10 grunner til at all offentlig kode bør være åpen

#1 Finansiert av offentlige midler

Utviklingen av produkter og tjenester i offentlige virksomheter er finansiert med fellesskapets midler. Det er med andre ord bygget med innbyggernes midler, og bør være åpent tilgjengelig for oss.

#2 Offentlige virksomheter er monopolister

Store deler av offentlig forvaltning møter ikke konkurranse. Eksempelvis er det ingen konkurrenter innenfor innkreving av skatt, tildeling av studielån eller foreldrepenger. Det er med andre ord ingen forretningshemmeligheter, og kildekoden bør derfor være åpen.

#3 Kode er implementasjon av regelverket

Systemene som lages av offentlige virksomheter speiler lover og regler som virksomhetene forvalter. Selv om abstraksjonsnivået og omfanget er ulik, er kode og regelverk prinsipielt to sider av samme sak. Begge deler bør være åpne.

Både regjeringen og Digdir har initiativer for «Klart og digitaliseringsvennlig lovverk». Noen drømmer attpåtil om å skrive lovene våre som kode.

#4 Offentleglova – transparent offentlig forvaltning

Offentleglova heter egentlig «Lov om rett til innsyn i dokument i offentleg verksemd». Den er grunnlaget for at alle skal kunne ettergå beslutninger og vedtak i offentlig forvaltning, og brukes mye av journalister. Intensjonen til offentleglova samsvarer veldig godt med åpen offentlig kildekode:

Formålet med lova er å leggje til rette for at offentleg verksemd er open og gjennomsiktig, for slik å styrkje informasjons- og ytringsfridommen, den demokratiske deltakinga, rettstryggleiken for den enkelte, tilliten til det offentlege og kontrollen frå ålmenta. Lova skal òg leggje til rette for vidarebruk av offentleg informasjon.

#5 Åpen kildekode er godt personvern

Personopplysningsloven understreker flere steder at behandlingen av personopplysninger må fremstå som åpen og forståelig. Ved å åpne kildekoden ville alle kunne se hvordan data blir behandlet, hvilke grep som er gjort for å sikre systemet og data, og hvordan eksempelvis innebygd personvern er gjennomført i praksis.

#6 Synlighet vil gi bedre kode

Åpen kildekode vil fremme kvaliteten. Når man vet at det man lager er synlig og tilgjengelig for alle, vil man i større grad bry seg om kvaliteter som lesbarhet, forvaltbarhet, sikkerhet og testbarhet.

Anna Shipman i GOV.UK skriver også om denne effekten:

It encourages good practice
When you know someone is watching, you tend to take greater care. You're more inclined to document your work clearly. You make sure your code is secure by keeping secrets separate from the code. You are polite and constructive in code reviews, and you follow good architectural principles.

In short: when other people can see your work, you tend to raise your game.

#7 Flere øyne finner flere feil

Linus’ lov sier at «given enough eyeballs, all bugs are shallow»: Jo flere som jobber med en kodebase, jo flere feil vil de finne. Påstanden er omstridt, og eksempler som Heartbleed og Log4Shell viser med all tydelighet at det ikke finnes noen garantier. Imidlertid er det indikasjoner på at populære åpen kildekodekomponenter mottar flere feilrettinger enn mindre populære. I alle tilfeller gjør åpent tilgjengelig kode det mulig for alle som er interessert å gjøre kodegjennomganger.

#8 Gjenbruk

Gjenbruk er ledergruppas våte drøm og teknologenes mareritt. Rett nok brukes og gjenbrukes en rekke plattform- og infrastrukturkomponenter. Når koden blir spesifikk for forretningsdomenet, blir gjenbruk vanskeligere. Det er lettere å bruke NAV sin nais-plattform enn å gjenbruke beregning av sykepenger. Gjenbruk kan betraktes som en bonus, spesielt for domenespesifikk kode.

Dette er også grunnen til å vektlegge åpent tilgjengelig kode framfor åpen kildekode med et levende nettsamfunn. Men gjenbruk kan allikevel forekomme. Det er ikke lenge siden jeg plukket opp at en kollega hadde tatt i bruk en funksjon som Kartverket publiserer åpent. En sekundæreffekt er at andre virksomheter kan la seg inspirere av og bruke løsningsmønstre som er åpent tilgjengelig.

#9 Gratis håndtering og tjenester

Mange tjenester tilbyr gratis eller redusert pris for åpen kildekode. Noen eksempler er GitHub, Snyk og DataDog. Her er en lengre liste.

#10 Økt konkurranse og attraktivitet

Åpent tilgjengelig kode kan bidra til å øke konkurransen. Konsulenttilbydere får mulighet til å sette seg inn i eksisterende kodebaser, og dermed få et vesentlig bedre grunnlag for å levere tilbud og folk. Tilgang til kodebasen kan også bidra til å påvirke hvor attraktiv en arbeidsgiver er, både for innleide og ansatte.

Sikkerheten må røktes i hele livssyklusen

Åpent tilgjengelig kode eksponerer en ny angrepsflate og gjør det lettere å finne sårbarheter. Angripere får kortere vei til svakheter i kode og tredjepartsbiblioteker. Sikkerheten må derfor røktes fra vugge til grav for alle systemer virksomheten har ansvar for.

Dette ikke er unikt for åpen kildekode. Nærmest daglig rapporteres det i nyhetene om innbrudd, lekkasjer og utpressingsangrep, uavhengig av hvordan koden forvaltes. Sikkerhet er obligatorisk i hele livssyklusen for alle systemer i den digitale tidsalderen. Security by obscurity vil aldri være tilstrekkelig.

Her er de viktigste anbefalingene:

• Etabler en sikkerhetskultur. Når alle team-medlemmer tar eierskap til og er observante på sikkerhetsutfordringer i det daglige arbeidet man gjør, da har man en fungerende sikkerhetskultur.
• Hemmeligheter må ligge utenfor kodebasen. Passord, nøkler og sertifikater skal aldri forvaltes sammen med koden.
• Slett eventuelle personopplysninger, eksempelvis test-data. Det er sannsynligvis ikke lov å forvalte personopplysninger i kodebasen uansett, men de må i alle fall ikke gjøres åpent tilgjengelig.
• Gå gjennom og/eller slett historikk når lukkede kodebaser åpnes.
• Bruk av tredjepartskomponenter er en kost/nytte-øvelse. Gjør en reell vurdering av community, modenhet, aktivitet og kvalitet. Foretrekk komponenter som har få avhengigheter; man har ansvaret for dem også. Hold avhengighetene oppdatert til enhver tid.
• Sørg for innebygd avhengighetssjekk i verdikjeden din med hensyn til utdaterte versjoner og eventuelle sårbarheter, som for eksempel verktøyene Dependabot og Snyk.

Kan all kode være åpent tilgjengelig?

Ja. Med få unntak:

• Algoritmer som brukes til å detektere svindel og misbruk.
• Kode som implementerer upubliserte endringer i lover og forskrifter. Denne kan åpnes så snart de er behandlet og vedtatt.
• Hemmeligheter – nøkler, passord og sertifikater – må som nevnt ikke ligge åpent tilgjengelig.

Dette er en marginal del av totalen, og bør være lett å holde orden på.

All I want for Christmas…

Det er mange fordeler med å forvalte koden åpent. Det finnes flere grunner i tillegg til de 10 i denne artikkelen. EU legger vekt på teknologiuavhengighet, konkurransekraft og innovasjon. GOV.UK peker på bedre samarbeid, læring og deling. Fordelene er mange, og sikkerheten må uansett røktes.

Kjære Digdir, Regjering, Storting og offentlige virksomheter i Norge! Til jul ønsker jeg at vi gjør som GOV.UK og forvalter all offentlig kode åpent tilgjengelig!

P.S. Forfatteren snakket også om dette temaet på JavaZone 2021. Videoen blir tilgjengelig i januar.

Photo by Riku Lu on Unsplash