Når man står over for at vælge en leverandør til et IT-projekt, er der mange ting at tage stilling til. Ofte fokuserer man på leverandørens kompetencer, projektets omfang og pris.
Men noget, som mange overser – og som kan få alvorlige konsekvenser senere – er spørgsmålet om ejerskab af kildekoden. Har du nogensinde overvejet, hvem der faktisk ejer koden til dit projekt?
Hvis ikke, så er du ikke alene. Mange har en tendens til at antage, at de automatisk ejer kildekoden, når de jo har betalt en udvikler for at lave den. Men det er ikke altid tilfældet.
Når du har læst dette blogindlæg, så ved du meget mere om, hvad en kildekode egentlig er. Hvis du allerede har fået udviklet et IT-projekt, viser vi dig, hvordan du finder ud af, om du ejer din kildekolde. Hvis du endnu ikke har fået udviklet et IT-projekt, giver vi dig gode råd til, hvordan du kan sikre ejerskabet af din kildekode. Vi belyser også nogle af de konsekvenser det (i værste tilfælde) kan have, hvis du ikke ejer din kildekode.
Hvad er en kildekode?
Kildekoden er hjertet i ethvert softwareprojekt. Det er den oprindelige kode, som udvikleren skriver, og som driver hele systemet. Uden adgang til denne kode kan det være næsten umuligt at foretage ændringer eller forbedringer af softwaren i fremtiden.
Desværre hører jeg FOR ofte om eksempler på virksomheder, der er blevet nægtet adgang til deres egen kildekode – og derfor har været tvunget til enten at betale i dyre domme for at få den frigivet eller, i værste fald, at udvikle hele systemet forfra.
Hvilke konsekvenser har det, hvis du ikke ejer din kildekode?
I langt de fleste tilfælde, har det egentlig ikke den store konsekvens, om det er dig eller din udvikler, der ejer din kildekode. Det er først, når/hvis du ønsker at skifte udvikler eller håndtere udviklingen internt, det kan blive et problem. Hvis din nuværende udvikler står som ejer af kildekoden, kan du risikere, at de nægter at udlevere den til dig.
Her vil jeg mene, at den “mildeste” konsekvens er, at du skal betale for at få frigivet din kildekode. Det kommer selvfølgelig helt an på, hvilken pris, du bliver stillet overfor, men lige meget hvad, er det noget, du kan forholde dig til.
Den værste konsekvens er, i mine øjne, at du skal til at udvikle hele dit system fra bunden en gang til. Det giver dig nemlig 2 meget kritiske udfordringer:
De økonomiske konsekvenser
At skulle udvikle et system fra bunden igen er i sig selv en stor omkostning, men det er faktisk ikke de eneste økonomiske konsekvenser, du kan risikere at opleve. Her er nogle af de økonomiske konsekvenser:
Dobbelt udviklingsomkostninger
Udviklingsomkostningerne vil ofte være lige så høje som første gang, dit system blev udviklet. Det betyder, at du kommer til at betale for samme projekt to gange – og i mellemtiden har du ikke fået nogen merværdi.
Tidsomkostninger
Udvikling tager tid, og hver dag uden en fungerende løsning kan koste din virksomhed penge. Hvis du skal udvikle et nyt system fra bunden, kan det tage måneder at få det klar til brug.
Mistet konkurrencefordel
Du har måske været i markedet i noget tid, og har fået dig en konkurrencemæssig fordel. Mister du adgangen til dit system, risikerer du, at dine konkurrenter overhaler dig indenom imens du venter på, at dit nye system bliver udviklet.
Tab af brugere
Hvis du ikke kan få adgang til din kildekode, risikerer du at miste dine eksisterende brugere og data. Måske har dit system allerede været i drift i måneder eller år. En periode hvor du har nået at indsamle mange brugere og data. Denne del kan du ikke nødvendigvis tage med ind i et nyt system, og det kan give dig følgende udfordringer:
Tab af brugerdata
Brugerdata er guld værd for de fleste virksomheder. Det kan være oplysninger om kunders præferencer, adfærdsmønstre, købshistorik eller brugerinteraktioner. Hvis du mister adgang til din kildekode og dermed ikke kan få fat i dataene, risikerer du at miste alt dette. Hvis det nye system ikke kan integrere eller migrere de gamle data, skal du muligvis starte helt forfra med en tom database. Dette kan både påvirke din forretning og kundeoplevelsen.
Mistet bruger tillid
Hvis dine brugere pludselig mister adgang til dit system eller skal tilmelde sig på ny, kan det skabe frustration. I værste fald kan det føre til, at du mister kunder, der ikke ønsker at gennemgå besværet med at oprette en ny konto eller miste deres historik. Genopbygning af brugerbasen kan være en langsommelig proces, og du risikerer at miste både loyalitet og tillid.
Datasikkerhed og GDPR
Hvis du arbejder i en branche med strenge regler omkring datasikkerhed, som for eksempel GDPR, kan tab af data også medføre juridiske problemer. Det kan føre til bøder eller andre sanktioner, hvis du ikke har sikret dine data ordentligt eller kan dokumentere, hvad der sker med brugernes oplysninger.
Hvordan finder du ud af, hvem der ejer din kildekode?
Når du indgår en aftale med en IT-leverandør om udvikling af software, står der ofte noget om ejerskab af kildekoden i kontrakten. Det er vigtigt, at du læser den del grundigt igennem, og her skal du være kritisk.
Hvilken kontrakt vil du helst underskrive:
Kontrakt 1: Det er leverandøren, der ejer softwaren og har ophavsretten hertil. Kunden tildeles derimod en brugsret dertil. Måske er det endda aftalt, at retten er ikke-eksklusiv og uoverdragelig og kun gældende i forhold til det antal brugere, der er aftalt mellem parterne.
Kontrakt 2: Det er kunden, der ejer softwaren, når fakturaen er blevet betalt - og kunden kan derefter gøre med den, hvad de vil. Det betyder, at kunden kan videreudvikle på softwaren, sælge softwaren eller ændre den lige så meget, de vil.
(Jeg ved godt, hvilken kontrakt jeg ville foretrække, hvis det var mig, der var kunden)
Sørg for, at kontrakten er til din fordel
For de fleste virksomheder er det klart mest fordelagtigt at eje kildekoden selv. Når du ejer koden, står du ikke med ryggen mod muren, hvis du vil videreudvikle eller ændre softwaren i fremtiden. Desuden sikrer du, at du frit kan vælge en anden leverandør, hvis samarbejdet med den oprindelige udvikler af en eller anden grund ikke længere fungerer.
Når du indgår kontrakten, skal du spørge dig selv, om du er villig til at være afhængig af en enkelt leverandør, eller om du vil have friheden til at arbejde med hvem som helst i fremtiden.
Mit råd er altid at sikre, at kunden ejer kildekoden efter endt projekt. Det giver både tryghed og fleksibilitet, og du undgår at stå i en situation, hvor du skal betale ekstra for at få adgang til alt det, du allerede har betalt for.
Hvad skal du gøre for at sikre ejerskab af din kildekode?
For at sikre dig mod potentielle problemer med ejerskab af kildekoden, er der nogle ting, du bør overveje, før du underskriver en kontrakt med en IT-leverandør:
Læs kontrakten grundigt
Sørg for at gennemgå alle klausuler, der handler om ejerskab af kildekoden. Hvis noget er uklart, skal du bede om en præcisering fra leverandøren.
Forhandling
Hvis standardkontrakten ikke giver dig ejerskab af kildekoden, skal du overveje at forhandle denne del af aftalen. Mange leverandører er villige til at imødekomme dette krav, især hvis det betyder, at de kan lande projektet. Hvis de ikke er villige til at forhandle, vil jeg på det kraftigste råde dig til at finde en anden leverandør.
Få en juridisk vurdering
Hvis du er usikker på kontraktens indhold, kan det være en god idé at få en advokat med speciale i IT-kontrakter til at gennemgå aftalen, inden du underskriver. Fortæl vedkommende at du gerne vil have særligt fokus på ejerskab af kildekoden.
Konklusion: Sørg for at eje din kildekode og undgå unødvendige risici
Afslutningsvis kan jeg kun understrege vigtigheden af at sikre ejerskab af din kildekode. Det er ikke bare en teknisk detalje, men en afgørende faktor for, hvorvidt du har fuld kontrol over din software nu og i fremtiden.
Hvis du har haft en dårlig oplevelse med overdragelse af din kildekode før, er jeg sikker på, at det allerede er det absolut første, du sikrer dig i en kontrakt med en ny leverandør.
Står over for at skulle vælge en leverandør til et helt nyt projekt, så har du formentlig ikke oplevet, hvilke konsekvenser det kan have, hvis du ikke ejer din kildekode.
Derfor er dette blot en venlig reminder til dig om, at du skal huske at tage stilling til dette inden du indgår en kontrakt med en udvikler. Det kan spare dig for mange problemer på den lange bane.
