kramselund jereminsen

Offentlige midler, offentlig kode!

Ansporet af tweets og et borgerforslag har jeg i dagens anledning støvet mit V2 blog login af.

Borgerforslaget

Det findes på:
https://www.borgerforslag.dk/se-og-stoet-forslag/?Id=FT-07672
Gør software, der er finansieret med offentlige midler, offentligt tilgængelig
ID: FT-07672

Hvorfor bliver software, der er finansieret med offentlige midler, ikke udgivet som Fri Software?
Vi ønsker en lovgivning, der kræver, at offentligt finansieret software udviklet for den offentlige sektor (f.eks. NemID) gøres offentligt tilgængeligt under en Fri og Open Source software-licens. Hvis det er offentlige penge, så bør koden ligeledes være offentligt tilgængelig.

Det er naturligvis et emne som ligger mig meget på sinde!

Det officielle lydspor er derfor denne gang, Aretha Franklin: Jump to It
https://open.spotify.com/track/28ihR0IVqNXJUHrvax2PeP?si=7f162be905f34d60
https://www.youtube.com/watch?v=_-DmMLKbT8g

Teksten handler, som så mange andre 80er numre om kærlighed. Jeg har også en kærlighed, stærk og brændende kærlighed for open source.

Fri og Open Source indflydelse på verden

Det ER på grund af open source at vi har internet, punktum. Det er på grund af open source at vi idag har 100.000vis af projekter og tilhørende programmeringssprog som vi kan bruge og sammensætte.

Jeg plejer at fortælle mine studerende at vi ofte kan finde løsninger i eksisterende programmer, biblioteker og allerede udviklede ting. Hvis ikke hele løsningen, så måske 80-90% af løsningen - hvilket sparer os mange mange resourcer.

Da jeg som ung studerende blev optaget på DIKU 1990 havde jeg nogle år før kørt en Basic Compiler til min C= 128. Jeg havde også købt både CP/M og en tekstbehandler.

Undervejs på studiet kom 386BSD og Linux. Jeg fandt gennem studiet historierne om X11 , det vinduesystem jeg stadig bruger - dog med valgfri grænseflade. AWESOME.

Jeg skrev mit speciale om IPv6 og lærte derigennem hele historien om BSD Berkely Software Distribution 's indflydelse på helt basale teknologier som vi i dag tager for givet.

Bare et eksempel er TCP/IP "reference implementationen"
https://en.wikipedia.org/wiki/Internet_protocol_suite

The spread of TCP/IP was fueled further in June 1989, when the University of California, Berkeley agreed to place the TCP/IP code developed for BSD UNIX into the public domain.

Not invented here

Vi har i Danmark et slemt tilfælde af not invented here https://en.wikipedia.org/wiki/Not_invented_here

Vi er sååååååå specielle at vi skal have vores egne løsninger, hint: det er vi ikke!

Vi spilder milliarder på løsninger som enten er utidssvarende, ikke transparente, svære at vedligeholde, fejlbehæftede, forsinkede, fortsæt selv den triste liste.

Milliarder som vi kunne bruge på at forbedre infrastrukturen, tilbyde reel, varierede, tilpassede løsninger - fordi grundlaget er mere robust og modent.

Økonomi

Lad mig med det samme gøre det helt og aldeles klart, open source betyder ikke gratis - som uden udgifter. Open source skal stadig udvikles, vedligeholdes, drives og passes. Der skal løbende fejlrettes og udbygges, migreres til nye versioner m.v.

Det er dog ubestrideligt at med et open source produkt kan man komme hurtigere igang, det er mere fleksibelt med hensyn til design af arkitekturen, man lærer også emnet at kende hurtigt og i mange detaljer.

Eksempel, og efter min mening udmærket eksempel - fordi det ikke er 100% open source.

Jeg tilbyder kurser i eksempelvis Intrusion Detection Systems (IDS), alle mine kurser er open source, du kan derfor finde det på https://github.com/kramse/security-courses/tree/master/courses/networkin...

Jeg anbefaler to værktøjer Zeek, som er udviklet siden midt 1990erne, og Suricata, frigivet 2009. Begge har således en længere historie og må betragtes som veletablerede, modne og robuste. De bruges i kritisk infrastruktur over hele verden. Du kan prøve dem nemt og de kræver blot en lille virtuel maskine. De findes også på Security Onion sammen med andre gode værktøjer https://securityonionsolutions.com/

Ved at basere løsninger på dette open source har man glæde af +25 og +10 års udvikling, forbedringer. Vis mig et dansk firma som kan lave en løsning med samme kvalitet under pres, på kort tid.

Det har selvfølgelig ikke været gratis, og blandt andet firmaet Corelight har ansatte som udvikler fuld tid på eksempelvis Zeek. De sørger formentlig for at mange af de kedelige opgaver indenfor projektet fixes.

Til gengæld kan enhver som har lyst lave en udvidelse til dette fantastiske værktøj. Hvis jeg eksempelvis ønsker at Zeek skal understøtte VXLAN fordi det er vigtigt for mig, så kan jeg.

Hvis det var et kommercielt firma skulle jeg enten betale dem for at gøre det, eller håbe at nok andre kunder vil finde den ændring tilpas interessant, at firmaet selv gør det.

DER kommer styrken ved open source frem. Vi kan allesammen give tilbage.

Om at give

Jeg giver til forskellige open source projekter, specielt dem jeg selv bruger. Det er eksempelvis Qubes OS som er mit daglige laptop operativsystem. Jeg har brugt Qubes ihvertfald siden Maj 2016, hvor jeg skrev blog indlæg om Librem laptop. Du kan støtte Qubes OS via https://www.qubes-os.org/donate/

Dernæst er der OpenBSD, og jeg kan reelt ikke huske hvornår jeg begyndte at bruge OpenBSD, men det nærmer sig nok 20 år. Dette projekt udigver også OpenSSH, som jeg ved I bruger.
Jeg tør godt vove den påstand at der i så godt som alle danske virksomheder er kode fra OpenBSD projektet, om ikke andet så i switche og access points med SSH management.

Det er endda også med i Microsoft Windows 10 and Windows Server 2019 :-)
https://docs.microsoft.com/en-us/windows-server/administration/openssh/o...

Du kan støtte OpenSSH/OpenBSD her: https://www.openbsdfoundation.org/donations.html

Kommercielle IDS regler

Eksemplet med IDS indeholder dog en vinkel mere, at dele ikke altid kan understøttes ved open source. Når jeg bruger Suricata benytter jeg et kommercielt regelsæt (ETPro) som udvikles af et firma, og indlæses i mine installationer. Det er direkte abbonnement for deres daglige ændringer til kritiske regler.

Der kan således både integreres og samarbejdes med kommercielle løsninger. Det er ingen hindring at koden er open source.

Man kan også have open source uden at man nødvendigvis må kopiere hele pakken. Det giver til gengæld både transparens og indsigt i hvad der reelt er implementeret. Der kan også findes sikkerhedsfejl, før systemerne sætttes i drift!

Eksempel på system der blev offentliggjort

Jeg er jo ikke tilhænger af elektroniske systemer til stemmeafgivelse. Vi kan automatisere hele processen hen til valgstedet, og udlevering af stemmeseddel ud fra elektroniske valglister, super duper - gør systemet open source.

Der er dog et større eksempel som passer rigtig godt i denne sammenhæng:
https://en.wikipedia.org/wiki/Electronic_voting_in_Switzerland

I kan selv dykke ned i den, og de mange vinkler, herunder sikkerheden. Det ender dog med at koden publiceres.

2019 Publication of the Swiss Post system source code with complete verifiability Opening of the platform to register to participate in the public intrusion test
Realization of the public intrusion test

Fremtidig vedligehold af software

