Standard og standard, fru statsråd

KOMMENTAR: Den betente OOXML-saken har brakt standardisering i fokus. Åpne standarder og åpen kildekode er to forskjellige ting. Begge er finfine saker, og det finnes noen sammenhenger.

Publisert Sist oppdatert

Mange tenker på standardisering som en prosess der representanter for interesserte selskaper kommer sammen på møter arrangert av en standardiseringsorganisasjon. De møtes for å bli enige om forslag til en ny standard. De jobber på møtene og mellom møtene, og til slutt blir de enige om forslaget som så dissekeres og vedtas av standardiserings-organisasjonen. Ofte er forslaget likt den konsensus som eksisterte i markedet fra før.

Prosessen frem til vedtaket tar lang tid, i mellomtiden raser utviklingen bare videre. Når standarden er vedtatt, kan det allerede være for sent. Både OSI og X.400 ble myrdet av TCP/IP lenge før de ble vedtatt. I andre tilfeller er standarden meget nyttig, slik det var da EDIFACT ble bestemt.

Fanden bor i detaljene. Standarder som peker ut en retning, men der detaljene ikke er spikret, er bare et skritt på veien. Da kan to produsenter begge hevde at de følger standarden – likevel kan ikke programmer fra de to utveksle data. På detaljnivå er programmene ikke kompatible. Derfor er mange skeptiske til standardenes verdi. Standardforakt er utbredt i it-kretser.

Åpen kildekode

Åpen kildekode er en betydelig bidragsyter til standardisering, men det foregår på en litt annen måte. Modellen heter "grov enighet og programmer som virker". Den ble først brukt av Internet Engineering Task Force i deres arbeidsgrupper, nå brukes den av flere.

Forskjellen fra vanlig standardisering er at man ikke forutsetter formell enighet og full deltagelse. Det vil si at modellen er mindre byråkratisk enn klassisk standardisering. Man samler interesserte og kompetente deltagere som strever etter å bli enige i hovedsak. Deretter setter de i gang med å utvikle programmer som virkeliggjør det man er blitt enige om. Tenkningen er "iterativ" i utgangspunktet: Man vet at første versjon aldri blir særlig bra, og forventer at forbedringer av standarden dukker opp mens man utvikler og tester.

Etter en stund har man en "de facto standard". Da finnes det også folk som behersker standardens detaljer og fallgruver, og kan lære opp andre. Dette er en praktisk metode som tiltaler dem som mener at standarden skal finnes når behovet er der, ikke fire år senere.

Denne typen standarder pleier å bli distribuert som åpen kildekode. Hvis det finnes et reelt behov for standarden i markedet, vil den bli tatt i bruk straks mange steder. Det vil dytte utviklingen fremover. Det kan godt hende at den åpne prosessen er en forløper til formell standardisering, men da har man noe konkret å starte med. Et eksempel er den såkalte Service Component Architecture (SCA) standard som ble utarbeidet gjennom to åpne standardiseringsprosjekter.

Ingen proprietære standarder

Den andre interessante sammenhengen mellom standardisering og åpen kildekode er at de aller fleste åpne standarder finnes implementert som åpen kildekode-programmer. Hele vitsen med standarder er at de skaper likhet mellom implementeringene hos produsentene, slik at produkter fra ulike kilder kan knyttes sammen. Standardisering øker produktenes verdi. Derfor tilhører proprietære standarder fortiden. Men det er slik at åpne standarder ikke er knyttet til åpen kildekode, de kan like godt anvendes i proprietære produkter. Uansett er det en stor fordel at standarden er prøvd ut av mange.

Det er greit å slå fast at åpen kildekode og åpne standarder ikke er samme sak. Åpen kildekode-produkter kan godt bygges proprietært, det vil si at utviklerne finner på nye løsninger der det kanskje ikke finnes standarder. Vi kan tenke på prosessen i faser. Først er det noen som utvikler et nytt program (eller komponent). Så oppstår behovet for å knytte det til andre, eksisterende programmer, og det skjer på en eller annen skreddersydd måte (hvis det ikke finnes allerede oppgåtte tilknytningsformer). Deretter dukker ideen opp om å velge en standard tilknytningsform gjennom en åpen prosess. Til slutt kommer kanskje formell, internasjonal standardisering.

Microsofts behov

OOXML er et spesialtilfelle. Microsoft Office har vært på markedet i en mannsalder. XML er nyere, men også det er velkjent og gjennomstandardisert. En utvekslingsstandard, ODF, er allerede godkjent av ISO. Det fantes ikke behov for en ny standard her, men det fantes et påtrengende behov hos Microsoft for å sikre at offentlig sektor ikke finner på å påby at MS Office skal erstattes med andre, mer åpne løsninger. Trolig er mange offentlige kunder i hemmelighet enige med Microsoft, de vil heller ikke skifte.

De fleste er enige med statsråd Grande Røys i at markedet behøver konkurranse med Microsoft Office. Me kjem, om inkje så brått.