Hvorfor interessere sig for hvad der gemmer sig under hjelmen på et installeret IT-system? Kildekode og teknologi er for nørder og ikke noget, vi som kunder behøver forholde os til? Sådan tænkte man måske før i tiden. Men så fandt man i kommunalt regi på at stille krav til samarbejdsformen som værende open source. Og hvor var det dog et klogt træk.
Blogindlæg af Morten Hoffmann, CEO ved STRONGMINDS
#1 Kvalitet
For nogle er ønsket om at springe over, hvor gærdet er lavest og lange en hastigt sammenklistret løsning over disken et quickfix, som kan synes attraktivt. Lad os med det samme rydde denne mulighed af bordet ved at insistere på, at løsningerne vi arbejder på, skal kunne tåle dagens lys. Gennemsigtigheden i open source-software gør det muligt for kunder, leverandører og andre interessenter at inspicere arbejdet, som det skrider frem.
Bemærk, at det ikke er nødvendigt, at du som OS2-kunde selv står for inspektionen. Du kan trække på hjælp udefra og få fagfolk til at vurdere kvaliteten af det produkt, du tænker at investere i, eller måske allerede har investeret i og nu vil sikre, er i trygge leverandør-hænder.
Men det behøver ikke være så bagudskuende og negativt. Sørger du løbende for at opsamle open source-erfaringerne på tværs i guidelines, vil både nuværende og kommende leverandører få glæde af indsigterne i hinandens systemer. På den måde startes en positiv spiral hvor højnelse af kvaliteten sker løbende og allerede ved formuleringen af krav i udbudsfasen.
#2 Sikkerhed
Tæt forbundet med observationen omkring øget kvalitet i open source-software, er sikkerhed. Det er klart, at skal du udstille kildekoden til de kørende IT-systemer, kan du som IT-leverandør ikke benytte tricks som f.eks. at gemme kodeord eller nøgler i koden selv. Du er nødt til at flytte informationen ud et sikkert sted, adskilt fra kildekoden. Sådanne mønstre opstår naturligt af at skulle spille med åbne kort.
Skulle du, trods omhu og grundig udvikling, have offentliggjort kode som kan knækkes, ja, så kræver det selvfølgelig en hurtigere reaktionstid. Endnu et incitament til at gøre sig virkelig umage. Det er aldrig rart at skulle arbejde under pres og på ubelejlige tidspunkter.
Det er positivt, at ikke kun leverandøren kan hjælpe til med at lukke hullet. Også andre leverandører - måske nogle med sikkerhed som ekspertise - kan indgå i præventive samarbejder med sikkerhedscheck før større releases.
#3 Økonomi
Man hører flere steder sammenligningen mellem en bil og open source. Open source tillader, at motorrummet åbnes, og motorens dele kan inspiceres, og måske repareres eller udskiftes på stedet. Proprietær kode derimod, har ingen kølerhjelm. Hvis bilen rammes af motorproblemer, må ejeren køre på værksted og håbe på det bedste.
Bindingen til leverandøren er selvfølgelig nøglen her, og der er ingen tvivl om, at manglen på konkurrence kan påvirke prisen på løsningen over tid.
Overblikket over motoren giver også mulighed for at reflektere over, om en original komponent kan erstattes af en anden tilsvarende, men billigere. F.eks. kan en traditionel MS*SQL server med tilhørende licens måske erstattes af en anden og mere prisbillig komponent (PostgreSQL, MySQL, MariaDB eller andre).
En hage ved at køre på forskellige værksteder og ”shoppe rundt” er selvfølgelig, at mekanikeren ikke rigtig kommer til at lære bilen og dens skævheder at kende, men denne observation giver måske også grund til selvinspektion, og måske kan fremtidige samarbejder have glæde deraf? Og du skifter vel kun værksted, når utilfredsheden bliver tilstrækkelig stor, idet omkostningerne ifm. skiftet er store. Driftsaftaler skal genforhandles, nye folk skal oplæres og en ny byggeplads etableres (f.eks. build pipelinen, som typisk ikke er open source).
Ved leverandørskift opstår også spørgsmål omkring ansvarsfordeling, men denne type spørgsmål er igen reaktive, og vi ønsker netop at skifte fokus, så vi i samarbejdet tænker proaktivt og ikke i ender i blame-game. Og hvad er et bedre udgangspunkt end et åbent, uden skjulte afkroge?
#4 Teknik
Når åbenheden sætter gang i teknologiske genovervejelser, er der også en hage, som ligger indgroet i valget af teknologistak. Du kan i starten af projektets levetid træffe beslutninger som kun vanskeligt, og med store omkostninger, er svære at gøre om. Udvikles et softwareprojekt f.eks. på en Windows-platform og med traditionelle tools/sprog (f.eks. .NET 4.6.1 og tidligere), kan en senere beslutning om at flytte til Linux koste dyrt.
Hvis du derimod fra start gør det klart, at projektet skal udvikles med cross-platform for øje, kan leverandøren vælge en værktøjskasse, som gør dette muligt (f.eks. .NET Core).
I det hele taget stiller åbenheden krav til omstillingsparatheden og modenhed for alle i samarbejdet. Der skal være procedurer og retningslinjer for f.eks. bug-reports, bug-fixes og releases, kildekode repos håndtering ved forgreninger osv. osv.
Men alle disse krav er til det gode – ved at blotlægge det, som er svært og blive bedre til håndteringen af udfordringerne, løfter vi projekternes samlede kvalitet og værdi.
#5 Governance
I takt med at flere og flere open source-produkter meldes ind i OS2-fællesskabet åbnes også op for muligheder med genbrug på tværs.
Igen er det en styrke, at vi kan kigge ind i de forskellige løsninger for at se fællestræk og udvinde nye delte komponenter. Det kræver blot, at vi er i stand til det, og gør det – governance.
Ved at lade alle leverandørerne indgå i et fællesskab, hvor vi kan se hinandens løsninger nudges også løsninger frem, som fra fødslen af kan være ”kompatible”.
What’s not to like?
---------
STRONGMINDS er et aarhusiansk udviklingshus og har i løbet af sommeren 2019 fået tildelt ansvaret for videreudviklingen af det mest udbredte af OS2 produkterne, OS2kitos.
Foto fra Hosea Georgeson på Unsplash.com