Hvad handler det blandt andet om...

En kommune, vi havde holdt en del møder med og hjulpet i gang med OS2borgerPC, fortalte os, at de havde fået et tilbud fra en anden leverandør af OS2borgerPC på ret præcist halvdelen af vores pris for drift og vedligeholdelse.

 Jeg troede simpelthen ikke på det først, men efter at have spurgt rundt, fandt jeg ud af, at den anden leverandør var samme virksomhed, som OS2 havde betalt for at lave code review på netop OS2borgerPC. 

En leverandør, som vi har hjulpet til at forstå OS2borgerPC i dybden, men som aldrig har leveret en linje kode til OS2borgerPC, og som vil hente løsningen, placere den på en server og tilbyde at drifte en kommunes borgerPC'er. 

På OS2’s produkter er der altid en ‘maker’ - en udvikler-virksomhed. Er maker-virksomheden dygtig til at dokumentere og delekildekode, og det er Magenta, så opstår der ofte en ‘taker’ - en freerider-leverandør, der downloader maker–leverandørens kode og tilbyder drift til kunderne til en lavere pris. 

Den ultimative konsekvens er, at maker-virksomheden ender med at blive udkonkurreret, og så er produktet dødt. Alle taber - også kommunerne.

Vi bliver nødt til at tale om den - elefanten i rummet. 

Den hedder også freeriding eller maker-taker-dilemmaet. Den handler om, at alle ender med at tabe, når man accepterer, at nogle leverer, mens andre lukrerer. 

Elefanten næres af en manglende forståelse for, hvordan man driver en open source forretning og af et tilsyneladende umætteligt behov for at presse priserne ned. 

Og nu, hvor kommunerne sjældent har held med at presse de større leverandører på priserne, får skruen en ekstra omgang over for de mindre leverandører.

Drømmen om uafhængighed 

Hvor ville det være besnærende: Små open source-leverandører på to-fire-seks medarbejdere, der alle knoklede for at levere det samme kvalitetsprodukt til kommunerne. Der på deres side shoppede rundt for at få det til enhver tid “bedste og billigste tilbud”, som det hedder på ‘udbudsk’. 

Og det hele var muligt, fordi alle løsninger ville være plug-and-play og nemme at bygge for andre leverandører og for kunderne, fordi alt ville være veldokumenteret, struktureret og lige til at hive ned af hylderne på internettet (GitHub). Det er en dejlig tanke, ikke? 

Men det er en model, der meget sjældent fungerer i virkelighedens verden - uanset hvor meget OS2 skriver ind i hensigtserklæringer og målsætninger, at ethvert produkt som minimum skal have to leverandører, og at alt skal kunne bygges hjemme på den kommunale matrikel, så vi får den totale leverandørfrihed. Og hvorfor det? 

Hovedsagelig af to grunde: 

