Hvornår er open source det rigtige valg for en organisation?

Matrixen er en beslutningsstøtte, ikke en facitliste. Den skal hjælpe ledelse, IT, indkøb og sikkerhed med at afgøre, om organisationen har modenhed nok til at få reel handlefrihed ud af open source.

Kort fortalt

Open source er ofte det rigtige valg, når organisationen har et klart behov for gennemsigtighed, leverandøruafhængighed, tilpasning, auditmulighed eller langsigtet kontrol over en vigtig digital funktion.

Men open source er ikke automatisk det rigtige valg, fordi licensen er åben, eller fordi anskaffelsesprisen ser lav ud. Organisationen overtager også et ansvar: for drift, supportmodel, sikkerhedsopdateringer, dokumentation, licensstyring, integrationer og vurdering af projektets sundhed.

Den praktiske beslutning er derfor ikke “open source eller proprietært?” i abstrakt forstand. Den er:

• om open source-løsningen løser et konkret organisatorisk behov bedre end realistiske alternativer
• om organisationen kan styre den ekstra handlefrihed uden at skabe ny sårbarhed
• om supportmarked, dokumentation, sikkerhedsproces og exit-plan er stærke nok til systemets kritikalitet

Artiklens anbefaling er at vælge open source, når modenhed og risiko passer sammen. Vælg smalle piloter eller driftede ydelser, når modenheden er lav. Vær meget forsigtig med at flytte kritiske processer til open source, hvis organisationen mangler ejer, supportaftale, opdateringsproces og beredskab.

Beslutningen artiklen hjælper med

Denne artikel hjælper ledelse, IT, indkøb, sikkerhed og jura med at beslutte, om open source er det rigtige valg for et konkret system eller en konkret softwarekategori.

Beslutningen kan ende i fire mulige svar:

Det sidste svar er ikke et nederlag for open source. Det er ofte et tegn på moden risikostyring.

Først: hvad open source betyder og ikke betyder

Open source handler grundlæggende om licensvilkår. Open Source Initiative beskriver, at open source ikke blot er adgang til kildekode; distributionsvilkårene skal blandt andet give ret til redistribuering, kildekode, afledte værker og ikke diskriminere mellem personer, grupper eller anvendelsesområder. Open Source Initiative: The Open Source Definition

Det betyder tre ting for organisationens beslutning.

For det første er “source available” ikke nødvendigvis open source. En leverandør kan give adgang til kildekode uden at give organisationen de rettigheder, der normalt gør open source strategisk interessant.

For det andet er open source ikke det samme som gratis drift. Licensen kan reducere nogle licensomkostninger, men den fjerner ikke omkostninger til implementering, support, sikkerhed, brugeruddannelse, integrationer, migration, dokumentation og governance.

For det tredje er open source ikke automatisk sikker eller usikker. Åben kode kan gøre gennemgang, audit og fælles fejlrettelse lettere, men sikkerheden afhænger stadig af vedligeholdelse, releaseproces, afhængigheder, konfiguration, patching og organisationens egen drift.

De seks modenhedsspørgsmål

Brug modellen her som første vurdering. Giv hvert område en score fra 1 til 5, hvor 1 betyder lav modenhed og 5 betyder høj modenhed. Scoren skal ikke give falsk præcision. Den skal vise, om organisationen er ved at købe handlefrihed eller blot flytte ansvar til et sted, ingen ejer.

1. Behov og beslutningsformål

Spørg først, hvilket problem open source skal løse.

Stærke begrundelser kan være:

• behov for audit og gennemsigtighed i en kritisk komponent
• ønske om flere mulige leverandører omkring samme teknologibase
• krav om tilpasning, integration eller langsigtet videreudvikling
• behov for åbne formater, dokumenterede grænseflader eller bedre exit-mulighed
• strategisk ønske om intern kompetence på et område, organisationen ikke vil være blind afhængig af

Svage begrundelser er typisk:

• “det er gratis”
• “det er mere suverænt” uden konkret afhængighedsanalyse
• “vi slipper for leverandører”
• “nogen i IT kan nok drifte det”

Open source bør vælges for et bestemt styringsformål, ikke som identitetsmarkør.

2. Projektets modenhed

Ikke alle open source-projekter har samme robusthed. Vurder derfor projektets sundhed før organisationen vurderer sin egen drift.

Se efter:

• aktiv vedligeholdelse og tydelige releases
• dokumenteret governance eller vedligeholderstruktur
• kendt licens og tydelig ophavsretlig information
• sikkerhedspolitik, rapporteringskanal og håndtering af sårbarheder
• test, reviewproces og release-noter
• dokumentation for installation, opgradering, backup og migration
• et fællesskab eller leverandørmarked, der ikke afhænger af én enkelt person

