Kræv Open Source i kommunens IT-systemer

Jeg foreslår at kommunen kræver at dens IT-systemer skal udvikles med Open Source. Eller endnu bedre, kræver at det skal være Fri Software. 

En rigtig god grund er sikkerheden: Man opdager brister i sikkerheden tidligere i open source end i lukket source - og i dag er sikkerhed meget vigtig…

For at forstå dette tekniske forslag, skal man sætte sig ind i nogle få begreber, de kommer her... 

• Open Source:
  Det er en måde at give adgang til sit software på, således at man kan læse kildekoden.
• Kildekode:
  Det er den tekst, der giver computeren instruktioner om, hvordan softwaren kører, opfører sig og ser ud, samt hvilken funktionalitet man kan finde i softwaren.
• Fri Software
  Det er en måde at give adgang til sit software på, således at man kan læse kildekoden, altså ligesom Open Source.
  Men det er tillige en måde at opfatte softwaren på:
  
  Fri software er modsat Open Source er fokuseret på friheder:

1. Friheden til at benytte programmet til ethvert formål.
2. Friheden til at lære, hvordan programmet virker og forandre det efter egne behov. Adgang til kildekoden (= Open Source) er en betingelse for dette 
3. Friheden til at redistribuere kopier, så du kan hjælpe din næste.
4. Friheden til at forbedre softwaren og udgive forbedringerne til offentligheden, så hele samfundet kan få gavn af det. Igen er adgang til kildekoden (= Open Source) en betingelse for dette.
   
   Denne måde at anskue software på vil give mest mening for det offentlige. Men Open Source vil med de rette betingelser opnå stort set det samme.

• Proprietær software:
  Det betyder at virksomheden, som udvikler softwaren, ejer det med henblik på at kunne sælge det til flere parter, ikke kun til den part der oprindelig bestilte opgaven.

Kan man lave ordentlige krav i sit udbud?

I dag når kommunerne skal lave udbud på software udviklingsopgaver, så bruger de som regel en skabelon, som digitaliseringsstyrelsen har lavet eller en lignende udgave.  I den kan kommunerne skrive alle sine krav og specifikationer til opgaven. 

Som regel så vil en udbudsopgave så gå til den virksomhed, som giver det bedste bud på, hvor lang tid de kan gøre det på og hvor få penge, det vil koste kommunen.

Det er da også fint at der er fokuseret på, at kommunen ikke skal spendere alverdens penge på de opgaver. Men kommunerne laver ofte store, komplekse og komplicerede opgaver, som tager lang tid og er svære at lave præcise specifikationer og krav til. 

Et problem er ofte, at de krav og specifikationer, som der er når projektet starter, kan nå at ændre sig. Fordi virkeligheden ændrer sig.

Det kan være alt fra lovændringer til glemte eller uforudsete små opgaver inden for projektet. Alt sammen er med til at højne risikoen for, at et projekt vil overskride sit budget. 

Hvorfor bliver budgettet overskredet?

Et andet problem er, at som det er i dag, kan virksomheder spekulere i at lave et relativt lavt budget som bud til kommunerne og derefter uden videre overskride budgettet igen og igen.

Grunden til at dette kan lade sig gøre er, at når først en kommune har valgt en virksomhed, er de bundet til den. Hvis de vil vælge en anden virksomhed, vil de tabe alt det arbejde, som den første virksomhed lavede, på gulvet samtidigt med at de risikerer, at den nye virksomhed også laver kalkulere overskridelser af budgettet. 

Jeg er godt klar over, at der ofte kommer ændringer som alt andet lige vil overskride budgettet.

Men når det for kommunen ikke er muligt at skifte virksomhed, uden at tabe alt der er investeret i et projekt på gulvet, så har man skabt en situation, hvor kommunerne mister den demokratiske magt, og derefter bare må agere ud fra, at man skal tabe så få penge som muligt.

Det kan de gøre på flere måder. En af dem er at begrænse projektet til et mindre område. En anden er helt at opgive projektet uden nogensinde at færdiggøre det. Begge muligheder er mildest talt ikke i orden i de fleste tilfælde. 

