Christian Zachariasen Kristian Gudal Kyrre Bratland Martin Coskun Svein Tore Werstad. Gruppe 3: Innovasjon og åpen kildekode

Transkript

1 Christian Zachariasen Kristian Gudal Kyrre Bratland Martin Coskun Svein Tore Werstad Rapport NTNU Norges teknisk-naturvitenskapelige Universitet TDT4851 Eksperter i Team, landsby nr. 8, vår 2009 Internett og nye arbeidsprosesser Fagrapport Gruppe 3: Innovasjon og åpen kildekode Problemeier: Alf Steinar Sætre Institutt for industriell økonomi og teknologiledelse Trondheim, 29. april, 2009

2 Innholdsfortegnelse 1. Abstract Introduksjon Hva er åpen kildekode? Kort historie Lisenser Ikke-restriktive Restriktive Høyrestriktive Firmaer med åpen kildekode som forretningsmodell Forretningsmodell Hva er en forretningsmodell? Å tjene penger på gratis programvare Embedded-modellen Hypoteser Økonomi Sikkerhet Brukervennlighet Spesialtilpasning Åpne filformater Support Konkurranse Innovasjon Metode Utarbeiding av intervjuguide Litteraturstudier Intervjuformen Forberedelse til intervju Resultater Konklusjon Referanser... 23

3 1. Abstract Gruppen tok for seg spørsmålet om hva som motiverer eller forhindrer bedrifter i å benytte seg av åpen kildekode. Vi utførte først en litteraturstudie der vi gikk gjennom tidligere utført forskning på området, og utformet deretter en intervjuguide med bestemmelser for hvordan intervjuene skulle gjennomføres. Intervjuene ble bestemt å være semi-strukturerte for at intervjuobjektene skulle ha mulighet til å gå utenfor den oppsatte strukturen, og gi oss mulighet til å utforske områder som vi kanskje ikke hadde tenkt på i intervjuguiden. Vi gjennomførte deretter intervjuene med noen utvalgte bedrifter, og transkriberte resultatene. Resultatene ble vurdert opp imot hva våre antagelser/hypoteser hadde vært. Vi konkluderte med at resultatene ikke samsvarte med antagelsene, og ble overrasket over hvor stor betydning det hadde hva andre bedrifter i samme bransje valgte i form av løsninger. Side 1 av 21

4 2. Introduksjon 2.1. Hva er åpen kildekode? For å kunne forklare åpen kildekode og hvordan det kan relateres til lukket kildekode, er det viktig at leseren har en forståelse for hva kildekode i seg selv faktisk er. Man kan se på kildekode som den tekstlige representasjonen av et program. Et program er, som de fleste vet, alt fra tekstprogrammet vi bruker for å skrive dette dokumentet, til kontrollprogrammet eller operativsystemet en bruker i datamaskinen sin (for eksempel Windows eller Linux). Alle programmer har på ett eller annet tidspunkt vært representert som klar og leselig tekst, og deretter blitt transformert til sin binære representasjon. Teksten eller koden som programmet består av er helt nødvendig for å kunne gjøre programmet kjørbart for datamaskinen din. I mange tilfeller kjøres teksten gjennom et annet program, en såkalt kompilator, som lager en kjørbar versjon av koden. I andre tilfeller tolkes teksten mens programmet kjøres, linje for linje, men oppførselen er den samme. Det som er relevant for leseren er at når det snakkes om åpen kildekode i motsetning til lukket kildekode, snakker vi om nettopp denne tekstbaserte representasjonen som er nødvendig for å generere et program. Et program som blir distribuert i sin binære form uten at sluttbrukeren har mulighet til å lese og tolke teksten som utgjør, er derfor lukket kildekode. Når noen distribuerer teksten som er nødvendig for å lage programmet, kalles det åpen kildekode. Disse momentene satt mot hverandre er i utgangspunktet svært enkle, men det finnes mange variabler som spiller inn og gjør selve saken komplisert. Penger er en av disse. Hvis alle programmer var åpent tilgjengelige i sin tekstbaserte form, altså som åpen kildekode, kunne sluttbrukeren bare lastet ned teksten og kompilert den selv, uten at han behøvde å betale penger for den. Hvis Microsoft for eksempel begynte å distribuere kildekoden til programmene sine, kunne interesserte tredjeparter se på de byggesteinene som blir brukt for å lage programmene og stjele bedriftshemmeligheter på den måten. Man har også de som mener at åpen kildekode er den aller beste måten å distribuere programvare på. Det finnes mange aktører her, ikke bare idealistiske enkeltpersoner eller grupper, men store bedrifter som tjener penger på å distribuere åpen kildekode. Vi skal kikke litt mer på dette markedet, og på de bedrifter som benytter seg av åpen kildekode. Situasjonen for åpen kildekode i dag er preget av en kraftig utvikling de siste årene. Microsoft, som tradisjonelt sett har vært ganske store på proprietære server- og desktopløsninger, føler definitivt et økt press fra grupper og firmaer som utvikler åpen kildekode. Side 2 av 21