Penge 
Et kvalitetsprodukt koster penge. Det er blevet tydeligt i udbudsmateriale generelt - kvalitet vægter mere og mere. I mange softwareudviklingsfirmaer er principper som shift-left (https://en.wikipedia.org/wiki/Shift-left_testing) og forebyggende vedligehold i højsædet, fordi det mindsker tilbageløb og højner kvaliteten. Det koster penge. Desuden kommer kvalitet ikke uden et tæt samarbejde mellem kunde og leverandør og uden et højt niveau af forretningsforståelse. Og jo flere timer, der skal lægges i disse aspekter af softwareudvikling, jo flere penge koster det. Det er virkelighedens verden, så hvordan skulle en verden med bittesmå kommunale it-budgetter og tårnhøje krav til de små leverandører føre til det leverandøruafhængige Nirvana? 

Skævhed i leverandørforholdet 
Markedet består ikke af ligeværdige virksomheder, der alle bidrager. Nogle er ‘makere’ (producenter), og nogle er ‘takere’ (freeriders). Når nogle bidrager og andre lever af bidragydernes kvalitetsarbejde, så nærer det ikke samarbejde og åbenhed. Ræset mod bunden er begyndt. Først dør ‘makeren’ af mangel på finansiering, dernæst dør produktet af mangel på ‘makeren’, og til sidst står ‘takeren’ i ensom majestæt, alene tilbage og falder som det sidste træ i skoven. 

Jeg tager de to punkter ét ad gangen:

I Magenta arbejder vi agilt og benytter scrum-rutiner med daglige standups, planlægning i sprints og en tæt - når det er bedst - dialog med kunderne. 

Vi frigiver kode hyppigt, tester og får feedback, og vi har en intern review-proces, der sikrer, at kode ikke kommer i test eller produktion, før mindst én anden udvikler har reviewet koden. 

Den ideelle team-størrelse kan man diskutere, og det bliver det - diskuteret altså. Men ingen, der kender til softwareudvikling, er uenige om, at et team på færre end tre udviklere ikke kan fungere. Fordi: 

● med færre end tre udviklere bliver et team uarbejdsdygtigt ved sygdom og fravær. Der mangler helt enkelt en reviewer og en tester. 

● med færre end tre udviklere vil en opsigelse fra en medarbejder amputere teamet i lang tid, og der er stor risiko for, at den tilbageværende udvikler, der er alene i længere tid, finder andet arbejde. 

● et team på færre end tre har svært ved at mønstre den arkitektur-kompetence, der også skal være til stede, hvis teamets løsninger skal udvikle sig. 

Min erfaring siger, at fem til ni teammedlemmer er optimalt, for så er der plads til dedikerede roller til: 

● arkitektur 

● frontend arbejde og UX 

● test 

● drift og support 

● infrastruktur og udrulning (fx. Kubernetes og Docker) 

● projektledelse og kundekontakt 

Men færre end fem kan gøre det. Det kan færre end tre udviklere imidlertid ikke. Og skal der koordineres, laves governance på kunder, opgaver og kode, så skal der også tilknyttes en projektleder.

Hvor går grænsen for økonomien i et kvalitetsprodukt? 

Inkl. overhead koster en it-udvikler med 3-5 års erfaring mellem DKK 700.000 og 900.000. Og det samme gør en projektleder. Lad os sige 750.000 for ikke at presse regnestykket. Tre udviklere og en projektleder koster altså 3 mio., før der er overskud. 

Skal vi tilbage til den ideelle verden, hvor alle virksomheder bidrager og gør deres bedste, så skal der være et økonomisk grundlag på minimum 6 mio. kr. (2 virksomheder à DKK 3 mio.), før det overhovedet begynder at give overskud. Og dette er under den forudsætning, at begge virksomheder udvikler, gør sig overvejelser om arkitektur, integrationer, roadmap osv. 

Men sådan ser virkeligheden ikke ud. På ingen af OS2’s produkter er der to blot tilnærmelsesvis ligeværdige leverandører. Der er enten kun én leverandør, eller også er der en ‘maker’ - en udvikler-virksomhed - og en ‘taker’ - en freerider-leverandør, der downloader maker–leverandørens kode og tilbyder drift til kunderne til lavere pris. Ofte så lav en pris, at det er umuligt for den samvittighedsfulde leverandør at konkurrere og vedligeholde den kode, som er afgørende for, at kunderne fortsat har en god oplevelse med OS2-produktet. 

Konsekvensen er, at maker-virksomheden ender med at blive udkonkurreret, og så er produktet dødt. Det sander til, bliver uanvendeligt, sårbarheder hober sig op, og til sidst er det udsultede produkt i så sølle en forfatning i forhold til de proprietære løsninger, at ingen vil have det. Og så taber alle. De små leverandører må dreje nøglen om, gode open source produkter forsvinder, og kommunerne i OS2 er tilbage ved udgangspunktet: De er i kløerne på de store udbydere, der leverer alt andet end open source.

OS2datascanner som case 

Lad mig tage et eksempel fra vores, Magentas, verden. 

OS2datascanner havde en svær opstart. I årene 2020-22 har vi som virksomhed investeret mellem DKK 3 og 4 mio. i at få OS2datascanner til at blive det modne produkt, det er i dag. Ingen udover os selv troede for alvor på, at der var et behov for et bredt anvendeligt GDPR-værktøj, der både kan hjælpe kommunerne med at rydde op i data, og som kan levere statistik og rapporter til kommunernes revision og dermed afløfte nogle af de krav, som følger i kølvandet på forordningen om databeskyttelse (GDPR) og NIS2. 

I dag har vi imidlertid en situation, hvor kommunerne nikker anerkendende til løsningen, og Magenta er næsten break even i forholdet mellem indtægter og udgifter. 

Og så skulle man tro, at den gode historie for alvor kunne begynde. Men det er ikke tilfældet. Vi møder kritik fra OS2's bestyrelse for ikke at tilbyde en så billig driftsaftale med mulighed for tilkøb af vedligeholdelse og udvikling, at det knap nok kan brødføde én enkelt udvikler. Teamet består af tre fuldtidsudviklere, to studenter og en projektleder. 

Argumentet fra bestyrelsens side er, at der altid bør være mindst to leverandører på samme produkt, for så skabes der konkurrence. Jeg er helt og aldeles enig i dette synspunkt - når der er tale om store løsninger med mange udviklere, sælgere, projektledere, arkitekter - og alt det andet rundt om større løsninger. 

Men når der er tale om et lille produkt, der lige har fået hovedet over vandoverfladen økonomisk, og som kun har få udviklere, så giver det ingen mening, og det er intet mindre end dødbringende. Og vi er forsvarsløse, for vi leverer åben kode, som alle kan kopiere. 

Det sker i dag med OS2datascanner, hvor en anden leverandør løbende henter den kode ned, vi udvikler, og tilbyder løsningen til en meget lav pris. Hvilket er muligt, fordi den anden leverandør aldrig bidrager med én linje kode. Det taber vi kunder på, og det svækker løsningen. 

Skal Magenta kunne tilbyde en løsning, der udvikler sig, og som holdes sikkerhedsopdateret og vedligeholdes, så sårbarheder fastholdes på et lavt niveau, kræver det, at vi har medarbejdere, der kender systemet, sådan at vi ikke skal bruge uanede mængder af overhead-timer på at oplære folk. 

Dette kræver, at vi løbende har tilstrækkeligt med opgaver til at fylde medarbejdernes tid ud, og at vi har folk siddende klar til at gribe opgaverne, når de kommer. Det, man betaler for i et abonnement, der inkluderer vedligehold, er jo netop hele pakken, alt hvad det koster at have mennesker ansat (ferie, fravær, opkvalificering osv), processer og procesoptimeringer, fx pipeline til deployment osv.

Hvert andet år bruger vi flere hundrede timer på opgradering til den seneste version af Ubuntu (Linux). Der er masser af ting, der skal konverteres, testes, gennemskrives osv. Oveni det er der den løbende support, dialog med kunder og brugere, oprettelse af nye brugere - og alt det som man får med, hvis man har en supportaftale med os. 

Vi har først i løbet af 2022 fået en positiv økonomi på løsningen, nu hvor OS2borgerPC anvendes af godt 30 kommuner. Ingen af dem har oplevet sikkerhedsissues som fx identitetstyveri, efter at de har fået OS2borgerPC. Og OS2borgerPC har stort set ingen sårbarheder. Hvorfor? Fordi koden vedligeholdes. Fordi udviklerne har tid til at rette sårbarheder og opdatere biblioteker, drivere, Python-programmer, Django-platformen under løsningen - alt det der skal håndteres dagligt, hvis løsningen ikke skal forvitre. 

Code review fører til en freerider-situation 
- med OS2’s opbakning 

Vi er loyale mod OS2. Vi skubber kommuner, vi er i dialog med, hen imod OS2 og opfordrer dem til at underskrive tilslutningaftalen, sådan at udviklingen kan koordineres. Derfor var vi i første omgang rigtig glade for, at koordinationsgruppen havde betalt en anden virksomhed for at foretage et review af koden, sådan at OS2borgerPC kunne blive løftet et niveau op i OS2's modenhedsskala. 

I Magenta er vi meget omhyggelige med at overholde OS2's kodeks, hvad angår upload af kode til OS2's GitHub, så snart vi releaser ny kode. Vi dokumenterer alt, og vi gør det nemt for andre at læse og forstå vores kode. Og samtidig brugte mine udviklerkolleger timer på at holde møder og hjælpe review-virksomheden med at forstå, hvordan OS2borgerPC, der er en ret omfattende løsning i dag, hænger sammen og fungerer. 

Maker-taker-problemet på OS2borgerPC 

Alt det gjorde vi i god tro. Derfor var min overraskelse desto større, da jeg af en kommune, vi havde holdt en del møder med og hjulpet i gang med OS2borgerPC, fik at vide, at de havde fået et tilbud fra en anden leverandør af OS2borgerPC på ret præcist halvdelen af vores pris for drift og vedligeholdelse. 

Jeg troede simpelthen ikke på det først, men efter at have spurgt rundt, fandt jeg ud af, at den anden leverandør til drift af løsningen var samme virksomhed, som OS2 havde betalt for at lave code review. En anden leverandør, som aldrig har leveret en linje kode til OS2borgerPC, men som vil hente løsningen ned, placere den på en server og tilbyde at drifte en kommunes borgerPC'er. 

Når vi så har udført en måneds vedligeholdelse, lavet nye sikkerhedsscripts, opdateret kodebiblioteker og sikret at OS2borgerPC fortsat fungerer på den nyeste hardware, og lægger en ny release op, ja så kan den anden virksomhed downloade vores arbejde på en time eller to - arbejde der andrager 100-150 timers vedligeholdelse - og tilbyde det til kunder, der slipper med halv pris i forhold til vores listepris, der skal dække vores arbejde. 

Sådan fungerer open source, hører jeg OS2 sige. Men nej, sådan fungerer open source faktisk ikke, hvis det skal blive ved med at være open source, veldokumenteret og nemt at gå til. En open source-udviklende virksomhed (en 'maker') kan ikke eksistere sideløbende med en free-rider, en 'taker'-virksomheds arbejdsfri profitering på maker-virksomhedens arbejde. 

Det er simpel økonomisk rationalitet, som er blevet påvist af blandt andet en nobelpristager (kildehenvisning, åbner i ny fane) og af mange andre økonomer. Det fungerer simpelthen ikke.

Vedligeholdelse er ikke et tilkøb - det er en grundlæggende forudsætning 

It-løsninger kan ikke udvikles en gang for alle, og så kan man planlægge nogle små 'vedligeholdelse-sprints' (ja, det er det ord, jeg ofte hører) hvert halve år, og så skal det hele nok gå. Sådan fungerer komplicerede it-løsninger ikke. Sådan fungerer stort set ingen løsninger i dag, hvor it er knyttet sammen på kryds og tværs, hvor integrationer til tredjepartssystemer bare SKAL fungere, hvis løsningen ikke skal være uanvendelig, og hvor fjendtlige hackingforsøg er dagligdag og ikke noget eksotisk. 

Alt dette koster penge. 
Og nej, det er ikke en løsning, at free-rider-virksomheden leverer ultrabillig drift, og at kunderne - kommunerne - så kan tilkøbe vedligeholdelse, når lorten rammer ventilatoren. Det er alt for usikkert, alt for tilfældigt og på ingen måde rimeligt. Og kommunerne orker det heller ikke. I realiteternes verden ønsker kommunerne løsninger, der fungerer. De ønsker et OS2borgerPC, der er sikkert, pålideligt, opdateret og i praksis ubrydeligt. Og det skal være nemt at anvende, nemt at lægge budget for løsningen og nemt at kommunikere med leverandøren. Og så skal de vide, at der er en plan for udvikling af løsningen, så den flytter sig med deres behov. 

Det leverer vi, og det kan vi kun, fordi vi er et team. To leverandører på et produkt - den ene skummer den daglige fløde, og den anden, der knokler for at holde produktet flyvende baseret på adhoc-økonomi. Er det sådan, det fungerer på løsninger fra KMD, Netcompany, IBM og de andre store leverandører? Nej. Og det kommer heller aldrig til at fungere på OS2's løsninger. 

Kvalitet koster 

Så hvad gør vi herfra? Jeg håber, der indfinder sig en erkendelse af, at kvalitet koster penge. Ønsker man ikke at betale det, det koster at holde en konkurrencedygtig løsning i luften, så får man, hvad man betaler for. Så sander løsningerne til, sådan som det senest er sket med OS2forms, som vi måtte trække os fra efter at have bygget en kostbar og egenfinansieret infrastruktur og deployment-pipepline. Uden infrastruktur og en effektiv kanal til deployment kan der ikke leveres den variabilitet, der er behov for, hvis en løsning effektivt skal kunne rulles ud til 10-20-30 kommuner. 

Fremtiden bliver, at en række små virksomheder med højst 5-10 medarbejdere kæmper om smulerne fra det bord, der ellers kunne blive rigt og fyldt med spændende open source-løsninger, der kan skaleres og anvendes i missionskritiske sammenhænge. Og som kunne hjælpe jer, kommunerne, med at bide skeer med de store closed source-leverandører. 

Det troede jeg egentlig var jeres vision med OS2. Men jeg ser visionen smuldre i disse år, og med den forsvinder de dygtige open source-virksomheder også. 

Og Magenta bliver en af dem.

Morten Kjærsgaard
Magenta
September 2023