OpenSSF Scorecard kan bruges som inspiration til maskinlæsbare og gentagelige sikkerhedstjek, fordi værktøjet vurderer open source-projekter på praksisser som vedligeholdelse, sårbarheder, branch protection, code review, afhængigheder og signering af releases. OpenSSF Scorecard

Scorecard er ikke en facitliste. En lav score betyder ikke automatisk, at projektet er ubrugeligt, og en høj score betyder ikke, at løsningen passer til organisationen. Men værktøjets checks viser, hvilke spørgsmål en professionel vurdering bør omfatte.

3. Intern kompetence og ejerskab

Open source giver mulighed for mere kontrol, men kontrol er kun værdifuld, hvis nogen kan bruge den.

Organisationen bør kunne svare på:

• hvem ejer løsningen forretningsmæssigt?
• hvem ejer drift, opgraderinger, konfiguration og sikkerhed?
• hvem kan læse logs, fejlfinde og vurdere release-noter?
• hvem vurderer licens- og compliance-spørgsmål?
• hvem kan overtage, hvis den primære leverandør eller interne nøgleperson forsvinder?
• hvor meget skal dokumenteres, før løsningen kan drives uden personafhængighed?

Hvis svaret på de fleste spørgsmål er uklart, er open source ikke nødvendigvis forkert. Men organisationen bør sandsynligvis vælge en driftet open source-ydelse, ekstern supportaftale eller afgrænset pilot frem for at gøre løsningen til et kritisk internt driftsprojekt.

4. Supportmarked og leverandøruafhængighed

Open source kan reducere leverandørafhængighed, fordi flere aktører i princippet kan arbejde med samme kodebase. Men “i princippet” er ikke nok.

Vurder:

• findes der flere reelle leverandører med erfaring i løsningen?
• kan organisationen skifte supportpartner uden at skifte hele systemet?
• er dokumentation og konfiguration tilgængelig for organisationen, ikke kun for leverandøren?
• kan kontrakten sikre adgang til kildekode, konfiguration, scripts, backup, driftsdokumentation og data?
• er tilpasninger lavet på en måde, der kan opgraderes og overdrages?

En open source-løsning kan stadig skabe lock-in, hvis én konsulent har bygget en udokumenteret specialopsætning, hvis data ligger i uklare modeller, eller hvis organisationen ikke har rettigheder og viden til at fortsætte med en anden partner.

5. Integrationer, data og exit

Open source er mest værdifuldt, når det styrker organisationens handlefrihed i praksis. Det kræver mere end kildekode.

Kravene bør omfatte:

• dokumenterede API’er eller integrationspunkter
• eksport af relevante data, metadata, historik og bilag
• almindelige eller veldokumenterede formater
• testbar import til en anden løsning eller et neutralt arkiv
• dokumenteret konfiguration og infrastruktur
• realistisk plan for backup, restore og migration

Hvis løsningen skal indgå i en bredere softwareforsyningskæde, bør organisationen også kræve overblik over komponenter og afhængigheder. SPDX beskriver sig selv som en åben standard til at repræsentere systemer med softwarekomponenter som SBOM’er og andre sikkerheds- og risikostyringsreferencer, og specifikationen er en international standard, ISO/IEC 5962:2021. SPDX

En SBOM løser ikke sikkerhed alene. Den er et grundlag for at vide, hvilke komponenter der indgår, så sårbarheder, licenser og afhængigheder kan vurderes.

6. Sikkerhed og softwareforsyningskæde

For kritiske løsninger bør open source-vurderingen omfatte hele vejen fra kildekode til driftet artefakt.

Spørg:

• hvordan bygges og signeres releases?
• kan organisationen verificere, at den bruger den software, den tror den bruger?
• hvordan håndteres sårbarheder i direkte og indirekte afhængigheder?
• findes der en sikkerhedsproces for rapportering og rettelser?
• hvordan testes opdateringer før produktion?
• hvem vurderer risikoen ved at vente med en patch?

NIST’s Secure Software Development Framework samler anbefalinger til sikre udviklingspraksisser og fremhæver, at rammen også kan bruges af softwarekøbere og forbrugere i dialog med leverandører og i anskaffelsesprocesser. NIST SP 800-218

SLSA er relevant som supplerende reference, fordi rammen fokuserer på integritet i softwareforsyningskæden, blandt andet gennem kontroller for kilde, build, afhængigheder og artefakter. SLSA

Det betyder ikke, at alle organisationer skal kræve fuld SLSA-implementering i alle indkøb. Det betyder, at kritiske open source-valg bør behandles som softwareforsyningskædevalg, ikke bare som applikationsvalg.

En praktisk beslutningsmodel

