Studiebloggen: Må studerende rette fejl i universitetets software?

Posted by & filed under In Danish, Studiebloggen.

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”.

This article was originally posted on version2.dk

Click to read (please post and read comments there)

Comments are closed.