Community på Sveriges dataportal

@Josef_Andersson Håller helt med!

I regeringens digitaliseringsstrategi från 2017 går att läsa: "Offentlig upphandling bör i större utsträckning användas som ett proaktivt verktyg för att främja utveckling, användning och implementering av digitalt drivna innovationer. Innovationsupphandling och innovationspartnerskap är i sammanhanget viktiga verktyg liksom medveten användning av lösningar i öppen källkod, standarder och testbäddar [...]"

Alltså, medveten användning är ett annat ord för strategi.

Idag hade vi en NOSAD-workshop om offentligkod.se och att denna omnämns i Kammarkollegiets Vägledning för avrop av programvaror och tjänster. Inspelningen kommer snart med tipsar att ni tar del av delade presentationer och vägledning. Presentationer och inspelningar ligger under https://nosad/workhops

@Josef_Andersson Vad kul. Ser framemot återkoppling.

@Nina_Berlin Jag tror inte att det är en workshop i den meningen att det går ut på att bygga något, utan mer ett öppet samtal eller en "frågor och svar"-session. Men ja, den är öppen för alla att delta i, bara maila adressen där för att få länken.

@Maria_Dalhage @johanlinaker Toppen!

Kul att läsa, mycket lovande utveckling tycker jag. Ett par kommentarer:

"Open source ger många ännu outnyttjade möjligheter för den offentliga sektorn, t.ex. att tillhandahålla innovativa medborgartjänster till en lägre kostnad."

Ja! Jag tror att det underskattas hur stor potential som finns här för att saker kan utvecklas av det offentliga tillsammans med medborgarna. Jag tror att många gärna skulle bidra. OBS att skillnaden är väldigt stor om man jämför:

"det gamla sättet": offentlig aktör upphandlar tjänsten X av ett företag. Som medborgare kan man skicka en felrapport, men allting är stängt och ägt av företaget och som medborgare är man inte speciellt sugen på att bidra till företagets produkt, som ju när som helst kan försvinna när priset höjs och en annan aktör upphandlas.

"det nya sättet": offentlig aktör utvecklar tjänsten X öppet, tillsammans med medborgarna. Som medborgare kan man inte bara skicka felrapporter utan man kan själv se hur saker fungerar och man kan själv aktivt bidra med förbättringar. Att bidra blir nu meningsfullt på ett helt annat sätt än om tjänsten var stängd och ägd av ett företag. De här frivilliga bidragen från medborgarna är helt gratis för det offentliga och bidrar dessutom till känslan att det offentliga bygger upp saker för samhällets bästa tillsammans med medborgarna.

"Behovet av kompetensutveckling och utbildning relaterad till open source [...]. Offentlig sektor behöver också ombesörjas med utbildning för att bli mer attraktiv för den begåvade arbetskraften och för att förstå hur man kan utnyttja de många möjligheter som open source ger. Konceptet Hackers-in-residence lyftes fram flera gånger."

I det sammanhanget tänker jag att det kan vara relevant att ställa kostnader i relation till vilka summor man annars betalar i licenskostnader och andra sorters kostnader för stängd utveckling. Jag tror att det är stora summor som brukar gå ut den vägen, det är den storleksordningen av resurser som är rimligt att lägga. Exempel: om Skolplattformen i Stockholm kostat en miljard, hur mycket egen kompetens, "Hackers-in-residence" och liknande hade de pengarna kunnat räcka till? Nyttan för det offentliga kommer i slutändan att vara mycket större.

@jonass sa i DIGGs rapport "En säker och tillgänglig statlig e-legitimation" publicerad 2023-01-30:

Vilka delar bör vara stängda tror ni?

Jag tror och hoppas att allting som ska köras hos användaren, "klient-sidan", ska kunna vara öppen källkod.

Den här biten på sidan 2 i bilaga 1 tyder på det:

"ingen del av den tekniska säkerheten ska bero på att
klientprogramvarans utformning hålls dold."

Men ovanstående är inte samma sak som att säga att den ska vara öppen källkod, formuleringen lämnar möjligheten att klientprogramvarans utformning kan hållas dold, bara det att den tekniska säkerheten inte ska bygga på det. Man anar då att DIGG tänkt att det kan finnas andra anledningar till att hålla saker dolda, kanske. Jag vet inte riktigt hur man ska tolka det.

