Fastlåst hos dit softwarefirma? Sådan kommer du fri
Udgivet: December 18, 2020
Senest opdateret: March 19, 2024
Udgivet: December 18, 2020
Senest opdateret: March 19, 2024
Estimeret læsetid: 10 minutter
At vælge udvikler til din hjemmeside, webshop, app eller software kan sammenlignes med at blive gift - uanset om det er en freelancer eller et full-service udviklingsfirma, så er det en relation, man ikke bør forhaste sig ind i.
Softwareudvikling kan sagtens være en langsommelig proces, og partnerskabet stopper ikke, når systemet er færdigt og implementeret. Løbende vedligeholdelse og fremtidige opdateringer skal medregnes, og den bedste person til at tage sig af det, er ofte den oprindelige udvikler eller det team, der først byggede systemet.
Det er overflødigt at sige, at et kunde-leverandørforhold inden for IT, på samme måde som et ægteskab, er vanskeligt og dyrt at opløse, når det først er etableret - og endnu sværere, hvis du finder ud af, at du er blevet fastlåst.
Ofte tales der om vendor eller leverandør lock-in i forbindelse med cloud-services, men det er også en ofte forekommende realitet indenfor softwareudvikling. Det kaldes undertiden også "kunde lock-in" eller "proprietær lock-in" – men uanset hvad, så henvises til en situation, hvor en kunde uforvarende fastlåses til den nuværende leverandør, fordi alternativet, at skifte til en anden, medfører urimeligt høje omkostninger eller betydelig afbrydelse af virksomhedens drift.
Leverandørskifte er ellers ikke en dagligdags ting indenfor softwareudvikling. Ideelt set ville det udviklingsteam, du valgte at arbejde med fra den oprindelige planlægning til udviklingen af dit system, også være din stabile samarbejdspartner omkring dine fremtidige behov, og så ville du ikke behøve at bekymre dig om at blive fastlåst.
Men hvad hvis du kommer i en situation, hvor den eneste måde at redde dit projekt på er at skifte leverandør?
I 1902 Software har vi set vores fair share af virksomheder, der af forskellige årsager ønskede at skifte udviklere - på grund af langsomme reaktioner på små opgaver, for mange fejl i systemet, under-performance, for mange oversete e-mails osv. - men man kunne ikke videregive projektet til os uden først at skulle gennem en anstrengende proces for at få en fuld kopi af deres system (inklusive kildekoden), afbryde forretningsgange og undertiden også betale voldsomme og uventede gebyrer på grund af en eller anden form af lock-in.
Indenfor softwareudvikling kan leverandør lock-in bunde i et eller flere af disse scenarier:
Nogle gange er det først, når kunden er klar til at skifte til et andet softwarefirma, at de finder ud af, at ophavsretten til kildekoden og andet projektmateriale faktisk ejes af udvikleren. Selv hvis de får en kopi af kildekoden, kan manglen på ophavsret være en begrænsning, og undertiden endda forhindre i at videreudvikle eller ændre deres system - som et resultat bliver de i sidste ende nødt til at starte forfra med den nye leverandør.
Hvis hjemmesiden eller webshoppen er bygget på et proprietært system, der ejes af udviklingsselskabet, er kunden fuldstændig afhængig af dette firma ved eventuelle ændringer, opgraderinger eller rettelser - uanset hvor små ændringer det måtte være. Og hvis kunden skal skifte til en anden udvikler, skal de også starte fra bunden med et andet system.
Problemet kan også udmønte sig i mindre skala med proprietære moduler installeret i systemer, der ellers er open source. Selvom din webshop er udviklet med Magento Open Source, vil det for eksempel stadig kræve en vis indsats at skifte til en anden udvikler, hvis webshoppen bruger moduler, der er proprietære for din udvikler. I disse tilfælde, vil kunden derfor skulle betale for modulerne enten fuldt ud eller via et månedligt abonnement. Alternativt skal den nye udvikler finde et andet modul eller specialudvikle moduler med samme funktionalitet.
I en anden variant af det foregående scenarie kan et system muligvis være open source, men udvikleren kan stadig nægte at dele kildekoden, fordi man hævder at have foretaget betydelige ændringer af den og nu betragter den som proprietær software.
I nogle endnu mere ærgerlige scenarier har udvikleren måske lovet at levere en kopi af hjemmesiden, men i virkeligheden er det bare en kopi af databasen, nogle XML-filer og nogle billeder. Det er ikke tilstrækkeligt for det nye softwarefirma til at overtage den fortsatte support af systemet. I dette scenarie er kunden enten nødt til at blive hos deres nuværende leverandør eller mere eller mindre starte forfra med det nye softwarefirma.
Vi har også oplevet, hvordan en leverandør bevidst sendte et ufuldstændigt system (med manglende kildekode-filer) bare for at skabe bøvl og yderligere forsinke migreringsprocessen.
Lad os være ærlige og sige at det sjældent er helt simpelt at skifte til en anden udvikler eller softwarefirma. Det vil altid kræve tid og kræfter at koordinere og videreformidle projektviden fra den gamle til den nye leverandør. Det bør dog ikke medføre disse problemer for de involverede parter, og der bør ikke være unødvendige omkostninger eller forsinkelser fra leverandørens side.
Du skal selvfølgelig være opmærksom på at vælge et softwarefirma til dit projekt i første omgang, så du ikke kommer i en vanskelig situation senere. Samtidig vil det dog ikke skade at forberede dig på de værst tænkelige scenarier - helt fra starten af dit samarbejde med din udvikler, bør du overveje følgende:
Vi anbefaler, at du ikke hoster hos din udvikler. Hvis du vælger at bruge din udvikler til hosting, betyder det, at filer og database(er) vil være på deres server, som de jo kontrollerer. I tilfælde af at du vil skifte leverandør (udvikler eller hosting), kan det, så snart der opstår mistanke om, at du leder efter en ny leverandør, være svært at få fuld adgang til dine filer og database(er). Din nuværende leverandør kan gøre det vanskeligt for dig at forlade dem ved at trække processen ud eller komme med undskyldninger for ikke at give dig den nødvendige adgang - de ønsker selvfølgelig ikke at miste en kunde.
Hvis du bruger en anden hostingudbyder end din udvikler, er det nemt at skifte til en ny udvikler. Du behøver kun at kontakte din hostingudbyder og bede dem om at ændre adgangskoden til din hostingkonto, og så kan din tidligere udvikler ikke længere få adgang til dit system.
Tilsvarende gælder, hvis du vil skifte hostingudbyder, så skal du bare kopiere dit system til en anden hostingudbyder og opdatere dine DNS-indstillinger - uden at skulle forklare noget for nogen.
Du er ikke i lommen på nogle af leverandørerne.
Læs omhyggeligt din projektkontrakt eller din leverandørs Vilkår & Betingelser, inden du starter projektet. Det skal være klart, at du som kunde har fuldt ejerskab af kildekoden og projektmaterialet, og at du får den originale de-kompilerede kildekode, hvis du beslutter at skifte leverandør. Alt dette bør være tilgængeligt for dig inden for syv arbejdsdage efter din anmodning - for at minimere driftsforstyrrelser mest muligt.
Det sker ofte, at kunder med ikke-teknisk baggrund overlader alt til deres udvikler, inklusive domæneregistrering, hostingopsætning, osv. Din udvikler kan helt sikkert hjælpe dig med disse ting, men du skal sørge for at have alle registreringsoplysninger hos dig, og du bør sikre, at alle services, moduler osv. er registreret under dit firmanavn. Således undgås besvær ved overførsel af kontoejerskab senere (for ikke at tale om de udfordringer, du måtte få, hvis du sælger din virksomhed, din hjemmeside eller webshop, når køberen finder ud af, at du ikke har fuldt ejerskab af alle de digitale aktiver).
Sørg for, at din udvikler informerer dig, hvis der er moduler, der skal installeres på din hjemmeside eller webshop for at udvide funktionaliteten. Så vidt det er muligt, er det bedre, hvis du køber modulet (i dit navn) fra en tredjepartsleverandør, end hvis du bruger et proprietært modul fra din nuværende udvikler. Hvis din udvikler skal lave et modul, der ikke er tilgængeligt i en kommerciel version, du kan licensere, skal du sørge for at beholde ejerskabet af dette modul, selv når du skifter leverandør.
Bemærk, at når softwarefirmaer bygger software, hjemmesider eller webshops, genbruger de ofte det samme sæt moduler eller biblioteker for at spare tid. Du kan ikke forvente at få fuldt ejerskab af disse moduler eller biblioteker, fordi firmaet så ville være nødt til at genudvikle komponenterne igen fra bunden, hver gang de laver et nyt projekt.
Sørg i stedet for, at du har rettigheder til:
Hvis et softwarefirma ikke er enig i dette, skal du komme videre så hurtigt som muligt, fordi du er sandsynligvis på vej mod en leverandør lock-in!
Hos 1902 Software får du altid de fulde rettigheder til kildekoden og til relateret materiale vedrørende udviklingen af dit projekt. Lige fra projektplanlægningsfasen lister vi alle de moduler, der skal bruges på din hjemmeside eller webshop, så du kan godkende dem. Vi beder også kunder om at købe alle tredjepartsprodukter, moduler eller tjenester, der er nødvendige for projektet i deres navn, og blot give os udvikleradgang, så vi kan arbejde med det.
Som nævnt ovenfor har vi et sæt moduler og biblioteker, som vi genbruger i vores projekter - men vores kunder bevarer retten til at bruge, ændre og inkludere disse moduler eller biblioteker, hvis de selv udvikler eller ændrer hjemmesiden eller webshoppen, eller hvis det foregår gennem et andet firma eller freelancer. De har også ret til at overføre disse rettigheder til enhver, der køber systemet eller virksomheden.
Selvom de fleste af vores kunder gerne bliver hos os i lang tid, har de, der skifter til andre leverandører det let, på grund af vores problemfrie overdragelsesproces, der er designet til at give mindst muligt besvær for vores kunder.
Ved 1902 Software er der ingen lock-in!
Hvis du søger et stabilt softwarefirma eller et udviklingsteam til at overtage et udviklingsprojekt, der er gået i stå, så kontakt os i dag og se, hvordan vi kan hjælpe.
AUTHOR
Peter Skouhus
En dansk iværksætter, der ejer 1902 Software Development, et it-selskab på Filippinerne, hvor han har boet siden 1998. Peter har stor erfaring inden for IT-udvikling, strategisk it-ledelse og salg.