Workshop – öppen källkod på Trafikverket

Workshopen genomfördes i Stockholm den 13 april 2022 i syfte att diskutera hur Trafikverket kan bygga förmågor, skapa strukturer för att nyttja öppen källkod och kollaborativt delta i öppna innovationsprocesser för att påskynda Trafikverkets digitala transformation. Deltagarna bestod av personal på Trafikverket som diskuterade frågeställningen i grupper för att hitta möjliga lösningar på hur organisationen kan vara delaktig i öppna innovationsprocesser och ta del av kunskap, resurser, utbyta idéer och lösningar med aktörer (born digital) i det digitala och öppna källkod ekosystemet. Innan deltagarna påbörjade grupparbetet presenterades en övergripande beskrivning av öppen källkod ekosystemet och hur kollaborativt samarbete bedrivs för att skapa en enhetlig bild av hur öppen digital teknologi och standarder utvecklas i kollaborativa samarbeten. Följande stycke sammanfattar presentationen av öppen källkods ekosystemet. I nästföljande stycke följer en sammanfattning av resultatet och möjliga lösningar som grupperna presenterade.

Presentation av öppen källkod ekosystemet

De flesta öppen källkodsprojekt drivs av idéburna organisationer så som exempelvis Apache, Eclipse och Linux Foundation. Som icke vinstdrivande organisationer finansieras de av en kombination av donationer, bidrag, frivilligarbete och medlemsavgifter på individ- och företagsnivå. De större öppen källkodsorganisationerna förvaltar ett stort antal projekt med hjälp av väldefinierade riktlinjer, principer och regler som företag och individer måste tillgodogöra sig för att bli en fungerade community medlem. Organisationsformen idéburen-ideell verksamhet passar väl med det kollaborativa samarbetet som utgår ifrån kollektivt ägarskap och kooperativt nyttjande av medel på ett kreativt, innovativt och produktivt tillvägagångssätt för ett gemensamt mål. Community och frivilligarbete grundar sig på inre motivationsfaktorer såsom personlig utveckling, passion att lära, vara del av något större och grupptillhörighet. Frivilligheten, passionen och möjligheten att utforska tillsammans med andra kan i många fall vara starkare än externa motivationsfaktorer, som exempelvis belöning, status eller undvikande av bestraffning för att uppnå mål och resultat. Öppen källkodsprojekt drivs av meritokrati, tillit, inkluderande kultur och transparens, vilket möjliggör utveckling av mjukvara med hög mognadsgrad, skalbarhet, anpassningsbarhet, säkerhet och hög innovationsgrad när privatperson, företag, universitet och institutioner kollaborativt samarbetar.

För att utveckla mjukvara finns det en väl utarbetat distribuerad iterativ utvecklingsmetodik som förfinats under decennier. Utvecklingsmetodik för livskraftiga öppen källkodsprojekt består av dokumentation, riktlinjer och guider om hur man deltar, uppförandekod, licens som reglerar vidareutnyttjande (copyleft), ärendehanteringssystem för buggar-förbättringar, diskussionsforum för löpande dialog och en styrgrupp bestående av deltagande personer och organisationer. Bevis på att utvecklingsmodellen fungerar är exempelvis att fler än 14 000 utvecklare och 1 400 företag har bidragit till Linux kärnan (operativsystem) sedan 2005 som drivs av Linux Foundation. Bilden nedan är från en studie¹ av deltagarnas sinnesstämning i Linux kärnans mejllista och hur förändringar i projektet påverkar deltagarnas motivation. Bilden åskådliggör strukturer av ett projekt där det finns olika typer av roller och processer för att delta i den kollaborativa utvecklingen. Rollerna består av contributor som är vanliga bidragare – ofta enskilda personer, committer större bidragare – ofta organisationer, samt maintainers och lead maintainers som ansvar för integration av kod som deltagarna bidrar med för olika moduler och drivrutiner i Linux kärnan. Maintainers – förvaltare/underhållare säkerställer att koden håller tillräcklig hög kvalitet och borgar för att koden i modulen kan integreras med det övriga systemet. När tidsfristen att bidra med kod för innevarande version är slut, börjar förvaltarna att integrationstesta moduler och bygga betaversionen av operativsystemet. Därefter börjar alla aktörer som bygger program och system att integrationstesta att deras mjukvara fungerar med senaste Linux kärnan. Exempelvis programpaketets distributörer (Linux Distributions) som Ubuntu, Red Hat och Suse. Utvecklare av fönsterhanteringssystem (Window Managers) såsom Gnome och KDE. Samt programutvecklare som LibreOffice, Mozilla och Spotify att testa att deras program är kompatibelt med kommande versioner av operativsystemet. Slutligen är det lead maintainer – tillika projektledaren, som bestämmer om versionen håller tillräckligt hög kvalitet och är mogen att släppas som officiell version. Linus Torvalds är den mest kända öppen källkodsförvaltaren.