Når de seks områder er vurderet, kan organisationen bruge en gate-model. Hver gate skal være bestået eller bevidst accepteret af en ansvarlig beslutningstager.

Hvis en gate fejler, bør beslutningen ikke automatisk afvises. Men organisationen skal vælge en af tre handlinger:

• reducér risikoen før valg
• vælg en mindre kritisk pilot
• accepter risikoen eksplicit på rette ledelsesniveau

Det farlige valg er ikke open source. Det farlige valg er ubevidst ansvar.

Hvornår open source ofte er det rigtige valg

Open source er typisk stærkt i fem situationer.

Når organisationen vil reducere afhængighed af én leverandør

Hvis flere leverandører kan implementere, drifte eller videreudvikle samme løsning, kan organisationen få en bedre forhandlingsposition og en mere realistisk exit. Det kræver, at konfiguration, dokumentation, data og tilpasninger ikke kun findes hos den nuværende leverandør.

Når gennemsigtighed er vigtig

For sikkerhedsnære, compliance-nære eller arkitektonisk centrale komponenter kan adgang til kildekode, issues, releasehistorik og sikkerhedsproces give bedre mulighed for review og audit. Det er især relevant, når organisationen ikke vil acceptere en sort boks i en kritisk del af porteføljen.

Når standardfunktionalitet kan kombineres med lokal tilpasning

Open source kan være velegnet, når organisationen har et almindeligt behov, men også enkelte nødvendige tilpasninger. Eksempler kan være interne værktøjer, portaler, analyseplatforme, dokumentationssystemer, integrationskomponenter eller infrastrukturværktøjer.

Tilpasning skal dog styres. En løsning med mange lokale ændringer kan blive sværere at opgradere end et proprietært standardsystem.

Når kompetenceopbygning er strategisk vigtig

Hvis organisationen skal kunne forstå et område dybt, kan open source være en praktisk læringsvej. Det gælder især teknologi tæt på data, integrationer, infrastruktur, identitet, automatisering eller sikkerhed.

Kompetenceopbygning er en investering. Den bør ikke gemmes som en ubetalt forventning til enkelte medarbejdere.

Når exit og lang levetid er vigtigere end hurtigste implementering

Open source kan være relevant, når systemet skal kunne leve længe, flyttes mellem driftsmiljøer, overdrages mellem leverandører eller dokumenteres uafhængigt af én kommerciel roadmap.

Det betyder ikke, at open source altid er langsommere at implementere. Men organisationen bør acceptere, at governance og dokumentation er en del af gevinsten.

Hvornår open source kan være det forkerte valg

Open source kan også være en dårlig beslutning.

Når ingen ejer driften

Hvis løsningen ender som “noget IT satte op”, uden supportaftale, patchproces, backup, overvågning og dokumentation, er risikoen høj. Det gælder især for systemer med persondata, kritiske arbejdsgange eller eksterne integrationer.

Når projektet er umodent i forhold til kritikaliteten

Et lille projekt kan være glimrende til et internt værktøj, men uforsvarligt som kritisk platform. Lav aktivitet, uklare releases, manglende sikkerhedspolitik eller afhængighed af én vedligeholder bør vægte tungt, hvis systemet er vigtigt.

Når organisationen har brug for en standardydelse, ikke softwareejerskab

Nogle gange er behovet bedst løst med en robust service: tydelig SLA, compliancepakke, brugersupport, integrationer, databehandleraftale og kendt ansvar. Open source kan stadig indgå bag ydelsen, men organisationen behøver ikke nødvendigvis selv vælge, drifte eller vedligeholde softwaren.

Når lokale tilpasninger bliver vigtigere end opgraderbarhed

Open source gør det muligt at ændre koden. Det er en styrke, men også en fristelse. Hvis organisationen ændrer for meget uden governance, kan den ende med sin egen private variant, som er dyr at opgradere og svær at supportere.

Når licens- og komponentstyring er uafklaret

Organisationen bør kende licenser, afhængigheder og brugskontekst. Copyleft, permissive licenser, tredjepartskomponenter, container-images, plugins og distribution kan have forskellige compliance-konsekvenser. Denne artikel er generel information og ikke juridisk rådgivning, men pointen er praktisk: licenser skal styres, ikke opdages tilfældigt.

Tradeoffs: hvad organisationen faktisk vælger

Open source ændrer fordelingen af ansvar.

En moden open source-strategi er derfor ikke at vælge mest mulig open source. Det er at vælge open source der, hvor den ekstra kontrol kan omsættes til konkret organisatorisk værdi.

Scenarier

Scenario 1: Internt dokumentationssystem