En ofte overset krølle er forøvrigt at når jeg har givet tilbage til open source, så overtager projektet bøvlet med at vedligeholde min ændring, så den virker fremad. Jeg kan således læne mig tilbage og bruge Zeek med VXLAN i al fremtid.

Fedt!

Det er i sig selv grund nok til at jeg vil have mere open source og fri software.

Frie data

Vi er ved at have en tradition snart for at frigive mere og mere data. Jeg læser jævnligt om åbne data projekter. Følg Søren Johannessen https://twitter.com/neogeografen for at se en masse eksempler og StreetComplete app - så du kan hjælpe. Jeg får det ikke gjort, men hermed givet videre.

Når vi så erkender at data uden kode intet er værd, og kode uden data intet er værd. Så er det måske på tide at vi sikrer at offentlige midler brugt til kode og data, ender under frie og åbne licenser!

Det er på tide!

Fri og open source

Jeg har valgt udtrykket open source, mens borgerforslag benytter Fri Software. Det er en snak som hurtigt bliver for lang. Jeg anbefaler derfor jer alle at købe bogen, ihvertfald alle der er kommet så langt her i blogindlægget er helt sikkert i målgruppen :-D
https://pragprog.com/titles/vbopens/forge-your-future-with-open-source/

Den gennemgår udover hvad open source er også roller og hvordan man kommer igang med at tilbyde sin hjælp til open source projekter. Jeg har selv genstartet en mere målrettet tilgang til mine "contributions" og har faktisk 3 pull requests igang med ændringer jeg gerne ser indlemmet i Zeek.

Kilder:
Bemærk også projektet Public Money, Public code https://publiccode.eu/

Kryptografi og open source

Yderligere kan vi nævne andre områder hvor vi har stor glæde af tæt samarbejde og transparens.

Kryptografi er for svært til at enkeltfirmaer kan gøre det /sikkert/. Her har vi store samarbejder mellem virksomheder, branchen, det offentlige - specielt NIST har været omdrejningspunktet.

Apropos NIST, hvis du/I mangler at skrive et sikkerhedsdokument eller politik er der ofte et NIST Special Publications dokument som I kan lade jer inspirere af. Det kunne være:

Computer Security Incident Handling Guide
https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final

eller den opdaterede

NIST SP800-63B: Digital Identity Guidelines
Authentication and Lifecycle Management
https://pages.nist.gov/800-63-3/sp800-63b.html

Fordi kryptografi er så forbasket svært, også at implementere, har vi stor glæde af fælles biblioteker som udvikles, fejlrettes og modnes. Der skal tages forbehold for mange angrebsvinkler, herunder timing angreb.

Det er derfor nødvendigt at bruge gode kryptobiblioteker. Det kan man få gennem Apples og Microsofts implementationer, som de bruger store summer på, eller gennem open source.

Kommentarer (51)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#2 Peter Nørregaard Blogger

Som Lise Gerd skrev i sin afskeds-blog er statens behov tit ret unikke.

Der er lang vej fra Henriks gode eksempler på vellykket open source et stykke nede i stakken og til at kunne opfylde behovet for tæt it-understøttelse i det offentlige.

Man kan sige meget rigtigt om det overdrevne i "vi-er-åh-så-unikke" effekten, men se lige på statens opgaver og så på, om der findes mange organisationer som løser lige akkurat de opgaver under de samme regler og omstændigheder. Der er ikke så mange.

Et open source ejendomsvurderingssystem vil ikke være særligt nyttigt. For statens fagsystemer taler situationen derfor ikke åbenlyst til fordel for open source. Selvfølgelig kan der indgå open source komponenter i sådan et, men det er en anden sag.

Men det er nok heller ikke nødvendigt med en open scource model her, mindre kan gøre det.

Det ville være nyttigt, hvis ingen leverandør kunne bruge systemet som malkeko. Og det ville være nyttigt ikke at skulle i genudbud med systemet hvert 4-8 år. Begge dele kunne opnås uden open source, men ved at indkøber fik de nødvendige rettigheder til at kunne få videre-udviklet koden hos hvem, de ville.

  • 13
  • 17
#3 Rune Hansen

Jeg har svært ved at se logikken (offenlig beslutningstagning er dog også stadig et mysterie for mig). Er der nogen der har problemer med at kildekoden til den opgave de er bestilt til skal ligge frit tilgængelig på GitHub? (Yderst suspekt)

Hvis der skulle være nogen i Uganda der kan bruge det, yderst fint. Og som du selv er inde på, så skal den "dybe tallerken" ikke opfindes igen ved et nyt udbud.

Jeg kan kun se, at det har interesse for en meget lille og bekostelig kreds der sidder med til bords på Christiansborg. (Lukket kode i store offenlige systemer)

  • 19
  • 1
#4 Ditlev Petersen

Jeg har svært ved at se logikken (offenlig beslutningstagning er dog også stadig et mysterie for mig). Er der nogen der har problemer med at kildekoden til den opgave de er bestilt til skal ligge frit tilgængelig på GitHub? (Yderst suspekt)

Der er to spørgsmål: Bør kildekoden for offentlige it-systemer være offentligt tilgængelig? Og: I hvilket omfang kan danske myndigheder basere sig på eksisterende (udenlandsk) software?

Det sidste kan være et stort problem. Der er en del områder, hvor det fint fungerer. Andre hvor det nok ikke vil fungere. Der er ting, der er særegne for et land, ikke kun for Danmarks vedkommende. Det er også en fordel, hvis dem, der udvikler systemet, er til at få fat i og kan lave en ændring rimeligt hurtigt. Og kan forstå og skrive forståeligt dansk. Endelig er der meget få, der bryder sig om at få trukket et standardsystem ned over hovedet. Brugerne vil høres, de vil have magt over systemet. Ikke nøjes med at fryde sig over, at deres chefer har været til "seminar" i USA og er vildt begejstrede for det, de blev prakket på.

Man er nødt til at tage hensyn til brugerne som noget af det første. Det behøver ikke betyde, at man ikke kan bruge andres dybe tallerkner.

  • 3
  • 0
#5 Maciej Szeliga
  • 18
  • 1
#7 René Nielsen

Som Lise Gerd skrev i sin afskeds-blog er statens behov tit ret unikke.

Jeg må bare “hakke til” og konstaterer at både du og Lise Gerd var dumpet på stedet, hvis i en eksamenssituation sagde den slags vrøvl, med mig som censor.

Punkt et så tilbyder open source den unikke detalje at borgerne kan kontrollere om f.eks. ejendomsskattesystem beregner ejendomskatten korrekt. I et retssamfund bør borgerne kunne kontrollerer udregningen og naturligvis eje kildekoden mhp. afstemning imod lovgivningen, som jo har den særlige egenskab at ændrer sig med få års mellemrum.

Punkt to, så er det velkendt at de såkaldte “arkitekter” indenfor statens systemer ofte mangler enhver jordforbindelse når fagsystemer skal kommuniker på tværs. Ordet “Afstemning” er et “fyord” i det offentlige, men i det private forbindes ordet med fængselsstraf, hvis der sker manglende afstemning.

Naturligvis skal offentlige systemer være open source og derudover er der den lille detalje, at hvordan skal en borger kunne kontrollere om systemet regninger rigtigt, hvis han ikke kan læse kildekoden og sammenholde med lovgivningen?

Producenten må finde ud af om han ønsker at leverer et system til staten, hvad det skal koste og finde sig i, at borgerne snager i, om systemet regner rigtigt.

Der er ingen som forventer at producenten arbejder gratis, men producenten må rette hans fejl gratis og det er vel der, at open source gør forskellen.

  • 18
  • 11
#9 Malthe Høj-Sunesen