All mjukvara, program och IT stödsystem innehåller buggar och säkerhetshål. Diskussionen om öppen eller proprietär källkod är det säkraste alternativet är oftast ideologisk eller bygger på gamla föreställningar som enbart bidrar till att försena eller utgöra hinder för en digital transformation. Oavsett om det är öppen eller proprietär mjukvara behöver verksamheten insamla fakta om hur programvaror eller IT-stödsystem är uppbyggda. Exempelvis behöver verksamheten ha kunskap om vilka mjukvarukomponenter programmet eller IT-stödsystemet är beroende av, hur snabbt säkerhetshål korrigeras, hur licenserna som mjukvaran kommer med påverkar möjligheten att lösa säkerhetshål som identifieras när program och system tagits i drift med mera.

För att underlätta faktainsamlingen finns det flera initiativ som sammanställer och samlar in underlag från forskare, utvecklare, säkerhetsexperter och användare. Exempelvis driver Google ett program som heter Project Zero som samlar in kritiska säkerhetshål från forskare och säkerhetsexperter. Från tidpunkt när säkerhetshålen identifieras räknas antalet dagar innan de korrigeras och görs tillgängliga för användare. Korrigeras inte buggarna inom en bestämd tidsperiod publiceras säkerhetshålen offentligt för att sätta press på systemleverantörer och mjukvaruutvecklare. Listan nedan visar den genomsnittliga tid det tar för mjukvaruutvecklare och företag att, enligt Project Zeros rapport från 2021, rätta till allvarliga säkerhetshål i öppen och proprietär källkod.

En skillnad mellan öppen och proprietär mjukvara är att öppen källkod kan genomlysas och kontrolleras för att identifiera potentiella säkerhetshål och beroenden av tredjepartskomponenter innan det införskaffas och sätts i drift. Detta är inte möjligt vid införskaffande av slutna IT-system, istället måste verksamheten lita eller avtalsreglera ansvar och skyldigheter med systemleverantören. Exempelvis införskaffade Coop ett kassasystem från Visma EssCom, troligtvis utan vetskap om att de i sin tur nyttjade tredjepartskomponenter från en annan systemleverantör som heter Kaseya, för att fjärrstyra och uppdatera kassasystemet. Mjukvaran från Kaseya innehöll allvarliga säkerhetshål vilket ledde till att kassaapparater kapades av hackare som krypterade all data i systemet och utpressade Coop på stora summor pengar för att återställa systemet. Detta ledde till stora inkomstbortfall och kostnader för Coop som fick stänga och installera en uppdaterad version i alla butiker.

Log4Shell kallades ett säkerhetshål i öppen källkod komponent för att skriva meddelanden till systemloggen som heter Log4j. Komponenten härstammar från 2001 och används fortfarande av ett antal få systemlösningar och kunde utnyttjas för att exekvera skadlig kod via externa anrop. Säkerhetshålet i Log4J manifesterar exempel på utmaningar kopplade till öppen källkod ur flera aspekter. En av dessa är underfinansiering av öppen källkodsprojekt ,som i fallet med log4j, som under två decenniers tid underhölls och utvecklades av några få programmerare som aldrig fått ersättning för sitt arbete. En annan aspekt är att verksamheter som använder komponenten inte granskar och utvärderar öppen källkodslösningar i tillräcklig utsträckning, utan lämnar över detta strategiska beslut till utvecklare. Detta kan äventyra cybersäkerhet och skapa problem som påverkar verksamhetens systemarkitektur, vilket kan få stora ekonomiska konsekvenser.