@jonor det är egentligen ingen skillnad annat än ”hantverksmässigt” - vilket (ram-)avtal som ska användas och vad är det vi behöver kravställa, hålla koll på i affären och därmed systemets livscykel.

Man kan i enlighet med lagen om offentlig upphandling be om att få en specifik öppen programvara installerad och driftad. Det kan man inte kravställa när det gäller en proprietär lösning eftersom den proprietära lösningen hämmar konkurrens. Samma gäller öppna standarder. Helt ok och rekommenderat att kravställa på, men det är inte ok att kravställa stängda format.

Man kan i en upphandling också vara mer ”generell” och specificera funktioner och utifrån dessa välja Open source alternativen. Detta är ju mindre klokt än att testa och utvärdera först, när den möjligheten faktiskt finns.

Och det är det som är den stora fördelen med Open source i upphandlingssammanhang. Det går enkelt att testa och utvärdera programvaran innan en större investering. Och du äger din backlog. Dvs du kan ändra funktionalitet när du behöver genom att utveckla. För ett proprietärt system behöver du vänta tills företaget väljer att utöka sin funktionalitet. Ibland händer det och ibland inte.

De utmaningar som finns handlar oftast om osäkerhet. Får jag verkligen kravställa ett öppet format eller en implemententation i en öppen programvara, när jag inte får göra detta för proprietära lösningar?

Är det ok att bidra tillbaka till en programvara med pengar som en myndighet investerat? Är det i enlighet med lagen om offentlig upphandling?

Är det ok att dela en programvara som en kommun utvecklat (genom att köpa kompetens från en leverantör) med andra kommuner? Eller behöver kommunerna först samarbetsavtal?

Det är dessa typer av frågeställningar som skapar osäkerhet och gör att många är rädda för att kravställa öppna standarder och öppen källkod. Men vanligast är nog att de flesta inte ens reflekterar över vissa krav. De sk icke-funktionella kraven. Det finns en bunt sådana under NOSAD lästips. Och det var därför jag också hänvisade till eSAMS arbete. Det är också därför vi tagit fram offentligkod.se. För att hjälpa varandra att visa vilka öppna programvaror offentlig sektor redan använder och därmed har erfarenhet av.

@jonor @Maria_Dalhage I många IT-tunga organisationer, åtminstone i näringslivet, är sådant som agilitet och öppen källkod självklarheter. Man har börjat diskutera post-agil metodik, som t ex empowered product teams.

På myndigheterna i offentliga sektorn räknas inte alltid IT som en del av kärnverksamheten. Man har en beställar-utförar-kultur sedan många år tillbaka, förstärkt med konsulter och leverantörer. Man skiljer på "IT" och "Verksamhet". Där faller hela tanken med digitalisering, eftersom det handlar om verksamhetsutveckling med teknikens hjälp.

Här är vi inte överens internt på myndigheterna. Vissa vill det ena, andra vill det andra. Det här slår på sådant som verktyg för öppen källkod. Om digitalisering är en fråga för IT och inte för Verksamheten, och IT är en utförare som ska leverera till Verksamheten, så är ett verktyg för att hantera öppen källkod IT:s problem. Verksamheten jobbar i office-paketet.

Jag hoppas och tror de flesta i det här forumet håller med mig om att det blir dålig kod och dåliga system om vi inte utvecklar den tillsammans.

Varje myndighet behöver hitta sin egen väg framåt i det här och komma överens om hur de ska jobba utifrån sina egna förutsättningar, vad gäller uppdrag, målgrupp, kultur, kompetens, finansiering och allt sådant.

När man väl har kommit fram till det är det enkelt att ta in ett verktyg. Just nu tror jag inte alla myndigheter tycker att de behöver ha ett verktyg för det här.

Bulgarien har också en lag om att mjukvara som utvecklas på uppdrag av det offentliga måste bli öppen källkod.

@Nina_Berlin Hittade nyheten. Lägg gärna den här länken där också.