Er der nogen der har problemer med at kildekoden til den opgave de er bestilt til skal ligge frit tilgængelig på GitHub? (Yderst suspekt)

Enhver hacker, statslig eller ej, starter med at lave open source dataindsamling; LinkedIn, Facebook, nyhedsmeddelelser, StackOverflow, Experts Exchange.

Forestil dig at kildekoden til PolDisp var frit tilgængeligt - det kan godt være at en borger (som er kompetent udi software) kunne spotte en fejl, men hvad er garantien for det? Jeg vender ofte tilbage til https://blogs.worldbank.org/opendata/quality-open-source-software-how-ma... og især at det tog 20 år at spotte en fejl i en simpel binær søgealgoritme.

Med tanke på hvor meget software det offentlige bestiller årligt, tvivler jeg meget på at der findes nok individer i Danmark som både 1) har kompetencer til at spotte kodefejl, 2) kompetencer til at finde og forstå bagvedliggende jura, 3) lyst til at udføre gode review, og 4) tid til at gøre det.

  • 9
  • 10
#10 Morten Bo Nielsen

Som jeg ser det er der et par gode grunde til at open source offentlig kode, selv hvis det ikke er specielt brugbart for andre f.eks. hos skat.

Første tanke er at en mellemleder som har ansvaret for driften og udviklingen af noget software, ofte ikke selv har hverken interessen eller kompentencerne til at forstå softwaren. Open sourcer man den slags, vil leverandøren kunne blive stillet til ansvar på en helt anden måde ved at borgere, akademia, eller andre begyndte at granske koden for design og kode problemer.

Min anden tanke går på "digitaliseringsklar lovgivning". Når/hvis vi kommer dertil vil dem som implementerer systemerne bestemme hvordan lovgivning skal fortolkes. Dette burde være offentligt tilgængeligt på lige fod med selve lovgivningen/bekendtgørelserne.

Lidt fra Dansk IT om digitaliseringsklar lovgivning: https://soundcloud.com/danskit/diglov

  • 13
  • 0
#11 Rune Hansen

Jeg synes jo faktisk “rapporten” du henviser konkluderer noget andet.

Nu er osint jo efterhånden en allemands ting, og det er af mange årsager (blandt andet GDPR) blevet væsentligt mere besværligt de senere par år. Men jeg mener nu heller ikke det har så meget med åben kildekode at gøre.

Jeg har af mange årsager (især af sikkerheds hensyn) kun opensource i huset med undtagelse af iOS.

Jeg vil dog til enhver tid også sige at man ikke bare skal have blind tillid til noget på baggrund af at det er OSS. Der er bare en tendens til at folk “opper” sig lidt mere hvis deres kode offentliggøres.

Derudover forventer jeg at disse milliard priser på software vi har set fra de få firmaer der vinder udbudene, bygger på en microservice metodologi, og meget af det de fakturerer for allerede er OSS.

Sikkerhedsmæssigt siger VB artiklen jo at men bare skal poste de samme midler i OSS som i den “hemmelig” kode. Og som jeg forstod var mindre projekter mere sikre i OSS regi.

  • 7
  • 0
#13 Sune Marcher

Et open source ejendomsvurderingssystem vil ikke være særligt nyttigt. For statens fagsystemer taler situationen derfor ikke åbenlyst til fordel for open source. Selvfølgelig kan der indgå open source komponenter i sådan et, men det er en anden sag.

Vores offentlige administration vil nok ikke få de store synergieffekter af at blive Open Source, og jeg er heller ikke sikker på alting pinedød nødvendigt skal være fuldstændigt tilgængeligt-for-offentligheden Open Source (fx systemer til politiet eller infrastruktur).

Men alting burde som minimum udvikles med kildekode-ejerskab til det offentlige. Og selv ting hvor vi som offentlighed ikke får adgang, bør projekterne drives med principper fra Open Source udvikling – fx at source code repositories, dokumentation/wikis og så videre er under statens ejerskab, i stedet for der udlevers best-effort (eller måske endda så-lidt-som-kontraktligt muligt) .zip dumps når en levendør udskiftes. Der bør være så høj transparens som overhovedet muligt!

Jeg har set eksempler hvor en tidligere leverandør enten leverer muligvis-ikke-helt-komplet .zip export af source kode, eller Git repository hvor de har insisteret på at anonymisere så man ikke blot har fjernet navne, men reelt sat alle committers til samme dummy-identitet. Og leverandører der har været så bitre over at miste deres malkeko, at de mere eller mindre har forsøgt at sabotere overtagelsen.

Den slags kan man undgå med ordentligt, offentligt ejerskab samt et mix mellem decideret Open Source hvor muligt (mere OS2, tak!), og "intern semi-Open Source" til resten.

Og så skal der gøres op med det forbandede udbudscirkus, de semi-korrupte venneklubber, og "vi skal have ét nyt kæmpesystem!" mentaliteten.

  • 22
  • 0
#14 Nis Schmidt

Citat fra forslaget:

Grunde til offentlig software:

  • Skattebesparelser ved at lignende programmer behøver programmeres fra bunden hver gang.

Der burde nok gave stået:

lignende programmer ikke behøver programmeres fra bunden hver gang

Hvor mange i Danmark udvikler seriøs "åben kilde" programmer?

500, 5000 eller 50.000?

"Fløjtespillerens dilemma" må tages op i anden sammenhæng.

  • 1
  • 7
#17 Lise Gerd Pedersen Blogger

Men er det nødvendigt og eller nyttigt at koden er lukket?

Måske ikke. Men før man offentliggør koden, bør man overveje, hvem der skal behandle henvendelser fra borgere, konkurrenter mv. om kodekvalitet, mistanker om fejl (også fra folk, der ikke kan gennemskue koden) osv.. samt hvor mange ressourcer man vil og kan afsætte til det. Det kan ikke undgå at fordyre projekterne. Om fordelene vil opveje det, skal jeg ikke kunne sige.

  • 15
  • 6
#19 Ditlev Petersen

Det kunne jo være at borgerbidrag gjorde projekterne billigere

Det kommer jo meget an på mængden og kvaliteten. Hvis man skal have en "sluse" ansat til at vurdere og journalisere borgerbidrag, så kan det hurtigt blive dyrt. Med mindre der kun kommer få og meget værdifulde bidrag. Mit pessimistiske gæt er, at det vil vælte ind med velmente bidrag om at man har valgt en forkert database, en forkert udviklingsmodel, et forkert programmeringssprog, en forkert platform og at alle kommentarer burde skrives på fransk.

Nu dumper jeg sikkert også.

  • 9
  • 2
#20 Flemming Kaa Madsen

Der er prisen for it-systemer, prisen for de skrottede og udfasede systemer også følgeomkostninger af it-systemer. I i "følgeomkostninger" ligger drift, men i lige så høj grad andre udgifter, der kan følge med. PH Kamp nævner i den her blog EFI-systemet: 1 mia, følgevirkning gæld øget til XXX mia. Status : Er helt skrottet.