Vid val av öppen källkodslösningar är det viktigt att välja projekt där det finns tillräckligt många utvecklare och verksamheter som deltar för att säkerställa livskraftighet och vidareutveckling. Det finns ett stort antal parametrar som projektdokumentation licens, riktlinjer, målsättning, utvecklingsmetodik, deltagarfrekvens, uppförandekod, diskussionsforum, kodhanteringssystem med mera som avgör projektens livskraftighet. För att välja rätt öppen källkodsprojekt behöver verksamheten bygga egna förmågor eller samarbeta med aktörer som har kompetens att utvärdera öppna källkodslösningar och komponenter. Verksamheter som är delaktiga i öppen källkodsprojekt har oftast personer med kompetens att hantera relationen med öppen källkods ekosystem för sköta ingående och utgående innovationsprocesser för att främja den egna konkurrenskraften. Denna verksamhetsfunktion benämns Open Source Program Office (OSPO) och digitala aktörer (born digitals) som exempelvis Google, Spotify och Amazon, har egna team som jobbar med att hantera relationen med öppen källkods ekosystem. Det är betydelsefullt för att sköta innovationsprocesser och kunskapsutbyte med en heterogen grupp digitala aktörer som ingår i det digitala ekosystemet.

Det finns en problematik i att många nyttjar gratis mjukvara och öppen källkod utan att reflektera över livskraftighet eller stödja utvecklingen för systemkritiska mjukvarukomponenter. Teckningen nedanför illustrerar en skämtteckning om den otacksamma roll och bristande erkännande som utvecklare ibland har.

Presentation grupparbete

Workshopen innefattade ett grupparbete som problematiserar hur Trafikverket som traditionell verksamhet skulle kunna vara delaktig i öppna innovationsprocesser för att utbyta kunskap, resurser och idéer med aktörer i det öppna källkods ekosystemet. Som utgångspunkt inför grupparbetet presenteras ett antal påståenden för att definiera transportsystemet och beskriva några av de karakteristiska drag som utmärker en bransch där Trafikverket verkar. Dessa påståenden var följande:

• Trafikverket är en funktionsindelad hierarkisk verksamhet som består av processflöden som inte enkelt och snabbt kan ändras
• Transportsektorn är en traditionell bransch som dikteras av avtalsreglerade samarbeten med långa upphandlingsförfaranden och leveranser
• Traditionella verksamheter behöver genomgå radikal kulturell och strukturell förändring samt upparbeta nya förmågor för att möjliggöra en digital transformation

För att bryta ner den övergripande frågeställningen fick arbetsgrupperna mer specifika frågeställningar som stöd för att komma med förslag på verksamhetsförändringar och initiativ som bidrog till delaktighet i det digitala ekosystemet. Dessa frågeställningar var följande:

• Hur kan resurser, strukturer, förmågor och kultur förändras/upparbetas för att möjliggöra Trafikverkets delaktighet i digitala ekosystem och öppna källkodsprojekt ?
• Vilka administrativa processer, styrning, upphandlingsrutiner och praxis måste förändras om Trafikverket skall vara med att bidra med resurser och finansiering av öppen digital teknologi och standarder?
• Är existerande styrning, reglering och direktiv redan anpassade eller är det kulturen som begränsar Trafikverkets möjlighet att delta i öppna innovationsprocesser och öppen källkodsprojekt?

Följande redogörelse är en sammanställning av några av de lösningsförslag som grupperna presenterade och som dokumenterades av workshopens moderator. Deltagarna var indelade i tre grupper bestående av fyra till fem personer, och benämns som grupp 1–3 nedan.

Sammanfattning gruppresentation och diskussion

Samtliga grupper betonade att nuvarande verksamhetskultur och praxis utgör ett hinder för att använda och delta i öppen källkodsprojekt när det gäller anskaffningsprocessen av programvara och systemstöd. Grupp 1 betonade att upphandlingsförfarandet inte är nödvändigt vid anskaffande av öppen källkod eftersom den är gratis att använda. Samtliga grupper poängterar att verksamheten måste ställa om från upphandling av licenser av standardiserade systemlösningar baserat på funktionalitet, och istället upphandla eller anställa kompetens att vidareutveckla öppen källkodslösningar. Som en konsekvens har Trafikverket inte tillräckligt med egna resurser att delta i det kollaborativa samarbetet för att vidareutveckla, anpassa och driva öppen källkodslösnigar. Grupp 2 argumenterade för att hela anskaffningsprocessen av programvara och IT stöd måste ses över för att skapa förståelse om allmännyttan med öppen källkod som en kostnadseffektiv lösning genom att dela resurser, kunskap och minimera risker vid utveckling av gemensamma systemlösningar och mjukvarukomponenter. Baserat på att den digital utvecklingen till stor del drivs av öppen källkod uttryckte grupp 2 en förhoppning om att upphandlingar av systemlösningar och programvara borde prioritera öppen källkod som ett kostnadseffektivt alternativ och för att undvika inlåsningseffekter.

