Open source er gratis
Ja
og nej. Open source kode kan downloades gratis, men services som
hosting, support, drift, mv. skal tilkøbes ved en leverandør (eller I
skal gøre det selv). Vedligehold og tilpasning af kode koster
arbejdstimer i egen organisation eller eksternt. Hvis I vil være med til
at sikre et bæredygtigt projekt, er det god stil at støtte open source
projekter finansielt.
Der er altså udgifter ved open source, fordi digitalisering er mere end en statisk kodebase.
Open source er uholdbart
- Fordi man som virksomhed ikke kan tjene penge på open source.
Nej. Der er flere måder at skabe en forretning med open source, f.eks. hosting, vedligehold, udvikling og support. Open source er med til at stimulere konkurrence blandt it-leverandørerne, der kan konkurrere på deres udviklingsevne og teknologiforståelse.
Open source er uden styring
- Hvem som helst kan skubbe koden (ændringer) ind, som de vil.
Nej.
En open source løsning har en (eller flere) maintainer
(”projektledere”), der kigger på nye forslag til ændringer i eller
tilføjelser til koden og udvælger efter, hvad der er bedst for kodebasen
og dens vision.
Hos OS2 er en maintainer en
koordinations-/styregruppe med hjælp fra en leverandør. Engagerede medlemmer er
der nemlig mange af – og tak for det!
Er ikke modent software
Ja og nej. Linux (styresystem), Drupal (hjemmesider) og OpenSSL (et sæt krypteringsværktøjer) er eksempler på modne og velstrukturerede open source projekter. Hvis et open source projekt ikke er modent, kan det f.eks. skyldes kvaliteten af organiseringen og/eller finansieringen eller at der slet og ret ikke findes det behov, som løsningen vil adressere. Ligesom med alt andet software skal man vurdere fundamentet bag selve løsninger.
Open source er ikke for offentlige myndigheder
Jo det er. Organisationen Free Software Foundation Europe (FSFE)
har kørt en kampagne, der hed Public Money Public Code, hvor de bl.a.
argumenterede for, at software, der bliver lavet af offentlige midler,
bør være åbent, så alle kan kigge med i kode.
Det skaber
transparens i den offentlige sektor og sikrer igen, at en myndighed kan
vælge imellem flere leverandører eller skifte undervejs. Sådan kan man
stimulere konkurrence og sikre, at borgerne får det bedste og meste for deres
skattekroner. Og det betyder også, at det er muligt for virksomheder og
private at spotte sikkerhedshuller og derfor styrke sikkerheden i koden. Et eksempel er Italiens Open by Default princip for den offentlige sektor. Tjek også Foundation for Public Code samt Tysklands Sovereign Tech Fund.
Manglende support
- Der er ingen garanti for support eller service fra en leverandør.
Det er korrekt, at der i udgangspunktet ikke er en direkte supportkanal, da open source software udvikles af et frivilligt fællesskab. Der er ikke en enkelt leverandør ansvarlig for at yde support. Imidlertid vil der næsten altid være adgang til support i dette fællesskab og for næsten alle open source-projekter er det også muligt at indgå service- og supportaftaler med en leverandør. Styrken er, at du selv kan vælge leverandøren og omfanget af den nødvendige support.
Mange store open source-projekter har også en virksomhed bag sig, f.eks. IBM, Red Hat, Google, Meta, Amazon og mange andre, der har offentliggjort open source-projekter, som de også sikrer vedligeholdelsen af. Der er også mange projekter, der er en del af en fond, som f.eks. Linux Foundation, Eclipse Foundation eller Apache Foundation. Der er derfor rig mulighed for at finde og bruge open source-projekter, hvor der er adgang til rigelig support og service.
Som med alt andet software, er det vigtigt at foretage et compliance-check for at kende risici og muligheder, og veje dem mod din organisations egne kompetencer.
Kompleksitet i vedligeholdelse
- Det kræver intern ekspertise at vedligeholde og opdatere open source software.
Hvis man vælger at påtage sig ansvaret for vedligeholdelse og opdatering af kildekode og teknologi, kræver det den rette ekspertise. Det er dog en styrke ved open source software at have dette frie valg. Du kan vælge at håndtere det selv, hvis din organisation har de nødvendige kompetencer. Alternativt kan du vælge at købe ydelser fra en ekstern leverandør eller kombinere begge dele. Du har altså stor frihed, og det er her, kompleksiteten opstår - pludselig skal man forholde sig til det frie valg.
For de open source produkter, der er i OS2-fællesskabet, sikrer vi, at der er mulighed for at købe ydelser hos mindst en leverandør. Samtidig etablerer vi et vidensfællesskab, der sikrer, at man deler forpligtelsen og dermed også hinandens ekspertise.
Sikkerhedsrisici
- Åben kode kan udnyttes af ondsindede aktører, hvis den ikke vedligeholdes korrekt.
Ja, både åben kildekode og lukket kildekode kan potentielt udnyttes af ondsindede aktører, hvis det ikke vedligeholdes korrekt. I al kildekode, der ikke vedligeholdes korrekt, vil det være muligt at finde og udnytte sårbarheder, og her vil nogen mene, det er nemmere, når kildekode er frit tilgængelig. Men det betyder ikke, at åben kildekode er mere usikker end lukket kildekode.
Faktisk kan åben kildekode i mange tilfælde være mere sikker. Netop fordi koden er åben for alle, kan den gennemgås og forbedres af et globalt fællesskab af udviklere. Dette kan føre til hurtigere identifikation og løsning af sikkerhedsproblemer sammenlignet med lukket kildekode, der kun kan gennemgås af et begrænset antal personer. Det er også velkendt, at udviklere i det åbne er mere grundige end udviklere, der skriver kode, ingen kan læse.
Det vigtigste er, at uanset om softwaren er åben kildekode eller lukket kildekode, skal den vedligeholdes korrekt. Dette inkluderer regelmæssige opdateringer og patches for at rette eventuelle sikkerhedsproblemer. Hvis dette ikke sker, kan begge typer software være sårbare over for angreb. Igen er der en større transparens omkring åben kildekode (open source). Her har du rent faktisk mulighed for at tjekke, om en kildekode holdes opdateret, og af hvem den holdes opdateret.
"Security through obscurity" har aldrig været en anerkendt sikkerhedsmetode - altså noget er ikke sikkert bare fordi det er skjult, og noget er ikke usikkert bare fordi det er åbent.
Fragmentering
- Der er risiko for forskellige versioner og inkompatibilitet mellem komponenter med open source.
Ja, der er en potentiel risiko for fragmentering i open source-projekter. Da open source-kode er frit tilgængelig, kan enhver udvikler tage koden og lave sin egen version af softwaren. Dette kan resultere i forskellige versioner af softwaren, der er inkompatible med hinanden, også kendt som "forking". Forking (forgrening) kan være en styrke, da det kan medføre innovation og tilpasning, men det kan selvfølgelig også skabe udfordringer med kompatibilitet og standardisering.
Det er derfor vigtigt at have en god projektstyring og et stærkt fællesskab (community) omkring open source-projekter for at minimere risikoen for uhensigtsmæssig forking. De seriøse og etablerede open source-projekter har regler og procedurer for bidrag for at sikre, at alle ændringer er i tråd med projektets overordnede retning og mål. I OS2-fællesskabet arbejder vi netop på at sikre dette.
Forking til forskellige versioner vil kun være et problem, hvis man har et projekt uden en fælles retning og et primært udviklingsspor. Hvis man har styr på det primære projekt, kan det i princippet forgrene sig lige så meget som nødvendigt, uden at det har en negativ indvirkning på hovedprojektet.
Længere implementeringstid
- Open source software kan tage længere tid at tilpasse og implementere end kommercielle løsninger.
Det er en udbredt misforståelse, at implementering af open source-software altid tager længere tid end kommercielle løsninger. Tidsrammen for implementering kan variere meget afhængigt af flere faktorer, herunder kompleksiteten af det specifikke projekt, tilgængeligheden af nødvendig ekspertise og støtte, og omfanget af nødvendige tilpasninger til den specifikke brugssituation. I nogle tilfælde kan open source-software være hurtigere og nemmere at implementere, fordi det er mere fleksibelt og kan tilpasses mere præcist til brugerens behov. Dog kan der i nogle tilfælde være behov for mere tid til tilpasning og implementering, hvis der kræves omfattende specialtilpasning, eller hvis der er begrænset adgang til support og ekspertise. Det samme kan og vil gøre sig gældende med standardiseret kommercielt udviklet software.
Grundlæggende er alt software standardiseret til specifikke behov og vil derfor kræve tilpasning af den ene eller anden grad, uanset om det er open source eller proprietært. Misforståelsen opstår højst sandsynligt, fordi man med open source har en større frihed og fleksibilitet i forhold til at tilpasse, og derfor er tilbøjelig til at gøre dette fremfor at tilpasse sine forretningsgange.
I OS2-fællesskabet har vi et fokus på, at løsningerne er generiske og tager afsæt i fælles behov. Dermed skabes der også fælles løsninger.
Begrænset funktionalitet
- Open source mangler måske nogle af de avancerede funktioner, der findes i kommercielle løsninger.
Det er en misforståelse, at open source-software har begrænset funktionalitet sammenlignet med kommercielle løsninger. Faktisk er mange open source-programmer og -systemer utroligt kraftfulde og fulde af avancerede funktioner. Hvad angår funktionalitet, afhænger det af det specifikke stykke software og ikke, om det er open source eller ej, derfor er det vigtigt at evaluere softwaren på baggrund af dine specifikke behov.
Det er værd at bemærke, at fordi open source-software er åben for alle, er der en enorm kollektiv intelligens på arbejde for at forbedre og forfine disse værktøjer. Dette kan ofte resultere i en hurtigere implementering af nye funktioner og forbedringer sammenlignet med kommercielle løsninger.
Endelig giver open source-software dig friheden til at tilpasse og udvide softwaren efter dine behov. Hvis der er en funktion, du har brug for, der ikke allerede er der, kan du (eller en kyndig programmør) tilføje den. Dette er simpelthen ikke en mulighed med de fleste kommercielle produkter.
I OS2-fællesskabet fokuserer vi på, at der udvikles software med robust funktionalitet, der opfylder behovene hos vores medlemmer. Der lyttes til brugerne, og der arbejdes konstant på at forbedre og udvide tilbuddene uden at gå på kompromis med f.eks. risikoen for fragmentering af projekterne.
Færre garantier
- Der er ingen officielle garantier eller ansvar ved fejl eller nedbrud i open source software.
Det er korrekt, at open source software som udgangspunkt ikke kommer med de samme garantier som kommerciel software. Når man downloader og bruger open source software, er det normalt "som det er", uden garantier for dets funktion eller ansvar for eventuelle fejl eller nedbrud.
Det betyder dog ikke, at der ikke er nogen support eller hjælp at få. Mange open source projekter har aktive fællesskaber af brugere og udviklere, der kan hjælpe med at løse problemer, og for de større og mere etablerede projekter, er der også mulighed for at købe kommerciel support og services fra professionelle aktører.
I tillæg er det vigtigt at huske på, at etablerede open-source-projekter ofte bruges globalt, og mange mennesker er afhængige af, at løsningerne fungerer. Derfor vil der også være hjælp at få eller hjælp at købe.
Desuden giver open source software dig mulighed for selv at rette fejl og forbedre softwaren, hvilket ikke er en mulighed med de fleste kommercielle produkter.
Det er selvfølgelig vigtigt at være opmærksom på disse forskelle og foretage en grundig analyse, inden man beslutter sig for at bruge open source software i en kommerciel sammenhæng.
Skaleringsproblemer
- Det kan være udfordrende at skalere til meget store systemer eller organisationer.
Det er en misforståelse, at skaleringsproblemer skulle være specifikke for open source-software. Om software er skalerbart, har intet at gøre med, om det er open source eller ej. Det kobles i højere grad til softwarens arkitektur og design. Men ja, ligesom enhver anden type software, kan der være udfordringer forbundet med skalering af open source-software. Skaleringen kan være en teknisk udfordring, afhængig af softwarens arkitektur og design. Men det er vigtigt at bemærke, at mange open source-løsninger er designet til at være yderst skalerbare og bruges netop i meget store systemer og organisationer.
Udfordringen kan også være organisatorisk, da implementeringen i en større skala kræver koordinering, kompetenceudvikling og muligvis kulturelle ændringer. Det kan være nødvendigt at have adgang til passende teknisk ekspertise, enten internt eller gennem eksterne leverandører, for at sikre en succesfuld implementering og drift.
I OS2-fællesskabet har vi fokus på, at der tages højde for skalering fra starten, og der samarbejdes om at sikre, at løsningerne kan håndtere de krav, der stilles i en større skala.
Kompleks licensstyring
- Nogle open source-licenser kan være komplekse og svære at forstå og overholde.
Ja, nogle open source-licenser kan være komplekse og kræver omhyggelig styring for at sikre, at man overholder alle betingelser. Det er imidlertid vigtigt at bemærke, at langt de fleste open source-projekter bruger standardlicenser som GPL, MIT eller Apache, som er velkendte og bredt forståede i softwarebranchen. Derudover findes der værktøjer og ressourcer, der kan hjælpe med at håndtere licensstyring. Det er selvfølgelig afgørende at forstå licensbetingelserne, inden man integrerer open source software i sine projekter, ligesom man ville gøre det med kommerciel software.
I OS2-fællesskabet har vi adgang til viden om open source licenser og kan hjælpe med at skabe overblik og forståelse for de licenser, som indgår i en softwarepakke.
Det er også vigtigt at bemærke, at stort set alt software indeholder open source projekter. Selv kommerciel software gør brug af open source, og her har du ikke indsigt i, hvilke licenser leverandøren har indlejret i deres software, med mindre leverandøren kan levere en såkaldt Software Bill Of Materials (SBOM).
Afhængighed af fællesskabet
- Udviklingen og vedligeholdelsen afhænger af fællesskabets engagement og ressourcer.
Ja, det er korrekt, at udviklingen og vedligeholdelsen af open source-software afhænger af fællesskabets engagement og ressourcer. Dette er både en styrke og en udfordring ved open source. Det er en styrke, fordi det betyder, at mange forskellige mennesker og organisationer bidrager til udviklingen og forbedringen af softwaren. Det er en udfordring, fordi det kan betyde, at hvis fællesskabet mister interessen eller ressourcerne til at opretholde et projekt, kan det blive forladt eller forældet. Men mange open source-projekter har robuste, aktive fællesskaber og mange forskellige bidragydere, hvilket hjælper med at sikre deres fortsatte sundhed og succes. Det er også det faktum, at et stykke software er open source, som er med til at sikre, at bidragydere kan udskiftes, og manglende interesse fra en bidragyder kan føre til en blomstrende interesse fra den næste. Omvendt er den samme risiko til stede i kommerciel og lukket software. Hvis leverandøren oplever, at kundegrundlaget (interessen) forsvinder, vil de højst sandsynligt stoppe med at prioritere udviklingen og med tiden udfase produktet. Her vil det ikke være muligt for en ny bidragyder at træde til, fordi der er tale om proprietær software.
Mangel på professionel dokumentation
- Dokumentation kan være mangelfuld eller ustruktureret sammenlignet med kommercielle produkter.
Ja, det kan være korrekt, at nogle open source-projekter ikke har samme niveau af professionel dokumentation som kommercielle produkter. Kvaliteten og mængden af dokumentation kan variere meget fra projekt til projekt. Det gør sig gældende uanset om der er tale om open source eller proprietær og kommerciel software. Efterspørgslen i markedet dikterer mængden og kvaliteten af dokumentation. Det er vigtigt at bemærke, at mange open source-projekter har omfattende og detaljeret dokumentation, ofte langt bedre end hvad man ellers ser. Derudover er den åbne og samarbejdende natur i open source fællesskaber med til at sikre, at mangler eller fejl i dokumentationen ofte bliver identificeret og rettet hurtigt.