Community på Sveriges dataportal

@Maria_Dalhage Lägger en direktlänk till eventet för dem som inte hunnit anmäla sig eller inte vill anmäla sig, men ändå delta: https://internetstiftelsen.zoom.us/j/82149415166?pwd=RHBMbzdYYWlDQ1FHOCt6WCtwMERjdz09

@elias ja, precis. När vi har jobbat på prestanda för att höja användarupplevelsen så har vi sett att det också är bra för miljön. Två enkla tips är statiska webbsidor och små bilder.

@jonor Tack för feedback 🙂 jag tror inte vi har fått så mycket feedback på det här, det är kanske därför vi inte prioriterat upp att fixa det hittills. Jag förstår dina synpunkter, de är relevanta.

Det har gått ett tag sedan denna tråd skapades och sedan dess har CRA-förslaget till viss del omarbetats och omformulerats. Se länk.

Delar nu ett uttalande (8 augusti 2023) från Open Source Business Alliance om Cyber Resilience Act (CRA).

Uttalandet stödjer målen med CRA men uttrycker farhågor om hur lagen påverkar öppen källkodsprogramvara.

Open Source Business Alliance betonar öppen källkodsprogramvarans roll för innovation, konkurrens och digital suveränitet.

De oroar sig över att CRA, som verkar vara utformad för proprietär mjukvara, kanske inte passar öppen källkodens utvecklings- och distributionsmodeller väl.

Uttalandet föreslår förbättringar för att skydda öppen källkodsekosystemet, inklusive tydligare definitioner för kommersiella aktiviteter och rollerna i öppen källkodsprojekt. De varnar för överreglering och rättslig osäkerhet som kan skada öppen källkodsindustrin.

OSB Alliance uppmanar den tyska regeringen att säkerställa att CRA inte skadar öppen källkodsprojekt och erbjuder sin expertis för diskussion och samråd.

@joho68 när du skriver i oppetmoln.se , länka gärna till de olika artiklarna i detta forum. Det står massvis med matnyttigt där. 🙂

@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.

@elias toppen, ska kolla in videon då jag missade själva eventet.

@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.

@Matself håller med i det du skriver. Sedan PSI-direktivet har det gått 20 år. Så knappast någon myndighet kan känna sig tagen på sängen vid det här laget. Bara att konstatera att även Sverige behöver kraftfulla lagar som incitament.

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

@Jonas-Nordqvist Japp, bra tips! 🙂

@Maria_Dalhage ja visst är det kul, skrev om det här på LinkedIn när parlamentet antog utkastet, med länkar till nuvarande NIS samt förslagstext och 2021:s NIS-incidentrapport för Sverige.

@tove jag tolkar job to job mobilitet som omsättning på kvalificerad personal. Hur lätt det är att byta jobb. https://ec.europa.eu/eurostat/cache/metadata/Annexes/hrst_esms_an4.pdf
Är inte säker på att de viss uppgång eller nedgång av denna siffra säger så mkt egentligen. Men då kan jag ha missförstått. Det har hänt förr 🙂

@tove EU-Kommissionens förslag till Interoperable Europe Act är en viktig fortsättning på EU:s arbete med interoperabilitet inom den offentliga sektorn, såsom European Interoperability Framework (EIF).

Medan EIF, som en uppsättning rekommendationer, inte är bindande är däremot Interoperable Europe Act den första föreslagna förordningen (överrider nationell lagstiftning) om interoperabilitet med bindande bestämmelser för medlemsstaterna. Olika interoperabilitetsinitiativ har finansierats genom EU-program sedan 1995 (IDA, IDABC, ISA och ISA2). Finansiering fortsätter under Digital Europe-programmets Interoperable Europe Initiative. EU:s medlemsstaterna har deltagit i arbetet med förlag till förordning via en expertgrupp.

@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.