Mickes skolblogg

Välkommen till Mickes skolblogg. En plats där jag kommer att publicera arbeten som tagits fram i programmet IT-användning och samhällsutveckling på HV.

Var är jag? Vad gör jag? Hur gör jag det?

    follow me on Twitter

    Profillänk på Facebook

    Leta i den här bloggen

    fredag 5 juni 2009

    Godkänd C-uppsats Betyg VG nominerad till BEST stipendiet!!!

    clip_image001

    Fria och öppna programvaror inom kommunal verksamhet –

    Vägen mot öppna standarder?

    Free- and open source software in municipalities –

    The way towards open standards?

    Datum: 2009-06-05

    Version: Slutversion

    Författare

    Hanson Malin 731223

    Larsson Mikael 711113

    Handledare

    Professor Per Flensburg

    Examinator

    Docent Kerstin Grundén

    C-uppsats

    Informatik 15 hp

    Abstract

    This report deals with the attitudes within municipalities of open source software and open standards and if open source software may be an option to gain open standards. The aim has been to find out if open source software and open standards would be able to solve the lock-in problems that municipalities have against proprietary software. The study is conducted as an exploratory, inductive and qualitative study with depth interviews of subjectively selected informants as data collection method. A literature review has also been implemented by the relevant books and articles. Some economic determinants of municipalities to make use of open source software have not been considered in this study. The informants used in this study are all IT managers in a Swedish municipality and our key informants have been selected in a subjective manner based on the expertise they have in the subject. The conclusions drawn were that municipalities have been difficult to define standards and open standards, and that they do not automatically see the connection between open standards and open software. They also see different areas of interest for standardization.

    Keywords: Standard, Open standard, Open Software, Open Source, Lock-in Problems

    Sammanfattning

    Denna rapport tar upp kommuners inställning till öppna program och öppna standarder och om öppen programvara kan vara ett alternativ för att få öppna standarder. Syftet har varit att ta reda på om öppna program och öppna standarder skulle kunna lösa de problem som kommuner har med inlåsningar mot proprietär programvara. Studien är genomförd som en explorativ, induktiv och kvalitativ studie med djupintervju av subjektivt utvalda informanter som datainsamlingsmetod. En litteraturgranskning har också genomförts av relevanta böcker och artiklar. Några ekonomiska faktorer för kommuner att använda sig av öppen program­vara har inte beaktats i denna studie. De informanter som använts i denna studie är alla IT-chefer inom någon svensk kommun och nyckelinformanterna har valts ut på ett subjektivt sätt utifrån den expertkunskap de besitter inom ämnet. Slutsatserna som drogs var att kommuner har svårt att definiera standarder och öppna standarder, och att de inte med auto­matik ser kopplingen mellan öppna standarder och öppen programvara. De ser också olika områden som intressanta för en standardisering.

    Nyckelord: Standard, Öppen standard, Öppen programvara, Öppen källkod, Inlåsnings­problem

    Förord

    Vi vill ta tillfället i akt och tacka våra familjer för att de stått ut med oss under den intensiva period det varit att producera denna uppsats. Vi vill också tacka vår handledare Professor Per Flensburg för adekvat och konstruktiv kritik. Ett speciellt tack skickar vi till Ann Svensson, för all stöttning, både moraliskt och praktiskt när de tunga stunderna kommit.

    Tack allihop!

    Malin Hanson & Mikael Larsson

    Innehållsförteckning

    1. Inledning.. 2

    1.1. Inledande om öppna standarder och öppna program.. 2

    1.2. Egna tidigare utförda studier. 3

    1.3. En första tänkt inriktning. 4

    1.4. Ändrad inriktning. 4

    1.5. Problemområde och frågeställning. 5

    1.6. Syfte. 5

    1.7. Avgränsningar. 6

    1.8. Målgrupp. 6

    1.9. Disposition.. 6

    2. Metoder.. 7

    2.1. Övergripande metod/forskningsansats. 7

    2.1.1. En explorativ forskningsstrategi 7

    2.1.2. Induktiv metodansats. 8

    2.1.3. Kvalitativ undersökningsmetod. 9

    2.2. Datainsamlingsmetod.. 10

    2.3. Population och urvalsmetod.. 10

    2.3.1. Population. 10

    2.3.2. Urvalsmetod. 10

    2.4. Intervjuer. 11

    2.4.1. Nyckelinformanter. 11

    2.4.2. Etiska aspekter. 11

    2.4.3. Informanter. 11

    2.4.4. Intervjuförfarande. 12

    2.5. Analysmetod.. 13

    2.6. Mäter vi det vi vill mäta och mäter vi på ett trovärdigt sätt?. 13

    2.6.1. Författarnas bakgrund. 14

    2.6.2. Studiens validitet 14

    2.6.3. Studiens reliabilitet 15

    2.6.4. Studiens objektivitet 15

    3. Teoretisk referensram... 16

    3.1. Historik om öppna och fria programvaror. 16

    3.2. Den offentliga situationen.. 17

    3.2.1. Utvecklingen inom den offentliga sektorn. 17

    3.2.2. Svårigheter inom kommuner att införa öppna programvaror. 18

    3.3. Öppen programvara, standarder, öppna standarder. 18

    3.3.1. Vad är öppen programvara?. 18

    3.3.2. Vad är en standard?. 19

    3.3.3. Vad är en öppen standard?. 20

    3.3.4. Sverige och öppna standarder. 20

    3.3.5. Vad är SOA?. 21

    3.3.6. Vad är en licens?. 21

    4. Kommuners verksamhetsutveckling med öppna program... 21

    5. Empiri 23

    5.1. Definition av standarder och öppna standarder?. 23

    5.2. Vad behöver standardiseras?. 25

    5.3. Varför behöver det standardiseras?. 25

    5.4. Hur ska det standardiseras och av vem?. 26

    5.5. Vart är det på väg?. 29

    5.6. Attityden till öppna program och öppen standard.. 30

    6. Analys och diskussion.. 31

    6.1. Problem för kommuner vid en standardisering. 31

    6.2. Definitioner av standarder och öppna standarder. 34

    6.3. Vad, varför och hur öppna standarder?. 35

    6.4. Öppna standarder och kopplingen till öppna programvaror. 36

    6.5. Bakomliggande faktorer. 37

    7. Slutsatser.. 37

    8. Rekommendationer.. 38

    9. Referenser.. 39

    10. Kontaktuppgifter.. 43

    Bilder

    Bild 1 Katalogstruktur Windows XP 19

    Bilagor

    Bilaga 1 Intervjuplan testversion

    Bilaga 2 Intervjuplan


    En tankeväckande historia

    Nedanstående citat hämta från KLUGE.DE (2007).

    How to gain market share

    Yesterday at a customer site:

    Customer: So can you also help us with infrastructure and hardware problems?
    Me: Yes, of course!
    Customer: We need help upgrading to
    Vista and Office 2007.
    Me: Ooops…
    Customer: Is there a problem?
    Me: Well, you have now Windows XP and Office 2003 - and to be honest thats everything you need. In fact I would recommend taking a look at Open Office 2.2. So why do you want to upgrade?
    Customer: Very simple: We want to read and edit Office 2007 DOCX files.
    Me: But why? Nobody in the world uses that format except Microsoft itself?
    Customer: We receive every day documents in that format from the European Commission in
    Brussels, we are part of many groups in Brussels, and they send out their stuff as DOCX.
    Me: So tell them to convert it to DOC or even Open Document Format. There are probably hundreds of other interest group outside in Europe that receive these files and cant open it - and don’t want to spent thousands of Euros to upgrade the systems.
    Customer: No way. Everybody in
    Brussels uses now Office 2007, and they will not stop sending the documents out in DOCX. We tried and failed.
    Me: But what is the reason for this bullshit?
    Customer: Microsoft gave away Office 2007 licenses to the Commission’s administrative staff - for free.

    So this is how it works.”

    1. Inledning

    Om det är något vi fått lära oss under åren på Högskolan Väst, så är det att iteration ska man inte vara rädd för. Det är oftast det som i slutändan leder processen framåt, även om det ibland kan kännas väldigt tungt att behöva ”börja om” igen! Under nedanstående rubriker diskuteras ämnesval samt ges en inledande inblick i problemområdet.

    1.1. Inledande om öppna standarder och öppna program

    Flera kommuner är fastlåsta i proprietära programvarulösningar, det vill säga de är beroende av en eller ett fåtal kommersiella leverantörer vars programvaror är upphovsrättsskyddade eller patenterade. Proprietär programvara är synonymt med stängd källkod, vilket inte är fallet när det gäller öppna program. Öppna program bygger på öppen källkod och är till sin natur oftast uppbyggda utifrån öppna standarder. Och det är detta som denna studie ska undersöka närmare, om förhållandet öppna programvaror och öppna standarder är en lösning för kommunernas inlåsningsproblem.

    Någon egentlig enhetlig definition på vad en öppen standard är, existerar inte. Generellt så avses att den är fri att använda för alla och att den är certifierad av något standardiseringsorgan. Leverantörer av proprietära program ska tillhandahålla all funktionalitet som en kommun idag behöver när det gäller allehanda IT-system. Det är detta som avses med det som brukar kallas för inlåsningsproblem. Kommunerna är så beroende av dessa leverantörer och måste följa deras standarder och avtal och de har svårt att ta sig ur denna låsning på grund av olika anledningar (Åsblom, 2009). Det kan handla om avtal, integrationssvårigheter och restriktioner för hård- och mjukvara.

    När ansvariga i vissa kommuner tillfrågats har de oftast inte sett öppna programvaror som det absolut viktigaste som behövs för att lösa inlåsningar. Istället påpekas utvecklingen av öppna standarder som en viktig och avgörande faktor för att komma ifrån inlåsningar och göra kommunala organisationers system mer öppna och transparenta (Östling, 2008). Exempel finns där några kommuner har tagit ett första steg mot denna utveckling, där man i ett öppet brev ställer krav på leverantörer av proprietär programvara att göra dessa kompatibla med OpenOffice och då främst filformatet ODF (Open Document Format) (Åsblom, 2009). Även den högst ansvarige i regeringen, Mats Odell (2007), anser att öppna program och öppna standarder är något som både myndigheter och kommuner behöver titta närmare på när upphandlingar ska göras och han är också inne på att det eventuellt skulle vara bra med någon form av riktlinjer för att underlätta detta val. Frågan är vad menar kommuner med öppna standarder? Är det öppna filformat man främst avser till exempel ODF (vilken också är antagen som en svensk standard) (se Wallenquist, 2008), PDF (Portable Document Format) eller Microsofts svar på öppen standard OOXML (Microsoft Office Open XML) (Strömbergson & Görling, 2009), eller finns det andra betydelser som man också väger in i detta begrepp?

    Att frågan ställs om det finns andra betydelser som också vägs in i begreppet öppna standarder, beror på att det inte finns någon egentlig enhetlig definition på vad en öppen standard är (Wikipedia, 2009; Rejås, 2009). Microsoft (2009) ser på öppna standarder på ett sätt. De menar att en öppen standard inte har med öppen källkod att göra per definition. Öppen källkodsrörelsen ser på det på ett annat vis (Tiemann, 2006). En öppen standard för denna rörelse behöver inte betyda att det per automatik har med öppen källkod att göra. Dock så är kulturen och ideologin sådan att den förespråkar öppna standarder framför de låsta. Finns det olika definitioner på vad en öppen standard är och i förlängningen vad kommuner efterfrågar, hur ska då de som levererar programvaror veta vad som avses?

    Även Dacke[1] menar att öppenhet betyder olika på olika nivåer och det behöver definieras för att få en enhetlig innebörd. För att kompatibiliteten och integrationen ska vara möjlig mellan system och program behövs standarder för hur utbytet av informationen mellan systemen ska gå till, det vill säga mellan systemens gränssnittsytor (Svenska datatermsgruppen, 2007) och kommunikationsprotokollen, vilket Daniel Ekström konstaterar i ett examensarbete utfört i samarbete med Vägverket (2004). Det kan även, som tidigare nämnts, innebära att filformaten måste standardiseras för att kunna läsas av flera program och system. Visserligen anges säkert vilka standarder som krävs i en kravspecifikation, men det gäller ju bara för en kommun, eller i bästa fall några få som inlett ett samarbete kring IT-frågor och upphandlingar av de samma. Lagen om offentlig upphandling (LOU) kan också sätta käppar i hjulet för kommuner som vill satsa på öppna standarder. LOU föreskriver att det främst är formella standarder som ska åberopas vid upphandlingar. Formella standarder bestäms dessutom av erkända standardiseringsorgan. Även icke formella standarder kan uppfylla de krav som kommunerna har, vilket i dagsläget alltså kan vara svårt att införa (IT-standardiseringsutredningen, 2007).

    Uppfattningen är att det blir en naturlig startpunkt att fråga kommunerna hur de definierar öppna standarder och vilka problem de ser med att implementera dessa, för att se, om just öppna programvaror stämmer överens med dessa definitioner. Microsoft (2009) skriver bland annat på sin sida att ”Öppna standarder bestäms av oberoende standardiseringsorgan och har inget med öppen källkod att göra per definition”. Detta styrker tidigare egna undersökningar som visade på att det inte var området öppna programvaror som egentligen stod högst på kommunernas lista över åtgärder för att skapa en större frihet och för att själva välja programvaror, utan det var öppna standarder som efterfrågades (Hanson & Larsson, 2009ABC). Är det nu som Östling[2] säger, att öppna program till största delen är synonymt med öppna standarder så borde även öppna programvaror vara av stort intresse för kommuner.

    1.2. Egna tidigare utförda studier

    I tidigare undersökningar utförde vi studier för att se hur inställningen till öppen källkod och användningen av den samma inom svenska kommuner ser ut idag, både mer generellt i en kvantitativ enkätstudie (Hanson & Larsson, 2009A) och mer specifikt inriktat mot några utvalda kommuner i en kvalitativ intervjuundersökning (Hanson & Larsson, 2009B). Resultaten som framkom i dessa studier pekade på att kännedomen och kunskapen om öppen källkod eller OSS (Open Source Software) ute i kommunala verksamheter är relativt låg (Computer Sweden, 2008). Det var IT-ansvariga som hade den största kunskapen inom detta område men ute på förvaltningarna och bland beslutsfattarna var kännedomen om och kunskapen om OSS ingen alls eller väldigt låg, enligt de intervjuade IT-cheferna. Det fanns även bristfälliga kunskaper bland de IT-ansvariga, vilket de även själva påpekade. Det framkom i dessa studier att öppen källkod eller fri programvara inte sågs som det viktigaste för att skapa en öppen verksamhet och komma bort från inlåsningsproblem med mera. Öppna standarder poängterades från flera respondenter som något av en nyckelfaktor för att kunna lösa många av de problem som man såg med att vara bunden till en eller ett fåtal leverantörer eller ett fåtal låsta standarder, alltså det som benämns som inlåsningsproblem. Tidigare genomfördes även en litteraturstudie om hur användningen av öppen källkod och fria programvaror ser ut mer generellt, alltså inte bara mot kommunal sektor (Hanson & Larsson, 2009C). Vidare framkom det att öppna standarder var en nyckel till många problem.

    1.3. En första tänkt inriktning

    Vid diskussion kring ämnesval inför denna C-uppsats var det resultaten av egna tidigare studier som fick ligga till grund. De pekade bland annat på att intresset, generellt sett, för öppen källkod tycktes öka inom offentlig verksamhet. Valet föll på licensmodeller, inte öppna standarder således, för öppen källkod och fri programvara och dess lämplighet inom kommunal verksamhet som ett område där intressanta infallsvinklar för en C-uppsats kunde genereras. En licensmodell kan kort beskrivas utifrån reglerade avtal där användaren ges olika möjligheter att utifrån vald licens modifiera, kopiera, vidaredistribuera och förbättra en programvara. Efter ett möte med en ”guru” inom området; Mats Östling på SKL (Sveriges Kommuner och Landsting), ändrades dock uppfattningen. Han menade att licenser i sig och öppen källkod eller fri programvara egentligen inte är något större problem för kommuner, då de redan är vana att hantera dessa då det gäller proprietära programvaror[3]. Vår teori och infallsvinkel på denna C-uppsats inledningsvis, om att licenserna kunde ställa till problem vid implementation av OSS (Open Source Software) i kommunal verksamhet, kom således att förändras. Därmed säger vi dock inte att licenser inte kan innebära ett problem för kommunal verksamhet, bara att vårt fokus har fått en ny inriktning. Vi anser fortfarande att en undersökning om licenser skulle vara intressant att utföra.

    1.4. Ändrad inriktning

    Mats Östling menar att det som påpekats i de egna tidigare undersökningarna, om vikten av öppna standarder för att lösa kommunernas problem, visserligen var helt korrekta och mycket tänk­värda. Han menar även att svaren som kommunerna gav på enkätundersökningen och intervjuerna som genomfördes i dessa studier, tydde på en bristande förståelse för vad öppna standarder är, hur man uppnår detta, och att man inte har förstått sambandet mellan öppna standarder och öppen källkod eller öppna programvaror som han kallade det (hädanefter så kommer termen öppna programvaror att användas som samlingsbegrepp för öppen källkod och fri programvara). Östling menar att den naturliga vägen att uppnå öppna standarder är att övergå till öppna programvaror, vilka han anser bygger just på öppna standarder, som ”standard” så att säga. Han gav också exempel på tre olika perspektiv eller ”faser” vilka han anser kan användas för att exempelvis se hur långt en kommun har kommit i sin insikt om öppna standarder och öppen programvara[4]. Detta sätt att tänka var till viss del nytt för oss. Vi redovisade dock ett synsätt på paradigmskifte när det gäller kommunal verksamhet och öppen källkod kontra proprietär källkod i vår litteraturstudie (Hanson & Larsson, 2009C), vilken inte alls låg långt ifrån det tankesätt som Östling presenterade, även om den primära inriktningen i dessa båda synsätt koncentrerades på två olika saker. Utifrån den egna förförståelsen samt den information som Östling gav, ansågs att det vore intressant att undersöka det påstådda sambandet mellan öppna programvaror och öppna standarder.

    1.5. Problemområde och frågeställning

    Problemområdet som är av intresse att studera närmare är öppna standarder och öppna programvaror i kommunal verksamhet. För att göra studien hanterbar och koncentrerad till ett specifikt område så väljer vi att bryta ut en primär frågeställning ur problemområdet:

    • En undersökning av några kommuners uppfattning gällande öppna standarder samt om öppna programvaror skulle kunna vara ett alternativ för att nå öppna standarder?

    För att kunna besvara denna så ser vi fyra sekundära frågor som viktiga:

    · Hur definierar dessa kommuner begreppet öppen standard?

    · Vad är det som behöver standardiseras?

    · Upplever de att öppna program är en väg mot öppna standarder?

    · Kan öppen programvara tillgodose kommunernas definition av öppna standarder?

    1.6. Syfte

    Syftet är att undersöka om användning av öppna programvaror inom den kommunala sektorn skulle kunna vara en väg för att minska de påstådda problemen med låsta format och in­låsning mot en eller några få proprietära leverantörer.

    1.7. Avgränsningar

    Denna studie inriktar sig inte på de ekonomiska aspekterna av en övergång från proprietära programvaror till öppna programvaror. Att det kostar pengar att göra det tros inte vara är en alltför vågad gissning. Även om det i längden blir lönsamt för kommuner anses det vara ett så pass stort område att undersöka, att det passar bättre i en egen studie.

    1.8. Målgrupp

    Denna rapports primära målgrupp är forskare och studenter som eventuellt kan finna intressanta uppslag till vidare studier i ämnet. En sekundär målgrupp är kommunpolitiker och kommunala tjänstemän som på något vis är med och påverkar beslutsprocessen när nya system och programvaror ska införskaffas och när nya, eller ändringar i, strategiska IT-planer tas fram. Förhoppningen är att denna rapport ska kunna fungera som en liten tankeställare innan beslut fattas.

    1.9. Disposition

    Kapitel 1 Inledning

    avgränsningar, målgrupp och disposition.

    Kapitel 2 Metoder

    I detta kapitel redogörs för övergripande val av metod, samt sekundära val av metoder som datainsamlingsmetod, urvalsmetod och analysmetod. En redogörelse för intervjuplan och genom­förandet av intervjuerna återfinns även i denna del.

    Kapitel 3 Teoretisk referensram

    I detta kapitel redogörs för ämnesval, bakgrund till studien, problem och syfte, I detta kapitel redogörs för vad som framkommit i den litteraturstudie som inledde arbetet med denna rapport. Bland annat redogörs för öppen källkod, fri programvara, öppna standarder och kommuners problem med inlåsningar mot enstaka proprietära leverantörer tillika låsta format.

    Kapitel 4 Empiri

    Här redovisas det sammanställda resultatet av de genomförda intervjuerna.

    Kapitel 5 Analys och diskussion

    I detta kapitel analyseras och diskuteras det empiriska resultatet utifrån den teoretiska referensramen.

    Kapitel 6 Slutsatser

    I detta kapitel redovisas vilka slutsatser som dragits utifrån analysen av materialet.

    Kapitel 7 Rekommendationer

    Här redovisas de rekommendationer som dryftas att ge utifrån det framkomna resultatet.

    Kapitel 8 Referenser

    En källförteckning över de angivna referenserna i rapporten.

    Bilagor:

    Här presenteras bilagor av sådant material som anses vara viktiga att publicera tillsammans med rapporten, men som inte anses vara av sådan art att det måste finnas med i själva rapportinnehållet.

    2. Metoder

    2.1. Övergripande metod/forskningsansats

    En metod är en hjälp för den som vill studera det komplexa samhälle som vi lever i. Att tro att en enda metod kan förklara alla fenomen är dock en utopi. Därför måste man försöka hitta den metod som bäst belyser de frågor som studien avser att behandla (Holme & Solvang, 1997). Nedanstående rubriker försöker ge en förklaring till vilken/vika metoder som valts och varför. Detta för att läsaren ska kunna bedöma resultaten och dess relevans.

    2.1.1. En explorativ forskningsstrategi

    Då problemområdet och frågeställningen är det som styr valet av metod, påbörjades med att försöka avgöra vilken forskningsstrategi som frågeställningen krävde. Det första steget var att bestämma om det handlade om en explorativ, deskriptiv, förklarande eller normativ studie som skulle utföras. Att utföra en deskriptiv studie betyder att problemet är väl definierat och tydligt strukturerat och lämpar sig väl för att bestämma de egenskaper ett forskningsobjekt har. Man bestämmer värden på variabler och samband (Wallén, 1996). Det handlar även om att reducera analysen ner till individnivå (Alvesson & Sköldberg, 2008), vilket riskerar att göra att man missar viktiga pusselbitar. Frågorna som ska besvaras i studiens problemområde är inte av den arten att de går att bestämma värden på, vilket gör att denna strategi faller bort. Förklarande studier inriktar sig på att undersöka vilka kopplingar som finns mellan faktorer som ger upphov till ett visst fenomen (Wallén, 1996). Inte heller denna strategi överensstämde med problemområdet, där det inte handlar om att se kopplingar mellan faktorer, utan mer att ta reda på vilka faktorer som kan vara av avgörande betydelse för de undersökta kommunerna och deras förhållningssätt till problemet.

    En normativ studie (a.a.) hade i och för sig varit roligt att genomföra, men detta förutsätter att det undersökta i denna studie redan var antaget som en slags norm för vad en kommun ska satsa på, samt att formuleringen av problemet hade sett annorlunda ut än vad som nu är fallet. En explorativ studie utförs för att få ”… grundläggande kunskaper om problemets vad, när, var och i vilket sammanhang…” (ibid. s. 46). Den används när det fattas kunskap inom området för att samla in så mycket relevant information som möjligt om problemområdet för att komma vidare i studierna. När informationen är insamlad så försöker man belysa denna på ett så öppet och allsidigt sätt som möjligt. På grundval av problemets formulering och art så var en explorativ strategi given.

    Denna typ av studie stämmer väl överens med det hermeneutiska förhållningssättet (Wallén, 1996; Alvesson & Sköldberg, 2008) och det kunskapsläge som finns inom det valda problemområdet. Många studier har gjorts om öppna standarder och vikten av dessa för kommunal verksamhet, men när det gäller studier om öppna program och huruvida det är den naturliga vägen att gå för att uppnå öppna standarder, är det sämre ställt. Ser man till det Wallén (1996) säger om varför en explorativ studie utförs så stämmer detta bra överens med problemet.

    Då frågeställningen är av en öppen art utan några inbyggda antaganden, underlättar en explorativ strategi att verkligen gå på djupet istället för att försöka försvara eller dementera vissa påståenden som kan vara inbyggt i problemområdet. Alvesson och Sköldberg (2008 s.XXX) menar att ”Exploration … ger en möjlighet att uppnå en mer fullödig förståelse för den aktuella empiri… en flexibel metod för datainsamling, där principerna för urvalet revideras successivt under forskningsprocessen …”. Vi som studenter är då friare att under studiens gång, med hjälp av öppna frågor och en viss lyhördhet, anpassa studien till ny kunskap. Detta ansågs vara en viktig faktor för att besvara problemet på ett adekvat sätt. Ett öppet och flexibelt angreppssätt var en nödvändighet för att inte låsas fast i en alltför snäv tankebana, utan möjligheten att utforska nya infallsvinklar, eller ta upp nya frågor med informanterna, sågs som viktigt för att verkligen kunna belysa problemet från många håll.

    Alvesson och Sköldberg (2008 s.XXX) menar att ett explorativt angreppssätt borde kombineras med en ”inspektion” för att verkligen ”vrida och vända” på problemet. Med begreppet inspektion menas att man under studiens gång testar och undersöker de begrepp som framkommer för att se om dessa verkligen är relevanta och hållbara. Detta för att på så sätt kunna revidera de begrepp som framkommer i den empiriska undersökningen. Den ”inspektion” som blev aktuell i denna studie, var när nya begrepp eller nya infallsvinklar på problemet framkom, som ansågs vara viktiga att ställa frågor om till nyckelinformanterna. Detta för att deras syn på saken skulle komma fram samt för att vidga förståelsen och insikten.

    2.1.2. Induktiv metodansats

    Enligt Wallén (1996) så talar man om två metodansatser, den induktiva och den hypotetisktdeduktiva metoden. En tredje variant finns också, den abduktiva, eller abduktion, vilken kan sägas vara en blandning av de båda tidigare nämnda. Den abduktiva förutsätter att det finns ingående erfarenhet av det område frågorna gäller, erfarenhet av liknande fall (a.a.) med mera. Den hypotetiskt – deduktiva metoden tar sin utgångspunkt i en hypotes, eller flera hypoteser, för att genom olika experiment till exempel, testa hur väl hypotesen håller i ett empiriskt sammanhang. Studien är av en explorativ art grundat på de frågeställningar som föreligger, därför är det en induktiv metodansats som ska användas. Denna ansats tillåter att studenter ”upptäcker på vägen” (ibid. s. 47-48). Det behövs ingen teori att utgå ifrån som är förankrad och accepterad inom den akademiska världen, utan det är tillåtet att fritt formulera egna teorier eller nya forskningsuppslag utifrån det empiriska materialet.

    2.1.3. Kvalitativ undersökningsmetod

    Enligt litteraturen kan man skilja på två huvudinriktningar när det gäller metoder, en kvantitativ och en kvalitativ ansats. Den kvantitativa brukar något förenklat jämställas med siffror, och adekvat mätning av ett problem eller fenomen. Den kvalitativa kan enkelt benämnas som en metod att med ord beskriva ett problems karaktär och dess möjliga lösningar. Man kan även skilja på dem genom att säga att en kvalitativ försöker gå mer på djupet i enskilt utvalda studieobjekt, den kvantitativa försöker att finna mer generella innebörder, ofta i ett större antal studerade objekt (Holme & Solvang, 1997). Avsikten med denna studie var inte att finna generella förklaringar eller teorier, då frågeställningarna syftar till ett fåtal undersökta kommuner, därför passade en kvalitativ undersökningsmetod bäst. Wallén (ibid. s. 73) menar dock att ”kvalitativa studier har dock inget värde i sig utan behöver motiveras väl”. Wallén (a.a.) fortsätter med att ställa upp ett antal huvudskäl till varför dessa studier behövs. En avsikt med studien var att försöka få en ökad förståelse för hur begreppen definieras bland informanterna, där passade en av Walléns (ibid. s. 73-74) huvudpunkter väl in med detta syfte. ”Innebörder och symboler måste tolkas kvalitativ… Speciella tolkningsproblem gäller om det finns anledning att tolka in något utöver det som direkt är förhanden, som är dolt, underförstått.”

    En möjlig väg hade varit att först göra en kvantitativ undersökning för att undersöka hur många som anser att öppna standarder är viktigast för en kommun, men detta hade förutsatt en förförståelse för problemet på ett helt annat sätt än vid en kvalitativ ansats, vilket gjorde att detta valdes bort. Ännu ett skäl att inte använda en kvantitativ metod är de begränsningar, som detta innebär för de undersökta enheterna, att påverka teorin. Alla respondenter ställs inför samma frågeställningar och tvingas att svara utifrån ett och samma sätt (Holme & Solvang, 1997). Vid kvalitativa studier så har forskaren en helt annan möjlighet att ställa följdfrågor, att ställa frågor om sådant som framkommer under själva datainsamlingen. Det kan vara sådant som annars hade gått förlorat om respondenten/informanten bara fått besvara exempelvis med en enkät. Vi kan dock se att det är möjligt i ett senare skede att testa de teorier och slutsatser som en kvalitativ undersökning ger för att undersöka om dessa kan sägas gälla generellt eller inte. Avsikten har inte varit att dra några generella slutsatser så det kommer inte att utföras någon sådan undersökning. Det överlåts till någon mer hugad.

    2.2. Datainsamlingsmetod

    Innebörden av standarder och öppna standarder inte är definierad på ett enhetligt sätt, vilket anses vara av största vikt för förståelsen av kommuners krav på öppna standarder. Detta för att få en någorlunda klar bild av hur dessa begrepp tolkas idag av kommuner, företrädare för kommuner eller andra som är involverade i detta arbete. Den datainsamlingsmetod som ansågs bäst passa för denna studie utifrån den forskningsstrategi och valda metodansatsen, var djupintervjuer (Wallén, 1996). Djupintervjuer med speciellt utvalda informanter vilka erhållits, dels från nyckelinformanterna men också med hjälp av urvalsmetoden snöbollsmetod, se kapitel 2.3.2 Urvalsmetod. Utgångspunkten för en intervju är ofta att forskaren vill veta mer om en viss företeelse och öka sin förståelse för problemet (Holme & Solvang, 1997). Denna form av informationsinsamling är krävande och kan ta lång tid vilket kräver mycket analysarbete från forskarens sida. En stor fördel är dock att det även i analysarbetet går att återvända till informanterna och be om klargöranden eller ställa fler följdfrågor, om det skulle anses nödvändigt. Ur den intervjuades synvinkel kan det även vara en krävande situation att besvara frågor som går på djupet och där han eller hon själva måste fundera på vilket svar hon eller han vill ge (a.a.). Det ideala är även att forskaren till slut, upplever att frågorna besvaras lika, det vill säga att det har uppstått en mättnad (a.a.).

    2.3. Population och urvalsmetod

    2.3.1. Population

    Inledningsvis sattes begränsningarna för populationen att de informanter som skulle få delta i undersökningen skulle vara IT-chefer eller på annat sätt kunna ses som ansvariga för kommunens IT-utveckling. Vidare var det på grundval av de urvalsmetoder som presenteras i kapitel 2.3.2, som de slutliga informanterna valdes ut. Intresset låg i att hitta informanter som kunde bidra till att utveckla synen på problemet samt att öka förståelsen och insikten. Valet att kalla dem för informanter och inte respondenter berodde på möjligheten att ändra dessa, om det ansågs nödvändigt, allt eftersom kunskapen och förståelsen för problematiken växte. Backman (2008) menar att det är förfaringssättet som används vid kvalitativa studier.

    2.3.2. Urvalsmetod

    Tre olika urvalsmetoder användes i denna studie. Idén kommer från en D-uppsats (Lanäs & Lundkvist, 2005) där man hade använt sig av en kombination av ett subjektivt urval, ett flerstegsurval och ett snöbollsurval. Det ansågs viktigt att få intervjua några informanter från kommuner som kommit en bit på väg i arbetet med att implementera öppna programvaror, samt andra väl insatta inom området, därför valdes en väg som ligger ganska nära ett snöbollsurval. Nyckelinformanterna kontaktades och ombads ge vidare förslag på andra informanter som kunde vara intressanta. Lanäs & Lundkvist (2005) beskriver hur detta inte bara hjälper till att hitta ”rätt” informanter, utan att det faktum att studenter kan öppna många stängda dörrar, genom att hänvisa till en rekommendation. Ett subjektivt urval, vilket ligger ganska nära ett snöbollsurval, kan passa bra om kunskapen om den undersökta populationen kan anses vara god. Nackdelen med denna typ av urval är att det är svårt att uttala sig om hur säkra resultaten som framkommer är (Holme & Solvang, 1997). Att påstå att kunskapen om populationen var god inför urvalsprocessen, stämmer inte, men en bra överblick över vilken typ av information som var intressant fanns. Kombinationen av snöbollsurval och subjektivt urval stämde även bra överens med den explorativa forskningsansats som valdes. För att begränsa antalet informanter, användes ett flerstegsurval som sista urvalsmetod. De föreslagna informanterna översteg det antal som ansågs hinnas med under projektets begränsade tid, vilket gjorde urvalet nödvändigt. Att göra ett flerstegsurval innebär att ett urval görs på urvalet. Urvalet gjordes även på ett subjektivt sätt utifrån den erhållna information från informanterna samt utifrån den egna kunskapen om dessa, utifrån det valdes personer som ansågs mer intressanta. Kriterierna för detta sista urval var följande:

    · En subjektiv bedömning av vilka som dels hade den största implementeringen av öppna programvaror, enligt nyckelinformanterna, samt dels de kommuner som hade mindre positiv syn och såg svårigheter med öppna program inom den egna kommunen.

    2.4. Intervjuer

    2.4.1. Nyckelinformanter

    Nyckelinformanterna som använts i denna studie är dels Professor Per Flensburg, som gav namnen på flertalet intressanta och för problemområdet väl insatta personer. Det är även de personer, som efter Pers rekommendationer, valts ut och kontaktats. De som valdes ut var Mats Östling på SKL, och Peter Dacke administrativ chef för Barn och utbildning, Botkyrka kommun – Sambruk.

    2.4.2. Etiska aspekter

    Då intervjuerna gjorts med informanter som representerar en kommun, diskuterades om dessa informanter och kommuner skulle presenteras öppet i rapporten. Slutsatsen blev dock att det skulle gynna studien om de intervjuade fick vara anonyma och alltså bara kända av oss studenter (Holme, Solvang, 1997). Detta kanske kan ha inneburit fördelen att någon eller några informanter svarat ärligare på frågor som kunde uppfattas som känsliga att svara på offentligt. Informanterna informerades även om att den inspelade intervjun skulle komma att transkriberas och att materialet skulle kunna tänkas bli föremål för en granskning av forskare eller andra studenter, om dessa önskade ta del av materialet.

    2.4.3. Informanter

    Fem informanter blev till slut resultatet av urvalsprocessen. När den sista informanten skulle intervjuas, informant B, så uteblev denne av godtagbara skäl. Intervjun var inplanerad så sent i arbetet, varför en ny tid för intervju inte bokades. Det ansågs viktigt för trovärdigheten och ärligheten i de svar som gavs så därför valdes att avidentifiera informanterna. De kommer således i redovisningen av det empiriska materialet att refereras till som informant A, C, D och E samt i analysen kapitel 6. Det ansågs dock nödvändigt att redovisa lite bakgrundsfakta om de kommuner som informanterna företräder, detta för bedömningen av validiteten och reliabiliteten samt för generaliserbarheten av resultaten.

    Kommun A: Belägen i Västsverige med ca 35 000 invånare. Använder idag inga program­varor med öppen källkod, men har testat bland annat Open-Office.

    Kommun B: Belägen i sydöstra Sverige med ca 15 000 invånare. Utebliven intervju.

    Kommun C: Belägen i norra Sverige med ca 100 000 invånare. Har varit med och utvecklat en del öppna program och är den i studien som har den största implementeringen.

    Kommun D: Belägen i Västsverige med ca 60 000 invånare. Har enligt egen utsago ”en mycket blygsam” användning av öppna programvaror. Främst inom skolvärlden och på webbsidan.

    Kommun E: Belägen i Östra Sverige med ca 35 000 invånare. Har idag inga öppna program­varor, men ingår i ett samarbete med närliggande kommuner där rekommendationer om vissa öppna programvaror ska tas fram.

    Förutom de fem angivna informanterna så erhölls skriftligt material om en färsk utredning gjord i en av de ovanstående kommunerna, som till viss del, hade med denna rapports frågställning att göra. Denna utredning kan utlämnas avidentifierad, om så önskas.

    2.4.4. Intervjuförfarande

    För att verkligen få till den optimala intervjusituationen är det sannolikt bäst om man som intervjuare kan möta den man intervjuar ”öga mot öga”. Det var inte möjligt i detta fall, mest av ekonomiska skäl. Metoden som valdes för att komma så nära detta som möjligt, föll på att med hjälp av videokonferensverktyget Marratech[5] och webbkameror, utföra intervjuerna på distans. På detta sätt gavs ändå en större och bättre kontakt med informanten än om exempelvis en telefonintervju utförts, utan möjligheten att se varandra. Marratech erbjuder också en mycket lätthanterlig inspelningsfunktion för ljud och video, vilket underlättade, då kravet var att få spela in intervjuerna för att underlätta en senare hantering av dessa. Alla fyra intervjuerna genomfördes på detta sätt. Närvarande vid dessa intervjuer var informanten och båda författarna till denna studie. För att inga missuppfattningar om vad informanterna avsåg att förmedla i sina svar på frågorna, vilket ansågs som det viktigaste, avslutades intervjuerna med att göra en kort sammanfattning av vad som framkommit. Informanten tillfrågades därefter om korrektheten i sammanfattningen. Under analysen av dessa intervjuer har ingen kontakt tagits med informanterna för att kontrollera att vår tolkning stämmer.

    Även om denna studie har bedrivits utifrån en explorativ ansats, ansågs det ändå viktigt att det fanns en genomtänk plan, för att garantera att så mycket information som möjligt om problemet kunde fångas upp. Planen innehåller de övergripande frågeställningarna som önskades svar på (se bilaga 1 Intervjuplan testversion). En första testintervju genomfördes för att kontrollera intervjuplanens utformning och relevans, men efter testintervjun så framstod det ganska klart att intervjuplanen inte var tillräckligt väl­strukturerad och genomtänkt för att få de svar som problemområdet stipulerar. Därför omarbetades intervjuplanen till att mer fokusera rakt på problemet (se bilaga 2 Intervjuplan). Detta för att verkligen få svar på de frågor som ansågs vara viktiga för studien men även för möjligheten för informanterna att svara fritt och naturligtvis med möjligheten för oss som intervjuare att även i de fortsatta intervjuerna kunna ställa följdfrågor, om så ansågs nödvändigt.

    Val av teknik när intervjuer genomfördes ställde också till lite problem. Intervjuerna genomfördes på redovisat sätt men vid vissa tillfällen saknades ljudet. Inspelningen hade således fallerat några sekunder. Vi hoppas och tror dock att detta inte påverkat studien i en negativ riktning, utan att materialet ändå lyckats analyseras på bästa sätt.

    2.5. Analysmetod

    För att kunna analysera intervjuerna som genomförts på ett strukturerat sätt, har en metod som kallas för helhetsanalys använts (Holme & Solvang, 1997). Utgångspunkten har varit fyra sekundära frågorna som tagit fram ur problemområdet för att på så sätt försöka hitta sådant i intervjuerna som kan placeras in under respektive frågeställning. Istället för att som (a.a.) föreslår, klippa och klistra, så valdes att med färgkombinationer markera upp den transkriberade texten utifrån dessa frågeställningar. Detta gjorde det enkelt att hitta avsnitt som på något sätt har med frågeställningen att göra, och underlättar när citat ska väljas ut som understryker det beskrivna. Denna delanalys av intervjuerna presenteras under kapitel 5.1-5.6. En helhetsanalys utfördes därefter där empirin diskuteras utifrån den teoretiska referensramen, vilket presenteras under rubriken Analys och diskussion (kapitel 6). Det teoretiska materialet har inhämtats från böcker och artiklar som på något sätt berör ämnet. Artiklarna är framsökta med hjälp av de verktyg, databaser och e-tidskrifter med mera, som tillhandahålls på Högskolan Väst: s biblioteks hemsida[6].

    2.6. Mäter vi det vi vill mäta och mäter vi på ett trovärdigt sätt?

    En kvalitativ studies validitet och reliabilitet är inte alls så viktigt, enligt vissa, som när det handlar om en kvantitativ studie (Holme & Solvang, 1997). Detta har dock börjat användas allt mer i den kvalitativa vetenskapstraditionen (Gunnarsson, 2002). Enkelt förklarat kan man säga att i en kvantitativ studie så har man redan innan datainsamlingen börjar, bestämt sig för en metod med erkänd reliabilitet och validitet för det syfte man vill nå. I en kvalitativ undersökning är detta något som arbetas med kontinuerligt under hela projektet (a.a.). Ännu en differens är att det i en kvalitativ studie även innefattar hur analysen av den insamlade datan utförts, medan det i en kvantitativ främst avser att beskriva att rätt sorts data samlats in.

    2.6.1. Författarnas bakgrund

    Då denna studie är av en kvalitativ art är det viktigt för reliabiliteten och validiteten att redogöra för den bakgrund som främst författarna och handledaren har, samt varför detta ämne valdes (Gunnarsson, 2002). Allt för att underlätta för läsaren att förstå vilken förförståelse författarna har. Vi som skrivit denna rapport är två studenter på Informatik­programmet på Högskolan Väst och handledaren, Per Flensburg, är professor i social informatik. Vår tidigare erfarenhet inom öppna programvaror och öppna standarder sträcker sig enbart till privat användning av de gratis och öppna programvarorna OpenOffice[7] som är en kontorssvit liknande Microsofts Office paket och GIMP[8] som är ett bildredigerings­program liknande Adobe photoshop[9]. Intresset för detta ämne väcktes på allvar då vi deltog i ett projekt inom Västerviks kommun där det undersöktes vilken GIS-plattform (Geografiska Informations System) som skulle kunna vara aktuell för kommunen. Vi tyckte oss se ett visst motstånd och en låg kunskap om öppna programvaror och genomförde därefter ett flertal studier inom detta i efterföljande kurser.

    2.6.2. Studiens validitet

    När det gäller kvalitativa studier och validiteten så kan man bryta ut två begrepp, intern validitet och extern validitet. Gunnarsson (2002) ställer upp vissa begrepp som, om de är bra beskrivna, gör att trovärdigheten på arbetet ökar:

    Intern validitet

    v Kommunikativ validitet – forskarens förmåga att kommunicera forskningsprocessen, vilket består av följande punkter:

    · Beskrivning av förförståelse – vilket görs ett försök till inledningsvis under kapitel 1.2 Egna tidigare utförda studier, där tidigare forskning som de varit inblandade i redovisas, samt i kapitel 2.6.1 Författarnas bakgrund.

    · Beskrivning av datainsamling – beskrivs under kapitel 2.2 Datainsamlingsmetod

    · Beskrivning av urval – beskrivs under kapitel 2.3 Population och urvalsmetod

    · Beskrivning av analysprocessen – beskrivs under kapitel 2.5 Analysmetod.

    v Deltagarkontroll – vilka möjligheter har deltagarna haft att korrigera fel och miss­uppfattningar och hur har detta gått till. Detta beskrivs under kapitel 2.4.4 Intervjuer.

    v Triangulering – innebär i vårt fall att vi hämtar in synpunkter från flera olika källor, kommuner och experter, som har olika relation till problemet en så kallad käll-triangulering.

    Extern validitet

    Med extern validitet avses hur överförbart eller tillämpligt de metoder och resultat som använts är i ett generellt perspektiv. I en kvalitativ studie är det därför av yttersta vikt att verkligen presentera hur man gått till väga för att få fram resultaten och vilka resultaten är. Hur generaliserbart detta är avgörs sedan av den som läser rapporten. Det som även påpekas i denna rapport, är de fynd som framkommit vilka enbart kan appliceras på objekten som ingått i studien. För kunna generalisera anses att mer forskning behövs och med en annan forskningsansats.

    2.6.3. Studiens reliabilitet

    Också när det gäller reliabiliteten så ställer Gunnarsson (2002) upp ett antal begrepp som måste vara väldefinierade i en kvalitativ studie:

    v Kvaliteten på teknisk utrustning – vilken utrustning användes och hur? Detta redogörs för under kapitel 2.4.4 Intervjuförfarande.

    v Kvaliteten på forskaren – delas upp i nedanstående begrepp

    Ø Beskrivning av förförståelsen – se intern validitet kapitel 2.6.2

    Ø Forskarens förmåga att göra bra observationer/intervjuer – anses vara svårt att beskriva, men det som beskrivs under kapitel 2.4.4 intervjuförfarande är ett försök till detta.

    Ø Forskarens förmåga till följsamhet mot data – hur har den inledande datainsamlingen påverkat resten av den samma? Då studien är av en explorativ art samt att en snö­bollsmetod använts som en av urvalsmetoderna så är det av största vikt att redovisa om inriktningar har ändrats under resans gång och på vilket sätt och varför i så fall. Detta görs under kapitel 2.4.4 intervjuförfarande.

    Ø Kvaliteten på forskarens handledning – detta redovisas under kapitel 2.6.1 Författarnas bakgrund.

    2.6.4. Studiens objektivitet

    Objektiviteten är till mångt och mycket samma som den interna validiteten se kapitel 2.6.2 Studiens validitet. Forskaren ska vara neutral och undvika att lägga in egna värderingar i de data som framkommer vid intervjuer. Hur väl utforskarna till denna rapport lycktas med detta är svårt att säga. Ett sätt att kontrollera detta på är att låta oberoende forskare ta del av intervjuerna, för att de ska kunna bedöma detta och sedan jämföra resultatet (Gunnarsson, 2002). Detta överlåts dock till någon annan.

    3. Teoretisk referensram

    Öppen källkod och fri programvara är den svenska översättningen av de vedertagna begreppen; ”Open Source och Free Software”. I denna rapport kommer vi att använda oss av samma definition som Statskontoret (2003) gör när de samlar öppen källkod och fri program­vara under en gemensam benämning; öppna program. Begreppen kommer endast användas var för sig när specifika fall av begreppen berörs. Öppen källkod är den svenska översätt­ningen av ”open source” och fri programvara översatt från ”free and open source software”. Nedan beskrivs historik om öppna och fria programvaror, om den offentliga sektorns situation, samt en förklaring av begreppen öppen programvara, standarder och öppna standarder.

    3.1. Historik om öppna och fria programvaror

    Det amerikanska förvarsdepartementet började på 60-talet att utveckla föregångaren till Internet; ARPAnet, (Computer history museum, 2006) där återfinns de första liknande prin­ciperna som idag kännetecknar de grupper ”communitys” som genom samarbete och till­gängliggörande av källkod ger allmänheten tillgång till öppna och fria program (Demil & Lecocq, 2006). På 80-talet ändrades synen på programvara från att bara ha varit en maskin­vara till att ses som en tillgång som kunde generera intäkter (Klang, 2008). Richard M Stallman, en programmerare, startade redan 1983 fri programvara rörelsen då han insåg att det uppstod problem med att bara släppa sin kod fri. Tanken var att alla människor som bidrog till förbättring, utveckling och bearbetningar skulle dela med sig av detta. Så blev det inte. Han startade ett projekt, GNU som står för “GNU is not UNIX”, till detta utarbetade han en speciell licens, GNU-licensen (GPL – General Public License), för att garantera att programvara utvecklad inom GNU-projektet skulle förbli fri och öppen för alla att använda och nyttja. 1985 grundade Stallman ”Free Software Foundation, (FSF)” som är en icke-kommersiell organisation med uppdraget att främja och utbilda för datoranvändare runt om i världen (Free Software Foundation, 2007).”GNU – (General Public Licens)” licensen kom senare att bli känt som ”copyleft”. ”Copyleft” innebär att kod licensierad under GPL licensen som integreras med andra programvaror måste enligt avtalet öppna upp den kod som den integrerade programvaran innehåller. I mitten på 1990-talet när Internet fick sitt stora genom­brott och Linus Torvald utvecklade Linux kernel, så tog utvecklingen av öppen källkod fart (Mc Inerney, 2007).

    The Open Source Initiative (OSI) bildades 1998 och är en mer kommersiell utveckling av FSF. Bruce Perens och Eric S Raymond är grundarna till rörelsen. OSI är idag det av sam­hället erkända organet för översyn och godkännande av licenser. OSI är aktivt engagerad i öppen källkodsbyggnad och hur ”Open Source” -teknik, licenser och modeller för utveckling som kan ge ekonomiska och strategiska fördelar. Det finns licenser med olika nivåer av bort­avtalad upphovsrätt som erbjuder olika grader att nivåer för att använda, kopiera, modifiera och vidaredistribuera programvaror. De olika modeller som finns är beroende på om programmeraren har valt att ansluta sig till OSI eller FSF för licensiering av sin programvara.

    3.2. Den offentliga situationen

    3.2.1. Utvecklingen inom den offentliga sektorn

    I Sverige finns sedan början på 1990–talet lagen om pliktexemplar SOU 1993:1392 §32 som talar bland annat om standarder för dataformat för att säkerställa att man även i framtiden kommer att kunna läsa de dokument som finns lagrade i våra elektroniska arkiv, i dagligt tal kallad arkivlagen. I TF, Tryckfrihetsförordningen uttrycks det att offentliga handlingar och kommunikation bör ske med hjälp av öppna standarder.

    Begreppet öppna programvaror har fått stor spridning eller som Hemphill (2005) uttrycker sig; det har nått ut till den ”kritiska massan”. Sedan öppna programvaror uppmärksammats har flertalet både nationella och internationella utredningar gjorts de senaste åren inom området. Hemphill (a.a.) menar att det är en indikation på att detta fenomen har tagit mark inom den offentliga sfären. 2002 gjorde EU en gedigen undersökning av FLOSS (Free Libre Open Source Software). Studien tar upp både konsekvenser och hur öppna program verkar. Resultatet blev en stor bas av primära uppgifter om öppna program och en identifikation på indikatorer för att kunna mäta värdet av dessa programvaror när de sprids och utvecklas. Statskontoret (2003) utförde en mer lokal undersökning som belyser våra svenska för­hållanden. Våra skandinaviska grannar gjorde under samma period liknande undersökningar men har idag kommit längre med att integrera öppna program i sin offentliga sektor, mycket beroende på den förankring som detta fått på den politiska arenan i respektive land. Stats­kontorets utredning blev sedan förstudie för den policy som statskontoret (2004) utformade. Policyn beskriver hur ramavtal ska hanteras vid upphandling av öppna program. Öppna standarder och öppna format påtalas som viktiga faktorer för att öka konkurrensen, inte­roperabiliteten, det vill säga systems förmåga att kunna integreras och kommunicera med varandra, och samtidigt minska kostnaderna inom den offentliga sfären.

    OSOR (Open Source Observatory and Respository) inom EU har utformat riktlinjer för anskaffning och upphandling i offentlig sektor av öppna program (Gosh, Glott, Schmitz, Boujraf, 2008). Här pekas på viktiga faktorer för medlemsländerna som transparens, lång­siktighet och kostnadseffektivitet. OSOR indikerar att vid upphandling av programvara med öppen källkod bör kravspecifikationen inte baseras på funktionskrav för specifika produkter eller specifika leverantörer. Istället bör egenskaper som öppna standarder och öppen programvara vara en del av dessa krav, antingen som ett minimikrav eller som gynnande egenskaper vid upphandling (a.a.). Samtliga rapporter pekar på vikten av öppna standarder samtidigt som de tar upp fördelar med fria och öppna programvaror. Denna indikation förstärks av de förslag till vidare studier som tas upp i ovan nämnda rapporter.

    3.2.2. Svårigheter inom kommuner att införa öppna programvaror

    Den kommunala sektorn brottas idag med de kostnader som är förenade med programvaror. Kommunerna betalar licensavgifter för hela kommunen eller för enskilda användare på olika nivåer vilket är skillnaden mot öppna programvaror. Öppna program har licensvillkor som handlar om rätten för användaren att modifiera, kopiera, vidaredistribuera och förbättra käll­koden medan de proprietära programmens licenser inte ger användaren tillgång till vare sig koden eller några modifierande rättigheter. Dedrick och West (2003) visar i sin studie hur viktigt det är för en organisation att ha en enhetlig standard i sin miljö vilket en proprietär leverantör som Microsoft erbjuder sina kunder. Genom möjligheten att lägga till program och applikationer som är utvecklade mot deras plattform. Öppna program utvecklats i ”communitys” där egennyttan (Von Hippel, 2005 s. 33-43) har varit den främsta drivkraften för att skapa nya öppna program. Detta kan vara en av förklaringarna till varför det finns så få system utvecklade mot den offentliga och främst den kommunala marknaden inom denna rörelse. I hans bok konstaterar han att ”behovet” ofta har en hög grad av heterogenitet för flera produkter. Kommuner som överväger att byta eller ta in nya system har inte funnit eller har problem att hitta öppna alternativa system som täcker in behovet som kärnverksamheten i en kommun kräver. Det finns få öppna program som klarar den komplexa funktionalitet som krävs av ett verksamhetssystem (Åsbom, 2009). Avsaknad av ett väl genomtänkt samarbete kan också vara en orsak till att kommuner har så svårt att få till en utveckling av verksamhetssystem grundade på öppen källkod. Samarbete har även visats sig effektivt när man ser hur kommuner gemensamt kan gå samman för att trycka på en proprietär leverantör, för att få större möjlighet att integrera öppna och slutna system i en och samma miljö (a.a.).

    3.3. Öppen programvara, standarder, öppna standarder

    3.3.1. Vad är öppen programvara?

    Program som finns att ladda ner från Internet eller att köpa finns endast i en sammanställd version som är redo att användas och köras. Sammanställd innebär att den faktiska program­koden, kallad källkoden, som programmeraren skapar har körts genom ett särskilt program som kallas en kompilator som översätter källkod till en form som datorn kan förstå (Beekman, 2006). Det är oerhört svårt att ändra den sammanställda versionen av de flesta applikationer och nästan omöjligt att se exakt hur programmeraren skapat olika delar av programmet. De flesta leverantörer av kommersiella programvaror ser detta som en fördel att hålla andra företag borta från att kopiera deras kod och använda den i en konkurrerande produkt. Leverantörer av sluten kod benämns som proprietära (Hemphill, 2005). Öppen källkod är motsatsen och ingår i den sammanställda versionen. Utvecklare inom den öppna rörelsen uppmuntrar användarna att modifiera och anpassa källkoden. De tror att på sikt blir programvarorna mer felfria – fritt från buggar och användbara.

    Fri programvara är en fråga om användarnas frihet att köra, kopiera, distribuera, och modifiera programvaran. Detta brukar benämnas som de fyra friheterna (Cooper, DiBona, Stone editorer, 2005). Oavsett vilken licens man väljer att distribuera programvaran under, så kan aldrig dessa fyra friheter avtalas bort. Fri mjukvara behöver inte vara gratis: man får ta betalt, men alla nya användare får samma friheter som tidigare användare (Computer Sweden, 2008). Något felaktigt tror många att fri programvara inte betyder icke-kommersiellt. Ett fritt program (FSF, 2007) måste vara tillgängligt för kommersiell användning, utveckling och distribution. Du kan ha betalat pengar för att få kopior av fri programvara, eller du kanske har fått kopior utan kostnad. Men oavsett hur du har ditt exemplar så har du alltid friheten att kopiera och ändra programvaran, även att sälja kopior. OSI-modellen innehåller tio stycken kriterier som måste uppfyllas för att artefakten ska ses som öppen programvara (Coar, 2006; Cooper, DiBona, Stone editorer, 2005). FSF och OSI är de organisationer som idag ses som ”myndigheterna” i det så kallade öppen källkods­samhället (OSS - open source software), enligt Ueda (2005). Det finns två olika men liknande definitioner av fri programvara och öppen källkod. Det som till största delen skiljer dessa åt är den ideologiska rörelse som dessa härstammar från samt även de värderingar som återspeglas med de riktlinjer som respektive rörelse bygger på (Statskontoret, 2002). Ytterligare en skillnad mellan dessa två organisa-tioner är hur de licensierar sina programvaror. De licenser som finns för FSF och/eller OSS är avtal med olika grader av öppenhet (Wheeler, 2007). De skapande upphovsmännen – programmerarna kan genom dessa licenser avtala bort (Klang, 2008) hela eller delar av sin upphovsrätt eller behålla sina rättigheter.

    3.3.2. Vad är en standard?

    Bild 1 Katalogstruktur Windows XP

    clip_image003Vad är egentligen en standard? Om man slår upp ordet standard i ordlexikonet Nationalencyklopedin (2009) får man veta att en standard är något som man jobbat fram, för att få en lösning på ett ständigt åter­kommande problem. Inom IT-området finns det centrala standarder för dataformat (Shah och Kesan, 2007), nätverkskommunikation och fysiska apparater för att informationsutbytet mellan användare ska fungera. Standarden utformas som ett dokument där olika parter beskriver hur och på vilket sätt något ska utföras. Publiceringen av det formella dokumentet sker av ett oberoende standardiseringsorgan. I Sverige är det SIS ( 2008) som är det huvudsakliga standardiserings­organet och på internationell nivå är det ISO och W3C.

    Standarder brukar utvecklas gradvis över tid då förändringar i omvärlden påverkar kraven och möjligheterna. Shah och Kesan (2007) menar att öppna standarder tar längre tid att utforma än vanliga standarder. Det går också att dela in standarder i de Jure och de Facto. De Facto standard är en standard som har vuxit fram till ett vedertaget begrepp inom en bransch eller inom ett område. De Facto standarder är inte certifierade av något standardiseringsorgan, utan är alltså en standard som antagits som en standard för att användarna av den ser stora fördelar med den. De Jure standarder är certifierade standarder som är certifierade av erkända standardiseringsorgan att förvalta och att utveckla (Nationalencyklopedin, 2009).

    3.3.3. Vad är en öppen standard?

    Det finns flera definitioner av vad som utgör en öppen standard. Olika definitioner presenteras av Bruce Perens, OSI, EIF 2.0, W3C etc. Gemensamt är att de har alla samma grundläggande innebörd: standarden skall vara öppen och fritt tillgänglig och kunna implementeras fritt utan restriktioner. Det motverkar dessutom inlåsning (Shah och Kesan, 2007) till leverantörer. Definitionen av öppna standarder är fortfarande en gråzon (a.a.). Öppna standarder kan nämnas inom en mängd olika områden; filformat, kommunikationsprotokoll, affärsprocesser (Nordqvist, 2006) med DSAP (Systems Analysis and Program Development), gränssnittsytor mellan olika system och applikationer och katalog­strukturer (se bild 1 Katalogstruktur Windows XP). En standardiserad katalogstruktur underlättar då utvecklare och programmerare ska hitta vart filer och information ligger, alltså i vilken mapp de kan hitta den.

    De "de facto-standarder" (Nationalencyklopedin, 2009) som har fått en stor spridning och används rikligt har blivit mer vedertagna de senaste åren. Det är icke öppna standarder som inte har en status av officiell standard, här kan man nämna Microsofts doc-format som anses vedertaget men inte är en formell standard (Perens 2007). Perens har skrivit den mest citerade definitionen av öppna standarder: Open standards; Principal and Practice, som är mer av en princip och en praxis för att dels erbjuda och dels driva standarden och samtidigt se till vad som gör en standard öppen. Praxisen (Perens, 2008) försvarar dessutom fria programvaror i den hårda konkurrensen vid standardiseringar. Krechmer (2005) har analyserat vad som kännetecknar en öppen standard. Det finns tre olika parter i en standard; officiella standardiseringsorgan, implementatörer, användare. De har alla med sin egen syn på vad som utgör en öppen standard. Dessa tre gruppers olika krav är var för sig rimliga, men tillsammans blir de allt annat än enkla att uppfylla. Kraven har han sedan benat ut till tio kriterier som även de är svåra att uppfylla (a.a.).

    3.3.4. Sverige och öppna standarder

    I ett övervägande i utredningen SOU 2007:47 (IT-standardiseringensutredningen 2007) beskrivs hur man kan ta stöd i lagen om offentlig upphandling (LOU). Där stadgas det hur standarder får åberopas och där är formella standarder huvudalternativet. Trots detta domineras den offentliga upphandlingen av applikationer med proprietär programvara. SOU trycker på att upphandlingen bör sträva efter att använda dessa öppna standarder som finns med god funktion inom en mängd områden och detta bör dessutom ge avtryck även i ram­avtalsupphandlingar.

    3.3.5. Vad är SOA?

    En beskrivning hur ett informationsutbyte bör ske och vilka krav kommuner bör ställa på utbytet av informationen i gränssnittsytorna, även kallade interface. SOA (Service Oriented Architecture) är en tjänsteorienterad arkitektur (Franzén, 2009) som underlättar integration mellan system i en öppen arkitektur där man kommer bort från de traditionella stuprörs systemen. När man pratar om arkitektur syftar man till att strukturera ett datasystem. Systemets uppbyggnad kan beskrivas i form av komponenter eller processer. Struktureringen styrs utifrån från ett antal principer (Mathiassen, Munk-Madsen, Nielsen, Stage, 2001). För att beskriva SOA har vi refererat till en d-uppsats av Franzén (2008 s. 13-15). Hon tar stöd i ett projekt Serviam (2008) där primära uppgifter hämtats. Följande förklaring av SOA kommer från det projektet:

    ”SOA är ett koncept som går ut på att kopplingar mellan olika system och applikationer sker genom ett tjänsteutbyte. Ett system eller applikation tillhandahåller en tjänst medan ett annat agerar klient. Istället för att flera system eller applikationer gör samma sak kan dessa anropa varandra för att, till exempel, utföra en speciell process eller hämta specifik data. Detta kan göras mellan företag externt för att utbyta information eller internt för att integrera befintliga system. Syftet är det samma som med det traditionella tjänsteutbytet mellan företag: system och applikationer behöver inte ha samma logik utan de kan dela på arbetsuppgifterna.”

    3.3.6. Vad är en licens?

    En licens kan ses som ett avtal. I svensk rättslagsstiftning görs ingen väsentlig skillnad mellan ett avtal eller en licens (Klang, 2008). Tyngdpunkten ligger i den överenskommelse som parterna har ingått i. De juridiska förutsättningarna för licenser ligger på olika grader av dels upphovsrätt och dels avtalsrätt. Licenserna underlättar för programmeraren att följa det upphovsrättsliga regelverket och samtidigt dela med sig av sin skapande kod men utan att släppa alla sina rättigheter. Ueda (2006) påpekar hur öppna program med sina licenser inte längre bara är verksamma inom rörelsens utvecklings ”communitys” utan har utvecklats mer mot att bli affärsmodeller som kan anpassas till näringslivet. Standarder utgör en viktig del när öppna programvaror ska licensieras för att användas i näringslivet. Syftet som FSF har är att säkerställa att alla genom de fyra friheterna får tillgång till koden men de blir då även skyldiga att dela med sig av egna förbättringar, bearbetningar etc. FSF genom Stallman:s GNU licens benämns ”copyleft”. Motståndare menar att copyleft ”smittar” det vill säga att integrerar man kod med GNU-licensen så måste även denna släppas under GNU-licensen. Förespråkare menar motsatsen att man ”vaccinerar” kod så att den håller sig öppen (Klang, 2008).

    4. Kommuners verksamhetsutveckling med öppna program

    I detta kapitel presenteras information som vi inhämtat från de två huvudsammanslutningarna som verkar för svenska kommuner. Information från våra nyckelinformanter, som har kopplingar till dessa sammanslutningar, redovisas under denna rubrik också. Materialet i form av samtal och annan litteratur ansågs inte tillhöra vare sig teori- eller empirikapitlen utan ett mellanting, där av placeringen.

    Sambruk och SKL är två kommunala sammanslutningar som verkar för att bland annat stödja och hjälpa till med verksamhetsutveckling inom kommuner. SKL är en arbetsgivar-organisation för kommuner och landsting där merparten av Sveriges alla kommuner är medlemmar. Sambruk är en kommunsammanslutning vars vision är att genom samverkan skapa förutsättningar för kommunal verksamhetsutveckling, baserad på e-tjänster. Denna organisation har medlemmar, i form av organisationer och kommuner, som på mer frivillig basis väljer att aktivt jobba för utveckling av e-tjänster i denna sammanslutning. Initiativet i sambruks (Larsson, 2008) arbetssätt ligger i linje med de ambitioner och satsningar som görs av Sveriges kommuner och Landsting (Carlstedt, 2009) och fd. VERVAs satsning för en samordnad offentlig förvaltning där integrerade och sammansatta e-tjänster tillhandahålls. I denna studie har vi inhämtat material, expertkunskap i form av samtal med aktiva inom dessa organisationer. Därigenom har vi fått den snöbollseffekt vi önskade när vi av experterna löpande fått tips på material, personer att tala med inom området som behandlar den frågeställning vi försökt besvara. För att intraoprabiliteten ska effektiviseras behövs ett långsiktigt och strategiskt tänk. Samarbete mellan kommuner som exempelvis samman-slutningarna Sambruk eller SKL, möjliggör kostnadsbesparingar och utbyte av resurser och programvaror.

    De flesta kommuner är idag inlåsta mot en eller några få specifika leverantörer[10] som visserligen tillhanda håller stabila och säkra system men som kostar och försvårar integration av program och applikationer från andra leverantörer. I slutna system finns det liten eller obefintliga chanser att modifiera och anpassa programvaran då man inte har tillgång till källkoden. De proprietära leverantörerna har ofta i sina avtal även reglerat på vilka eller vilken hårdvara deras program måste installeras för att kommunen ska få teckna avtal för support och stöd. Supportavtalen är något som kommunerna är väldigt beroende av i sitt operativa arbete där man snabbt kan få den hjälp man behöver. Dacke[11] menar att kommuner inte kan byta ut sina bassystem, det blir allt för resursmässigt krävande. Man bör istället eftersträva efter ett vinnar- vinnarkoncept. En lösning som han föreslår är en sammanslutning av kommuner som kan jobba tillsammans mot stora leverantörer för att få en öppenhet och därmed integrationsmöjligheter. För att detta ska bli realiserbart behövs en dialog, mellan kommuner och leverantörer på en affärsmässig nivå. Hela branschen måste pressas och konkurrens­utsättas menar han, vilket kräver utveckling av nya affärsstrategier. Det som krävs för att klara att integrera och drifta öppna system kräver mer resurser och uppgraderade kunskaper menar kommunerna (Östling, 2008). Enligt SKL:s enkätundersökning gjord mot landets kommuner om öppna program påvisas brister främst inom programmering inom kommunernas IT-avdelningar.

    En utvecklad programvara som designats för en kommun skulle alltså tillfredställa andra kommuners krav (behov) på programvara. Varför uppfinna hjulet flera gånger? Som en nyckelinformant uttrycker det. Delning av utvecklingsarbete och programvaror sparar resurser, ökar effektiviteten och ökar samverkan enligt SKL (Östling, 2007). Sambruk har i sitt arbete mot öppenhet mer konkret beskrivit öppenheten i form av en upphandlings och kravspecifikation i rapporten ÖTP (öppen teknisk plattform) (Ohlsson, 2007). Sambruk säger i denna rapport: ”att standardapplikationerna inom kommunsektorn har släpat efter ur öppenhetssynvinkel” (ibid. s.19). Sambruk förväntar sig dock att detta ska kunna lösas, dels baserat på generella systemutvecklingstrender, dels grundat på Sambruks och andras påverkan och upphandlingstryck. SKL:s undersökning 2008, som utfördes tillsammans med Verva mot kommuner respektive myndigheter, pekar på bland annat på kommuners önskan om öppna standarder för att kunna integrera olika programvaror med varandra, inte källkoden i sig. För att kommuner ska lyckas med detta vill de flesta kommuner ha ett utbyte av erfarenheter med andra kommuner (Östling, 2008). Citatet, som återfinns i båda rapporterna, både SKL:s och Vervas, visar på att det ändå finns ett samband mellan öppna program och öppna standarder:

    ” Öppen programvara har också en given roll i arbetet med öppna standarder, dels genom att öppna program i stort sett uteslutande använder öppna standarder, dels genom att referens­implementationer av öppna standarder byggs på öppen programvara. Öppna standarder är ett av de viktigaste inslagen för att åstadkomma en europeisk fri inre marknad, en mer konkurrensneutral upphandlingssituation och en effektivare offentlig sektor.”

    Sambruk, SKL och Linköpings universitet håller också på med ett projekt i Vinnova: s regi, ”Business Models for Open Source Software in the Public Sector: New Opportunities for Customers and Suppliers” där de studerar affärsmodeller. Deras förväntade resultat är bland annat ”Förslag på ramverk för fungerande affärsmodeller och arbetssätt för införskaffande, utveckling och förvaltning av öppen programvara för kunder i offentlig sektor (främst kommuner) och deras leverantörer” (Öhrwall - Rönnbäck, Anna, 2008 slide 8). En affärsmodell är en modell över hur leverantörer och kunder, i detta fall kommuner, ska kunna dra fördelar ur ett affärsmässigt samarbete på lite längre sikt.

    5. Empiri

    Under nedanstående rubriker redovisas det empiriska materialet utifrån den helhetsanalys (Holme & Solvang, 1997) som genomförts på det transkriberade källmaterialet. Rubrikerna är en uppdelning i de återkommande teman som framkom vid denna analys. Om någon vill ta del av transkriberingarna, kontakta författarna till denna rapport (se sista sidan för e-post­adresser).

    5.1. Definition av standarder och öppna standarder?

    Att få ett klart och rakt svar från informanterna om vad en standard och en öppen standard är visade sig svårt. Informant D uttrycker sig så här: ” … det är väl ingen skillnad på vad som är en standard för en kommun som är en standard för någon annan. En standard är väl något som är fastställt av något organ då som har någon sorts definitionsrätt…” Informant C menar att det inte finns någon gemensam definition av en standard. Det finns olika områden för standarder, dels för omedelbar hantering av information i Web Service och dels då det sker en senare hantering av data, när filer ska lagras. De definitioner som anges av informanterna är bland annat: de facto standarder, certifierade standarder, standarder för fil­format, standarder för informationsutbyte och standarder för affärsprocesser. Nedanstående citat från informant D visar på osäkerheten och svårigheten att verkligen definiera begreppen och att det finns olika områden där standarder behövs:

    ”Ja, det är det ju. Det kan ju även vara affärsprocesser om vi tänker på jaaa…, vad heter det ehh affärslogik som ju…. Alla kommuner har ju i stort sett lika regelverk att leva under. Och det vet ni ju att vi har Kommunallag och vi har ju en massa myndighetsutövnings som ska göras och för att göra allt det då så finns det ju ingenting som säger att man behöver göra på ett mängder av olika sätt, på olika ställen. Utan man kan göra i stort sett en Best practise lösning och då skulle man kunna definiera en standard för affärsprocess. Och gjorde man då det, så skulle man kunna tänka sig att det vore betydligt enklare och mer kostnadseffektivt att utveckla IT-stöd för det här också då. Idag så har man ju många gånger snarlika sätt att göra saker och ting på men det är ju uppfunnet av de lokala, av de egna kommunerna och det kan skilja sig lite åt i handläggning från det ena stället till det andra.”

    När frågan om hur man definierar en öppen standard ställs så svarar man bland annat så här, vilket kanske tyder på att kommuner behöver sätta en enhetlig definition på vad en öppen standard är:

    Informant C:

    ” Ja alltså standardbegreppet det är ju ett sådant där begrepp som är svårhanterat bara för att det betyder så väldigt olika för olika personer. Men när man pratar om öppna standarder i det här begreppet så är det för mig en definition för ett informationsutbyte mellan system.”

    Informant E:

    ” Nä öppna standarder så att säga, standarder.. dokument så att säga, filformat ja format så att säga, det är det som jag ser som standards då. Men öppna program och öppen programkod det, ok ja, det är ju också en sak då om man hur man ser på det, men det är nog lite mera komplex situation det där också då tror ja att ..”

    Informant D:

    ”ja det är en bra fråga! …Ja det är en standard som är tillgänglig för alla det är klart att det som inte är tillgängligt för alla att använda sig av och då är det ju den proprietära standarden som i alla fall historiskt sett har varit lite oåtkomliga...”

    De två definitioner som är genomgående för alla informanter är att de ska vara till­gängliga för alla och att de ska vara certifierade av erkända standardiseringsorgan som anses stå för hållbarhet och kontinuitet.

    5.2. Vad behöver standardiseras?

    När frågan om vad som behöver standardiseras ställs så ges lite olika svar. Det är för verksamhetssystemen inom kommunerna som det verkligen vore intressant och nödvändigt med öppna standarder enligt informant D. Idag använder kommunerna enligt informanterna A och E mest de facto standarder, standarder som är utvecklade och inmutade av mjukvaru-branschen tillika leverantörerna på den proprietära/låsta sidan. Dessa levererar till största delen de verksamhetssystem och kontorsapplikationer som kommunerna använder idag. Informant A anser att: ”Det kanske är så på vissa områden att dessa är så att säga inmutade av proprietära leverantörer, till exempel kontorssidan.”

    Det påpekas av informanterna att filformaten bör standardiseras och med det klarar man av informationsutbytet långt i de miljöer man har idag. Filformat är viktiga när det gäller öppna standarder enligt informant A och på arkivsidan finns det i lag standardiserat hur detta ska gå till. Informant E menar att:

    ”Det är väl som jag sa lite grann det där kanske lite invävt, men jag tror ju det att vi har inga stora trygga leverantörer framöver. Utan jag tror att vi alltmer framöver måste förlita oss på standards så att vi får kontinuitet i vår datalagring och vårt sätt att utbyta information. Jag ser framför mig då att vi kommer ha stora generella databaser där vi lagrar information som på nått sätt ska vara analyserbar och kunna långtidslagras över tiden. Lagra det i format som är standards. ”

    Gränssnitten anses också behöva standardiseras och standarder när det gäller mallbibliotek och kataloger anses också vara något som är angeläget. Informant A säger så här:

    ”… Sen är det även så att de leverantörer som, för det finns några exempel på leverantörer som har väldigt hårda kopplingar där det inte bara handlar om några enstaka utdata, utan där man bygger liksom hela mallbibliotek och alla dokument i filsystemet då va… Man skulle från applikations­sidan kunna ha byggt den kring, ha sagt så här att vi stödjer ldap då va som så att säga katalog standard då. Då skulle man kunna ha jobbat mot både ad och exempelvis novell eller open ldap eller någon annan öppen katalogtjänst”

    5.3. Varför behöver det standardiseras?

    För att komma bort från den inlåsning som informanterna menar att kommunerna har mot de flesta leverantörer av verksamhetssystemen, så behöver standards utvecklas för den kommunala marknaden. Leverantörer med större låsningar, exempelvis när vi talar om kata­logstrukturer, är svårare att öppna då man skulle bli tvungen att bygga om hela infrastrukturen menar informant A. Katalogstrukturer har en betydelse för vilken hårdvara man kan eller inte kan använda sig av beroenden på leverantörens slutenhet. Ska ett program få bestämma vilken underliggande struktur man ska ha? Informanten menar med detta att vissa proprietära pro­gram har en så hård koppling till vissa hårdvaror. Något som också upplevs problematiskt är att alla leverantörer, menar informant C, inte är medvetna om vilka format som är certifierade eller inte. Ledningarna hos leverantörerna måste bestämma sig för vilken standard som de ska följa i sina system och program när de utvecklar. Leverantörernas problem med att använda önskad standard, kan bero på kommunernas brist på beställarkompetens, menar informant C. Kommunerna klarar inte av att vara tydliga nog med att utforma kravspecifikationer för vad som krävs eller hur kommunerna vill ha systemet. Han menar även att det finns en snedvriden konkurrenssituation på marknaden:

    ”Problemet är väl att det finns alltid ett sorts oligopol eller liknande. Det är ett antal olika leverantörer räknade på ena handen fingrar oftast som dominerar markanden. Det finns ju en outtalad kartellbildning dem emellan de har ju även delat upp marknaden, segmenterat den geografiskt i vissa fall då. Och det är ju ingen bra situation ju för någon. Det måste om vi ska få rimliga prisbilder och rimliga möjligheter att påverka så måste ju den strukturen raseras.”

    Han pratar också om ett maktspel som pågår mellan kommuner och deras leverantörer där han menar att det är kommunerna som gemensamt måste ställa krav för att åstadkomma en förändring:

    ”Ja det är ju liksom alltid ett maktspel naturligtvis och så länge man kan ta ut dom pengar man gör idag för verksamhetssystem så kommer man ju fortsätta. Varför ska man förstöra ett befintligt buisnesscase? Det kommer naturligtvis inte leverantörerna att göra, om de inte har något som trycker på dem att göra det. Och sambruk driver ju ett annat projekt för att titta på skolans administrativa system för att försöka få dem att öppna sig och det är andra gången i ordningen som det projektet försöker drivas, har precis startat upp. Vi får se vad det kan åstadkomma.”

    Ett problem som informant D ser är att inte komma åt källkoden i den bemärkelsen att det blir dyrt på grund av att det finns få leverantörer av verksamhetssystem på den öppna markanden och att i dagens system sätts logiken och funktionaliteten av leverantören och inte av beställa­ren – kommunen. Inlåsningsproblem som kommunerna presenterar består ofta i synen på exempelvis programvaror på kontorssidan där RTF-format (Rich text format) anses som en inlåsningsfaktor, men det menar både informant A och E är en chimär då detta relativt enkelt borde kunna lösas. Informant E menar att man även är rädd för att ta steget att ha två system. Han förklarar att man behåller ett slutet format för de system som har hårda kopplingar men att man sedan i kommunen beslutar att för övriga handlingar så använder man brevmallar, dokument som ska långtidslagras, diarieförda dokument och liknande i ett öppet format. Detta påstående stöds av informant C som påtalar att 80 % av kommunens mallar är inte knutna till något slutet system.

    5.4. Hur ska det standardiseras och av vem?

    När frågan om hur man ska gå tillväga för att sätta standarder och öppna standarder så pratar informanterna, A och D om olika grupperingar kring bildandet av standarder och nämner standardiseringsorgan som de anser bör ha definitionsrätten. Informant A säger: ”Sen tenderar det väl till att vara så att så att säga att det som definierar det är ju olika grupperingar som definierar standards.” Något som informant C påpekar som viktigt är att många måste kunna få vara med och bestämma när det gäller öppna standarder och att den är tillgänglig för alla menar informant D. Det som flera informanter påtalar är att utvecklingen av standarders är en dynamisk process som sker över tid. Certifierade standarder typ ISO och exempelvis det öppna dokumentformatet pdf, anses mer stabilt och säkert då dessa certifierade organ står för hållbarhet och kontinuitet. Utvecklingsprocessen blir dock trögare och tar längre tid.

    Kommuner måste tillsammans, enligt informant A, gå ihop och underifrån utveckla standarder som passar för just deras verksamheter. Då ökar också inflytandet för kommuner gentemot leverantörerna, vilket inte har lyckats ännu enligt informant E. Genom att kommu­nerna påverkar lokala och mindre leverantörer av system mot att utveckla mot öppna standarder istället för mot låsta plattformar ökar man trycket för öppenhet. Informant A menar också att kommunerna är dåliga på att engagera sig i utvecklingen av standarder och säger så här:

    ”… Jag tror att man måste ha ett lite längre perspektiv på det här va, därför att, man kan säga att vi har ju, eller rätt ofta har vi tagit den rollen att vara den som sitter och väntar på nästa release. Och då är vi väldigt passiva då och vi säger att det är en bra release och en bra produkt då va å så använder vi det då va men. Det andra förhållningssättet, vi pratar ju nu om standards och så va, kräver ju ett mer engagemang å så för det finns ingen, som jag förstår det här med att ta fram standarder är ju en grupp aktiva individer som gör det. Så det kräver, även om det kanske inte, det kanske inte kanske inte är så i realiteten idag att vi är så jätteengagerade i sånt arbetet, men hela arbetsmetoden är ju den att det byggs lite underifrån då med det här med standardiseringsgrupper och att hela tanken att ta fram mjukvaran är mer baserad på en större grupp människor som deltar i processen. Jag tycker det är en skillnad man märker här att här finns det kanske då en form av större inflytande, eller chans till ett större inflytande om man skulle vilja det. Men jag tror inte att jag har sett en bok så att säga, det vore kul om ni nånstans har sett det, att så att säga att ja här finns det någon som har så att säga.”

    Kommunen som representeras av informant C redovisar dock ett projekt där de tillsammans med en annan kommun lyckades standardisera bort ett gemensamt problem vid utbyte av information, i form av filformat, som alla i slutändan tjänade på i ett vinnar-vinnar koncept.

    ”Jag satt här som projektledare för 5 år sen, kanske 10 nu…,för ett gemensamt gymnasieintagningssystem i xxx län. Och en kollega till mig satt som i samma roll som mig i xxx för xxx län. Vi skulle skapa en gemensam gymnasieintagning och bägge två upphandlade system och fick varsitt system. Det finns två stora leverantörer, det börjar komma in fler men då var det bara två på skolmarknaden… Vi konstaterade att de här leverantörerna inte kunde prata med varandra och det var ju ett gyllene läge att göra något… vi har ett gemensamt problem här, hur löser vi det? Där var vi ju i ett gyllene läge, för dom skulle ju utbyta information bägge två fast åt olika håll. Det blev en värdigt kreativ diskussion så vi kom ju fram till en standard… Så det var et konkret exempel på ett sätt där man når framgång i det, men det var ju just att det var en gemensam problembild.”

    De dialoger som förs i Sambruk borde enligt informant A dokumenteras för att ge kommuner legitimitet tillika auktoritet. Vid upphandlingar kan man då även ta stöd av arkivlagen när man vill påverka leverantörer mot en standardiserad öppenhet. Ett kommunkollektiv skulle då generera för­delen att man får det man vill ha i systemen, och inte det man erbjuds enligt informant D. Ett problem är att applikationsutvecklarna försöker att standardisera sig själva utifrån en kommersiell produkt som redan finns på markanden. Det ger en snabbare utveckling och till­gång till en säker marknad påpekar informant A. Inom affärsapplikationer är kulturen fort­farande sådan att det är den proprietära sidan som har systemen med funktionaliteten som krävs, kanske beroende på att det finns för lite konkurrens än så länge från leverantörer av öppen källkod. Fanns en öppenhet skulle man kunna få in konkurrensutsättningen på marknaden för programvaror vilket inte finns idag säger informant D. Ett problem som informant C ser är den alltför omfattande förfrågan kommuner gör vid en upphandling. Mindre leverantörer av främst öppen källkod har helt enkelt inte resurser att satsa för att besvara denna då de inte kan räkna med att ”ro i land” upphandlingen, vilket gör det svårt att ta sig in på den kommunala marknaden.

    I Norge och Danmark har öppna program fått genomslagskraft i den politiska sfären vilket informanterna D och E menar behövs för kommunerna i Sverige. Ett direktiv uppifrån med centralt styrda riktlinjer och en förankring inom någon kommunal intresseorganisation eller som informant E uttrycker det: : ”En mer rikslikare för hur det ska gå till.” Informant A påtalar även hur svårt det är att försöka få in denna fråga om öppenhet upp i den egna kommun­styrelsen och även in på den lokala politiska agendan då detta område är både omfattande och komplext. Han menar också att kommuners behov är relativt likartade då det gäller programvarulösningar. Han svarar så här på frågan om kommuners behov är väldigt likartade:

    ”Ja i princip tror jag att det är så va. Vi kan ju titta på den minsta kommunen då som kanske har en 5-6000 invånare över xxx som har över 35 000 invånare och vidare till Göteborg som har över 450 000 invånare, vi kör samma skoladministrativa system. Programvarulösningarna ser ju faktiskt likadana ut. Oavsett hur stor kommunen är. Det skulle på nått sätt leda i bevis att det är lika, sen organisatoriskt och storleksmässigt så ser vi olika ut. Men i princip är det väldigt mycket som är samma.”

    Han ser dock svårigheter då kommunerna dels är självstyrande och att den organisatoriska uppbyggnaden och storleken skiljer sig åt. Men då kommuner är öppna så finns det också en möjlighet i detta, menar han, då de kan dela med sig av sina kunskaper och erfarenheter:

    ”… Det är svårt också för kommuner att, vi ser lite olika ut också. Det finns en svårighet för oss alltså att, och dessutom är vi självständiga. Till konstruktionen är vi ju självstyrande vilket gör att kommunförbund till exempelvis har väldigt svårt att tala för oss. De kan vara med att påverka och så va, men att bara vara talesmän är jättesvårt då va. Så det ligger alltså visa svårigheter i detta men det finns också möjligheter i det för vi är så öppna, vi är så liksom, det är lätt att dela med sig av kunskaper och erfarenheter mellan kommuner då va. Jag tror inte alls att den öppenheten finns kanske på den privata sidan där man kanske är konkurrenter. Så det ger oss en styrka i det här att vi kan dela information och erfarenheter väldigt lätt.”

    Också informant C är inne på att kommunernas behov är snarlika varandra:

    ”… Idag så har man ju många gånger snarlika sätt att göra saker och ting på men det är ju uppfunnet av de lokala, av de egna kommunerna och det kan skilja sig lite åt i handläggning från det ena stället till det andra… Det är liksom stora kommuner har givetvis andra behov än vad små kommuner har. Men de allra största kommunerna är oftast delats in i stadsdelsnämnder eller likna de och då så kommer man ju ner i att hantera storlekar i alla fall. Men det är klart att en kommun som, vad ska vi ta, Malmö stad jämfört med Bjurholm det är klart att det är stora skillnader på hur de hanterar det men å andra sidan är det Bjurholm väldigt tätt förknippat med Umeå så att. De gör saker och ting tillsammans. Men storleken avgör till viss del men myndighetsutövningen är ju densamma som ska göra på ett, av alla kommuner ändå.”

    5.5. Vart är det på väg?

    Enligt informant A och E så ser framtidsutsikterna positiva ut för mera öppna standarder, då leverantörerna har förstått att hänga på trenden för att vara kvar på banan. Ett område som utmärker sig då informanterna pratar om en utveckling mot öppna program och öppna standarder är e-tjänsterna. E-tjänsternas plattform bör följa ÖTP (Öppen teknisk plattform) som är en standardiserad upphandlings- och kravspecifikation sammanställd av Sambruk. Problemet är att kommunernas uppgift anses vara att sköta verksamheten, därför måste det köpas in e-tjänster som uppfyller ÖTP kraven. Det kommer då att behövas adaptrar (program­fixar) för att anpassa integrationen och informationsutbytet till de underliggande verksamhets­systemen så att informationen i form av olika dataformat kan konverteras för vidare behand­ling och lagring. Adaptrar blir nödvändiga för informationsutbyten mellan systemen då det inte anses gå byta ut den miljö som kommunerna befinner sig i idag ur både ekonomisk och andra resursmässigt krävande aspekter. Något mer konkret menar informant C att Sambruk borde äga källkod och förvalta och förädla den via communitys men beställarkompetensen måste ändå utbildas eller finnas inom kommunen. Sambruk borde kunna vara ett stöd här menar han. Förvaltningen av standarder med förädling och utveckling, menar informant C, är en minst lika viktig fråga. Informant D håller med informant C men menar att problemet ligger i att man inte kan tvinga kommuner att vara medlemmar i Sambruk, något denna informant ser som en nödvändighet i så fall. Trenden, menar flera av informanterna, går nu mot att nya affärsmodeller utvecklas när leverantörer kan tänka sig att tillgodose kommunernas krav på öppna standarder. Detta bör ske i en dialog med leverantören och inte under hot. Flera av respondenterna påvisar också en kritisk hållning till Sambruk. Informant C säger så här om Sambruks inställning till lösning på problematiken med standarder och öppna program:

    ”… Och här då tycker jag att Sambruk skulle kunna bli en större kraft, för skulle samla Sambruk och vi tar en annan dimensions så är ju är ju alla kommuner leverantörer, man har ju leverantörer inne på många ställen. Men Sambruk vill ju på något sätt låta markanden sköta det här och jag tror inte att markanden gör det på ett vettigt sätt…”

    Informanterna A och C talar om en möjlig framtida utveckling mot ett informationsnav, där informationen via en adapter kan kommunicera med underliggande applikationer. ÖTP ses dels som en teknisk arkitektur och dels som en kompetenshöjning för landets IT-enheter, enligt informant C. Han menar att det är SOA arkitekturen (service oriented architechture) som beskrivs och hur systemkrav och gränssnittsytor ska se ut för att passa i en tjänstebaserad arkitektur, som anses vara framtiden. Informant C hänvisar också till landstingens sätt att hantera problematiken: ”Landstingens början till tänk när det gäller arkitekturuppbyggnad och standardiseringen av en gemensam nomenklatur borde kommuner se på.” Informant D menar att man även borde kunna standardisera det han kallar affärslogik, det informant C kallar processflöden, inom ex SKL för att kostnadseffektivisera IT-stödet. Det skulle vara bra med en nomenklaturensning, en enad nomenklatur för kommunernas IT. Först då blir det möjligt att få till affärslogiska lösningar. Kommunen som informant C företräder har gjort en djuputredning inom GIS området där de har informationsmodulerat den data som avses att behandlas i ett GIS system genom att kartlägga processflödena och schematiskt byggt upp det liknande en relationsdatabas. Denna utredning kan, menar han, ligga till grund för deras SOA arkitektur som då även skulle kunna anpassa för andra områden utanför GIS området:

    ” Vi har idag vad vi kallar metakatalogen som är, som utbyter personbunden information då. Och där har vi fått till logik och alltihopa så att vi kan logga in med e-id, bank-id eller motsvarande mot tjänster i vår kommun då va. Och alla våra medarbetare kan logga in, och där har vi löst mycket av den arkitekturen som behövs kring individer och individers åtkomst så att säga.”

    Det som informanterna C och E är överens om är den kompetens som saknas inom kommunerna när det gäller att förstå och kunna bygga arkitekturen utifrån ett öppet tänk – med SOA. Utvecklingen och trenden mot öppna program har bara börjat diskuterats inom de kommunala verksamheterna. Det redovisas dock att i två av informantkommunerna, A och C, har det tagits beslut i respektive kommunstyrelse för att använda öppna dokumentformat och att man ska verka för att upphandla öppen källkod där så är möjligt.

    Informant A:

    ”… Och man kan väl säga att det här intresset, nu har ju vi fått ta ett antal beslut i kommunstyrelsen då runt öppna standarders exempelvis då. Nu säger vi ju, nu för tiden säger vi att vi ska jobba mot öppna standarders och vi slår fast att öppna dokumentformat har vi skrivit in i kommunstyrelsens beslut då va. Så där kan man ju säga att där finns det ju en politisk support idag…”

    5.6. Attityden till öppna program och öppen standard

    Oavsett vad man väljer är man alltid inlåst, enligt informant D, då man fortlöpande gör aktiva val av öppna eller slutna programvaror till sin miljö. Informant A säger att flera inom kommunen anser att programvaror med de facto standard inom den proprietära sidan anses bättre än en öppen standard men det är enligt honom ett kortsiktigt tänk. Kommuner har länge varit passiva och bara väntat ut en befintlig leverantörs nästa release, de byter inte ut något som fungerar och ställer inte heller krav på leverantörerna. Informant E menar att man måste tänka långsiktigt när man ska inhandla nya system med tanke på vad för sorts information som ska utbytas och hur detta ska kommuniceras.

    Internet baseras på öppna program och har utvecklats över en lång tid och det är i den öppna miljön som öppna program passar bäst anser informant A. Här finns många etablerade aktörer i communitys som förvaltar och driver på de öppna standarderna av typ XML, tcp/ip etc och det är ett arbete som informant menar: ” bara rullar på.” Det är även en fråga om kulturen inom organisationen när det gäller öppna program och öppna standarder. Han tror det ökar när fler inser dess fördelar. Gemensamt för alla informanter är att de anser att öppna standarder är viktigare än öppen källkod.

    Informant A:

    ”…nja jag vet inte riktig om man verkligen kan säga det va. Jag tror inte att det är så enkelt även om det är så med öppen källkod per definition att man jobbar med öppna standarders. Men det utesluter ju inte att även en proprietär leverantör kan ansluta sig till en öppen standard.”

    Informant D:

    ”…däremot så kanske det är vanligare att öppna programvaror anammar öppna standarder än att proprietära gör det. Men det är nog inget som kopplar ihop dom så det egentligen. Och det blir säkert vanligare och vanligare att även proprietära system anammar öppna standarder.”

    Informant E:

    ”…nää utan öppna standarder det är en sak men visst sen beaktar man sen då öppna programvaror och sånt men man kan så då att det finns ju en koppling så länge som vi håller oss till Office”.

    Egentligen spelar det ingen roll för kommuner om det är öppet eller proprietärt, om de får leverantörer att bygga så kallade black boxes (moln enligt informant C) som sköter informations­utbytena, bara det fungerar. Det behöver således inte vara öppen källkod, bara öppna standarder som dessa program förmedlas med. Det som också påpekas unisont är vikten av support från leverantören av en applikation eller ett system. Informant A menar att kommunerna inte anser att de ska bygga och eller förvalta egna system då de ser framtida förvaltningsproblem etc. utan de vill kunna få applikationer levererade med tillhörande support. Kommuner är duktiga på verksamheter menar han, men inte på programmering. ”Man får allt serverat men man får då betala.” Det skulle underlätta om Sverige fick ett mindre antal kommuner och fler regioner som samarbetande, tror informant D. Man kan inte gå och vänta på detta, det måste ju fungera idag och imorgon. Microsoft helhetslöser det idag. A och C anser också att öppen källkods applikationer driver på utvecklingen och bygger på öppna standarder. En fördel för öppen källkodsideologin enligt informant C är att det bygger på öppet tänk, inga inlåsningar och utveckling utifrån öppna standarder. Men enligt informant D så kan man inte vänta på att utvecklingen mot öppna standarder ska ta fart. Han menar att:

    ”I vårt användande av informationsteknik hos oss, jag kan inte vänta på att en rörelse kanske kommer att etablera öppna standards och så vidare utan min verksamhet måste ju ha ett IT-stöd i morgon och en fungerande informationsarkitektur imorgon.”

    6. Analys och diskussion

    I detta avsnitt knyts det empiriska materialet ihop med den teoretiska referensramen och kapitlet om kommuners verksamhetsutveckling med öppna program.

    6.1. Problem för kommuner vid en standardisering

    Vad är egentligen en standard för en kommun, vad är deras definition på en standard? För att utreda detta måste det först börjas med att förklara svårigheterna som kommuner ställs inför vid en standardisering. Som framgår av det empiriska materialet, är en enhetlig definition på vad en standard eller en öppen standard egentligen innebär svår att sätta. De som tillfrågats menar att begreppet betyder olika för olika intressenter, något som också Krechmer (2005) påpekar, när det gäller öppna standarder, att det finns tre olika intressegrupper som alla vill komma till tals när en standard ska sättas. Kommunerna är ju, vilket påpekas i empirin, enligt lag självstyrande och har alltså själva beslutanderätten över vilka standarder och leverantörer av allehanda program­varor som ska tillämpas. Men skiljer sig olika kommuners behov åt, när det gäller verksamhetssystem och IT-arkitektur, så mycket att det inte finns en enhetlig väg för hur man ska gå tillväga och vilka standarder som kan komma ifråga? Det som framkommit i empirin pekar åt båda hållen egentligen. Det skiljer storleksmässigt och organisatoriskt mellan kommuner, men de uppgifter som kommunerna är satta att sköta ser likvärdiga ut, oavsett dessa skillnader. Så en gemensam lösning borde gå att få till, anser vi, en lösning som passar alla kommuner när det gäller standarder, om kommunernas behov verkligen är lika.

    En väg mot denna lösning kan vara att sätta en gemensam standard för nomenklaturen i alla kommuner. Idag kan det, enligt de intervjuade, skilja sig mellan kommuner när det gäller ett begrepps innebörd, något som ställer till problem när information ska utbytas mellan kommuner och de system de har. Och det tycker vi är en rimlig utveckling. Om alla inblandade har samma nomenklatur, behöver inga missförstånd eller problem uppstå av den anledningen. Det påpekas att landstingen har kommit mycket längre i sin standardiseringsprocess, och det som nämns i detta samband är en nomenklaturensning, det vill säga att man enas om vad ett begrepp egentligen innebär. Om en kommun betecknar ”fastighet” på ett sätt, och en annan kommun på något annat sätt, kan det naturligtvis uppstå svårigheter när olika system ska integreras. Om denna standardisering av nomenklaturen genomfördes, skulle mycket vara vunnet anser både vi och en av informanterna. Då spelar det ingen roll att olika kommuner hanterar samma ärende inom olika förvaltningar, begreppet ”fastighet” betyder ändå samma sak. Det vore då lättare att standardisera även kommunikationen mellan system och applikationer anser vi.

    En möjlig väg som vi och några av informanterna ser, inte bara gällande nomenklaturen utan även ett samarbete vid framtagande av rekommendationer med mera, är att kommunerna går samman. Exempelvis i Sambruk eller någon annan kommunsammanslutning och ställer gemensamma krav på leverantörerna av främst verksamhetssystemen. Visserligen påpekar en av informanterna att det skulle innebära ett tvångsmedlemskap i denna intresseorganisation, att alla kommuner måste vara med, vilket man inte kan kräva, med hänsyn tagit till kommunallagen och självstyret. Det resonemanget anser vi inte håller. Vågar några kommuner ta steget och gå före och visa att det faktiskt går att påverka leverantörerna, då kanske även de som valt att stå utanför inser fördelarna och väljer att gå med. Det finns exempel, där man i dialog med leverantörerna och med ett samarbete mellan kommuner faktiskt har lyckats att komma till en överenskommelse som gynnat alla i slutändan. För att detta ska vara möjligt, anser vi, så behövs ett ökat samarbete mellan kommunerna, något som idag existerar i alldeles för liten utsträckning. Att, som några av respondenterna påpekar, tro att en liten kommun själv ska kunna påverka sina leverantörer av system och applikationer är en utopi, vilket också vi håller med om. Men om flera kommuner kan enas om vilken eller vilka standarder som ska gälla, så anser vi att detta kommer att generera större möjligheter att påverka leverantörerna att utveckla mot dessa standarder.

    Vi anser, att på grund av de svårigheter som kommunerna har att enas kring gemensamma standarder och det faktum att marknaden för kommunala verksamhetssystem är relativt liten, har lett till en oligopolliknande situation. De kommersiella leverantörerna har idag stor makt att själva avgöra vad kommunerna behöver, och vilka funktioner och möjligheter som ska erbjudas i de system de levererar. I empirin redogörs för kommuners passivitet vilket vi även menar är en av svårigheterna med att komma vidare mot öppenhet, kommunerna måste gemensamt definiera vilka standarder som kommunerna vill ha för att kunna påverka sina leverantörer. En standard för vilka standarder som ska gälla. Alla informanterna redovisar ett beroende av sina leverantörer i form av att få support och stöd i det operativa arbetet. Vilket vi anser tyder på att det maktförhållande som råder mellan kommun och leverantör är svårt att påverka utan en gemensam hållning.

    Statskontoret har för de statliga myndigheterna utvecklat en policy när system ska upphandlas. Policyn förespråkar öppna programvaror och öppna standarder i den mån det är möjligt. Standardiseringsutredningen tar även stöd i Lagen om offentlig upphandling när de utformar upphandling och ramavtal för den statliga offentliga sektorn. Visserligen kan kommuner välja att följa denna policy, men den anses inte vara fullt kompatibel med de krav som kommunerna har. I en finsk studie (Laine, Oksanen, Välimäki, 2005) där svårigheter med att inför öppna program i finska kommuner redovisas, påvisas nödvändigheten av erfarenhetsutbyte när en så stor organisationsförändring ska till vilket endast kan utvecklas i en form av någon sammanslutning där kommuner samarbetar. Detta anses även av flera av informanterna som en förutsättning för att lyckas i standardiseringsutvecklingen. Standarder måste även förvaltas och förädlas kontinuerligt vilket bara ett erkänt standardiseringsorgan anses klara av om standarden ska kunna få status av hållbarhet och kontinuitet. Detta framgår ganska tydligt i det empiriska materialet där informanterna påpekar att kommuner inte ska utveckla eller förvalta, utan ägna sig åt det de kan bäst, nämligen verksamhet.

    Att man pratar om olika saker när man pratar standard eller att det finns en avsaknad av styrning och samarbete är inte de enda problemen som kommunerna tycks brottas med. Ett stort problem, eller en orsak, beroende vilken ståndpunkt man har, är att kommuner är så beroende av företrädesvis Microsoft och deras produkter. Vissa tycks uppleva detta som ett problem, medan andra istället ser det som ganska bekvämt, att det går att luta sig mot en stor och stark leverantör av främst kontorsapplikationer. Detta faktum ses även av några av de tillfrågade som det största problemet för en utveckling mot mer öppenhet. Låsningen till en eller ett fåtal stora leverantörer, med sina de facto standarder gör det svårt för mindre utvecklare eller utvecklare av öppna standarder, att vara med och konkurrera på den kommunala marknaden. Visserligen menar en informant att vissa av problemen, till exempel RTF-formatet, egentligen inte är något problem utan kan ganska enkelt lösas. Andra saker är dock svårare att lösa, särskilt när det handlar om så kallade hårda kopplingar mellan system, det vill säga att vissa applikationer kräver att man kör mot till exempel en Microsoft-plattform. Hur detta ska lösas vet varken vi eller de tillfrågade, men kanske är öppen källkod och öppna program svaret på detta?

    De varierande definitionerna på en standard som framkommer i empirin behöver inte betyda att man pratar olika språk enlig oss. Istället kan det handla om att det fokuseras på olika inriktningar inom de olika kommunerna. När en informant exempelvis pratar om att en proprietär standard är säkrare och bättre än en öppen standard, skulle det kunna betyda att denna har ett mer kortsiktigt tänk än den som säger att det vore bra om en öppen standard blev en de facto standard. Den senare ser till morgondagens drift, medan den förra kanske ser fördelar på lite längre sikt. Ett liknande fall kan vara de rekommendationer från intresseorganisationer som en informant påtalade som viktiga, och där en annan nämnde en nomenklaturstandard som även borde tas fram av en gemensam organisation. Är det ett sätt att säga samma sak, fast på två helt olika sätt? Vi anser det och det visar med all önskvärd tydlighet, de problem man har med definitionerna kring gemensamma begrepp ute i de undersökta kommunerna.

    6.2. Definitioner av standarder och öppna standarder

    Det som med all tydlighet framkommit i intervjuerna, och som redan nämnts ett antal gånger men som inte nog kan poängteras, är att en standard kan betyda olika saker för olika personer beroende på vilken infallsvinkel de har, vilket benämns som en gråzon av Shah, Kesan (2007). Det var ingen av informanterna som gav en klockren beskrivning av begreppet standard, eller öppen standard. Kommunerna är dock ense om att en standard definieras enklast som en överenskommelse mellan två eller flera parter, hur exempelvis ett informationsutbyte mellan kommuner ska gå till. Detta stämmer väl överens med det som framkommit i teoriavsnittet. Ser man till kommunernas definition av en öppen standard, generellt sett, så skiljer sig denna något från vad som framkommit i teoriavsnittet. Kommunerna anser att en öppen standard bör vara certifierad av ett erkänt standar-diseringsorgan för att få den legitimitet som behövs. En klar distinktion görs även mellan en de facto standard och en standard som antagits av ett standardiseringsorgan. Den sistnämnda anses ha större bärighet än den förra, vilket även styrks av Hemphills studie (2005), vilket kan ses som något motsägelsefullt. Om en standard antagen av till exempel ISO, ses mer legitim och mer som en ”riktig” standard, varför har man då det stora beroendet av en de facto standard, som en informant menar att Microsofts doc-format är? Borde man då inte frångå denna standard och istället införa något format som är accepterat av något standar-diseringsorgan? Att en standard är certifierad av ett standardiseringsorgan är även viktigt när det gäller öppna standarder. EU har fastslagit följande kriterier för att definiera öppen standard; dels ska standarden utformas av ett standardiseringsorgan som är icke-vinstdrivande, dels ska den vara tillgänglig och fri för alla och helt gratis eller mot en liten avgift. En öppen standard kan heller aldrig bli någons immateriella rättighet, exempelvis patenteras utan måste förbli avgiftsfri. Detta framgår även i det empiriska materialet. Det tycks som att de tillfrågade informanterna beskriver öppna standarder precis som EU definierar den. Ingen av dem nämner egentligen öppen källkod eller öppna program i samband med detta.

    Beroende på den integrationsnivå som önskas i ett informationsutbyte mellan två system menar de att det kan vara allt från filformat, kommunikationsprotokoll, katalogstrukturer och andra gränssnittsytor som behöver standardiseras. Något som skulle kunna underlätta en standardisering inom många av de nämnda områdena är att kommunerna genomför en informationsmodulering eller en utredning av hur processflödena ser ut, enligt oss. En av våra informanter, vars IT-avdelning är uppdelad i en strategisk och en operativ del, har informationsmodulerat sina informationsflöden inom GIS-området. Förhoppningen är att detta arbete kan, använt på rätt sätt, skalas utanför GIS området och mycket väl vara grunden till den SOA arkitektur som han, liksom vi, anser nödvändig i framtiden. Informanterna talar även om standardisering av sina affärsprocesser vilket liknar den ovan nämnda processflödes­utredningen. SOA var något som flera av informanterna diskuterade. SOA sågs inte som en standardisering men man ansåg att om en standardisering kunde komma till stånd, på ett helt annat sätt än idag, skulle detta underlätta utvecklingen mot en tjänstebaserad arkitektur vilket även Franzén (2009) konstaterar i sin fallstudie.

    6.3. Vad, varför och hur öppna standarder?

    Det område som påtalas som det viktigaste området för att få till öppna standarder på är filformaten. Löser man detta så har man kommit långt menar några av informanterna. Det stämmer säkert. Mycket av problematiken ligger säkerligen i att det krävs konverteringar av olika slag för att kunna översätta från ett filformat till ett annat, så att flera olika program kan läsa samma data. Detta var ett problem som konstaterades i en egen tidigare utredning som utfördes gällande GIS-plattformar, att det kunde krävas en omfattande process för att få till denna konvertering. En standardisering med öppna format ses även som betydelsefullt när det gäller gränssnitt mellan system, även om detta inte är lika tydligt i de uttalanden som görs. Upphandlingspolicyn ÖTP (Öppen Teknisk Plattform) som utformats av Sambruk är en början för detta (Ohlsson 2007). Kan det vara så att kommunerna på något sätt har den insikten att det inte går att påverka detta? Att filformaten är lättare att få till en öppen standard på, än när det gäller gränssnittet, att man därför väljer att fokusera på det enklaste?

    De lösningar som presenterats för oss, när det gäller gräns­snitten, innebär i första hand alltså en användning av befintliga system och program. Adaptrar ska lösa integrationen menar man. Vem ska då utveckla dessa adaptrar? Ska den proprietära sidan göra det? Blir man inte med automatik kvar i den inlåsning som man på något sätt vill ta sig ur då? Att på detta sätt lösa integrationen och kommunikationen mellan program och system kan bara ses som en kortsiktig lösning, enligt oss. Kan man istället få till en gemensam nomenklatur, som alla kommuner kan följa och även kartlägga processflödena inom kommuner, så anser vi att en kombination av öppna standarder och en tjänstebaserad arkitektur är den mest intressanta vägen att gå, precis som många av informanterna också är inne på.

    Hur ska användningen av öppna standarder öka inom den kommunala sfären? Samarbete är A och O för att detta ska lyckas. Precis som någon av informanterna säger, kanske det måste till någon form av styrning uppifrån. Skulle inte SKL eller Sambruk kunna ta denna roll, på ett mer handgripligt sätt? Att det skulle innebära att man tvingar kommuner till ett medlemskap i denna organisation, anser vi vara en felaktig slutsats, som en av informanterna drog. Att se till att ta fram väl genomtänkta rekommendationer är inte att tvinga någon till ett medlemskap, utan att ge dem en valmöjlighet. Detta ställer dock stora krav på kommunerna, eller rättare sagt de som beslutar om IT-strategiska mål inom kommunerna, att inse fördelarna med en kommungemensam standard. Den standarden, anser vi, bör naturligtvis vara av en öppen karaktär för att kommunernas valmöjligheter av leverantörer inte ska begränsas mer än nödvändigt.

    6.4. Öppna standarder och kopplingen till öppna programvaror

    De undersökta kommunerna ser ingen direkt koppling mellan öppna standarder och öppna programvaror. Flera menar på att även den proprietära sidan av leverantörerna kan använda sig av öppen standard i sina program och sina system. Detta påstående är naturligtvis sant. Det finns inget som säger att, till exempelvis Microsoft, inte skulle få använda sig av öppna standarder. Vill de då göra det i någon större utsträckning? Är de beredda att släppa det de ser som sina stora inkomstkällor, standarden, eller källkoden i vissa fall? Vi tror inte att så är fallet. Inte så länge trycket mot dem är så pass lågt som det idag verkar vara. För att skapa detta tryck, så skulle en ökad användning av öppna program inom kommunerna kunna vara ett sätt, anser vi.

    Vi tycker oss kunna se att det faktiskt finns en ganska tydlig koppling mellan öppna standarder och öppen programvara. Ser man den kopplingen mellan öppna program och öppna standarder som vi gör, så kan man historiskt förklara det med den kultur och den ideologi som öppna program växt fram ur. Här förespråkas öppenhet och transparens genom hela livscykeln för programvaran. Utveckling från den första fria rörelsen mot mer kommersiellt tänk när det gäller öppna programvaror påvisar även öppenheten och stabilitet i form av de licenser som används för att säkra detta. Visst finns även problemet med att det finns allt för få utvecklare och leverantörer av specifika verksamhetssystem för kommuner idag. Men med nya affärsmodeller som stödjer en sådan utveckling, så kanske detta problem är borta inom några år. Får man till dessa affärsmodeller så att även små lokala företag vågar och kan ge sig in på denna marknad, så kommer den konkurrenssituation som då uppstår att påskynda utvecklingen av öppna program också inom denna sektor, det är vi helt övertygade om.

    För att leverantörer av öppna program ska få en chans att konkurrera på lika villkor med de proprie­tära leverantörerna på den kommunala marknaden, behövs väl utvecklade affärs-modeller. Affärsmodeller som ger de mindre leverantörerna en chans att skräddarsy lösningar med den funktionalitet som krävs av en kommun. De proprietära leverantörernas ”hyllprodukter” som kommunen idag köper, med i vissa fall onödig funktionalitet, borde i längden bli dyrare för kommunerna. Mindre leverantörer och en utveckling med öppna standarder, kan också inne­bära att en beställare, i detta fall en eller flera kommuner, kan dela upp utvecklingsarbetet på flera leverantörer. Detta skulle inte bara kunna innebära en mindre kostnad för kommunerna, utan också kunna vara ett sätt att stödja en regional tillväxt av små företag som utvecklar programvara med öppen källkod och öppna standarder.

    Ett problem som vi ser kvarstår, är hur kommunerna ska lösa sitt beroende av support och service av program och system, något som de säger sig vilja ha kvar i fortsättningen också. Kan de små leverantörerna av öppen programvara lösa detta med de affärsmodeller som finns idag, eller måste det till en utveckling på det området? Vi tror att så är fallet, att i framtiden kommer det att handla mer om kompetens och utbildning som genererar intäkter för leverantörerna.

    6.5. Bakomliggande faktorer

    När analysen av det empiriska och det teoretiska materialet utförts, så tycker vi oss ha sett några faktorer som återkommande utmärker sig som viktiga utgångspunkter mot ett fortsatt standardiseringsarbete för kommunerna och leverantörerna, mot öppna program och främst öppna standarder. Dessa faktorer har inte uttalats av informanterna på ett tydligt och precist sätt utan något som vi själva tolkat in då vi läst ”mellan raderna”. De tre intressantaste punkterna är:

    · Kommunerna borde gemensamt enas om vilka standarder för informationsutbyte som ska gälla. Detta för att unisont kunna påverka de påstådda maktfulla proprietära leverantörerna

    · En gemensam nomenklatur inom kommunal IT borde väsentligt öka chanserna för kommunerna att enas om öppna standarder

    · För att få till öppenhet och transparens i den kommunala IT-miljön så kanske en ny arkitektur med en mer tjänstebaserad utgångspunkt måste till. Detta för att, som informanterna menar, att ett informationsnav ska kunna integreras och bli en vettig lösning. Tanken är inte att byta ut systemen i dess helhet utan istället att organisera och modulera om den befintliga miljön, så att den bättre passar en tjänstebaserad struktur.

    7. Slutsatser

    Det som framkommit är att kommuner har svårt att definiera vad en standard och en öppen standard är. Den största orsaken till detta tycks vara att det inte finns någon manual eller rekommendation att följa. Det som först och främst efterfrågas är någon slags ”rikslikare”, framtagen av staten, eller av någon av de intresseorganisationer som företräder kommunerna. De definitioner som anges är alla riktiga, men kräver olika angreppssätt för att definiera. Att få en proprietär leverantör att släppa källkod till sitt unika system är säkert en mycket svårare nöt att knäcka, än att få samma leverantör att läsa in filformat vilka anses som en öppen standard. Kommunernas svårigheter med att definiera en öppen standard har även gjort det svårt att bedöma om öppna program stämmer överens med deras vaga definition av öppna standarder. Ståndpunkten att standarder bör utformas och certifieras av oberoende och erkända standardiseringsorgan är inte något som direkt kan hänföras till öppna programvaror. Däremot att tillgängligheten ska gälla för alla, stämmer väl överens med den ideologi som råder inom den öppna källkodsrörelsen.

    Det råder också delade meningar om vad som behöver standardiseras. Några menar att man kommer långt med att bara standardisera filformaten. Andra menar dock att en standardisering mer på djupet, till exempel en standardisering av gränssnitt mellan system, är minst lika viktig. Det som kan skönjas är att de som kommit längst i arbetet med öppna standarder och öppen programvara, är de som även anser att det är mer än bara filformaten man måste titta på. Hur ett informationsutbyte ska gå till är det som de anser vara mest intressant.

    Att öppna program per automatik skulle lösa standardiseringsproblematiken finns inga belägg för, vare sig i det som kommunerna säger, eller i litteraturen. Även de kommuner som idag till viss del använder öppen programvara, har problem med olika standarder. Det största problemet tycks vara Microsoft och den låsning som många av leverantörerna till kommunernas verksamhetssystem har. Därför har det bara varit möjligt för kommunerna att byta ut program som inte har denna hårda låsning. Detta talar för att det måste till ett nytt synsätt på öppna standarder. Istället för att börja på programsidan, kanske man istället skulle börja fundera på öppna lösningar i hela IT-arkitekturen. Någon form av processflödes­utredning måste till för att se hur systemen egentligen hänger samman. Får kommunerna till denna ”karta” så går det sen lättare att byta ut system och program från låsta format, till öppna.

    För att uppnå detta så ser vi att de tre punkter som vi tar upp i kapitel 6.5 Bakomliggande faktorer, är av stort intresse att titta närmare på för kommuner som vill komma framåt med standardisering och öppenhet.

    För att till slut besvara vår primära fråga i denna studie: Kommuner ser öppna standarder som något bra och som något som är värt att satsa på, då de tror att det skulle lösa en del av de problem de idag har, med inlåsningar med mera. De tror att det skulle bli billigare i viss mån, om man till exempel kunde byta ut Microsoft Office, mot en öppen lösning, typ OpenOffice. De anser dock inte att öppna program, med automatik, genererar öppna standarder. Den parallellen går ändå att dra, anser vi. Öppna program är det samma som öppna standarder, och genom att övergå till öppen programvara, övergår man också till öppna standarder, med automatik.

    8. Rekommendationer

    Vi anser att det vore en stor fördel för Sveriges kommuner att det gjordes en kommunspecifik utredning för öppna programs verkan och konsekvenser i kommuner. Kommuners behov, som vi ser det, skiljer sig från de statliga myndigheternas behov. Kommunerna borde, genom SKL, Sambruk eller någon annan sammanslutning för kommuner, även utforma riktlinjer efter de specifika behov som kommuner efterfrågar när det gäller system och program. I ett sådant samarbete så finns alla möjligheter att utveckla förståelse kring och kunskap om öppna program. I ett samarbete ges möjligheter att byta erfarenheter och i slutändan kanske både bygga, anpassa och förvalta kommunspecifika system.

    Affärsmodeller och informationsmoduleringar/processflödesbeskrivningar och hur dessa skulle kunna utformas och genomföras på bästa sätt, ser vi som intressanta fortsatta uppslag till forskning. Det skulle även behöva undersökas hur en informationsmodulering skulle kunna kopplas till öppna standarder och öppen programvara. En studie som jämför landstingets syn på arkitektur med kommunernas syn på arkitektur skulle även vara intressant, då landstinget tycks ha kommit längre i sin standardisering.

    9. Referenser

    Alvesson Mats, Sköldberg Kaj (2008) Tolkning och reflektion – vetenskapsfilosofi och kvalitativ metod. ” 2:a upplagan . Lund: Studentlitteratur.

    Backman, Jarl, (2008) Rapporter och uppsatser. 2:a upplagan. Lund: Studentlitteratur.

    Beekman, George, Quinn Michael J (2006) Computer confluence – tomorrows technology and you. 7 ed. Upper saddle river, New Jersey USA.

    Carlstedt, Irene, (2009) Startsida/Om SKL. [Elektronisk] Tillgänglig: <http://www.skl.se/artikel.asp?C=5605&A=11736> [2009-05-19]

    Coar Ken (2006). The Open Source Definition.[Elektronisk] Tillgänglig;

    <http://www.opensource.org/docs/osd> definitionen

    <http://www.opensource.org/board> styrelse o grundare [2009-03-27]

    Computer Sweden (2008) Open Source-ordlista. [Elektronisk]

    Tillgänglig;<http://cstjanster.idg.se/sprakwebben/ord.asp?ord=%F6ppen%20k%E4llkod> [2009-04-06]

    Cooper Danese, DiBona Chris, Stone Mark editorer (2005)”Open Source’s 2.0 – The continuing evolution. USA. O‘Reilley Media Inc.

    Dedrick, Jason, West, Joel (2003). Why firms adopt open source platforms:

    A grounded theory about innovation and standards adoption. [Elektronisk] Tillgänglig;

    < http://www.google.se/search?sourceid=navclient&ie=UTF-8&rlz=1T4ADBR_enSE217SE217&q=Why+firms+adopt+open+source+platforms%3a+A+grounded+theory+about+innovation+and+standards+adoption >

    [2009-04-16]

    Ekström, Daniel, 2004). Kommunikationsprotokoll inom ITS – en inventering av kommunikations­protokoll inom intelligenta transportsystem och tjänster. [Elektronisk] Tillgänglig: <http://publikationswebbutik.vv.se/upload/1058/2004_178_kommunikationsprotokoll_inom_ITS.pdf >[2009-05-15]

    Franzén, Jenny (2009) FACTORS TO SUCCEED WITH SOA - Shared Experiences from Five Organizations moving towards a Service-Oriented Architecture. Göteborg: IT University of Göteborg. [Elektronisk] Tillgänglig: <http://gupea.ub.gu.se/dspace/bitstream/2077/19330/1/gupea_2077_19330_1.pdf>

    [2009-05-15]

    Free Software Foundation (2007). The Free Software Definition. [Elektronisk] Tillgänglig: <http://www.gnu.org/philosophy/free-sw.html> [2009-02-18]

    Gosh, Rishab Aiyer, Glott, Ruediger, Schmitz, Patrice-Emmanuel, Boujraf, Abdelkrim (2008) OSOR Guidelines- Public procurement and Open source Software ver 1. [Elektronisk] Tillgänglig: <http://www.osor.eu/idabc-studies/OSS-procurement-guideline-public-draft-v1%201.pdf> [2009-04-06]

    Gunnarsson Ronny (2002) Validitet och reliabilitet. [Elektronisk] Tillgänglig: <http://www.infovoice.se/fou/bok/10000035.htm> [2009-12-15]

    Hanson Malin, Larsson Mikael (2009A) Öppen källkod och kommunal verksamhet –

    Attityder till öppen källkod. [Elektronisk] Trollhättan: Högskolan i Trollhättan. (Enskilt arbete i informatik, teori och forskningsmetodik, ITC501, 7,5 hp, 2008. Tillgänglig: <http://mickes-skola.blogspot.com/2009/03/kvantitativ-rapport-itc501.html> [2009-04.10]

    Hanson Malin, Larsson Mikael (2009B) Öppen källkod och kommunal verksamhet –

    En kvalitativ analys av inställningen till öppen källkod inom kommunal verksamhet. [Elektronisk] Trollhättan: Högskolan i Trollhättan. (Enskilt arbete i informatik, teori och forskningsmetodik, ITC501, 7,5 hp, 2008. Tillgänglig: <http://mickes-skola.blogspot.com/2009/03/rapport-itc501-kompletterad-version-2.html> [2009-04-10]

    Hanson Malin, Larsson Mikael (2009C) Öppen källkod och offentliga organisationer –

    Hur ser det ut idag och vart är man på väg? [Elektronisk] Trollhättan: Högskolan i Trollhättan. (Enskilt arbete i konsekvenser av IT för individ, organisation och samhälle, KIC 501, 7,5 hp, 2008. Tillgänglig: <http://mickes-skola.blogspot.com/2009/03/litteraturstudie-kic501.html >[2009-04-10]

    Hemphill Thomas A (2005). Government Technology Acqusition Policy: The case of proprietary versus ”open source” software. Bulletin of Science, Technology & Society, Vol. 25, No. 6, 484-490. [Elektronisk] Tillgänglig: <http://bst.sagepub.com/cgi/content/abstract/25/6/484> [2009-04-09]

    Holme Magne Idar & Solvang Krohn Bernt (1997) Forskningsmetodik – Om kvalitativa och kvantitativa metoder. 2:a upplagan. Lund: Studentlitteratur.

    IT-standardiriseringsutredningen (2007). Den osynliga infrastrukturen – om förbättrad samordning av offentlig IT-standardisering: Betänkande. Stockholm: IT-standardiserings­utredningen. (SOU 2007:47) [Elektronisk] Tillgänglig: <http://www.sll.se/Handlingar/Landstingsstyrelsen/2007/ls071204/Sam0763.pdf>

    [2009-04-15]

    Klang, Mathias (2008). Copyright – Copyleft, en guide om upphovsrätt och licenser på nätet ver 2.0. [Elektronisk] Tillgänglig: < http://www.iis.se/docs/Copyright-Copyleft_webb.pdf >

    [2009-04-07]

    KLUGE.DE (2007) How to gain marketshare. [Elektronisk] Tillgänglig: <http://www.kluge.de/2007/07/how-to-gain-market-share.html> [2009-04-11]

    Laine, Juha, Oksanen, Ville, Välimäki, Mikko (2005). An empirical look at the problems of open source adoption in Finnish municipalities. [Elektronisk] Tillgänglig:

    < http://portal.acm.org/citation.cfm?id=1089643 >[2009-05-18]

    Lanäs Lina, Lundkvist Mattias (2005) Supply Chain Management – Minskad osäkerhet med automatik? [Elektronisk] Tillgänglig: <http://epubl.ltu.se/1404-5508/2005/237/LTU-SHU-EX-05237-SE.pdf> [2009-04-11]

    Larsson, Göran (2008). sambruk/om sambruk. [Elektronisk] Tillgänglig:

    <http://www.sambruk.se/vanstermeny/omsambruk.4.76e8b1c6112f078db498000145312.html > [2009-05-19]

    McInerney, Paul-Brian (2007). Technology Movements and the Politics of Free/Open Source Software. Science, Technology & Human Values 2009; 34; 206. [Elektronisk] Tillgänglig: <http://sth.sagepub.com/cgi/reprint/34/2/206> Registrering krävs. [2009-02-16]

    Mathiassen, Lars, Munk-Madsen,Andreas, Nielsen, Peter Axel, Stage, Jan(2001) Obejktorienterad analys och design, andra upplagan. Lund: Studentlitteratur

    Microsoft (2009) Öppen källkod. [Elektronisk] Tillgänglig: <http://www.microsoft.com/sverige/government/general/opensource.mspx> [2009-05-04]

    Nationalencyklopedin (2009). Standard. [Elektronisk] Tillgänglig: <http://www.ne.se/sok/standard?type=NE> [2009-04-07]

    Nordqvist, Carl-Johan (2006) Processförbättring med SAP. Göteborg: Handelshögskolan i Göteborg. [Elektronisk] Tillgänglig: <http://gupea.ub.gu.se/dspace/bitstream/2077/3354/1/IA7400%20Carl-Johan%20Nordqvist.pdf> [2009-05-15]

    Odell Mats (2007) Svar på skriftlig fråga 2007/08:738. [Elektronisk] Tillgänglig: <http://www.riksdagen.se/webbnav/index.aspx?nid=71&dtyp=frs&rm=2007/08&dok_id=GV12738&nr=738> [2009-04-11]

    Ohlsson, Sven-Håkan (2007) Öppen teknisk plattform V.2.0, [Elektronisk] Sambruk, kommunala e-tjänster(projektledare Janne Dicander). Tillgänglig <http://www.sambruk.se/download/18.76e8b1c6112f078db498000178027/%C3%96ppen+Teknisk+Plattform+(%C3%96TP)+v2.0.pdf> [2009-05-15]

    Perens, Bruce (2009). Homepage/Political policy/Open Source/Free Software. [Elektronisk] Tillgänglig: <http://perens.com/policy/open-source/ >[2009-04-06]

    Rejås Marcus (2009) Fri programvara eller öppna standarder?[Elektronisk] Tillgänglig: <http://blog.rejas.se/2009/01/23/390/ >[2009-04-12]

    Serviam. (2008). Service Oriented Architecture & Web Services. [Elektronisk] Tillgänglig:

    <http://dsv.su.se/soa/arkitektur.shtml> [2009-05-07]

    Shah, Rajiv C & Kesan, Jay P (2007) Open standards and the role of politics ACM International Conference Proceeding Series; Vol. 228 pages 3-12. [Elektronisk] Tillgänglig: <http://portal.acm.org/citation.cfm?id=1248462> Registrering krävs [2009-02-24]

    SIS, Swedish Standards Institute (2008) Standarder får världen att fungera- verksamheten på SIS 2008. [Elektronisk] Tillgänglig: <http://sis.se/pdf/SIS_VB2008.pdf >[2009-04-09]

    Statskontoret (2004) Upphandlingspolicy för programvara avseende öppna standarder och öppen programvara a. [Elektronisk] Tillgänglig: <http://www.statskontoret.se/upload/2687/2004109.pdf >[2009-04-07]

    Statskontoret (2003) Öppen programvara. [Elektronisk] Tillgänglig: <http://www.statskontoret.se/Statskontoret/Templates/PublicationPage____917.aspx >

    [2009-03-02]

    Strömbergson & Görling (2009) Öppna standarder och dokumentformat inom statsförvaltningen. [Elektronisk] Tillgänglig: <http://www.gorling.se/dokumentformat>

    [2009-04-10]

    Svenska datatermsgruppen (sidansv. Svanberg, Peter) 2007 Svenska datatermgruppen/Ordlista/Sökordsregister/Gränssnitt. [Elektronisk] Tillgänglig: <http://www.nada.kth.se/dataterm/rek.html#a77> [2009-05-15]

    Tiemann, Michael (2006) Open Source Initiative- Open standards requirement for software. [Elektronisk] Tillgänglig:< http://www.opensource.org/osr> [2009-05-04]

    Ueda, Masahi (2005). Licenses of Open source Software and their Economic Values saint-w,pp.381-383, 2005 Symposium on Applications and the Internet Workshops (SAINT 2005 Workshops). [Elektronisk] Tillgänglig: <http://doi.ieeecomputersociety.org/10.1109/SAINTW.2005.79> Registering krävs

    [2009-03-26]

    Ueda, Masahi (2006). A Model of Open Source Software Style R&D on Business Software Engineering Advances, International Conference on Volume , Issue , Oct. 2006 Page(s):46 - 46). [Elektronisk] Tillgänglig: <http://ieeexplore.ieee.org/Xplore/login.jsp?url=http%3A%2F%2Fieeexplore.ieee.org%2Fiel5%2F4031778%2F4031779%2F04031831.pdf%3Ftp%3D%26isnumber%3D%26arnumber%3D4031831&authDecision=-203> Registrering krävs [2009-04-10]

    Von Hippel, Eric (2005). Democratizing innovation. The MIT Press, Cambridge, Massachusetts.

    Wallén Göran (1996). Vetenskapsteori och forskningsmetodik. Upplaga 2:13. Lund: Studentlitteratur.

    Wallenquist Anders (2008). ODF är nu svensk standard. [Elektronisk] Tillgänglig: <http://www.dfs.se/node/2385> [2009-04-11]

    Wheeler, David (2007). The Free-Libre / Open Source Software (FLOSS) License Slide. [Elektronisk] Tillgänglig: <http://www.dwheeler.com/essays/floss-license-slide.html>

    [2009-04-07]

    Wikipedia (2009) Öppen standard. [Elektronisk] Tillgänglig: <http://sv.wikipedia.org/wiki/%C3%96ppen_standard> [2009-04-11]

    Åsblom Joel (2009) Kommuner rasar mot Microsoftlåsning. [Elektronisk] Tillgänglig: <http://computersweden.idg.se/2.2683/1.214952/kommuner-rasar-mot-microsoftlasning> [2009-04-11]

    Öhrwall - Rönnbäck, Anna (2008) Bossanova Affärsmodeller för öppen programvara i offentlig sektor: Nya möjligheter för kunder och leverantörer. [Elektronisk] Tillgänglig: <http://www.iei.liu.se/forskning/forskningsprojekt/bossanova> [2009-05-19]

    Östling, Mats (2007). Fria och öppna program-Innovation, delning och öppenhet, erfarenheter från Programverket och omvärlden. Sveriges Kommuner och landsting. [Elektronisk] Tillgänglig; <http://projekt.ladokenheten.umu.se/main.php/Mats.pdf?fileitem=3965398> [2009-04-16]

    Östling Mats (2008) Kommuners och landstings användning av öppna

    Program. [Elektronisk] Tillgänglig: <http://www.skl.se/artikeldokument.asp?C=4474&A=56823&FileID=233903&NAME=Rapport%5Fkommuners%5Foch%5Flandstings%5Fanv%E4ndning+%5Fav%5F%F6ppna%5Fprogram.pdf> [2009-04-11]

    Bilaga 1. Intervjuplan testversion

    Denna intervjuplan ska fungera som ett hjälpmedel vid intervju av informanter från de utvalda kommunerna.

    Syfte: Att få svar på de frågeställningar som vi har i vår problemformulering.

    Mål med intervjun: Att få en förståelse för de utvalda kommunernas syn på standarder, öppna standarder och öppen programvara.

    Beräknad tid: ca 60-90 minuter.

    Plats: Intervjun kommer att ske via videokonferensverktyget Marratech och kommer att spelas in för att sedan transkriberas.


    Nedanstående frågor är en stödmall att följa, dock kan det tänka sig att flera följdfrågor ställs beroende på respondentens svar.

    Frågor:

    Presentation av tidigare studier som en inledning.

    Vad är er erfarenhet av öppen källkod inom kommunen?

    I tidigare studier framkom att det fanns svårigheter, tekniskt sett, med att införa nya program. Har ni upplevt sådana problem?

    Vad var/är dessa i så fall?

    Hur upplever ni det som ibland kallas för inlåsningsproblematik, det vill säga att ni kanske är väldigt beroende av en eller ett fåtal stora leverantörer som låser fast er till en plattform/miljö

    Långsiktigt perspektiv? Lösning med nya öppna applikationer? Arkitetekturuppbyggnad?

    Utredningar gjorda inom området av Statskontoret, SKL och VERVA bl.a., påtalar vikten av öppna standarder inom en kommunal miljö. Tidigare informanter skulle önska ett fram­tagande av en kommunal praxis för att definiera just vad som är en öppen standard.

    Hur ser du på saken? E-tjänster öppna format ett måste(ÖTP)?

    Vad är en öppen standard för Er när det gäller programvaror? Webbens öppna arkitektur.

    Koppling mellan öppna program och öppna standarder?

    Ideologin inom OSS förespråkar öppenhet etc. Kan det vara en fördel när nya program ska utvecklas? Utvecklingen i communitys sker under öppna former.

    Best practise och existerande teknologier kännetecknar OSS. Kan det uppmana till ut­vecklingen av öppna program med öppna standarder?

    Finns det något som de proprietära har som inte OSS har?

    Är samarbete framtidens melodi? Erfarenhetsutbyte? Nya tjänsteorienterade affärsmodeller?

    Bilaga 2. Intervjuplan

    Denna intervjuplan ska fungera som ett hjälpmedel vid intervju av informanter från de utvalda kommunerna.

    Syfte: Att få svar på de frågeställningar som vi har i vår problemformulering.

    Mål med intervjun: Att få en förståelse för de utvalda kommunernas syn på standarder, öppna standarder och öppen programvara.

    Beräknad tid: ca 60-90 minuter.

    Plats: Intervjun kommer att ske via videokonferensverktyget Marratech och kommer att spelas in för att sedan transkriberas.


    Nedanstående frågor är en stödmall att följa, dock kan det tänka sig att flera följdfrågor ställs beroende på respondentens svar, samt att vissa frågor tillkommer allt eftersom fler informanter intervjuas.

    Frågor:

    Presentation av tidigare studier som en inledning.

    Hur definierar du en standard?

    Hur definierar du en öppen standard?

    Vad anser du behöver standardiseras?

    · Filformat?

    · Gränssnitt?

    · Kommunikationsprotokoll?

    · Katalogstrukturer?

    · Annat som behöver standardiseras?

    Hur ska det standardiseras?

    · De facto?

    · De jure?

    Varför behöver det standardiseras?

    Vad är en öppen programvara för dig?

    Hur ser du på förhållandet mellan öppna standarder och öppen programvara?

    · Finns det en direkt koppling?

    Om ja, på vilket sätt?

    Om nej, varför inte då?

    Finns det andra aspekter som du anser är viktigt att diskutera när det gäller just standarder och främst då öppna standarder och öppna programvaror?

    Gör en sammanfattning av det som sagts för att kontrollera att vi har uppfattat informanten korrekt på i alla fall de absolut viktigaste punkterna.

    10. Kontaktuppgifter

    För den som vill kontakta oss för frågor eller för att få ta del av transkriberingar eller annat material, kontakta oss på:

    Malin Hanson: malin.hanson@hotmail.com

    Mikael Larsson: informatikermicke@comhem.se

    Eller ta kontakt med Högskolan väst:

    Högskolan Väst

    Institutionen för Ekonomi och IT

    461 86 Trollhättan

    Tel 0520-22 30 00 Fax  0520-22 30 99

    www.hv.se


    [1] Peter Dacke Adm.chef – BoU. Botkyrka, Sambruk, telefonkonferens den 20 april 2009

    [2] Mats Östling IT-strateg SKL, telefonkonferens den 31 mars 2009

    [3] Mats Östling IT-strateg SKL, telefonkonferens den 31 Mars 2009

    [4] Mats Östling IT-strateg SKL, telefonkonferens den 31 Mars 2009

    [5] www.marratech.hv.se

    [6] http://www.bibliotek.hv.se/extra/pod/?action=pod_show&id=1159&module_instance=1 (Behörighet för att använda dem behövs)

    [7] http://sv.openoffice.org/get

    [8] http://www.gimp.org

    [9] http://www.adobe.com/se/products/photoshop/photoshop

    [10] Peter Dacke Adm.chef – BoU. Botkyrka, Sambruk, telefonkonferens den 20 april 2009

    [11] Peter Dacke Adm.chef – BoU. Botkyrka, Sambruk, telefonkonferens den 20 april 2009

    //Micke Lidköping vid Vänern