Det helt store problem her er, at man ikke kan se forskel på en kalkuleret budget overskridelse og en reel budget overskridelse, hvor projektet enten ændrede sig eller at virkeligheden hvor projektet skal bruges, ændrede sig.

Problemet sat i perspektiv

Det er også et problem at opgaverne som regel bliver så store, at iværksættere og mindre virksomheder ikke har en chance for at byde ind på dem. 

Det er ikke svært at se alle de konsekvenser som disse udfordringer kan skabe…
Kommunerne har ikke demokratisk kontrol med deres budget, efter de har udbudt en softwareudviklings opgave. Hvis det bare var en bygning de skulle bygge, så kunne de altid komme og fysisk se, hvor langt det er nået og se, hvad der er af fysiske problemer. Dette kan man ikke med softwareudvikling.

Virksomheder gemmer nemlig deres software bag copyright og giver som regel kun kommunerne adgang til brugen af softwaren med henstilling til, at de kan sælge de samme software til andre virksomheder/kommuner og derfor altid vil tjene stort på dette. Dette kaldes også proprietær software.

Hvad er løsningen?

Jeg kan ikke lave en 100% løsning på alle de problemer, som jeg har opstillet, men vil prøve alligevel.
Jeg mener de fleste af disse problemer og udfordringer, som gør at kommunerne mister deres demokratiske kontrol, kan løses med et meget simpelt krav i udbuddet til virksomhederne.

Kræv at softwaren som virksomhederne skal udvikle skal være Open Source. Eller endnu bedre, kræv at det skal være Fri Software.

Før alle kritikerne råber op om at det koster penge at udvikle software, så må jeg lige minde om at jeg på intet tidspunkt siger, at kommunerne ikke skal betale for det. Jeg siger, at når først en kommune har betalt for et stykke software, så skal det være vores allesammens ejendom, da det er vores skat der et gået til at betale udviklingen af softwaren.

Derudover løser det også et par af de problemer, som jeg har ridset op tidligere. Hvis en virksomhed overskrider budgettet igen og igen, så kan kommunen altid vælge at afbryde samarbejdet med virksomheden og kræve alt, der er blevet udviklet leveret med henblik på at finde en anden virksomhed, der kan færdiggøre udviklingen.

Sådan kommer den demokratiske kontrol med pengekassen tilbage i kommunens hænder.

Hvis man så også gør sig bevidst, at det skal være små software moduler, der passer sammen når man beder om udviklingsopgaver, så kunne man nemt lade 2-3-4-5 forskellige virksomheder fokusere på hver deres mindre modul.

Dermed vil man gøre en større udviklingsopgave tilgængelig for mindre virksomheder og iværksættere, og fordi det er open source eller Fri software vil alt, hvad alle virksomhederne laver, være tilgængelige for hinanden hele tiden. De vil derfor relativt nemt kunne samarbejde om at sikre, at modulerne passer sammen.

Og nu kommer der så en lille bonus. Hvis en kommune får udviklet et software modul, som en anden kommune kan bruge, så vil udviklings udgifterne til den anden kommune sænkes, da de jo bare kan tage og tilpasse modulet til deres eget behov.

Der er endnu en bonus: hvis en udvikler derhjemme ser en fejl eller mener at han kan lave udvidelser, der gør at han eller andre kan bruge softwaren, som man har stillet frit, så vil han nemt og gratis kunne lave software, som kommunen efterfølgende nemt ville kunne samle op på.

Der er et par små ulemper ved dette forslag.
Den eller de første kommuner, som går ind i dette, vil sandsynligvis havde de største omkostninger til udvikling i starten, men over tid vil de omkostninger falde dramatisk.

Samt at det vil blive dyrere at bede en virksomhed om at udvikle software for at give det frit efterfølgende, da virksomheden jo stadigvæk skal tjene penge og ikke efterfølgende vil kunne tjene på at sælge den udviklede software videre til andre. 

Disse små ulemper kan i starten godt virke uoverkommelige, men sagen er, at på lang sigt vil det altid kunne betale sig at kræve open source i alle udviklingsopgaver.