Eller styring af vore sygehuse: Sundhedsplatformen kostede mindst 2 mia i 2018. Hvilket var uden at indregne at "produktionen" skulle være faldet i størrelsesordnen 10 %. Begge tal er i høj grad til disskution. (Her havde man et jysk alternativ til til noget mindre. (Også vidt jeg kan se er eneste argument for at vælg et amerikans system frem for at jysk at "amerikansk" er finere end "jysk".) Her kører system fortsat og vil nok blive ved med det for ingen politikker vil gennem den proces igen. Her har Epic så en stabil! indtægt/malkeko.

Jeg er overbevist om, at mere offentlig indsigt vil kvalificere både kvalitet og samlet pris (indkøb, (fejlslagne projekter), drift, tilkøb og utilsigtede udgifter).

Men det kræver så en helt anden model for at indføre, drifte og ændre IT-systemer.

I kommentar #9 fremhæves det, at for få ved nok til at kunne og ville deltage i "offentlige kodekik". Det er både et teknisk problem og et demokratisk problem. Det tekniske er "PC-kørekort-problemet": I slutfirserne fik IBM vedtaget at befolkningen som helhed, skulle holdes til at være brugere. Det har så forfulgt os lige siden: vi er langt hen af vejen som befolkning (inklusive politikker), henvist til at nikke og sige ja til hvad vi får tilbudt. Den eneste måde at få skovlen under der er at uddanne. Men vi er ikke meget for at undervise i håndværk her i landet. I folkeskolen er der ikke meget praktisk tilbage. Vi skal jo designe, også bygger de i Kina.

Dermed bliver det til et demokratisk problem: I og med at programel styre og kontrollere store dele af vores liv, og vi ikke ved hvad der foregår, kan vi ikke tage begavede beslutninger: Vi styre ikke selv.

  • 9
  • 2
#21 Ditlev Petersen

I kommentar #9 fremhæves det, at for få ved nok til at kunne og ville deltage i "offentlige kodekik". Det er både et teknisk problem og et demokratisk problem. Det tekniske er "PC-kørekort-problemet": I slutfirserne fik IBM vedtaget at befolkningen som helhed, skulle holdes til at være brugere. Det har så forfulgt os lige siden: vi er langt hen af vejen som befolkning (inklusive politikker), henvist til at nikke og sige ja til hvad vi får tilbudt. Den eneste måde at få skovlen under der er at uddanne.

Jo da. Spørgsmålet er så, hvor mange man kan uddanne til at forstå "obskure" programmer, hvis de i forvejen ikke interesserer sig voldsomt for emnet. Der er jo meget andet, der også er ekstremt vigtigt. Det er jo ikke nok "bare" at lære at programmere lidt i f.eks. Python. De fleste vil stå af, hvis de så ser et andet sprog. Eller hvis koden er lidt "snedig". De fleste, også politikere, vil være nødt til at støtte sig til "eksperter".

Hvis man kunne fordoble antallet af borgere, der havde en god forståelse for computere and all that, ville det være imponerende. Og det ville stadig være meget få.

Det bedste, jeg tør håbe på, er at mamge ved lidt, om hvordan det lugter. Og at en sælger eller en økonom ikke er de eneste, man skal snakke med.

Men jeg er ret pessimistisk for tiden.

  • 2
  • 1
#22 Eskild Nielsen

Før ca 1990 var det almindeligt at statslige kontrakter indholdt en passus om at leverancen omfattede kildekoden samt det nødvendige for at kunne 'bygge' projektet. (Processen hed noget andet den gang)

Derved kunne systemet også vedligeholdes selv efter at leverandøren var gået konkurs.

Jeg kender til mindst 2 projekter fra mit tidligere arbejde, hvor dette blev udnyttet til at holde essentielle systemer i drift i MEGET lang tid efter at en bestemt leverandør var forsvundet.

  • 13
  • 0
#24 malik taaning

Håndteringen af henvendelser vil kræve ressourcer - det vil du vel ikke betvivle? Jeg skriver jo udtrykkeligt, at jeg ikke kan vurdere, om fordelene berettiger det. Omkostningerne skal bare ikke overses.

Du skriver også udtrykkeligt at "Det kan ikke undgå at fordyre projekterne".

Her vil jeg blot påtale at din påstand lader til at være ubegrundet og subjektiv.

Du vælger i hvert fald ikke, at præsentere data eller argumenter der underbygger din påstand.

Der kan sagtens opstilles scenarier hvor det at håndtere henvendelser vil have en netto gevinst for projekterne - og derved gøre dem billigere. Eksempelvis patches afleveret af subject matter experts, eller tidlig påtale af bugs.

  • 4
  • 7
#25 Lise Gerd Pedersen Blogger

Du skriver også udtrykkeligt at "Det kan ikke undgå at fordyre projekterne".

Okay, så prøver jeg at udtrykke mig mere præcist: Det kan ikke undgå at påføre projekterne omkostninger til at håndtere og vurdere henvendelser. Om der er besparelser, der opvejer disse omkostninger, skal jeg ikke kunne sige. Skal vi stoppe ordkløveriet her?

  • 17
  • 3
#27 Jesper Sørensen

Mit pessimistiske gæt er, at det vil vælte ind med velmente bidrag om at man har valgt en forkert database, en forkert udviklingsmodel, et forkert programmeringssprog, en forkert platform og at alle kommentarer burde skrives på fransk.

Jeg arbejder med open source hver eneste dag og kigger ofte i diverse projekters kildekode, issues og pull requests når der mangler dokumentation eller jeg støder på bugs. Jeg mindes ikke at have set nogen der ønskede at gøre nogen af de ting du beskriver her.

Ja, der er af og til folk som opretter issues på ting som faktisk er dokumenteret, eller bidrag som er ude af scope i.f.t. hvad der var tænkt med projektet eller bare af for lav kvalitet.

I det store hele fylder den slags dog ret lidt, især hvis projektet i forvejen har en høj kvalitet. Det er tværtimod bidrag med "kød på" som kræver opmærksomhed, og den opmærksomhed er efter min vurdering en god investering.

Måske er jeg naiv, men jeg tror at der er mange dygtige udviklere i DK som vil være stolte af at have ydet et bidrag til et offentligt projekt - om det så bare er en stavefejl som ville koste en konsulenttime, men nu koster et tryk på en merge-knap.

Og hvis man virkelig mener at omkostningen til at håndtere bidrag er for stor, så kan man jo bare undlade at tage imod bidrag. Alene det at projektet kan tjekkes igennem vil have en positiv effekt på kvaliteten.

Der vil muligvis være henvendelser som man er nødt til at reagere på, eksempelvis vedrørende sikkerhedshuller, men det er vel bare godt hvis den slags bliver opdaget?

  • 18
  • 0
#28 Ditlev Petersen

Jeg arbejder med open source hver eneste dag og kigger ofte i diverse projekters kildekode, issues og pull requests når der mangler dokumentation eller jeg støder på bugs. Jeg mindes ikke at have set nogen der ønskede at gøre nogen af de ting du beskriver her.

Nu gætter jeg lidt, men de mennesker, der roder med de projekter, er vel på en eller anden måde involverede i projekterne (floskel: som brænder for sagen). Hvis det nu var det danske skattesystem, valgsystemerne, sundhedsbetonklodsen og lignende, så vil en masse uden for projektet komme med kommentarer og ideer.

Jeg læste engang for længe siden, at det var umuligt at diskutere AI flere steder, fordi en eller anden "profet" hele tiden blandede sig. Her vil man (måske) kunne se flere profeter og nogle med forstand på sagerne kommentere og skrive og ... Nogen skal sortere i tingene. Man kan jo ikke afvise alle indlæg fra folk på Ringkøbingegnen eller hvad man nu tøws.

  • 5
  • 5
#29 Jesper Sørensen
  • 5
  • 1
#30 Michael Cederberg

Det kunne nu alligevel være sjovt at se koden til Sundhedsplatformen på GitHub. Bare for lige at være helt sikker på at koden er alle 2000000000kr værd. (For min skyld behøves de ikke at tage imod nogen henvendelser)

Det er er faktisk en interessant case. Selvom jeg kun har fulgt projektet som almindelig borger vil jeg gætte på at koden kan deles op i følgende:

  1. Base funktionalitet fra EPIC
  2. Integration til diverse apparater (ultralydsscannere, røntgen, blodtryksmålere, EEG, respiratorer, etc.)
  3. Custom implementation af UI og arbejdsprocesser for det danske sundhedssystem
  4. Integration til andre offentlige systemer

(#1) er det fuldstændigt urealistisk at forestille sig som open source. Hvis man havde valgt en anden leverandør så var det heller ikke muligt. Alternativet havde været at skrive et system fra bunden til Danmark.

(#2) kunne være open source men så ville danskerne skulle betale for hele udviklingen. Hvis man lader EPIC eje koden, så kan de sprede udgifterne ud på flere kunder som alle bruger samme apparat. Fx. så jeg at rigshospitalet bruger et Philips system til at overvåge patienters "vital signs". Det er rimeligt at forvente at samme system bruges af en række andre kunder.

(#3) og (#4) er klart mulige kandidater. (#4) vil givetvis afsløre hvor håbløst integration til diverse gamle systemer er lavet herunder sikkerheds- og drift-problemer. Ikke fordi jeg ved noget specifikt, men jeg har set tilstrækkeligt meget integration til systemer fra 70'erne og 80'erne til at vide at alt er det muliges kunst.

(#3) er selvfølgeligt der hvor "kødet" er. Hvorvidt man kan læse koden uden at forstå det underlæggende i EPIC systemet skal jeg ikke kunne sige. Vigtigere er det at man skal have ganske indgående forståelse for de arbejdsprocesser der findes i sundhedssektoren for at forstå de valg der er truffet. Jeg har svært ved at se nogen bruge lang tid her med mindre man finder en læge eller sygeplejerske der også kan programmere.

  • 2
  • 0
#31 Jesper Sørensen

(#2) kunne være open source men så ville danskerne skulle betale for hele udviklingen. Hvis man lader EPIC eje koden, så kan de sprede udgifterne ud på flere kunder som alle bruger samme apparat. Fx. så jeg at rigshospitalet bruger et Philips system til at overvåge patienters "vital signs". Det er rimeligt at forvente at samme system bruges af en række andre kunder.

Jeg mener at man er noget blåøjet hvis man tror at EPIC ikke bare sælger den samme kode gentagne gange til overpris.

Den her "hvorfor give de andre lande noget gratis?"-tankegang er udelukkende en fordel for de lukkede leverandører og en ulempe for alle andre.

Dertil ville det vel være meget betryggende at den kode som skal overvåge dine "vital signs" rent faktisk kunne tjekkes efter i sømmende?

(#3) er selvfølgeligt der hvor "kødet" er. Hvorvidt man kan læse koden uden at forstå det underlæggende i EPIC systemet skal jeg ikke kunne sige. Vigtigere er det at man skal have ganske indgående forståelse for de arbejdsprocesser der findes i sundhedssektoren for at forstå de valg der er truffet. Jeg har svært ved at se nogen bruge lang tid her med mindre man finder en læge eller sygeplejerske der også kan programmere.

Jeg formoder at de programmører som har bygget systemet ej heller er læger og sygeplejersker.

Er det helt utænkeligt at der sidder en læge eller sygeplejerske derude som har en partner der kan programmere?

Min partner er pædagog, og hvis jeg havde mulighed for at bidrage til at hendes - og mange andre pædagogers - hverdag blev forbedret, så ville jeg gøre det med glæde.

  • 6
  • 1
#32 Klavs Klavsen

Okay, så prøver jeg at udtrykke mig mere præcist: Det kan ikke undgå at påføre projekterne omkostninger til at håndtere og vurdere henvendelser. Om der er besparelser, der opvejer disse omkostninger, skal jeg ikke kunne sige. Skal vi stoppe ordkløveriet her?

Men hvorfor SKAL man håndtere de henvendelser ? Det må hver anvender selv beslutte om det giver mening for dem.

Man kan jo f.ex. se her: https://www.version2.dk/artikel/open-source-projekt-til-cpr-numre-sparer...

Der mener kommunerne ihvertfald at de alle sparer penge, på at have gjort netop det - udvikle i Open Source. Hvor er du mener de har overset nogle udgifter i Open Source modellen?

En af de KÆMPE fordele ved Open Source udvikling er at den indsigt, giver mulighed for andre (f.ex. andre kommuner/afdelinger i staten) at se på hvad der ER lavet.. og f.ex. se at 60% af et system - ligner noget de ville kunne bruge.. HVIS det system blev modulariseret (delt op i mindre systemer der samarbejdede) - således at man kunne anvende de fælles komponenter FLERE STEDER..

Når man begynder at designe sine ting på denne fornuftige måde - så finder man mange fælles komponenter - og kommer oftest frem til et sted hvor det kun er DATA og evt. lidt kode, der kan skrives til at være "frivillig"/modulerbar (f.ex. workflow engine konfiguration) - der gør den vigtige forskel for den enkelte anvender med sine unikke behov..

Og når man bygger på Open Source standard komponenter (hvoraf nogen er udviklet af en selv) - så vil det oftest være en stor hjælp når næste "kommune" - f.ex. gerne vil benytte noget de "60%" af dit projekt.. at man så kræver at de så skriver de nødvendige tests til at sikre deres ændring af koden stadig dur - hvorved det oprindelige projekt vinder (fordi koden bliver mere fleksibel og får bedre tests af at funktionalitet stadig dur) - og det projekt der fik de 60% foræret - vinder, fordi de nu ikke længere er alene om at skulle vedligeholde de 60% - da der er flere brugere..

At vælge Open Source fordi så kan borgere finde problemer er at være blind for de sande fordele Ved Open Source - som er kompetent samarbejde om fælles behov - og hjælp til at indse de fælles behov og strukturere koden derefter.

Linux kernen er et godt eksempel - den bliver hele tiden omstruktureret og udvidet til at understøtte nye behov. f.ex. valgte Android projektet at forke kernen, men har indset at det tjener dem bedre (selvom de har så mange penge som de har hos Google) - at få deres ændringer/forbedringer til at fungere med "upstream Linux" - kernen.. så det har de brugt lang tid på.. Ligeledes har mange andre firmaer indset det samme og afsat ressourcer til at udviklerne kan arbejde efter Open Source modellen.

Det er DETTE det offentlige Danmark burde indse.

  • 9
  • 0
#33 Michael Cederberg

Jeg mener at man er noget blåøjet hvis man tror at EPIC ikke bare sælger den samme kode gentagne gange til overpris.

Det håber jeg de vil gøre. På den måde ejer de koden og skal sørge for at holde den opdateret. Jo flere der bruger den jo bedre.

Dertil ville det vel være meget betryggende at den kode som skal overvåge dine "vital signs" rent faktisk kunne tjekkes efter i sømmende?

Kun hvis der rent faktisk er nogen der gør det og bruger tid på det. Hvis jeg skal reviewe mange tusinde linjer kode uden at forstå krav, design beslutninger, uden at snakke med udvikleren, etc. så tager det laaaang tid. Jeg har svært ved at se den store interesse blandt udviklere i at gøre det for et bespoke system til det offentlige i Danmark.

Er det helt utænkeligt at der sidder en læge eller sygeplejerske derude som har en partner der kan programmere?

Men vi taler rigtigt meget kode. Ikke bare en simpel app. Hvis du ender med at nogen kigger 1% af koden grundigt efter i sømmene så er værdien tvivlsom. At man skulle sidde som par efter arbejdstid og kigge på kode og holde det op mod arbejdsprocesser i det offentlige virker usandsynligt. Det er ikke engang noget der sker i stor målestok når man bliver betalt for det. At en udvikler graver næsen ned i OpenVPN, GCC, Linux USB driver, etc. er meget mere sandsynligt.

Jeg tror grundlæggende at folk ikke forstår at den slags applikationer her sjældent er teknisk kompliceret. Der er sikkert en fin teknisk kompliceret driver et sted til røntgen-apparatet fordi det kræver at man implementerer en RS-232 baseret protocol fra 1983 men det er ikke det vigtige eller svære.

Det komplicerede er at afdække brugernes arbejdsgange, optimere samme, finde ud af hvor de kan omlægges til at passe til systemet og hvor systemet skal tilpasses. Det handler mere om at sætte sig ned og forstå hvordan en specifik gruppe læger eller sygeplejesker arbejder end om IT. Og der er fantastisk mange forskellige grupper. Og hvad når neurologerne på Rigshospitalet ønsker at have andre processes end dem på Herlev Hospital. Etc. etc.

  • 2
  • 0
#34 Lise Gerd Pedersen Blogger

Men hvorfor SKAL man håndtere de henvendelser ? Det må hver anvender selv beslutte om det giver mening for dem.

For mange af de statslige systemer er der kun 1 (en) anvender. Hvis denne statslige institution ikke håndterer henvendelser, hvad er pointen så? Spørgsmålet er, om den i henhold til forvaltningsloven overhovedet kan undlade at registrere og besvare henvendelser?

Husk også, at staten sjældent udvikler noget selv. Det er outsourcet til leverandører. Så det vil ikke være statsansatte, der kan spare en konsulenttime ved selv at trykke på en merge knap (som Jesper skrev i #27).

Generelt kan jeg sagtens se fordelene ved open source - men de forudsætter efter min mening, at der er mere end én anvender af koden.

  • 7
  • 5
#35 Jesper S. Møller

Generelt kan jeg sagtens se fordelene ved open source - men de forudsætter efter min mening, at der er mere end én anvender af koden.

Det er jo lidt et cirkulært argument, for hvordan vil man finde nye anvendere af kode som man ikke kan finde eller vurdere egnetheden af? Udstillet koden by-default vil der kunne opstå mulighed for at koden få mere end én anvender.

Som andre har skrevet, så er åbenheden en anden af fordelene, og den kunne sagtens være indsatsen værd — udviklere, der ved at deres evt. sjuskede arbejde bliver udstillet til offentligt skue, vil måske være lidt mere omhyggelige end i dag - ellers vil deres reviewere forhåbentlig.

Endelig behøver man jo slet ikke tage imod pull-requests, eller være åben for bug reports. Så vil der ikke komme nye kanaler for henvendelser.

  • 6
  • 0
#36 Klavs Klavsen

For mange af de statslige systemer er der kun 1 (en) anvender. Hvis denne statslige institution ikke håndterer henvendelser, hvad er pointen så? Spørgsmålet er, om den i henhold til forvaltningsloven overhovedet kan undlade at registrere og besvare henvendelser?

De statslige systemer jeg har set har oftest 80% + dele af systemer der ligeså godt kunne være blevet bygget af standard Open Source biblioteker/komponenter - inkl. noget workflow engine mv. Mange af dem ER endda bygget sådan - men fordi alt er skjult er ingen ens (selvom de ligeså vel kunne benytte de samme open source komponenter og alene der, drage en kæmpe fordel på tværs af alle systemer).

Så alene det at kunne begynde at bygge sine systemer af mere Open Source - ville nedbringe størrelsen på ens egen del af systemet.. Og mange af disse komponenter - som igen oftest er (eller kan blive) bygget af open source komponenter - vil være genanvendelige på tværs af andre systemer (selvom de har helt andre formål - er de store komponenter typisk de samme - eller kunne services af samme workflow-engine.. samme UI biblioteker mv..

Alene at ensrette de biblioteker der bruges og anvende de samme på tværs af statslige/kommunale systemer og samarbejde om vedligehold der - ville være en kæmpe hjælp.

Så kunne man også begynde at holde øje med kendte sårbarheder til de libraries man anvender, opdatere mv. - hvilket man overhovedet ikke gør idag - fordi man bare "har et system".. selvom det egentlig ikke er virkeligheden bag.

  • 4
  • 0
#37 Nis Schmidt

Ja, det er klart at offentligt udbud af IT-systemer bør ledsages af krav og adgang til kildeteksten. Om ikke andet ville dette krav demotivere de mest griske bud.

En del mere disciplin i udbud ville nok også hjælpe.

Men det største OSS marked er amerikansk: 50 stater med ca samme størrelse som de tre nordiske, men med ét fælles sprog. Det er nok derfor det meste open source kommer derfra?

  • 1
  • 0
#38 Martin Dahl

Selvom der kan være komponenter, der kan genbruges på tværs af projekter, så er det i mindre grad kode-genbrug, der er argumentet for open source.

Det drejer sig om urtusindets vigtigste princip for demokrati og lighed, og det er transparens.

Ikke at forveksle med det modsatte af retten til privatliv, vel at mærke.

Transparens lader os se kildekoden til offentlige projekter, så vi kan vurdere hvad vi får for pengene og samtidig evaluere hvilke algoritmer, der regulerer os ift. skat og øvrig social lovgivning.

Transparens lader os følge virksomheders omsætning, til kanalisering i evt. skattely, så vi kan ekskludere den slags virksomheder fra vores øvrige fællesskab.

Transparent kan sikre at Moms-karousseller ikke kan etableres.

Transparens ville have vist offentligheden, år før Skats egne chefer så røgen, at der blev udbetalt uforklarlige milliarder på baggrund af uforklarlige mængder beskatning af udbytter.

Og tilbage til kildekode og borgerforslaget. Så skal den slags være tilgængeligt i et gængs accepteret format, og versioneret ift. nuværende driftsversion.

Dvs, man kan kræve, at ligesom PDF er oldtids-formatet man afleverer underskrevne dokumenter i, så er statens egen git platform, der man leverer de aftalte projekter, i takt med at de i driftsættes.

En nødvendig del af en ægte IT strategi for en stat, er at stille services tilrådighed og angive konkrete retninger for godkendte løsninger.

  • 3
  • 0
#39 Morten Jensen

Med tanke på hvor meget software det offentlige bestiller årligt, tvivler jeg meget på at der findes nok individer i Danmark som både 1) har kompetencer til at spotte kodefejl, 2) kompetencer til at finde og forstå bagvedliggende jura, 3) lyst til at udføre gode review, og 4) tid til at gøre det.

Jeg kan ikke tælle hvor mange tilfælde af kodefejl jeg har fundet i projekter på github, hvor jeg ikke aner hvad koden reelt gør, men kan se at det er kodet forkert. Det er slet ikke alle bugs der er så overfladiske, men der findes mange af den slags.

Jeg synes man bør skelne mellem kodefejl og designfejl. Forstået således at kodefejl er når koden ikke udfører programmørens intention, og designfejl er når koden er fejlfri, men designet forkert så den ikke udfører opgaven korrekt.

Det kræver ingen domæneviden at finde kodefejl, og dem er der immervæk mange af. Jeg har læst flere empiriske studier der viser at software review fanger 20-40% af fejlene i koden. Mon ikke der bliver solgt noget kode til det offentlige i ny og næ, som aldrig er blevet reviewet af nogen?

Jeg synes også det er en fejl at tro, at kun danskere vil have interesse i at reviewe koden. Det ser da også flot ud på eks. en kineser eller inders CV, at have rettet fejl i software der driver dansk kritisk infrastruktur.

Jeg er enig med Lise Gerd i, at det må koste noget hvis der skal reageres på henvendelser. Jeg tror dog prisen er lav set ifht. fordelene og de potentielle besparelser.

  • 1
  • 0
#40 Bjarne Nielsen

Jeg er meget enig i overvejelserne om fordelene ved open source, og vil tilføje, at jeg fra sidelinjen flere gange har oplevet at aktindsigter og lignende bliver afvist med henvisning til kontrakter, forretningshemmeligheder og konkurrencevilkår, og er blevet efterladt med en grim fornemmelse af, at det vist var en meget bekvem undskyldning (that's not a bug, that's a feature).

På den anden side, så sidder jeg også tilbage med en fornemmelse af, at de gode erfaringer ikke kan overføres direkte, og at det kan blive ... ahem ... "usædvanligt byrdefuldt".

Hvorfor? Tja, en fornemmelse er jo en fornemmelse, men jeg tror ikke at jeg fornærmer nogen, hvis jeg påstår at ledelsen af langt de fleste opensource projekter har en betydeligt større forståelse for softwareudvikling end den gennemsnitlige offentlige kunde (der er stor variation). Jeg har hørt om kontrakter med krav om 100% automatisk test, hvilket medførte at alle toString() metoder blev fjernet.

Alt for ofte virker det som om at kortsigtede og synlige resultater kan prioriteret over langsigtet holdbarhed, og fikse ideer over kvalitet. Modeluner og "flux capacitors" virker også til at være mere udbredte end man skulle tro. Jeg gruer for, hvad "folkestemningen" kan føre til, uden kloge hoveder med kølig overblik og dyb indsigt som modvægt.

På den anden side, så kunne det måske få sat spot på nogle af de værste plattenslagere.

Lad mig sige det på den her måde: jeg tror, at det med fordel kunne spille en meget større rolle, men at det farligt at gøre det til et alt for direkte krav.

  • 0
  • 0
#41 Jens Jönsson

Et open source ejendomsvurderingssystem vil ikke være særligt nyttigt. For statens fagsystemer taler situationen derfor ikke åbenlyst til fordel for open source. Selvfølgelig kan der indgå open source komponenter i sådan et, men det er en anden sag.

Men det er nok heller ikke nødvendigt med en open scource model her, mindre kan gøre det.

Det er en i flg. mig forkert måde at anskue det på. Ulempen ved software brugt af det offentlige, er at mindre firmaer sjældent kan være med. Hvis koden er frit tilgængelig for et fagsystem, så kan andre udvilke udvidelser til det/vedligeholde det. Igen, som Henrik nævner, så vil det jo ikke betyde at det offentlige nødvendigvis IKKE skal betale. Men mangler de funtionalitet, så kunne de lægge opgaven ud og så kunne alle byde, store som små. Ofte ville de små kunne være med på f.eks. prisen. Jeg kunne godt se at der kunne spares nogle milliarder på IT projekter i det offentlige.

Mener at England for år tilbage er begyndt på netop det...

  • 5
  • 0
#42 Klavs Klavsen

Mener at England for år tilbage er begyndt på netop det..

https://www.version2.dk/artikel/saadan-aabnede-den-engelske-stat-smaa-it...

Præcis - og de vurderer at have sparet 5 milliarder på den måde at arbejde på.

Og HER er Open Source en kæmpe fordel for at samarbejdet fungerer og man bedre kan uddelegere mindre opgaver til mindre virksomheder (som jo udgør 70% + i Danmark) som i dag ikke får mange offentlige opgaver fordi det ALTID SKAL være kæmpe opgaver - til overpris og KUN til de få udvalgte, der altid virker til at snyde statskassen.

  • 6
  • 0
#43 Joseph Petersen

Generelt kan jeg sagtens se fordelene ved open source - men de forudsætter efter min mening, at der er mere end én anvender af koden.

Lise, jeg må sande jeg kan ikke se dit argument for én avender.

Igennem min karrier har jeg gang på gang set hvordan kollegaer i større virksomheder duplikere kode, laver systemer som ikke snakker sammen eller for lavet et system hvor der er frygt for at lave ænderinger for de kan ikke se konsekvenser da deres kode er gemt godt væk og til tider ikke engang ligger i en versions kontrol system. Hvis det ses i private virksomheder hvem siger det ikke også sker i offentlige projekter som til tider kan virke at der er behøv for enorm hemmelighed.

Alle vores statslige IT systemer ville have stor gavn af open source. Hvis der er stor fokus på kode deling. Jeg er sikker på er der er business logik der kan deles på tværs af flere projekter samt kunne der deles viden hvordan infrastukuren bliver kørt på landsplan. Min erfaring siger mig at abstraktioner på tværs i software er med til at øge udviklers produktivitet.

F.eks. hvis alle statslige IT systemer blev hosted i datacentere der var kørende på samme infrastrukt som benyttet sig af Linux for at spare licenses til Microsoft og andre lignende licens problemer. Derudover hvis man benyttet større open source projekter som f.eks. Kubernetes til at drive alt software som staten havde kørende ville der sikkert være mange penge at spare.

Frygten for henvendelser må jeg sande også at være uforstående for. Det lyder for mig som i, flere af dem som har skrevet i denne tråd, aldrig har prøvet at bidrage eller vedligeholde et open source projekt og derved at jeres frygt ikke grundet i et projekt drives i open source.

Det minder mig igen og kollegaer der er bange for at vise deres kode frem og ligesom har fået en følelse af ejerskab over koden og derved er bange for nogle kigger på koden eller nogle søreme tillader sig at kritisere koden.

Vores offentlige administration vil nok ikke få de store synergieffekter af at blive Open Source, og jeg er heller ikke sikker på alting pinedød nødvendigt skal være fuldstændigt tilgængeligt-for-offentligheden Open Source (fx systemer til politiet eller infrastruktur).

Lyder til at der mangler forståelse for open source tilbyder hvis projekter. Kode søgning på tværs af en organisation på f.eks. GitHub kan være med til at du kan finde frem til noget kode. Hvor nogle allerede har lavet arbejdet for dig og du kan benytte dig af et kode biblotek der ligger offentligt tilgængligt på f.eks. nuget.org eller pypi.org. Eller offentligt APIer som er udviklet og driftet på samme måde for alle statslige projekter med en fælles API gateway der var f.eks. beskyttet med nemid og derved kunne borger også udvikle projekter som kunne benytte de offentlige APIer. Du skal ikke lede langt for at finde fordele, se bare i vores bank sektor. Her findes https://www.aiia.eu/ som før gik under navnet Nordic API Gateway.

Ej kan jeg hellere ikke se hvorfor kode til infrastruktur eller politet ikke kan være open source. Det siger bare noget om at det ikke er strukturet korrekt bag systemer der kan holde ting beskyttet. Her tænker jeg f.eks. på Hashicorp Vault som er med til at kunne lave dynamiske secrets med rolling keys.

  • 2
  • 0
#44 Sune Marcher

Lyder til at der mangler forståelse for open source tilbyder hvis projekter.

Jeg har lavet løsninger både for det offentlige og det private, og i øvrigt anvendt større eller mindre mængder af Open Source til det hele.

Men det lyder som om du har en del ønsketænkning i din post, hvor mine overvejelser også bygger på at ikke alting er greenfield udvikling, at der er masser af legacy der udvikles videre på.

Og jeg må nok også hellere præcisere - når jeg skriver "Vores offentlige administration vil nok ikke få de store synergieffekter af at blive Open Source" mener jeg at vi har rigtigt mange systemer der har meget lidt med hinanden at gøre. Fællesmængder af business logic mellem skatteindragelse, politisystemer, patientjournal, ...? Der skal nok være nogle ting, men jeg tvivler på at Open Sourcing ville føre til massive mængder af kodegenbrug, fordi der er så mange lovgivnings-kringelkroge med specifikke behov.

At anvende standard Open Source komponenter i løsninger er dog en helt anden sag, og en no-brainer :-)

Men lige meget om der ikke automatisk kommer besparelser, måske kan være af udgifter til pull request reviews, og så videre, har jeg naturligvis støttet borgerforslaget – som Martin Dahl nævner: så meget transparens som muligt, tak.

Kode søgning på tværs af en organisation på f.eks. GitHub kan være med til at du kan finde frem til noget kode. Hvor nogle allerede har lavet arbejdet for dig og du kan benytte dig af et kode biblotek der ligger offentligt tilgængligt på f.eks. nuget.org eller pypi.org.

Det her er mere ovre i "anvendelse af Open Source" end "offentlige systemer skal udvikles Open Source" :)

GitHub er lækkert også selvom du ikke skriver Open Source kode, og jeg kan i øvrigt anbefale https://livegrep.com/search/ til index + search, det er guld værd når man har en kodebase på ikke-triviel størrelse.

Ej kan jeg hellere ikke se hvorfor kode til infrastruktur eller politet ikke kan være open source. Det siger bare noget om at det ikke er strukturet korrekt bag systemer der kan holde ting beskyttet. Her tænker jeg f.eks. på Hashicorp Vault som er med til at kunne lave dynamiske secrets med rolling keys.

Når man har lavet lidt arbejde indenfor visse sektorer erfarer man at der er kæmpe bunker af lorte-legacy der ikke er lige til at udskifte, og som desværre ikke tåler at blive udstillet offentligt. Jeg er ikke fan af security through obscurity, men der er ting som vi er nødt til at leve med en rum tid endnu.

(Jeg har lavet min del reverse engineering, så vi behøver ikke tage en diskussion om hackere har behov for kildekode eller ej).

  • 2
  • 0
#45 Joseph Petersen

Sune, jeg er helt enig om at jeg ofte kigger på udvikling med et grønt skær.

Det skal dog siges at her tanker jeg på hvad dette lovforslag kan være med til at bringe i fremtiden, jeg er fuldt forstående for at det tag tid at udvikle og det ikke sker nærmere fremtid.

Mine tanker om legacy kode er at det bør altid afbetales ellers øger du bare altid dine renter til legacy monsteret. Der kan altid skrives nyt software der snakker med legacy systemer og langtsomt udskifte mindre dele af systemerne med mindre komponenter så det er nemmere at vedligholde over tid.

Personligt synes jeg aldrig legacy er et godt argument for at stoppe et projekt eller stoppe vedligholdelse af et system (bug fixes, features, runtime dependencies updates, software dependencies updates, OS updates).

Hvis bare vi kunne betragte software som en levende organism der altid var under konstant udvikling 😅

  • 4
  • 0
#47 Henrik Sørensen

... vi har rigtigt mange systemer der har meget lidt med hinanden at gøre. Fællesmængder af business logic mellem skatteindragelse, politisystemer, patientjournal, ...? Der skal nok være nogle ting, men jeg tvivler på at Open Sourcing ville føre til massive mængder af kodegenbrug, fordi der er så mange lovgivnings-kringelkroge med specifikke behov.

Sune, prøve at læse Klavs Klavsens indlæg #36, for han er tæt på essensen af hvad det handler om.

Politisystemet, Skatteinddragelse og en masse andre "systemer" har overraskende meget til fælles ... fx. indgår der oftest et workflow system, som Klavs påpeger og hele rolle/adgangskontrolsystemet løser formentlig prik den samme opgave i system A og system B ligesom telemetri, logning og en laaang række systemstøtte funktioner bliver bygget gang på gang selvom det er præcis samme opgave de varetager.

Jeg kan se, at du langt hen ad vejen deler Klavs synspunkt,

At anvende standard Open Source komponenter i løsninger er dog en helt anden sag, og en no-brainer :-)

... men jeg forstår ikke hvorfor du så mener at det offentlige så ikke skal udvikle open source?

  • 0
  • 0
#49 Henrik Sørensen

Kan du pege på en klausul i standardkontrakterne, der opfylder kravet i denne blog med overskriften "Offentlige midler, offentlig kode"?

@Peter læs lige min kommentar #46 igen. Jeg kommenterer et citat fra et tidligere indlæg om adgang til kildekode.

... men læs også gerne K02 aftalen som fx har følgende pasus:

"....23.3 Kundespecifikt programmel 23.3.1 Kundens rettigheder Kunden har en tidsubegrænset brugsret, medmindre andet udtrykkeligt er angivet i bilag 15, til programmer og grænsefladespecifikationer, der er Kundespecifikt Programmel, samt den dertil hørende Dokumentation.

Brugsretten medfører en ret for Kunden til selv eller ved tredjemand at vedligeholde og ændre Kundespecifikt Programmel og dertil hørende Dokumentation, medmindre andet er angivet i bilag 15.

Medmindre andet udtrykkeligt er angivet i bilag 15, skal Leverandøren med faste intervaller og senest umiddelbart efter Kundens godkendelse af en delleveranceprøve, der omfatter det pågældende Kundespecifikke Programmel, foretage sådanne foranstaltninger, der gør kildekoden for dette tilgængelig for Kunden i tilfælde af Leverandørens misligholdelse. Leverandøren kan opfylde denne pligt ved løbende at overdrage kildekoden til Kunden, ved deponering hos tredjemand, eller på anden måde, der accepteres af Kunden. Kunden bærer alle omkostninger til deponering. De nærmere krav til deponering samt eventuelle indskrænkninger i Kundens brugsret til kildekoden skal anføres i bilag 15...."

Du kan finde kontrakten i sin helhed her: https://kammeradvokaten.dk/media/5131/k02-kontrakt.docx

Så vidt jeg husker, er der tilsvarende klausuler i de fleste af andre standardkontrakter, bl.a. K03 om agil udvikling.

Kravet skal naturligvis gøre det muligt for kunden at skifte leverandør og fortsætte udviklingen hos denne uden at skulle starte forfra. Så kunden HAR adgang til kildekoden i de fleste tilfælde. Og det var det jeg svarede på.

Der hvor filmen knækker er lidt længere nede i samme kontrakt, hvor der står:

"...Kunden kan ikke overdrage ændringer, udover fejlrettelser og integration til eksisterende og nye systemer, til andre, herunder andre Offentlige Institutioner."

Derfor er der behov for at man går skridtet længere og kræver at det skal være open source.

  • 3
  • 0
#50 Sune Marcher

... men jeg forstår ikke hvorfor du så mener at det offentlige så ikke skal udvikle open source?

Jamen det mener jeg da heller ikke? Jeg skriver endda "Men lige meget om der ikke automatisk kommer besparelser, måske kan være af udgifter til pull request reviews, og så videre, har jeg naturligvis støttet borgerforslaget – som Martin Dahl nævner: så meget transparens som muligt, tak.".

Ja, jeg tror at nogle folk har urealistiske forventninger til hvor meget synergi, kode-deling og besparelser det kan give (i modsætning til anvendelse af Open Source komponenter, der er en no-brainer), og ignorerer at det kan have fordyrende overhead – helhedsbilledet er rimeligt komplekst.

Du peger på fx workflow engine og auth/RBAC, men det er jo netop dele hvor der kunne tænkes at være eksisterende Open Source løsninger der kan anvendes, hvorimod jeg (og, hvis jeg forstår hende ret, Lise Gerd Pedersen) fokuserer på de den virkeligt store mængde custom business logic der ligger i de enkelte fagsystemer.

Men derfor støtter jeg alligevel op om at så meget som muligt bliver lavet som Open Source. Nogle steder vil det helt sikkert medføre besparelser, andre steder kan det gøre integrationsarbejde nemmere for resten af os, og så er der mit ønske om gennemgribende transparens.

Og så er der stadig "så meget som muligt" klausulen. Jeg tror ikke det er alt der kan eller bør være Open Source. Den er desværre lidt besværlig, og både mørkelygte-røvhullerne og jakkesæt-konsulenthuse-gribbene har interesser i at påstå at det er en stor mængde det drejer sig om.

  • 3
  • 0
Log ind eller Opret konto for at kommentere