5 2.2. Kort historie De fleste programmer som ble utviklet og distribuert i datamaskinens ungdom var faktisk av en relativt åpen natur: utviklere ville distribuere koden sammen med programmene sine, da det var vanlig at sluttbrukerne av programmene gjerne fikset feil i programmene på egen hånd. Det er viktig å tenke på at brukerne av dataprogrammer på denne tiden ofte var svært kunnskapsrike om datasystemene de brukte, og dermed hadde muligheten til å endre programmene slik at den fungerte bedre for dem. Da det på et punkt begynte å bli såpass mange brukere av disse programmene, fant de forskjellige firmaene som utviklet programmene ut at det var mulig å selge og tjene penger på dem. AT&T begynte å lukke koden og bare distribuere de binære versjonene av programmene sine, mot betaling. I 1983 begynte Richard Stallman å utvikle et operativsystem med det formål å ikke avgrense noen deler av kildekoden, men at selve grunnlaget for operativsystemet skulle være helt åpent og oppfordre til modifisering fra utviklere som drev med det på hobbybasis eller som hadde dette som sitt arbeid. I 1986 lanserte han den første versjonen av GNU General Public License, eller GPL. (GNU står for GNU's Not Unix). Lisensen oppfordret utviklere til å lage fri programvare, i motsetning til den lukkede programvaren som begynte å bli trenden hos mange programvareutviklere. I 1991 lanserte Linus Torvalds den første versjonen av Linux-kjernen, og den ble relansert i 1992 under GPL. Linux-kjernen ble benyttet i GNU-operativsystemet, og det første frie operativsystemet var født. Hobbyprogrammerere begynte å ta i bruk operativsystemet, og ga tilbake løsninger på programmeringsproblemer, fikset feil og økte støtte for eksterne enheter. I løpet av kort tid hadde Linux altså en ganske stor brukerbase. Etter hvert begynte flere såkalte distribusjoner å komme ut på markedet. En distribusjon er en utgave av den opprinnelige programvarepakken som oppfyller spesifikke behov. Et eksempel er Slackware-distribusjonen, som er ment for avanserte brukere og har verktøy avanserte brukere ofte trenger. Debian var en av de første distribusjonene, og lever enda, i sin versjon 4.0. Mye av utviklingen blir gitt bort til Debian fra utviklere som driver med dette som sin hobby. Man har regnet seg fram til at å utvikle dette operativsystemet fra grunnen av ville kostet omkring 13 milliarder dollar. Linux har utviklet seg til å bli et av de mest brukte operativsystemene verden rundt. Den mest populære plattformen for webservere, for eksempel, er den såkalte LAMP-plattformen: Linux, Apache, MySQL og PHP. Alle disse programvarepakkene er åpen kildekode. Side 3 av 21

6 Det er vanskelig å sammenligne åpen kildekode slik det var før i tiden, mot åpen kildekode slik det er nå. Til tross for at dataverdenen er såpass ung, har det vært en enorm utvikling på feltet fra de første nerdene begynte å bruke programvare, og frem til i dag Lisenser Det finnes utallige lisenser ute i verden. Det er ikke alltid like lett som utvikler å vite hvilken man skal bruke for programmet sitt. Det er heller ikke enkelt å sitte som bruker av kildekoden når man ikke er sikker på om man kan bruke koden i sitt eget prosjekt. Ikke-restriktive lisenser er lisenser som går ut på å ikke begrense videre utvikling av programvaren som er lisensiert. Restriktive lisenser har noen restriksjoner på programvaren, mens høyrestriktive lisenser har mange restriksjoner på programvaren som er lisensiert. Her følger en rask oversikt av de mest populære lisensene, kategorisert på hvor restriktive de er Ikke-restriktive BSD - en svært lite restriktiv lisens, der man kan gjøre stort sett hva man vil med koden som er lisensiert, så lenge man beholder den originale forfatterens navn og lisensmeldingen. MIT en enda litt friere versjon av BSD (f. Eks kan man med MIT reklamere for et produkt og ikke behøve å inkludere forfatterens navn i reklamen) Restriktive MPL Mozilla Public License, og LGPL Lesser GPL. Forskjellen mellom disse to og ikke-restriktive lisenser er at man ikke har lov til å endre lisens når man har gjort modifikasjoner på den originale kildekoden. LGPL tillater også bruk av biblioteker i proprietære pakker under visse forhold Høyrestriktive GPL - GNU General Public License. Virus -lisensen. Hvis man bruker GPL-lisensiert kode i et proprietært prosjekt, blir prosjektet «infisert», og man må lisensiere hele prosjektet under GPL. Hovedidéen med denne lisensen er å beholde gratis-delen av programvaren, selv om den endres Firmaer med åpen kildekode som forretningsmodell Det finnes flere firmaer som bruker åpen kildekode som sin forretningsmodell. Her følger noen av disse: MySQL (Sun) - grunnversjonen av produktet er gratis (GPL), men Enterprise-versjonen koster penger, og er ment for bedrifter som skal deployere større databaser. Side 4 av 21

7 FreeBSD, OpenBSD, NetBSD - Følger BSD-lisensen, en av de minst restriktive lisensene. Darwin, basissystemet for Apple's OS X er basert på FreeBSD. Det er i følge BSD-lisensen intet problem å bruke lisensiert kode i et proprietært produkt. Apache - Apache Foundation har flere prosjekter, men det mest brukte er Apache HTTP Server, den meste brukte webserveren i verden. Følger Apache License, som er en forenklet versjon av GPL. Mange vil stusse på dette. Mennesker som lager noe gratis, gjerne legger hele livet sitt i det, som andre bare kan ta? Her kommer vi delvis tilbake til idealismen knyttet til åpen kildekode, og delvis til andre variabler som spiller inn. Der Navaratnam (2008) skriver at «Apple er et eksempel på et firma som tjener penger på andres gratisbidrag» (parafrasert), er ikke dette et problem i seg selv. Kommunikasjonen mellom FreeBSD-utviklerne og Apple har vært svært god, mye fordi mange av endringene Apple gjorde på den kildekoden de tok fra FreeBSD ble sendt tilbake til FreeBSD i form av fikser på den gjeldende kildekoden Forretningsmodell Hva er en forretningsmodell? For å se på hvilken plass åpen kildekode kan inneha i dagens forretningsverden, har vi valgt å presentere ulike forretningsmodeller for åpen kildekode. Begrepet forretningsmodell har ingen klar definisjon, men i følge Navaratnam (2008) vektlegger Chesbrough følgende seks punkter. Forretningsmodeller (1) uttrykker en bedrifts value proposition (hva som skaper bedriften), den (2) identifiserer hvilke markedssegmenter bedriftens produkt eller tjeneste er beregnet for, og den (3) beskriver verdikjeden for produktet/tjenesten. Dette bunner ut i en (4) beskrivelse av kostnads- og inntektsstruktur, og det (5) plasserer bedriften i et nettverk av kunder, leverandører, komplementære firmaer osv. En forretningsmodell staker også ut hvilken strategiske kurs bedriften skal følge for å oppnå konkurransemessige fordeler i forhold til sine konkurrenter Å tjene penger på gratis programvare I sin artikkel om forretningsmodeller for åpen kildekode og hvilken innvirkning lisensvalg har på ulike modeller, benytter Navaratnam seg av følgende fem forretningsmodeller: (1) Duallisensiering, (2) supportmodellen, (3) Spesialtilpasningsmodellen, (4) Hosted-modellen og (5) Embedded-modellen Duallisensiering Ved duallisensiering vil en bedrift lisensiere software både som åpen kildekode og som proprietær programvare. Det vil da finnes en gratis og en betalt versjon av programvaren. For å rettferdiggjøre å ta seg betalt for noe man også gir ut gratis, vil den proprietære versjonen ofte innebære garantier Side 5 av 21

8 og/eller ha flere funksjoner. Ved duallisensiering bør man velge en restriktiv eller høyrestriktiv lisens. Velger man en restriktiv lisens unngår man behovet for å skrive om kode for den proprietære versjonen, noe man måtte gjort med en høyrestriktiv lisens som for eksempel GPL. Dette kommer derimot med den prisen at andre firmaer kan lage proprietære plug-ins for å selge disse. Høyrestriktive lisenser er de vanligste ved duallisensiering Supportmodellen En annen viktig forretningsmodell for åpen kildekode er supportmodellen. Bedriften selger her supporttjenester på ulik programvare. Ved bruk av denne modellen er det i utgangspunktet irrelevant hvilken lisens som benyttes, men den økte utviklingsfrekvensen høyrestriktive lisenser ofte medfører, gjør at denne lisensen ofte er preferert. Restriktive lisenser kan derimot også ha sin plass. Muligheten til å benytte proprietære moduler i programvaren, særlig egenutviklede, vil kunne by på differensieringsmuligheter en høyrestriktiv lisens ikke vil kunne matche Spesialtilpasningsmodellen Mange bedrifter driver med særegen virksomhet, og kan således ha relativt unike behov hva programvare angår. I slike situasjoner kan man enten velge å utvikle programvaren selv, eller å sette bort dette arbeidet. I begge tilfeller vil spesialtilpasning av allerede eksisterende programvare være et svært kostnadseffektivt alternativ, der dette er mulig. Bedrifter som selger slik spesialtilpasning av programvare følger spesialtilpasningsmodellen. Åpen kildekode er her ikke nødvendig, men er en enorm fordel både med tanke på den lave kostnaden og hvor enkelt det er å spesialtilpasse. Artikkelen til Navaratnam sier her at valg av lisens er irrelevant (Navaratnam, 2008, s. 11). Det skal derimot nevnes at det for kunden ofte kan ha noe å si. Dersom en høyrestriktiv lisens benyttes, må hele prosjektet forbli åpent. Dersom det eksisterer andre bedrifter med lik eller tilsvarende virksomhet, vil disse kunne skaffe seg det spesialtilpassede systemet gratis eller til en brøkdel av prisen det første selskapet betalte for å få det laget. For kunder vil derfor ofte åpen kildekode med en restriktiv lisens være å foretrekke, om dette finnes Hosted-modellen Modellen går ut på å ha programvare på servere og hoste dette for brukerne, enten gratis eller til leie. Google benytter seg av denne forretningsmodellen, og mye av deres programvare er åpen kildekode. Ved gratis bruk tjener bedriftene gjerne penger på andre ting. Google tjener penger på reklame, mens Ebay tjener penger på transaksjoner (Navaratnam, 2008, s. 12). Valg av lisens vil her være avhengig av hva som eksisterer. Må man velge høyrestriktive lisenser kan potensielle konkurrenter enkelt kopiere den tekniske løsningen. Hvis så vil det være viktig å ha Side 6 av 21

9 konkurransemessige fordeler på andre punkter, som for eksempel stor kundemasse, lavere pris og gode rutiner Embedded-modellen Denne modellen benyttes gjerne når bedriftens hovedfokus er salg av maskinvare. Softwaren vil i slike tilfeller benyttes til å øke verdien av maskinvaren og således selge mer. Åpner man sin programvare i slike tilfeller kan man kutte kostnader drastisk. Man er også bedre sikret mot konkurranse enn i de andre modellene, ettersom hardware er vanskeligere å kopiere enn software. Ved bruk av denne modellen vil restriktiv lisensiering være å foretrekke. Ikke-restriktiv lisensiering gir muligheten for at konkurrenter bruker bedriftens kode til å lage proprietære løsninger. Ved høyrestriktiv lisensiering oppstår derimot faren for at kode kan avsløre noe om oppbyggingen av maskinvaren, og slik forenkle kopieringen av denne. Ved restriktive lisenser kan nøkkelmoduler holdes proprietært slik at dette ikke skjer. 3. Hypoteser 3.1. Økonomi Når man skal vurdere kostnadene forbundet med valg av åpen eller lukket kildekode tenker man ofte på Total Cost of Ownership. TCO er en fremgangsmåte som brukes for å estimere direkte og indirekte kostnader. Dette er en prosess som i vårt tilfelle er utslagsgivende når man bestemmer seg for å gå for lukket eller åpent programvare. Direkte kostnader er kostnader som kan føres direkte tilbake til investeringen. Indirekte kostnader i denne sammenheng er kostnader som er bundet opp mot avgjørelsen. Våre antagelser rundt økonomi er at åpne løsninger er forbundet med mindre kostnader enn lukket programvare, og at TCO er en viktig faktor i valg av løsning Sikkerhet Sikkerhet er et punkt som pleier å ha varierende prioritet avhengig av hvilken bransje man snakker om. For de aller fleste bransjer er sikkerhet viktig opp til et punkt, slik at man vurderer hvor mye sikkerhet man behøver for sin programvareløsning og sin infrastruktur ut i fra hvor mye det vil koste å rydde opp etter et eventuelt hackerangrep. Så hvordan passer dette inn i idéen om åpen kildekode? I følge flere studier mener mange at hvis kildekode er åpen, så er sikkerheten lavere (Wheeler). Dette er en utbredt misforståelse som har mulighet til å påvirke valget om hvorvidt man skal kjøpe lukkede komponenter eller bruke åpne, Side 7 av 21

10 gratis komponenter i systemet sitt. Argumentet går ut på det at når en angriper kan lese kildekoden til et program, så er det lettere å finne angrepsvektorer fordi man forstår hvordan programvaren håndterer feil. Det er også lettere å påpeke svakheter i programvaren hvis man har tilgang til å lese kildekoden. Så langt stemmer teorien - det er virkelig lettere å finne måter å angripe et system på hvis man har tilgang til å lese kildekoden. Men det som balanserer opp for dette er at de fleste som oppdager slike feil vil rapportere dem til den som opprinnelig skrev kildekoden. Feilene vil dermed bli fikset raskt etter de har blitt oppdaget, ved at den opprinnelige forfatteren av kildekoden retter dem opp, eller at den som oppdaget feilen skriver en såkalt patch og sender den inn til den opprinnelige forfatteren. Argumentet for å kjøpe lukket programvare blir dermed at ondsinnede brukere, altså potensielle hackere, ikke har mulighet til å studere kildekoden på samme måte som de ville kunnet hvis kildekoden var åpen. De har dermed i utgangspunktet ingen klar idé om hvilke mulige angrepsvektorer som finnes i programvaren. For å sette dette på spissen kan vi bruke begrepet security through obscurity. Begrepet betyr at hvis man gjør sikkerheten i en programvare vanskelig å forstå, er det vanskeligere for en potensiell hacker å finne ut hvordan man kan angripe systemet. Security through obscurity blir sett ned på i hackersirkler og blant de som fokuserer på sikkerhet, fordi sikkerheten ikke nødvendigvis blir noe bedre bare man gjør den mer komplisert å forstå. Sikkerheten blir derimot bedre når man holder seg unna fristelsen for å lage den selv. Det finnes uendelige eksempler på smarte utviklere som produserer sine egne algoritmer for å kryptere passord eller annen personlig data, men som har oversett et eller annet eller ikke klarte å lage algoritmen riktig. Det er helt klart en fordel hvis man holder seg til sikkerhetsimplementasjoner som faktisk har blitt laget av sikkerhetseksperter. Fordelen med å eksponere sikkerheten i åpen kildekode er derfor at utviklere som har mer kompetanse på sikkerhet enn den opprinnelige forfatteren har mulighet til å gå gjennom koden og ordne opp i det som er for dårlig implementert. Bruce Schneier, en velkjent ekspert på datasikkerhet og kryptografi, mener at smarte utviklere må kreve åpen kildekode for alt som har med sikkerhet å gjøre. (Wheeler) Det er selvfølgelig viktig å huske på at åpen kildekode i seg selv ikke nødvendigvis gjør programvaren sikrere. Det er dog to hovedargumenter som taler for sikkerheten i forbindelse med åpen kildekode: Selve modellen gjør at utviklere forventer at kildekoden de skriver kommer til å bli lest gjennom av andre, og det finnes svært få utviklere av åpen kildekode som ikke er stolte av det de produserer. De vil helst at det de skriver er av bra kvalitet, ellers får de høre det av utviklere som har mer kompetanse og erfaring enn dem selv. I tillegg må man huske på at det finnes svært mange prosjekter ute i verden som bruker åpen kildekode, og man har større sjanse for at en Side 8 av 21

11 sikkerhetsekspert leser gjennom kildekoden hvis prosjektet har mange brukere. Større, mer velkjente prosjekter som Linux, for eksempel, har uendelig mye kompetanse angående sikkerhet, og problemer blir som oftest fikset svært raskt etter de har blitt introdusert i kildekoden Brukervennlighet Skal det foretas et valg mellom ulike typer programvare er brukervennligheten et viktig kriterium. Brukervennligheten har stor innvirkning på de totale kostnadene relatert til bruk av programvaren. Eksempler på dette er opplæring og support. Vår antagelse angående brukervennlighet er at programvare som de ansatte kjenner fra før benyttes i bedriften. Argumentet for dette er at man da reduserer kostnadene for opplæring og support. Eksempler på dette er Microsoft sin Office-pakke og Autodesk sine DAK-programmer. Alternative programmer av typen fri programvare har dermed vanskeligere for å komme inn på bedriftsmarkedet, da særlig i større bedrifter. Det franske politiet har valgt å satse på åpen programvare (Paul, 2009). Overgangen startet i 2005 da politiet byttet ut Microsoft Office med Openoffice.org for hele organisasjonen. Videre ble kommersiell programvare gradvis byttet ut med programmer basert på åpen kildekode, inkludert Firefox og Thunderbird. Microsoft Windows ble erstattet av Ubuntu. Pascal Danek (System Architect, Gendarmerie Nationale) poengterer at en overgang fra Microsoft Windows 2000/XP til Vista ville ha blitt mer komplisert, ettersom den nye versjonen av dette operativsystemet introduserer mange nye funksjoner og nytt design som kan forvirre brukerne. Vår antagelse er at åpen kildekode med samme forutsetninger som programmer med lukket kildekode har muligheten til å være like brukervennlige Spesialtilpasning Svært mange bedrifter og offentlige institusjoner driver med ganske særegen virksomhet. Et eksempel på dette er medisingrossister, som gjerne må forholde seg til ulike regelverk i forskjellige land. For disse bedriftene kan det være vanskelig å få tak i programvare som passer til deres behov. I slike situasjoner er én mulighet å utvikle alt fra grunnen av. Dette blir derimot ofte en veldig dyr løsning. Alternativt går det an å kjøpe inn eller laste ned et mer generelt produkt, og så på et eller annet vis skaffe spesialtilpassede plug-ins til dette programmet, slik at det skreddersys etter bedriftens behov. Ofte vil man på denne måten kunne spare mye penger. Når man skal spesialtilpasse programvare på denne måten, kan dette i utgangspunktet skje med både lukkede og åpne programmer. Med lukkede programmer vil det som regel være nødvendig at Side 9 av 21

12 produsenten gjør spesialtilpasningen, siden disse er de eneste med tilgang til koden. Med tanke på den monopolmakten en produsent har i et slikt tilfelle, kan vi enkelt se for oss at dette fort kan bli dyrt. Med åpne programmer er mulighetene derimot større. Man kan, dersom man har teknisk kompetanse til dette, tilpasse programvaren selv. Har man ikke denne kompetansen, eller man velger å bruke denne på andre ting, kan utviklingen settes bort til andre, for eksempel et konsulentfirma. Hvis bedriften allerede er kjent for å gi mye tilbake til åpen kildekode-mijøet, kan det også tenkes at man kan få mye gratishjelp herfra. Man skal ha visse ting i bakhodet når man skal gjøre spesialtilpasning av åpen kildekode. Dersom man ikke er helt alene om sin drift, men i et marked med få aktører, kan en slik spesialtilpasning gi bedriften et konkurransefortrinn. I slike situasjoner vil det å benytte seg av åpen kildekode-miljøer for utvikling utgå. Man må også tenke på hvilken lisens programvaren er under. Er denne for restriktiv, og man vil måtte legge ut hele prosjektet åpent, vil vinninga kunne gå opp i spinninga. Da må man potensielt velge å droppe hele prosjektet, eller betale dyrt for en lukket løsning Åpne filformater I sammenheng med åpen kildekode dukker temaet åpne filformater opp. Med åpne filformater menes utvekslingsformat for programmer, der filspesifikasjonene ligger fritt tilgjengelig på nett. Åpne filformater er uavhengige av operativsystemet man benytter seg av. Med et åpent filformat kan hvem som helst skrive et program for å benytte seg av formatet, i motsetning til lukkede filformater. Eksempler på åpne filformater: Filformat Standardisert av Bruksområde PDF ISO Dokumentutvelskling Office Open XML ISO/IEC Dokumentutveksling HTML/XHTML W3C Nettsider Med et åpent filformat kan altså hvem som helst benytte seg av formatet. Nettopp derfor har Standardiseringsrådet laget et forslag til bruk av IT-standarder i offentlig sektor. Bakgrunnen for dette forslaget lyder som følger: Side 10 av 21

13 Elektronisk samhandling internt i en offentlig virksomhet, mellom offentlige virksomheter eller med innbyggere og næringsliv, krever elektroniske løsninger som snakker samme språk, forstår hverandre og kan samhandle. Det er et viktig prinsipp at alle samhandlingsparter skal kunne velge elektroniske løsninger fra ulike leverandører, basert på egne ønsker og behov. En forutsetning for å kunne samhandle i et nettverk satt sammen av ulike løsninger og systemer, er at alle følger et felles sett av standarder. Åpne standarder gjør det lettere å oppnå interoperabilitet mellom ulike it-systemer produsert av ulike leverandører. Interoperabilitet gir bedre informasjonshåndtering og lavere kostnader. For bedrifter og det offentlige betyr det mer effektiv drift og et bedre og mer helhetlig tilbud til kunder og innbyggere. Fordi de er fullt dokumenterte og forvaltes av uavhengige organer sikrer åpne standarder også at vi i fremtiden har tilgang til historiske dokumenter, uavhengig av enkeltleverandører. sier kommunikasjonsdirektør i Microsoft Norge, Eirik Lae Solberg (Orelid, 2009). Gjennom bruk av åpne standarder oppfylles mange av regjeringens prinsipper for IT-politikk: Legge grunnlaget for en velfungerende elektronisk samhandling mellom offentlige virksomheter, og mellom offentlig sektor og omverdenen. Motvirke faren for at offentlige virksomheter og brukere blir låst til spesielle teknologier og leverandører. Bidra til likebehandling og inkludering av alle innbyggere, uavhengig av hva slags programvare eller programvareplattform hver enkelt benytter. Bidra til jevnere konkurransevilkår mellom aktørene i markedet, noe som kan være til fordel for norsk IKT-næring. Gjøre det enklere å bygge opp en delingskultur basert på fri programvare. (Direktoratet for forvaltning og IKT, 2009) Undersøkelser gjennomført av SSB (2008) viser at 5,2 prosent benytter kontorpakker basert på open source i staten. Det er verdt å legge merke til at dette tallet har avtatt fra Bruk av IKT i staten. Foretak som benytter open source software (prosent) Office-pakker på de ansattes arbeidsplasser Office-pakker på de ansattes arbeidsplasser Office-pakker på de ansattes arbeidsplasser Side 11 av 21

14 6,9 6,9 5,2 Historisk sett har en rekke formater over tid dominert markedet i en slik grad at de har oppnådd status som en type standard tross deres tilknytning til en kommersiell organisasjon og ofte tilknytning til en bestemt leverandør og kun ett produkt (kontorpakke). Disse formater betegnes ofte som de facto standarder eller industristandarder. Arbeidet med å gå over til åpne formater er dermed en tidkrevende prosess, blant annet fordi en eventuell utskiftning må foregå gradvis for å sikre kompatibilet Support Angående support er det i utgangspunktet stor forskjell på åpne og lukkede programmer. Når man kjøper proprietær programvare, kjøpes denne som feilfri. Det som følger med av feil vil man ha krav på at skal rettes. I tillegg vil det som regel være knyttet en supportavtale til kjøp av slik programvare. Får man et problem vil man på en eller annen måte kunne få hjelp av produsenten. Slike avtaler innebærer enten fri support, eller man må betale et beløp per gang. Når det gjelder åpen kildekode, er det ikke gitt at det finnes support på alt som er av produkter. Som nevnt under punktet Forretningsmodeller, er det visse utviklere av programvare som utgir sine produkter gratis og med kildekoden åpen. For disse er salg av support en ofte brukt forretningsmodell. For store og kjente programmer, som operativsystemet Linux, er det også slik at flere andre firmaer utenfor utviklingsmiljøet kan drive support. Det er derimot ofte slik at de som driver med support på slike programmer også er med på å utvikle, for å få bedre kjennskap til koden. Relativt nye eller små prosjekter har derimot ikke nødvendigvis noe firma knyttet til seg. Da kan det hende det ikke er mulig å få supportavtale på produktet i det hele tatt. Da må man satse på egen teknologikunnskap, eksterne konsulenter, eller man blir nødt til å finne løsninger fra andre ressurser. Det er viktig å påpeke at denne teksten omhandler den aller vanligste situasjonen, men det finnes selvfølgelig unntak. Et av argumentene for å bruke åpen kildekode er at leverandøren av den proprietære programvaren kan gå konkurs, eller at programvaren ikke støttes lenger. I disse tilfellene mister man kravet på support man hadde da man kjøpte den proprietære programvaren. Opplæring er en svært viktig del av support, på lukkede, men kanskje særlig på åpne programmer. Som Poynder (2001) skriver, krever åpne løsninger mer opplæring enn proprietære løsninger. De likner ikke nødvendigvis på de Windowsbaserte programmene som folk vokser opp med, og det Side 12 av 21

15 hjelper ikke at mye installasjoner og liknende gjøres gjennom kommandolinja, i motsetning til ved hjelp av mus som i Windows Konkurranse Vi antar at det er en del konkurranse mellom åpen og lukket programvare. Vi tror mye av konkurransen dreier seg om at produktene innehar forskjellige kvaliteter. En annen faktor er om utviklingsmulighetene er like. Vi ser at det er en trend at proprietær programvare blir kopiert av åpen kildekode. Dette vil følgelig ha innvirkning på konkurransesituasjonen. En annen faktor som har innvirkning på valg av åpen versus lukket, er konsekvenser valget medfører. Er det slik at man indirekte blir presset til å velge markedslederen fordi støtten ikke er like god hvis man velger en mindre aktør? 3.8. Innovasjon Innovasjon og åpen kildekode henger tett sammen. Ved å gjenta og sette sammen gamle idéer kan man øke verdien til et produkt. Dette er noen av hovedtrekkene i både innovasjon og åpen kildekode. Ved å bruke andres idéer, kan man enten forbedre disse eller skape helt nye idéer. Vil man skape noe nytt, trenger man nye visjoner og flere perspektiver. I en gruppe sammensatt av ulike personer, vil hver enkelt person gjøre om enhver situasjon til et rammeverk som gir mening for den enkelte basert på tidligere erfaringer og kunnskaper. I åpen kildekode-prosjekter er ofte mange personer involvert i hvert enkelt prosjekt. Loven om eksponentielle forbindelser gir et godt grunnlag for innovasjon i åpen kildekode-prosjekter. For eksempel, hvis en person i en gruppe på fem personer samarbeider med de andre i alle mulige undergrupper, er resultatet 75 ulike forbindelser. Det vil si at man har 75 ulike måter for gruppemedlemmene å dele informasjon, og hver av disse forbindelsene kan gi nytte. 20 av disse forbindelsene er mellom individer - en til en. 55 er med undergrupper og hele gruppen. Disse forbindelsene gir gruppen en enorm samlet kunnskap. (Carlson, C. R., Wilmot, W. W., 2008). 4. Metode Vi har valgt å jobbe med en metode som gir mulighet for at alle kompetansefelt som gruppen innehar, skal kunne brukes i en endelig flytende tekst. Gruppen bestod av ulike studieretninger, noe som gjorde at hver enkelt hadde forskjellige metoder å jobbe på ut ifra deres egen studieretning. Her vil vi se på de måtene vi har brukt for å gjennomføre forskningen vår. Side 13 av 21

16 4.1. Utarbeiding av intervjuguide Da vi bestemte oss for å gjennomføre et kvalitativt forskningsintervju begynte vi med å utvikle spørsmål. Vi gjennomførte flere idémyldringer før vi lagde et par utkast og senere reviderte utkast til tema og spørsmål som skulle stilles direkte knyttet opp i mot vår problemstilling. Dette er de antagelsene vi har diskutert i hypotesedelen om økonomi, sikkerhet, brukervennlighet, spesialtilpasning, åpne filformat, support, konkuranse og innovasjon. Det er mer enn bare spørsmål som skal tenkes på for å gjennomføre et intervju. Det er flere faktorer som skal spilles sammen for å få et fruktbart møte mellom to personer som ikke kjenner hverandre. Vi valgte å utarbeide en intervjuguide hvor vi beskrev alle elementer som bør bli beskrevet, selv om noen punkter er innenfor logikkens og folkeskikkens rammer. Ved innledningen av et intervju er det bestandig en fase hvor en presenterer seg selv. Her kan det være nyttig å skrive ned og lære seg punkt som gjør et godt førsteinntrykk. Ved å hilse har en allerede startet forberedelsen til selve intervjuet, og et godt førsteinntrykk gir en form for trygghet for både intervjuobjekt og intervjuer. Så bør en forhøre seg om hvilket medium stoffet som kommer frem i intervjuet skal komme fram. Vi valgte å bruke digitale opptakere slik at vi i etterkant kan notere ordrett hva som kommer frem, samt vi får en annen bedre samtale med objekt i og med at vi kan konsentrere oss om å holde samtalen i gang istedet for å se ned i notatene og prøve å skrive notater kontinuerlig. Å notere etter endt intervju vil være et mindre fruktbart prosjekt da et intervju ofte og bør være over en halvtime i og med at vi vil ha så utdypte svar som mulig. Neste punkt i intervjuguiden vil kanskje høre med til alles sunne fornuft, men det er meget verdt å nevne slik at en ikke glemmer at en er i det offentlige rom. En bør ikke ta med seg de kvalitetene en har hjemme i sin private sfære. En skal respektere objektets ønsker som anonymitet, ikke bruk av digital opptaker og lignende elementer som fører til at intervjuobjektet ikke føler seg vell. På samme linje som sunn fornuft bør en ha en akkeptabel oppførsel. En bør kle seg riktig og te seg som det profesjonelle samfunn krever. Mange av disse punktene sier seg selv at alle opprettholder, men det finnes kanskje noen som gjør punktene annerledes enn andre og det er på grunn av det at en gjennomtenkt intervjuguide er fruktbart. På denne måten kan vi legge føring på intervjuet slik at alle kan gjøre det på omtrent samme måte. Vi er fem personer som gjennomfører forskjellige intervju som skal derretter samles inn til et mål og eventuell løsning på en problemstilling Litteraturstudier Vår litteraturstudie har bestått av både individuelle studier og felles studier. De individuelle studiene tar for seg tekster som har en relevans til problemstilling og tema med innfallsvinkel fra ens egen studieretning. Ut over dette har vi hatt en del felles tekster som alle skal fordype seg i. Side 14 av 21

17 På grunn av gruppemedlemmenes varierende kunnskap om åpen kildekode, har vi funnet en samling av ressurser som omhandler åpen kildekode på en generell basis, og er ment for en leser som har lite eller ingen erfaring med åpen kildekode. Von Hippel og von Krogh (2003) har en artikkel som beskriver hva åpen kildekode er, historien og presentasjon av noen få forretningsmodeller knyttet rundt åpen kildekode. På samme måte skriver Navaratnam om åpen kildekode på et generelt grunnlag. Disse to artiklene tar også opp lisensdiskusjoner og virkninger. En tredje tekst som handler om åpen kildekode er Madanmohan og De (2004) sin artikkel hvor de diskuterer hvordan åpen kildekode brukes i en kommersiell og profesjonell måte i bedrifter. Utenom åpen kildekode har gruppen lest en artikkel som omhandler hvordan man tenker på improvisasjon i en ikke-musikalsk sammenheng. Grunnen til at alle skal fordype seg innen improvisasjon er at en i gruppen skriver om nettopp dette i sin masteroppgave. En artikkel som beskriver dette på en god og oversiktlig måte er Improvisation as a mindset for organizational analysis. Denne er skrevet av Karl E. Weick og er fin uansett hvilken vinkling en ser på åpen kildekode. Fra utviklerne av åpen kildekode blir brukt gjennom deres kreativitet og metode for jobbing, mens hos bedrifter kan improvisasjon sees ut i fra et struktur- og formmessig synspunkt Intervjuformen Det finnes flere måter å gjennomføre intervjuet på. Fagstoff som omhandler kvalitative intervjuer er har et såpass bredt spekter at det er om å gjøre finne metoder som relateres til det fagfelt vi holder på med. Vi valgte å bruke stoff fra pensum i informatikk og boka Researching information systems and computing av Briony J. Oates (2005) for å skaffe oss nødvendige retningslinjer og kunnskap om de forskjellige variantene vi har når det gjelder kvalitative intervju. I denne boken blir det nevnt tre måter å strukturere et intervju. Det ene kalles et strukturert intervju. Dette er en streng intervjuform hvor en stiller spørsmål og svar. En ønsker, ikke nødvendigvis korte, men relevante opplysninger til et og ett spørsmål en har planlagt å spørre. I et strukturert intervju skal en følge det en har planlagt å gjøre. Motsetningen til det strukturerte intervju er ustrukturerte intervju. Her presenterer du bare deg selv og enme før du lar objektet snakke uten avbrytelse eller lignende fra deg selv. Dette for at objektet selv skal få utvikle idéene selv, uten føringer fra deg som intervjuer (Oates, 2005, ss ). Vi har valgt en mellomting mellom disse du måtene å gjennomføre intervjuet. Det som Oates (s. 189) kaller det semistrukturerte intervju. Her tar du de tema en har utviklet i intervjuguiden som en sjekkliste underveis i intervjuet. Du lar objektet snakket ut ifra et bredt spørsmål som kan handle om alle tema du har skrevet opp i sjekklisten. Det du gjør her er å ikke være bundet til rekkefølgen i Side 15 av 21

18 temaene slik en er i strukturerte intervju, men heller ikke så åpen i forhold til relevanse for problemstillingen. I semistrukturerte er problemstillingen det overordnede spørsmålet, mens undertemaene er der for å være sikker på at alle de antagelsene du har gjort på forhånd, gjennom de tema du har i sjekklisten, blir tatt opp gjennom din samtale med intervjuobjektet. Fordelen med denne formen for intervju er at intervjuer lar objektet få lov til å snakke fritt. Oates skriver at semistrukturerte og ustrukterte intervju er ment for å utforske problemområdet, mens i strukturerte intervjuer fører intervjuer sine egne spørsmål til det man eventuelt vil snakke om. Det som tippet vektskåla i forbindelse med valg av semistrukturerte intervju for vår del, var at man kan komme med innspill eller komme med spørsmål i en slik form. I ustrukturerte har man ikke anledning til å spørre om uttrykk eller lignende som man ikke har hørt om eller har lyst til å vite mer om Forberedelse til intervju Forberedelsene til intervjuene innebærte en litteraturstudie, utarbeiding av intervjuguide og en bestemmelse av hvordan selve intervjuet skulle bli gjennomført. Ut over dette ble det gjort et utvalg over hvilke bedrifter vi ønsket å kontakte. Vi brukte vårt kontaktnettverk for å skaffe bedrifter vi mente var relevante for vår problemstilling og for å få med alles kompetansefelt. Dette utvalget måtte være bredere enn det antall bedrifter vi trengte, fordi vi mått forberede eventuelle avslag eller mangel av tid fra bedrifter. Da vi hadde valgt hvem vi ønsket å snakke, med tok vi kontakt ved hjelp av telefon og e-post. Gjennom telefonen fikk vi et interaktivt forhold med objektet og ved å skrive e-post på en profesjonell måte fikk vi et samsvar med hva som gjøres i dagens næringsliv og spesielt innenfor det tema vi arbeidet med. Ved generell kommunikasjon med bedriftene og deres kontaktpersoner var vi bevisst på språk, innhold og profesjonalitet. Hvis vi klarte å skaffe et godt førsteinntrykk måtte vi opprettholde det inntrykket og gjerne forbedre inntrykk gjennom hele forholdet. Vi prøvde å være presise i å holde frister og lignende. Det var vi som ønsket noe fra dem og da ville vi fort bli uprofesjonelle hvis vi ikke opprettholdte de krav bedriftene ønsket fra oss. 5. Resultater Intervjurundene ga oss både informasjon som vi hadde forventet da vi startet opp arbeidet med intervjuguiden, og ny informasjon som vi ikke hadde vært borti før. Svarene var informative og på noen måter overraskende. Det var en ulempe at vi kanskje hadde litt for få intervjuer å basere oss på da vi samlet sammen de viktigste resultatene fra rundene. Vi fokuserte ikke så veldig mye på hvilken Side 16 av 21

19 type bedrifter vi ville intervjue. Da dette var en mer utforskende intervjuprosess prøvde vi å få tak i bedrifter fra ulike felt og med ulike bakgrunner. Det slo oss ved gjennomgang av intervjusvarene at det var meninger på begge sider av spekteret - vi hadde de som var svært positive til åpen kildekode, og da spesielt Linux, og de som var svært positive til Windows. Det var interessant at Dynamica fremsto som negative til Windows, selv om de bruker operativsystemet til visse oppgaver. Erfaringene deres med Windows var at det var tregt og fullt av feil, samtidig som at Windows hadde færre muligheter enn Linux. Dette er et relativt vanlig argument blant Linux-brukere. I forbindelse med diskusjonen gikk et av gruppemedlemmene foreslo at de som bruker andre operativsystemer enn det som er vanlig (i følge Wikipedia (2009) har Windows XP, per mars 2009, over 62% av markedsandelen), kanskje vanligvis har mer erfaring og interesse for datamaskiner og programvare enn de som holder seg til Windows. I forbindelse med Rambøll-intervjuet fikk vi inntrykk av at deler av svarene hadde å gjøre med at intervjuobjektet ikke hadde så mye erfaring med åpen kildekode. Sett opp mot de øvrige svarene sitter Rambøll på de mest ekstreme meningene. Selv om de ikke var så veldig negative til åpen kildekode, hadde de andre intervjuobjektene enten et mer nøytralt forhold til det, eller en positiv holdning til åpen kildekode. Som forventet hadde de bedriftene som arbeidet med åpen kildekode-evangelisering og produksjon av åpen programvare de mest positive svarene. Redpill-Linpro er et selskap der mesteparten av virksomheten dreier seg om åpen kildekode. De bruker åpen kildekode til nesten alle oppgaver. Den oppgaven de ikke bruker åpen kildekode er lønning/økonomi. Redpill-Linpro forsvarer valget med at det er retningslinjer spesifikke for Norge som må følges, og det ikke finnes noen åpne løsninger som tilfresstiller disse kravene. I og med at vi bare kunne kategorisere to av besvarelsene som klart positive til åpen kildekode, og kun en som negativ til åpen kildekode, vil vi liste opp resultatene for disse veldig kort, og heller fokusere på de som ikke nødvendigvis hadde en klar mening. Vi valgte å fokusere på fire hovedpunkter når vi analyserte intervjusvarene: sikkerhet, økonomi, support og innovasjon, da disse sto ut som viktigere enn de andre tingene vi spurte om i intervjuene. Vi tar også for oss hvordan resten av bransjens valg av løsninger har en innvirkning på den enkelte bedrift. Det vi var interessert i var å finne ut hva bedrifter mente, og så om mulig sette disse meningene opp mot forskning som har blitt gjort på området. Angående sikkerhet mente de fleste at det ikke spilte noen rolle om kildekoden var åpen eller lukket. En av bedriftene vi snakket med hadde svært kraftig fokus på sikkerhet, men hadde ingen formening Side 17 av 21

20 om hva det var som var sikrest. Da intervjuer spurte etter en litt grundigere forklaring, sa intervjuobjektet at selv om koden hadde vært åpen ville ikke bedriften hatt kapasitet til å gå inn og lese den. På denne måten spilte det ingen rolle for dem spesifikt hvorvidt kildekoden var åpen eller lukket. En annen bedrift mente at åpen kildekode, og da spesifikt Linux, var sikrere fordi det ikke finnes nevneverdige virus til plattformen, og fordi det var flere tusen mennesker som bidro til at koden var sikker. Tilsynelatende er dette knyttet opp mot det faktum at i en bedrift som leverer proprietær programvare finnes det færre utviklere per produkt, slik at jo flere mennesker som bidrar til et produkt, jo større sjanse er det for at vanlige sikkerhetsproblemer blir oppdaget og dermed rettet. Angående økonomi var det veldig få svar. Noen hadde sett på Total Cost of Ownership (TCO) på de forskjellige løsningene. Da er det som oftest TCO mellom Windows og Linux-løsninger man snakker om. I bransjen blir det ofte sett slik: TCO ved Windows er høy i begynnelsen, men påfølgende support er ikke særlig kostbart. TCO ved Linux er lav i begynnelsen (da selve produktene som oftest er gratis), men stigende og så stabil da systemet er ganske vanskelig å lære seg, og det koster penger å investert i relevant opplæring av de ansatte. I tillegg er support på Linux som oftest slik at man spør andre enkeltindivider om støtte ved hjelp av nettfora eller lignende, i stedet for et helt firma. Redpill- Linpro, som driver med sin egen support, mente at åpen kildekode nødvendigvis er billigere enn proprietær programvare. Noen av bedriftene hadde supportavtaler med programvarefirmaer, men det var overraskende å finne at de som var klart positive til åpen kildekode ikke nødvendigvis behøvde support for sine åpne løsninger. Redpill-Linpro stiller ganske sterkt her, da de selv dedikerer betydelige ressurser til nettopp å ha kunnskap om det andre brukere av åpne løsninger måtte ha problemer med. Her ser vi klart at support har ganske mye å gjøre med økonomi. Det kan selvfølgelig finnes andre kostnader ved bruk av åpen kildekode som man også møter på proprietær programvare, slik som lisensiering. Med tanke på innovasjon var det et par interessante innspill, blant annet var det et av intervjuobjektene som snakket om åpen kildekode-miljøet som har drevet fram en del nye løsninger som tidligere ikke har eksistert. I tillegg finnes det flere eksempler på åpen programvare som har blitt utviklet for å være en erstatter for funksjonalitet som allerede finnes i proprietære løsninger. I disse tilfellene hender det også at åpen programvare blir utviklet for å være en samlepakke for funksjonalitet som finnes proprietært andre steder, men separert. Et eksempel er hvordan Linux ble utviklet opp gjennom årene, der mennesker fra flere forskjellige bakgrunner bidro til at programvaren ble en fleksibel gratisløsning med mye funksjonalitet som man tidligere bare kunne få totalt ved bruk av separerte, individuelle proprietære løsninger. Side 18 av 21

21 Til slutt er det viktig å nevne bransjestøtte. Stort sett alle bedriftene vi snakket med som hadde interesser i andre bransjer mente at det viktigste av alt var ikke hvordan programvaren ble lisensiert eller hvor innovativ den var. Det var altså svært lite idealisme å finne - det viktigste var at eventuelle kunders problemer ble løst på en tilfredsstillende måte. Hvis dette betyr å velge løsninger basert på åpen kildekode som da er billigere enn en proprietær variant, og både den åpne og den lukkede pakken løser samme problem, så velges den åpne løsningen. Men det er viktig at den åpne løsningen også støtter de muligvis proprietære standardene som ellers er regjerende i bransjen. Blant annet mente en av bedriftene at de kunne benyttet seg av OpenOffice i stedet for Microsoft Office, men på grunn av at resten av bransjen brukte Microsoft Office ville de minimere eventuelle kompatibilitetsproblemer og bestemte seg for Microsoft Office. Tendensen så ut til å være at dette går igjen de fleste steder, det er altså den ledende programvarepakken som blir valgt, og mye av grunnen er rett og slett at den er ledende. Side 19 av 21

22 6. Konklusjon Etter å ha gått gjennom resultatene med tanke på den opprinnelige problemstillingen, føler vi det er overraskende å se hvor mye som blir avgjort i næringslivet på basis av hvordan kunder og konkurrenter gjør ting. Svært mange hadde tanker om at inkompatibilitetsproblemer var noe av det verste man kunne komme bort i, og ville gjerne valgt løsningen sin med dette som det mest kritiske punktet. Vi var altså overrasket over at andre faktorer fikk ganske lav betydning i forhold til dette. Det skal nevnes at vi godt kunne ha intervjuet noen flere bedrifter, for om mulig få litt større utvalg å hente resultater fra. Resultatene våre og samfunnsnytten av rapporten som helhet er at den gir en pekepinn på hvordan bedrifter som er avhengige av bransjestandarder på samarbeid og filformater, mange ganger velger bort åpen kildekode til fordel for proprietære løsninger. Vi var veldig fornøyde med resultatene vi fikk, til tross for at vi kanskje ikke intervjuet så mange bedrifter som vi hadde planlagt. Vi føler at forskningen har opplyst et felt som kanskje ikke har vært tatt for seg så grundig i det norske åpen kildekode-samfunnet. Side 20 av 21

23 7. Referanser Carlson, C. R., William, W. W. (2008) Innovation: The Five Disciplines for Creating What Customers Want. London: Crown Business. Direktoratet for forvaltning og IKT. (2009) Standardiseringsrådets forslag til 2. versjon av Referansekatalog for IT-standarder i offentlig sektor.[online]. Tilgjengelig fra: [Lastet ned ] von Hippel, E. og von Krogh, G. (2003) Open Source Software and the Private-Collective Innovation Model: Issues for Organization Science. Organization Science, volum 14, ss Madanmohan, T. R. og De, R. (2004) Open Source Reuse in Commercial Firms. IEEE Software, ss Navaratnam, D. (2008) Open Source Business Models and the Impacts of Open Source License Choice. Oates, B. J. (2005) Researching Information Systems and Computing. London: Sage Publications Ltd. Orelid, M. (2009). En helt åpen diskusjon. Tilgjengelig fra: [Lastet ned ] Paul, R. (2009) French Police: we saved millions of euros by adopting Ubuntu. [online]. Tilgjengelig fra: [Lastet ned 28. April 2009]. Poynder, R. (2001) The Open Source Movement. [online]. Tilgjengelig fra: [Lastet ned ]. Statistisk Sentralbyrå. (2008) Bruk av IKT (Informasjons- og kommunikasjonsteknologi) i kommunene og fylkeskommunene, [online]. Tilgjengelig fra [Lastet ned ] Weick, K. E. (2002) Improvisation as a mindset for organizational analysis. Wheeler, D. A. Secure Programming for Linux and Unix HOWTO. [online]. Tilgjengelig fra: [Lastet ned 27. April 2009]. Wikipedia. Windows XP. [online]. Tilgjengelig fra: [Lastet ned 27. April 2009]. Side 21 av 21