Hur stor är nyttan av att öppna upp våra system?
Många typer av system/digitala tjänster som myndigheter utvecklar är relativt specifika för varje myndighet, och framförallt äldre system är ännu mindre generiska. Vi märker att vi inte ens har en gemensam syn på hur man ska beskriva ett ärende mellan myndigheter. Samtidigt ser vi att det finns tjänster som borde vara generiska och där vi borde kunna samutveckla både för att få bättre och kostnadseffektivare tjänster. När är det värt att öppna upp källkoden?
1 gillning
Jag tycker i och för sig att öppenheten har du värde i sig. Myndigheterna har ju också mycket gemensamt eller delar som inte behöver vara unika. Före kommer nog nyttan först tillsammans med att öppenheten i sig för med sig flera bra saker som tex transparens.
1 gillning
@bengtb, du som är arkitekt. Hur bör man tänka innan man designar en lösning. Jag kan tänka mig att många arvsystem kan kosta mer än vad det smakar att öppna upp, men när vi pratar nyutveckling 2020, borde vi inte kunna ta höjd för öppen källkod i designen? Alltså att man bygger lösningar som har åtminstone delar som kan återanvändas?
1 gillning
Har en känsla av att användarbarheten kan bli lidande, om ett system designas för alla leder det lätt till att det inte passar för någon. Däremot idén att dela källkoden som princip borde skapa incitament för att dokumentera och skapa något så generellt som möjligt inom den budget man har.
I mer än ett decennium har myndigheter pratat COTS (commercial off the shelf), och vi försöker att inte tänka inhouseutveckling by default, så någonstans har vi redan konstaterat att vi själva inte alltid är bäst i processer och användarupplevelser. Mot den bakgrunden borde det gå att se till generiska lösningar som är lättare och billigare att modifiera och framförallt är interoperabla med andra myndigheters system?
En praktisk nytta är att man som utvecklare på en annan enhet/myndighet/… har en chans att förstå hur systemet fungerar, utan att behöva ringa eller skriva till någon som ska förklara hur systemet fungerar med ord. Det är i synnerhet användbart om man skriver mjukvara som integrerar med systemet i fråga.
En annan nytta är möjligheten för studenter och medborgare att granska och lära sig av koden. Även om systemet som helhet förmodligen är myndighetsspecifikt, så innehåller de flesta system generella moduler som kan vara användbara för många.
En annan nytta är säkerhetsaspekten - ju fler ögon/kodanalysatorer som granskar koden, desto större chans att hitta buggar och säkerhetsproblem.
Givetvis finns också chansen att myndigheter i andra länder med liknande behov vill använda systemet, och samarbeta för att förbättra koden.
Ytterligare en nytta är att medarbetare kan känna sig stolta över att röra samhället i en bättre riktning.
1 gillning
En erfarenhet jag har är att ju mer hemlig en kod är desto sämre är den. Att något är öppet skapar ett incitament att göra sitt bästa, istället för att göra “fullösningar”.
Och när det gäller säkerhet så tycker jag man borde tillämpa kryptografins tumregler; att i ingen lösning ska säkerheten ligga i algoritmen utan säkerheten ska ligga i nyckeln. Dvs, algoritmerna måste vara öppna för att ett system ska kunna anses uppfylla grundegenskaperna för ett säkert system.
1 gillning
Att driva samhället i rätt riktning tycker jag också är en väldigt viktig del för mig. Jag, som nästan alla programmerare, har jobbat mycket med stängd kod. Mycket av det jag skrivit används inte längre idag, tex multimedia ramverk i gamla telefoner, det tycker jag känns väldigt omotiverande att det man gör bara används en kort tid. Öppen källkod har potentialen att leva mycket längre.
2 gillningar
När det gäller nyutveckling så måste det vara billigare att utveckla öppen källkod. Då har man tillgång till många fler gratis bibliotek än om man ska utveckla ett stängt.
Jag tycker att även om vi skulle utveckla moduler som bara rör oss, så finns det många anledningar till att den är öppen källkod; insyn, säkerhet, kvalitet, billigare (se ovan), billigare hantering (koden kan ligga på gitlab eller github, med bugghantering, etc istället för proprietära programvaror så som Jira, etc.)
Du har nog rätt att man inte ska generalisera ett system för mycket, men en viss form av generalisering är nog nyttig. Det gäller bara att hitta balansen och jag tror att gå öppen-källkod-vägen leder till mer återanvändning.
Sen tror jag att det egentligen är så att mjukvaran på alla myndigheter, kommuner, etc, huvudsakligen gör väldigt liknande funktioner, och att endast en liten del skiljer. Tex, Operativsystem, mail, forum, mötesbokning, schemaläggning, lönesystem, förmånssystem, tidsrapportering, semestersystem. Listan kan nog göras mycket längre…
I den del där systemen skiljer sig så tror jag att det i alla dom fallen inte behöver vara så. Om jag tycker att min organisations mjukvaruutvecklingsprocess inte passar in i github eller gitlab, då tycker jag man ska ställa sig frågan om det Verkligen är så? I många fall är nog svaret att det generella systemet skulle passa alldeles utmärkt.
1 gillning
Läs gärna Johan Linåkers forskningsartikel i ämnet:
Fallstudie avseende JobTech och Trafiklab.
Tycker han sätter fingret på att det krävs en mängd olika insatser för att komma igång.
1 gillning
Jag håller med om att det synsättet är lockande, men det finns flera problem med det. Dels finns det inte en algoritm som gör ett system säkert och dels är frihetsgraderna så stora. Numera är dessutom stora pengar inblandade när den organiserade brottsligheten klivit in på scenen.
Vi vet alla att göra ett system säkert är extremt svårt. Om det hade varit enkelt eller om pengar hade varit lösningen så hade jättarnas mjukvara aldrig haft en sårbarhet. Det som anses som ett säkert förfarande idag fungerar inte imorgon då motparten har hittat vägar att ta sig förbi skydd.
Specifikt för svenska myndigheter så har allt för många prioriterat funktion över säkerhet så systemen är inte säkra och att publicera den kompletta källkoden är problematiskt.
Det tycker jag dock inte ska stoppa oss, men det kräver mer resurser än man tror.
Mycket intressant fråga. Det finns två aspekter och den ena handlar om att använda öppen källkod vid utvecklingen av system. Det har många fördelar bara det. Du kan också göra din källkod öppen och tillgänglig för andra och det är den andra aspekten. Jag skulle säga att den första aspekten redan sker och skapar fördelar och där kanske vi inte behöver mest kraft och förändring just nu.
Att bara göra ett systems källkod tillgängligt på t ex github gör ingen glad utan att också lägga en hel del kraft på andra faktorer som jag tycker ofta glöms bort i diskussionen. Det finns så mycket öppen källkod idag, men bara en del av den håller måttet. Mycket öppen källkod är i praktiken inte användbar av andra. Det krävs många saker: kraven ska vara allmängiltiga; lösningen bör lösa svåra problem som många har; lösningen måste verkligen lösa det avsedda problemet; att koden skrivs på ett klart och tydligt sätt; att det finns dokumentation och inte minst att det finns någon att fråga.
En av de allra viktigaste aspekterna av framgångsrik öppen källkod har ingenting med teknik eller källkod att göra, utan är mycket mer mänsklig. Framgångsrika projekt har någon publik person som brinner för projektet och som har en stark närvaro i sociala media och håller diskussionen levande, rekryterar nya användare och utvecklare samt håller föredrag, påminner om dess existens mm. Det skapar med tiden en community utan vilken ett öppet källkodssystem inte klarar sig speciellt länge. De flesta repos på github saknar denna aspekt och därför känner ingen till dem. De du känner till och använder är de som har en sådan person som gör det känt och eftertraktat.
Härom dagen hörde jag en jämförelse mellan två stora öppna och källkodsprojekt. Båda var stora och komplexa. Det ena systemet hade ett litet och stabilt gäng utvecklare som hållit på länge. Det kände till sitt system väl och det fungerade bra. Det andra systemet fungerade också bra, men kärnan av utvecklare var mycket liten och det tillkom och försvann många utvecklare i projektet hela tiden.
Man skulle ju tro att det första projektet var det som fungerade bästa som projekt, men det var precis tvärtom. Det lilla projektet med utvecklare som kände varandra och källkoden väl hade ingen bra dokumentation, inget sätt att introducera nya utvecklare och var i alla avseenden introvert. Ställde man “dumma frågor” fick man svar som “RTFM!” vilket bara accelererade problemet. Det stökiga projektet med många utvecklare som kom och gick var tvungna att ha bra dokumentation och introduktion för nya utvecklare med möjlighet att få svar på “dumma frågor” för annars skulle det inte kunna fungera.
För att gå tillbaka till ursprungsfrågan så vet jag inte om det går att svara på den frågan egentligen. Jag tror att man måste gräva ett snäpp djupare och förstå vilka viktiga egenskaper man är ute efter och börja där. För att knyta ihop med frågan om öppen källkods-licenser och att det finns två perspektiv där en typ av licenser mer vill skydda utvecklarnas behov och andra som ser mer till användarna av systems behov måste man också förstå vilka man först och främst vänder sig till.
Vad är det för kvaliteter som du tänker på när du säga öppen källkod? Vad är det du skulle vilja se hände med system som vi myndigheter utvecklar? Pratar vi program för den egna datorn? System som används av fler? Systemkomponenter som kan användas vid utveckling? Bibliotek som som löser ett specifik problem? Jag tror att svaret blir lite olika beroende av vad man är ute efter.
Typiskt arkitektsvar alltså 
1 gillning
Med ditt resonemang Bengt borde risken för attacker öka ju mer tekniken är exponerad för omvärlden. Med andra ord så borde det som hackare (i dålig bemärkelse) löna sig att attackera generella system såsom linux-distros som körs på ”alla världens servrar” kontra små myndighetssystem. Givet att användningen av öppen källkod är hög (80-90%?) på myndigheter tordes det vara en dålig idé att stänga ner de få kodrader som en myndighet själva producerar. Min erfarenhet är tvärtom att det är enklare att ”slarva” med IT-säkerheten om systemet är stängt. Jag vill slå ett slag för att publicering av öppen källkod kommer leda till bättre rutiner och processer för IT-säkerhet.
Det finns många potentiella nyttor med öppen källkod (se ex. denna studie där jämför två stora privata bolag med Arbetsförmedlingen).
Skapa transparans och tillgängligöra sådant som beskostas av skattemedel är två sådana som kan uppnås genom att lägga ut sin kod på ex. GitHub. Möjliggörande av samverkan uppfattar jag också som ett vanligt argument. Dock är det med betoning på möjlliggörande.
Många nyttor som ex. sänkta kostnader och delat underhåll, bättre kvalitet och säkerhet, öppen innovation och standardisering av lösningar, hänger just på att det blir en samverkan kring open source-projekten, både för de man släpper och för de man väljer att använda. Att enbart släppa sin kod på GitHub, likt hur många gör med sin öppna data på dataportaler, medför per automatik inte något av detta.
Här krävs att man bygger ett community/ekosystem och där samlar intressenter, för en öppen dialog och möjligör en öppen samverkan kring open source-projekten. Samverkan gäller alla nivåer som kodbidrag, buggrapportering och triagering, diskussioner kring kravställning, skrivande av dokumentation, marknadsföring av projeket/communitybyggande…
Samma sak när man väljer att ta in och använda sig av open source-projekt, om det inte sker nån aktiv samverkan utgör projektet snarare en potentiellt säkerhetsrisk (se OpenSSL). Likaså om man väljer att stå utanför samverkan kan många av de potentiella nyttorna försvinna, ex. om man inte bidrar tillbaka sina ändringar eller nyutvecklade funktioner som istället måste läggas till på varje ny release som man väljer att ta in.
Den förväntade nyttan ska även vägas mot potentiella kostnader och risker. Det kan ex. kosta mer än vad det smakar att generalisera en lösning vilket kan krävas för att fler än du ska vara intresserad av att använda det eller bidra. Kopplat till det så hänger just mycket på om det finns ett extern intresse för projektet och att samverka kring det. Om det ska bidras till ett befintligt projekt hänger det på att de är intresserade att ta emot bidraget. Dessa och andra aspekter kan potentiellt radera ut den förväntade plussidan vilket man bör ha i beaktning.
Så för att knyta till huvudfrågan , det finns många nyttor (och risker/kostnader), hur stora de blir hänger på myndigheten 
2 gillningar
Ett typexempel på att vi båda har rätt eller att ingen har rätt om du så vill. Båda aspekterna finns samtidigt!
Är källkoden publicerad går den att granska och därmed kan kvaliteten förbättras. SAMTIDIGT om källkoden är publicerad kan även svarthattarna hitta felen och utnyttja dem. Båda sker idag, men i hur stor utsträckning detta sker är lite otydligt för mig.
Sen har vi den kommersiella aspekten. Det lönar sig att sikta in sig på buggar i Windows och andra stora kommersiella program för de används av många som glatt kan tänka sig att klicka på ogranskade länkar. Samtidigt är nog Windows det operativsystem som är säkrast idag (även om det är lite smärtsamt att medge det) och det har ingenting att göra med att källkoden är privat, utan beror på att Microsoft lagt ner gigantiska summor pengar på att jobba med säkerhet de senaste 25 åren. Linux och andra fria och öppna programvararor innehåller också en massa buggar, men är oftast inte lika luckrativa att hacka,. Någon nämnde openSSL som ett exempel på ett välskött projekt, men som nyligen ändå haft väldigt allvarliga buggar.
Vill bara avsluta med att även om jag diskuterar och debatterar nyttan med open source så är jag helt och hållet för öppen källkod. Det har gjort så mycket gott för oss människor och utan den skulle it-landskapet vara mycket tråkigare och utvecklingen skulle inte tagit oss dit där vi är idag.
1 gillning
Jag håller med och kanske är det det enkla svaret på varför vi ska välja öppen källkod!
Som jag ser det är öppen källkod en förutsättning för att lösa komplexa problem. Nyttan finns i processen, inte i betalningsformen. Det är inte så enkelt att säga varken att det är billigare eller dyrare på sikt. Kod är en kostnad, bra att dela. Öppna upp och generalisera är dyrt och kräver en investering i att skapa community.
Ett system som utvecklas med en öppen process redan från början har möjligheten att inkapsla större grad av komplexitet än vad en stängd process klarar av.
Vi driver just nu ett projekt med Göteborgsregionen där vi utvecklar ett skolsystem öppet från första raden. Vi bygger systemet för en skola i taget och slipper därmed göra generaliseringar för tidigt. Dessutom kan varje skola testa koden medan vi bygger och om de vill kan de anpassa koden till sin skola direkt eller förbereda sig under tiden.
Jämför med Skolplattformen som byggdes stängt och är fortfarande stängd vilket gör att de behövde bygga utifrån minsta gemensamma nämnaren och ta hänsyn till alla skolors komplexitet.
Ovanstående bygger dock på en annan fråga som ofta inte diskuteras och det är NÄR koden publiceras. Om du bygger hemligt och sen publicerar som en form av boksläpp uppstår inget av de fördelar jag pratar om.
Sen kan man även tillägga att öppen källkod även underlättar organisation. Om man gör koden så enkel att ladda hem och bygga lokalt så är det ofta även enkelt för nya medlemmar i teamet enklare kan bidra.
Så jag tycker att nyttan framför allt finns i processen och organisationen - inte i budgeten.
2 gillningar
Gillar att du nämner processen. Håller med!
Du nämner också skolplattformen, ett Stockholmshaveri. Här valde dock Alingsås kommun en annan väg; Öppen källkod. Göran Westerlund kommer att berätta om sina erfarenheter från ett lyckat öppen skolplattform.
Lyssna gärna på honom 6 oktober 10-12. Bokning sker via https://gitlab.com/open-data-knowledge-sharing/wiki/-/wikis/Digital-Workshopserie
Det finns en logik i att “många ögon” på koden hjälper med säkerheten, men det hänger på att det finns just många ögon som faktiskt tittar på koden, granskar, rapporterar buggar och åtgärdar vad de ser. Problemet med många projekt (som ex. OpenSSL, iaf tidigare) är att många tar dem för givet, tror att det finns ett community runt dem, företag som har dedikerade utvecklare och maintainers som jobbar heltid etc. En vanlig syn i små men välanvända projekt är dock att det sitter en, max två maintainers som får dra det stora lasset, helt eller delvis utanför sitt dagliga avlönade arbete.
Här hade myndigheter kunnat ta ett större ansvar genom att syna vad de har för beroenden, vilka projekt är de mest centrala, undersöka dess hälsa, och dedikera resurser att stödja dessa. Återigen ett exempel där det är samverkan som krävs för att uppnå den önskade nyttan.
För mer läsning på ämnet rekommenderar jag rapporten Roads and Bridges, samt boken Working in public av Nadia Egbal.
1 gillning
Värdet är minst 20 miljarder eftersom kostnaden för ”Verkställande och lagstiftande organ, ekonomi- och skatteförvaltning, utrikesförvaltning” är 80 miljarder (2018) och en effektivisering om minst 25% är att vänta av grundläggande byggblock som öppna och förvaltningsgemensamma format för diarieföring och därmed utbyte av myndighetsärenden, personuppgifter (för utländska och svenska medborgare), elektronisk identitet (för svenska och utländska medborgare) samt allmänna handlingar.
Ett förbättrat utbyte mellan myndigheter, näringsliv och medborgare motsvarar med största sannolikhet ett värde betydligt mer än 20 miljarder men låt oss undvika glädjekalkyler.
2 gillningar