Grupp 1 framhöll att det inte finns någon ansvarig för öppen källkods frågor, funktioner och styrning på Trafikverket. Det finns inga styrdokument eller policy som nämner öppen källkod som alternativ till proprietär teknologi, slutna systemlösningar och standarder. Grupp 3 beskriver det som att ledningen och cheferna inte förstår nyttan av öppen källkod. De beskriver att de personer i verksamheten som verkar för förändring och är pådrivande av initiativ för öppen källkods på Trafikverket inte får gehör från ledning eller chefer. Gruppen lyfter också problematiken med att mjukvaruutveckling bedrivs genom projektfinansiering, vilket skapar hinder för kontinuerligt utveckling och förändring. Förvaltningsmodell och projektstyrning beskrivs som stuprörsformad och rigid, vilket försvårar möjligheten att tillvarata möjligheter att samarbeta eller tillämpa ny teknologi. Eftersom alla aktiviteter måste vara planerade och budgeterade långt i förväg. Detta skapar hinder för innovativa initiativ och möjligheten att skapa synergier med andra aktörer som är mer snabbfotade och besitter strategisk flexibilitet att arbeta mer kundorienterat. För att förändra Trafikverkets hierarkiska och stuprörsformade verksamhet diskuterade mötesdeltagarna möjligheten att gå mot en agil utvecklingsmetodik, som exempelvis SAFe modellen som används på Skatteverket.

Grupp 3 argumenterade för att fler FOI projekt och medel skall finnas tillgängliga för experimentell utveckling för att bygga förmågor internt samt möjliggöra kunskapsutbyte med andra aktörer i transportsystemet och det digitala ekosystemet, som på sikt kan leda till innovation och synergieffekter. Idag finns, enligt gruppen, inga processer och strukturer för att ta vara på kunskap som upparbetas. Mycket av den kunskap och förmågor som upparbetas via forskning och utveckling försvinner när projekten är slut. En annan aspekt av den bristande kunskapshantering, är för projekt som misslyckas eller inte når sina mål, men där det finns många lärdomar att föra vidare till nya initiativ. Detta är viktigt för att inte riskera grupptänkande eller ensidig argumentation angående idéer eller teknologi som kanske inte var moget vid ett specifikt tillfälle, men som är värt att utforska vid en senare tidpunkt. Grupp 2 framförde argumentation för att konkurrensutsätta det ensidiga upphandlingsförfarandet av standardiserade IT-system från leverantörer som inte håller måttet, eller kan leverera tidsenliga lösningar som nyttjar öppen teknologi och standarder.

Öppen källkod används redan på Trafikverket i from av gratisprogram och digital infrastruktur (linuxservrar) där det finns formella processer vid anförskaffande av öppen källkod. Men vid utveckling av öppen källkodslösningar och programvarubibliotek finns det inga formella strukturer, processer eller rutiner vid förvaltning och vidareutveckling. Detta kan leda till oförutsedda kostnader och beroenden till systemleverantörer som vill sälja in öppen källkodslösningar som inte borde klassificeras som öppen källkod. För att kvalificeras som öppen källkod räcker det inte att systemlösningen finns tillgänglig på exempelvis Github eller Gitlab. För att vara ett livskraftigt öppen källkodsprojekt behöver det vara väl dokumenterat, riktlinjer för deltagande, uppförandekod, öppen källkodslicens som skall tillämpas och att projekt inte drivs utifrån en enskild aktörs egennytta. Grupp 3 exemplifierar denna problematik med Trafikverkets införskaffande av det som systemleverantörer kallar för öppen källkodslösning för hantering av metadata som fanns tillgänglig på Github. Öppen källkodslösning visade sig omöjlig att underhålla och vidareutveckla på grund av flera faktorer såsom bristande dokumentationen samt att projektet utvecklades av ett enskilt bolag med intresse att sälja lösningen till offentliga verksamheter. Utvärdering uppskattades att kostnaden skulle vara stora för att integrera öppen källkodslösningen med övriga systemlösningar på Trafikverket. Projektet fick avbrytas då det fanns uppenbara risker för inlåsningseffekter och beroende av det enskilda bolaget som skulle förvalta och utveckla systemlösningen. Detta är sekundära uppgifter från en individ i grupp 3 som var involverad men inte ansvarig för utvärderingen.

Senast uppdaterad 2024-03-01