En organisation vil erstatte spredte dokumenter med et internt dokumentationssystem. Systemet er vigtigt, men ikke direkte driftskritisk. Data er tekstbaserede, eksport kan testes, og IT har kompetence til drift eller kan købe driftet hosting.

Open source kan være et stærkt valg her. Risikoen er afgrænset, gevinsten ved åbne formater og lokal kontrol er tydelig, og en pilot kan vise brugeradoption før fuld udrulning.

Scenario 2: Kritisk fagsystem uden intern kompetence

En offentlig eller reguleret organisation overvejer et open source-fagsystem, fordi den ønsker leverandøruafhængighed. Systemet er forretningskritisk, integrationerne er mange, og organisationen har ingen intern erfaring med platformen. Der findes kun én lokal leverandør, og dokumentationen for migration er uklar.

Her bør open source ikke vælges som almindelig anskaffelse endnu. Organisationen bør først kræve dokumenteret supportmodel, exit-test, integrationsanalyse, datamodel, referencescenarier og tydeligt ejerskab. Alternativt kan open source være relevant som driftet ydelse med stærk kontrakt, men ikke som uafklaret internt ansvar.

Scenario 3: Infrastrukturkomponent med moden drift

En organisation har et erfarent driftsteam og vil standardisere en infrastrukturkomponent, hvor åbne formater, automation og leverandøruafhængighed er vigtige. Projektet er velvedligeholdt, har aktivt fællesskab, sikkerhedspolitik, dokumentation, releaseproces og flere supportmuligheder.

Her er open source ofte en stærk kandidat. Organisationen har både formål og modenhed. Beslutningen bør stadig kræve patchproces, testmiljø, rollback, SBOM eller komponentoverblik, dokumentation og beredskab.

Indkøbskrav før kontrakt eller implementering

Når open source indgår i et kritisk system, bør indkøb og kontrakt mindst adressere:

• hvem der har ansvar for sikkerhedsopdateringer og sårbarhedshåndtering
• hvordan releases vurderes, testes og implementeres
• hvilken support der findes, med svartider og eskalationsveje
• hvordan organisationen får adgang til kildekode, konfiguration, scripts og dokumentation
• hvordan lokale ændringer holdes opgraderbare
• hvilke licenser og tredjepartskomponenter der indgår
• om der leveres SBOM eller anden komponentoversigt
• hvordan data eksporteres, valideres og importeres andetsteds
• hvordan backup, restore, logning og overvågning fungerer
• hvordan løsningen kan overdrages til en anden leverandør eller driftsmodel

For mindre, ikke-kritiske værktøjer kan kravene skaleres ned. Men for kritiske systemer bør de ikke springes over, blot fordi softwaren er open source.

En simpel beslutningsregel

Brug denne regel i ledelses- eller indkøbsmødet:

Open source er et stærkt valg, når mindst fire ting er sande:

1. Organisationen kan forklare, hvilken handlefrihed open source giver i netop dette tilfælde.
2. Projektets modenhed passer til systemets kritikalitet.
3. Der findes en realistisk support- og driftsmodel.
4. Data, integrationer, licenser og sikkerhedsopdateringer kan styres dokumenteret.

Hvis kun de to første er sande, er en pilot ofte bedre end fuld implementering.

Hvis kun licensen er attraktiv, er beslutningsgrundlaget for svagt.

Hvad ledelsen bør spørge om

Brug spørgsmålene her før valg, fornyelse eller migration:

1. Hvilken konkret afhængighed reducerer open source i dette tilfælde?
2. Hvilket nyt ansvar overtager vi selv eller gennem en supportpartner?
3. Hvem ejer løsningen forretningsmæssigt, teknisk og sikkerhedsmæssigt?
4. Hvor moden er projektets vedligeholdelse, sikkerhedsproces og dokumentation?
5. Hvilke leverandører kan hjælpe os, hvis den nuværende partner forsvinder?
6. Hvordan håndterer vi licenser, SBOM, tredjepartskomponenter og sårbarheder?
7. Hvilke data og konfigurationer kan vi eksportere og validere?
8. Hvilke integrationer vil gøre løsningen svær at forlade?
9. Hvad koster drift, opgraderinger, support, migration og intern tid over tre til fem år?
10. Hvilken pilot eller test kan reducere usikkerheden før endelig beslutning?

Det afgørende spørgsmål er ikke, om open source er bedre i teorien. Det afgørende spørgsmål er, om organisationen kan omsætte åbenheden til dokumenteret handlefrihed.

Kilder

• Open Source Initiative: The Open Source Definition
• SPDX: System Package Data Exchange
• NIST SP 800-218: Secure Software Development Framework (SSDF) Version 1.1
• OpenSSF Scorecard
• SLSA: Supply-chain Levels for Software Artifacts

Dette er generel information og ikke juridisk rådgivning.