Öppen källkod för SR Play
Hej,
Har ett förslag/fråga om att släppa SR Plays källkod som öppen källkod under t.ex. GNU licensen eller liknande.
Tanken slog mig eftersom SR är public service och ändå inte vinstdrivande samt att det verkar som att både jag och många andra (av att läsa Google butiken recensioner) verkar ha upplevt mer och mer problem i appen på sistonde. Med bland annat uppspelning och kraschar.
Om man hade tillgång till källkoden skulle det ge en bättre möjligheter att felsöka och också kunna bidra med bugfixar och pull-requests.
Är detta något ni funderat på att göra?
Mvh,
Rickard
Har ett förslag/fråga om att släppa SR Plays källkod som öppen källkod under t.ex. GNU licensen eller liknande.
Tanken slog mig eftersom SR är public service och ändå inte vinstdrivande samt att det verkar som att både jag och många andra (av att läsa Google butiken recensioner) verkar ha upplevt mer och mer problem i appen på sistonde. Med bland annat uppspelning och kraschar.
Om man hade tillgång till källkoden skulle det ge en bättre möjligheter att felsöka och också kunna bidra med bugfixar och pull-requests.
Är detta något ni funderat på att göra?
Mvh,
Rickard
Följ inlägget
2
följare
Och mer allmänt, i vilka situationer ska skattemedel läggas på utveckling av kod som är sluten eller privatägd? Detta borde kanske vara särskilda fall snarare än allmän regel.
Jag skulle gärna se att svenska offentliga institutioner engagerar sig och tar ställning i denna fråga.
Dessutom är en betydande del av det innehåll vi erbjuder i apparna inte vårt eget. I appen kan du ladda hem även avsnitt med skyddat innehåll för off line-lyssning, eftersom nedladdningen är "inlåst i appen" och ljuden raderas samtidigt som våra rättigheter att erbjuda dem upphör. Det skulle bli juridiskt knepigt om vi beskrev exakt hur filerna lagras och vad som styr att de raderas. Jag (som i och för sig inte är jurist) tror att en sådan transparens skulle innebära ett brott våra avtal med rättighetsinnehavarna.
Dessutom finns det oerhört många beroenden till olika andra system, och oerhört många särfall att ta med i beräkningen som gör våra stora mobil-appar mindre lämpliga för Open Source.
Förutom dessa svårigheter finns det ytterligare en viktig aspekt. Open Source-projekt i större skala är svåra att driva och vi har inte möjlighet att göra det på ett bra vis idag. Det problemet märker vi med vårt öppna API, där en del önskemål och kloka tankar som dyker upp tyvärr inte landar "rätt hos oss". (Vi försöker styra upp detta!)
Det finns också säkerhetsfrågor att ta hänsyn till. Koden blir tillgänglig även för den som vill sabotera.
När det gäller våra största tjänster som mobilapparna, finns det alltså flera skäl till att vi inte ser en utveckling mot öppen kod inom en nära framtid. Däremot finns det inget som hindrar att ett community själva skapar en radio-app som open source med hjälp av vårt öppna API. Jag vet inte helt säkert om någon av de tjänster som hittills har byggts på detta vis har varit Open Source. De jag känner bäst till och där jag har en aktiv kontakt med utvecklarna, är inte öppna, men det finns en plug in för Logitech och en Ubuntu-app som jag tror bygger på öppen källkod (även om båda dessa tjänster har varit enmans-projekt).
Tidigare i veckan frågade jag Camilla Jettman, utvecklingschef på Sveriges Radio, hur vi funderar övergripande kring öppen källkod. Hon svarade:
Next Generation, den produkt som alltså delvis var/är Open Source, kan ni läsa om här (där vi emellertid inte nämner öppen källkod):
Sveriges Radio sänder direkt från mobilen
Next Generation har förstås inte så mycket med denna fråga att göra - men är ett otroligt viktigt verktyg för de kolleger som producerar innehåll för Sveriges Radio Play!
Tack för att ni vill bidra till att göra Sveriges Radio Play bättre, trots att vi inte har möjlighet att vara så öppna som man kan önska. Och förlåt för att svaret dröjt så länge ...
Vad syftar ni på här, på vilket sätt tycker ni open source-projekt är svåra att driva jämfört med andra projekt? Vad har detta med det öppna API:et att göra; där tillgängliggör ni data, men utvecklingen av programvaran bakom API:et sker väl inte öppet, eller har jag missat något?
> Det finns också säkerhetsfrågor att ta hänsyn till. Koden blir tillgänglig även för den som vill sabotera.
Det här får ni också gärna förklara närmare hur ni tror att det skulle gå till.Jag använder en applikation för att lagra lösenord som är skriven i öppen källkod. Hur skulle detta innebära att säkerheten för mina lösenord riskerar att komprometteras, eller hur skulle applikationen saboteras? Har ni exempel på att detta hänt i verkligheten?
> "Den kod vi la ut var det som kan beskrivas som en Telefonbok - dvs en funktion som håller reda på våra ljudkodare/-källor. Jag är osäker på om koden fortfarande är tillgänglig - det kostar trots allt att ha den publicerad och med tanke på det lilla intresset för att ladda ner så...
Vad pratar ni om här, vad är en telefonbok för ljudkodare/källor för något och varför hade ni förväntat er att det skulle finnas ett allmänt intresse för att vidareutveckla den applikationen? Hur såg källkoden ut och vilket språk och plattform var den skriven för?
Jag undrar också vad det är för kostnad ni syftar på; kostar det att lägga ut öppen källkodsprojekt på GitHub menar ni? Var publicerades källkoden? Hur stora kostnader pratar vi om?
Johannes, du kom med flera följdfrågor som aldrig fick svar, så jag gör ett försök nu!Att upprätthålla struktur och en bra kodstandard är svårt nog i ett traditionellt projekt med ett team av kolleger. Det skulle bli än svårare i ett open source-projekt, i synnerhet om det drivs av oss som inte har någon direkt erfarenhet av (större) sådana projekt sedan tidigare.Det kanske var en lite udda jämförelse. Det jag menade är att vi har en diskussionsyta för vårt API som vi verkligen behöver styra upp (och där planen är att flytta över diskussionen hit till supportforumet):
https://groups.google.com/g/sr-api
Idag missar vi att ta vara på de goda idéer och den kunskap som användarna av API:t vill hjälpa oss med. Om vi bjuder in lyssnarna i utvecklingen, så behöver vi ha beredskap för att ta vara på den kompetensen.De applikationer där det är känt att loggningsplattformen Log4j ingår utsattes självfallet för fler attacker än andra applikationer när informationen om att det finns ett säkerhetshål i Log4j spreds:
computersweden.idg.se: Experter varnar – hundratals försök i minuten att utnyttja Log4j-hålet
Säkerheten i koden i sig blir kanske varken högre eller lägre med öppen källkod, men om det är tydligt hur koden ser ut, exponeras eventuella säkerhetsproblem på ett olycklig vis.
Vi hade inte väntat oss ett brett allmänt intresse. Det ligger i sakens natur att mjukvara för att producera radio inte har allmänt intresse, vare sig att använda eller att vidareutveckla. Men givet detta, tolkar jag Camillas svar som att det varit lågt intresse för vår källkod även bland dem som arbetar med att utveckla mjukvara för radioproduktion.
Jag är inte speciellt insatt i frågan, men här kan du läsa mer om IRIS, Sveriges Radios projekt för öppen källkod:
Sveriges Radio öppnar källkoden för framtidens radio
För att återkoppla så tycker jag Sveriges Radios inställning i frågan om användning av öppen källkod framstår som opåkallat och anmärkningsvärt negativ, och jag undrar lite över vad detta kan bottna i, med tanke också på att man på webbplatsen nu också annonserar om samarbete med EBU, European Broadcasting Union, som upprätthåller och publicerar en tämligen omfattande katalog över just öppen programvara för radiodistribution.
Ex. från https://sverigesradio.se/artikel/bekraftat-utbrant-karnbransle-ska-forvaras-i-forsmark
"A European Perspective - Nyheter från europeiska public service-bolag"
"Sveriges Radio väljer varje dag ut nyheter från andra public service-bolag i Europa, ett samarbete inom EBU."
Via https://www.ebu.ch/eurovision-news/european-recommendation-box
EBU:s katalog på GitHub:
https://github.com/ebu/awesome-broadcasting
"A curated list of amazingly awesome open source resources for broadcasters."
Grundfrågan var alltså om Sveriges Radio funderar på attNågra sådana planer har vi inte idag. Jag vet inte om jag har lyckats förklara varför vi inte tror att våra Play-appar lämpar sig som open source?
EBU:s uppdrag lämpar sig för öppen kodEBU utvecklar stöd för många olika bolag, vilket är en del av deras uppdrag. Öppen källkod är ett smart sätt att ge oss som är medlemmar - och andra - möjlighet att vidareutveckla koden.
Något sådant uppdrag har inte Sveriges Radio. De tjänster vi utvecklar är i första hand till för våra lyssnare eller våra interna behov.
I listan över amazingly awesome open source resources for broadcasters på Github: EBU ingår flera byggstenar som vi på olika vis redan använder oss av på Sveriges Radio. Många av dessa har ingen direkt koppling till just EBU, medan andra är rena EBU-projekt där vi har tagit mer eller mindre aktiv del i utvecklingen. Vårt eget öppna projekt, IRIS Broadcast, (som håller reda på våra ljudkodare/-källor) finns för övrigt med i listan.
Ett väletablerat samarbeteVi har varit medlem i EBU sedan starten 1950. Att vi samarbetar med andra public service-bolag inom EBU är alltså inget nytt - men kanske lite okänt?
Dels har vi flera samarbeten som handlar om innehåll. Notturno som sänds i P2 nattetid är ett EBU-projekt, Eurovision Song Contest är ett annat.
Andra samarbeten handlar om att utveckla olika former av standarder, exempelvis RDS-tekniken och EBU R 128.
Ett samarbete inom EBU som är mycket aktuellt, är att EBU är med och koordinerar de hjälpinsatser från Sveriges Radio och andra public service-bolag för att hjälpa public service i Ukraina:
Så stödjer Sveriges Radio ukrainsk public service
Den tjänst du skrev om, A European Perspective, där vi delar nyheter mellan olika mediebolag tack vare bland annat EBU:s rekommendationsmotor PEACH (som även används av våra appar för att föreslå vidare lyssning) och EBU:s översättningstjänst EuroVOX, är ett spännande samarbetsprojekt. Varken PEACH eller Eurovox är open source (vad jag vet). Även om EBU, i rollen som samarbetsforum, har större andel öppna projekt än vad vi som är medlemmar i EBU brukar ha, utgör dessa endast en liten del av EBU:s utveckling.
Samarbeten inom EBU handlar även om att träffas och inspirera varandra. Vi får inspiration, och en del av det vi utvecklar inspirerar även andra. Här är ett sådant exempel som vi är stolta över:
Nytt system ökar genomslaget för unik Sveriges Radio-journalistik
Vilket tog oss en bit från ämnet "öppen källkod", men jag ville passa på att ge en bild av hur vårt samarbete inom EBU ser ut.
Jag ämnar, som sagt, återkomma till ämnet öppen källkod.
Jag blev själv nyfiken på hur EBU ser på öppen källkod och frågade Jørgen Bang, som leder EBU:s arbete med Strategic Programme on Platforms inom EBU. Han höll med om min beskrivning av att EBU:s uppdrag och syfte ofta lämpar sig för öppen källkod på ett annat vis än Sveriges Radios. Dessutom berättade han att flera utvecklingsprojekt, exempelvis PEACH som jag nämnde ovan, har lite av ett mellanläge. Det är inte öppen källkod, men koden är fri att använda för alla EBU:s medlemmar. Open source är något som diskuteras regelbundet inom EBU.
Sedan vill jag förstås kunna ge ett bra svar om hur vi på Sveriges Radio ser på öppen källkod, och det återkommer jag om!
Jag noterar mest frånvaron av policy och att det inte verkar läggas några resurser från svenskt håll på att utveckla öppna produkter som kan vara till gemensam nytta för flera organisationer eller för allmänheten. Jag tror området därtill motarbetas genom lobbying från näringslivshåll då man vill säkra sina inkomstkällor genom att sprida osäkerhet och tvivel inför öppna alternativ (en del av motargumenten tyder på detta tycker jag, som att utvecklingschefen på Sveriges Radio påstår att det "kostar att ha källkoden publicerad" utan att förklara denna omständighet närmare).
Jag inser att referensen till det öppna API:et gällde en jämförelse med de existerande mobil-apparna, men Sveriges Radio kunde då komplettera det öppna API:et genom att publicera en referensapplikation som visar hur API:et kan användas i praktiken som öppen källkod.
Jag var med på en konferens nu i maj, som hölls med Sveriges Radios teknikavdelning och den avdelning som utvecklar produkter och tjänster. Jag tillhör inte dessa avdelningar, utan var där för att "förmedla lyssnarnas syn" och visa hur supporten fungerar. Nåväl, under dagen hade de ett pass med fria samtal kring ämnen som deltagarna själva valde. Det handlade om allt från hur vi kan samarbeta mellan olika utvecklingsteam till hur vi ska behålla och rekrytera kompetens.
Ett samtal, dit många sökte sig, hade temat Open Source. Frågan intresserar alltså många tekniker och utvecklare på Sveriges Radio. En kollega som var med i samtalet om Open Source är Zakarias Faust, som leder arbetet i ett team med uppgift att "utveckla, underhålla och drifta nuvarande och nästkommande ljudinfrastruktur".
Jag bad Zakarias sammanfatta hur tankarna gick eftersom jag själv inte deltog i samtalen, utan bara hörde brottstycken från dem. Detta är alltså en subjektiv sammanfattning av hur samtalet gick i den (förvisso stora) grupp utvecklare som valde att prata om Open Source. Jag hoppas att det ändå ger en mer nyanserad bild av hur vi, internt, ser på frågan än den bild jag tidigare har förmedlat om att vi skulle vara opåkallat och anmärkningsvärt negativa:Zakarias berättar även att den del av Sveriges Radio som han tillhör, som arbetar med ljudproduktion, streaming, styrning av system, infrastruktur och andra underliggande system (alltså inte utveckling av publika produkter som våra appar), har formulerat dessa mål:Han sammanfattar det så här:Så långt Zakarias. Nu till ditt förslag:Där hänger jag inte riktigt med. På vilket vis skulle utveckling av en referensapp för att visa vårt API i praktiken vara en del av Sveriges Radios uppdrag? Om det behövs en referensapp för att förstå hur vårt API fungerar, har vi absolut misslyckats med dokumentationen, och har vi det, behöver vi troligen lägga krut på en mer användarvänlig dokumentation, snarare än att låta våra utvecklare (som är en resurs vi lider brist på) utveckla en app som vi inte har sett något behov av tidigare.
Att vi inte har sett eller förstått ett behov, betyder förstås inte att ett sådant saknas, så berätta mer om hur du tänker. Jag vill inte låta en potentiellt bra idé fastna i forumet bara för att jag inte riktigt förstår syftet.
Anledningen till att jag föreslår att Sveriges Radio publicerar en referensapplikation för sitt öppna API är att det kan vara ett första steg mot att erhålla en praktiskt förståelse för vad som i nuläget i förefaller bestå mest av teoretiskt resonerande i stil med "det vore trevligt med fred på jorden, men det går tyvärr inte just nu för våra vapenleveranser skapar arbetstillfällen", samt att det kan bidra till insikter i eventuella brister i det öppna API:et och en förståelse för konsumentens perspektiv, utgöra en ingång för bidrag och förbättringsförslag från externa användare, och fungera som ett konkret exempel som kompletterar dokumentationen.
Det kan ju finnas mer relevanta projekt för Sveriges Radios del, och det är förstås en fördel om man upplever projekten som meningsfulla för verksamheten, men jag tror det är ganska väsentligt att ta någon form av steg in i praktiska omständigheter för att skapa en grund och kompetens för realistiska resonemang om eventuella kostnader och nyttor.
Det sammanfaller ju också väl med de mål som drift- och produktionsavdelningen har formulerat: utforska open-source och publicera egenutvecklade mjukvaror när det ökar Sveriges Radios utvecklingsförmåga.
Sedan är det ju en intressant fråga och lite oklart vad Sveriges Radios uppdrag har att säga om det detta. Ingår det ens i uppdraget att tillhandahålla ett öppet API? I annat fall är det kanske detta något som bör avvecklas istället för att stjäla tid och kostnader från kulturarbetarnas och förlagens del av skatte-kakan.
Jag ska tipsa dem om förslaget om att skapa en publik open source-app som bygger på vårt öppna API, som vi normalt sett inte ska använda oss av själva, så kanske någon nappar på det vid tillfälle:
Vet inte riktigt vad du syftar på med länktiteln: "som vi normalt inte ska använda oss av själva", jag skymtar inte något svar på skälet till detta i länkens målsida.
Jag gissar att anledningen till att man ska kontakta Produkt- och Tjänsteutveckling är att bli hänvisad till ett internt API där all utvecklingstid läggs, medan det externa API:et i princip ignoreras.
------
Tillägget nedan skrevs fyra dagar senare, och har flyttats till en egen tråd:
Hur skiljer sig det interna API:et från det öppna?
------
Den 7 juni 2022:
Jag ser att det var en hänvisning till texten längst ned i API-dokumentationen, men det sägs inte mycket mer där än att dokumentationen skulle skilja sig åt. I praktiken har väl utvecklingen av det öppna API:et frusits sedan länge och det interna API:et är i princip en ny produkt som inte kommer externa användare till del.
Om vi bygger en ljudspelare för ett internt system, finns det andra sätt att hämta ljuden och vi slipper konkurrera med publika anrop i distributionsnätverk och lastbalanserare. Vi vill helt enkelt inte att intern trafik ska ta en onödig omväg. Vill inte heller att lyssning i våra interna system räknas in i det publika API:ts statistik. Det publika API:t är avsett för extern användning.
Detta om rent intern användning. Därutöver har vi även externa tjänster (apparna exempelvis) där behoven mer liknar det öppna API:t. Hur det kommer sig att vi har ett internt API för dessa tjänster hoppas jag att vi kan ta i en egen tråd, i kategorin för frågor om API:t, så att andra som är intresserade av ämnet har större möjlighet att hitta dit?
Framför allt skulle det bli mer resurseffektivt när det som skapas eller inköps för allmänna medel kan användas gemensamt av offentligt förvaltning och andra. Det bidrar också till större transparens och snabbare utveckling då man inte är begränsad till interna resurser på Sveriges Radio och hos leverantören och vad dessa finner för gott att åtgärda. Forumet fungerar inte särskilt bra i dagsläget, det är buggar i editorn så tecken försvinner när man redigerar, man har godtyckligt valt att ta bort funktioner som fetstil och citeringar som gör texten mer läsbar, det är svårt för läsare att hitta i ärenden och frågeställningar över tid. Många förslag och problem har lämnats utan åtgärd sedan flera år då de rapporterades. Som nämnts tidigare tror jag också det skulle bidra starkt till kompetensutveckling och förståelse för omvärlden i verksamheten.
Sedan tycker jag frågeställningen är en aning bakvänd.
Vad som vore mer än intressant att höra är vad som blir bättre för era lyssnare och läsare genom att lägga allmänna medel på utveckling av externt och privat ägda, slutna och leverantörslåsta produkter som allmänheten i trots sin egenskap av finansiär inte har rättighet eller tillgång till och som inte kan återanvändas eller utvecklas oberoende av en enskild leverantör. Hur rationaliserar ni detta?
> Om vi bygger en ljudspelare för ett internt system, finns det andra sätt att hämta ljuden och vi slipper konkurrera med publika anrop i distributionsnätverk och lastbalanserare.
Det du nämner har bara med driften att göra och inte med utvecklingen, ni kan mycket väl driftsätta externa och interna system med åtskild resurstilldelning, samtidigt som de är baserade på samma kodbas eller programvarukomponenter.
Vi utvecklar eget där det behovet finns, som för vårt webbpubliceringssystem (CSM) Isidor, där det inte finns något standard-CSM som kan hantera ljud på det sätt vi har behov av.Har du kontaktat Kundo om detta? Annars får du gärna beskriva problemet närmare i ett eget inlägg här, så tar jag upp det med deras utvecklare.Jag hör med dem vad det beror på. Några funktioner finns kvar, men saknar knappar. Markera ett ord och välj ctrl + b för fet stil och ctrl + iför kursiv stil.Det handlar delvis om hur vi som svarar i forumet väljer vad som ska synas. Syftet med detta forum är främst att vi på Sveriges Radio ska förstå problem och behov och hjälpa lyssnare att lösa dessa. Vi väljer därför att lyfta fram aktuella frågor som många ställer, medan förslag och frågor som inte har lika stort allmänt intresse inte syns utåt, men vi ser även dessa frågor internt och har med dem i diskussioner med utvecklarna. Ibland väljer vi att länka in relevanta delar av en frågas historik om samma fråga kommer in på nytt.
Det är alltså ett val vi har gjort själva, snarare än en teknisk begränsning. Att utveckla ett skräddarsytt forum för just Sveriges Radios support-behov, tror jag inte hade påverkat den saken.Det är jag väl medveten om, men ett annat forum-verktyg löser inte det problemet. Om du vill ta del av historiken kring ett visst ämne och inte hittar tillbaka till det som skrivits tidigare, exempelvis förslaget om att tablåerna ska expandera stegvis, så posta en ny fråga. De mindre synliga trådarna är inte hemliga, och de olösta frågorna är inte glömda.
> Att utveckla ett skräddarsytt forum för just Sveriges Radios support-behov, tror jag inte hade påverkat den saken.
Det handlar inte alls om att utveckla egna skräddarsydda system, tvärtom handlar det just om standardisering och återanvändning, och jag undrar om ni gör en avsiktlig misstolkning för att slippa ta ställning eller ändra på något, eller om ni faktiskt inte förstår vad öppen källkod innebär.
Då förefaller det än mer viktigt att ni försöker utöka er kompetens genom praktiska erfarenheter som en nödvändig förutsättning för att alls kunna föra diskussioner kring ämnet.
För att ta exemplet med diskussionsforum så finns det redan ett flertal existerande öppen källkods-produkter som används standardmässigt. Några av de mest populära är t.ex. Discourse och NodeBB. Poängen är just att man kan återanvända och vidareutveckla det andra skapat och lagt ned resurser på.
Varför skulle underhållet och utvecklingen av en existerande öppen källkodsprodukt bli mer kostsamt? Det är något som kan delas av de offentliga verksamheter som använder produkten och resultatet av investeringar i utvecklingen är öppna för allmänheten att ta del av. Vill man inte göra det själv kan man lägga ut det på en leverantör så som det ändå fungerar i nuläget, och jag förstår inte heller där vad lyssnarna skulle tjäna på att källkoden inte är öppen och har Sveriges Radio som produktägare.
Ett argument om egen utveckling är bara relevant om det gäller något helt unikt och specifikt för den egna verksamheten, och jag kan inte se varför det skulle vara fallet med vare sig supportforum eller ljudproduktion för public service, det är aktiviteter som drivs med etablerade tekniker och metoder över hela världen.
Vilka forumtjänster har ni gjort jämförelser mellan när ni upphandlade den nuvarande tjänsten och vilka kriterier var avgörande för valet av tjänst? Jag förmodar att upphandlingen finns redovisad någonstans som offentlig handling.
> Har du kontaktat Kundo om detta? Annars får du gärna beskriva problemet närmare i ett eget inlägg här, så tar jag upp det med deras utvecklare.
Om jag gör backsteg och raderar ett tecken framför ett blanksteg så försvinner även blanksteget, det händer ofta och är rätt irriterande. Det är ni som betalar Kundo för tjänsten så jag tycker inte ni ska lägga supportärenden på mig som användare när en tjänsten som jag inte valt själv fungerar dåligt. Jag har redan rapporterat problemet med borttagen citeringsfunktion i deras forum och blev hänvisad till att installera ett tilläggsprogram i min webbläsare för att formatera text.
Hade forumets källkod varit öppen hade jag själv kunnat bidra till att felsöka och finna en lösning på problemet. Jag gillar inte att vänta på andras godtycke att informera om eller lösa problem, särskilt inte när det gäller verksamheter som ska tjäna allmänheten och bekostas av skattemedel, där vill jag gärna ha rätt och möjlighet att förstå och påverka vad som händer.
Jag ber om ursäkt över det missförståndet som ligger helt på mig och inte speglar Sveriges Radios kunskap om vad öppen källkod innebär.Det stämmer att Sveriges Radio tillämpar LOU vid upphandlingar av och tjänster, men vad det innebär för hur detaljerat kraven redovisas publikt, vet jag inte. Jag försöker kolla upp det och återkommer.
När vi senast upphandlade forumtjänsten, lämnade jag synpunkter på juridiska, tekniska och funktionella krav, men jag tror inte att öppen källkod var en faktor som då vägdes in.Det var inte min avsikt att lägga över detta ansvar på dig. Jag tar förstås detta vidare till Kundos support. Som jag skrev får du gärna beskriva problemet närmare i ett eget inlägg här, så tar jag upp det med deras utvecklare, men jag rapporterar in det du nu beskrivit (ihop med något som kan vara relaterat, som jag stött på när jag redigerat tidigare kommentarer), och återkommer om de behöver mer information. Du får en dold kopia till den e-postadress du använder i forumet.
Jag frågar även varför de formateringsfunktioner som en gång lades till efter ditt förslag, har tagits bort. Även det med dold kopia till dig.
Trevlig helg och förlåt min misstolkning av ditt förslag om att byta supportplattform till en som bygger på öppen källkod.
Nej, jag menade det jag skrev, att övergå till en öppen källkodslösning - som naturligtvis för en vanligt förekommande tjänst oftast är en existerande produkt - och låta någon av era nuvarande leverantörer drifta och underhålla tjänsten mot ersättning eftersom de redan besitter sådan kompetens. Sedan är det ju annan fråga om de skulle åta sig detta, så alternativet att anlita en annan leverantör är möjligen mer plausibelt, men poängen var dels att produkten och leverantören kan vara oberoende, dels att ingen involverad part behöver förlora på det, och att det finns mycket att vinna ur en samhällsekonomisk synvinkel. Faktiskt är det så att jag som skattebetalare tycker det nuvarande slentrianmässiga upplägget med att bekosta underhåll och utveckling av tillgångar under enskilt ägande känns mycket onödigt och tveksamt och kanske till och med oförsvarligt vid en sådan jämförande analys. Byter man leverantör förlorar man samtidigt all tillgång till resultatet av dittills investerade resurser.
Hoppas attityden till och förståelsen för öppen källkod kan utvecklas till det mer positiva inom den offentliga sektorn framöver (och särskilt då Sverige hamnat på efterkälken på detta område), då det borde lämpa sig i synnerhet inom sådan verksamhet där det inte föreligger konkurrensmässiga hinder att dela och återutnyttja resurser och lösningar.
Du skrev att Sverige har hamnat på efterkälken. Kan du ge exempel på länder där det finns ett starkare stöd? (Gör nog varken till eller från för hur vi på Sveriges Radio arbetar eller borde arbeta med frågan, men jag blev lite nyfiken.)
Bra fråga, det verkar finnas en del verksamheter som faktiskt gör investeringar i öppen programvara.
https://computersweden.idg.se/2.2683/1.764157/oppen-kallkods-konsulten-skriver-nytt-storavtal-med-skatteverket
2022-03 Öppen källkods-konsulten skriver nytt storavtal med Skatteverket
Jag kan inte säga på rak arm hur det ser ut i dagsläget, men såvitt jag vet ligger Sverige inte bland de främsta i Europeiska jämförelser vad gäller öppna data och digitalisering, och det finns troligen en stark korrelation till acceptans för, kompetens inom och användning av öppen källkod..
Här nedan är en rapport med en jämförande tabell som visserligen är från 2016.
Om ni ser till ert eget exempel, hur upplever ni på Sveriges Radio att utvecklingen har framskridit vad gäller öppna data och öppen källkod de senaste 6 åren?
Rapporten nämner både positiva och negativa tendenser.
https://joinup.ec.europa.eu/sites/default/files/news/attachment/ramboll_rapport_slutversion_-_internationell_utblick_oppen_programvara_31_mars_2016_pdf.pdf
"
Öppen programvara inom offentlig sektor i Sverige
* Ingen aktiv styrning eller preferenspolitik kring öppen programvara bedrivs inom
svensk statsförvaltning.
* Ingen central aktör i Sverige har tagit något samlat grepp kring att analysera frågan under den senaste tioårsperioden. Flera utredningar har dock pekat på potentialen.
* Få centrala beslutsfattare har en tillräcklig förståelse för IT och källkod, vilket
begränsar förutsättningarna för att identifiera strategiska möjligheter och
långsiktigt driva igenom migrationsarbete
* Finns en ovilja att frångå befintliga sammanhållna proprietära lösningar till förmån för inslag av öppen programvara
* Otillräcklig beställarkompetens kring öppna programvarulösningar, särskilt bland mindre IT-resursstarka offentliga aktörer
* Vanans makt gör att upphandlande aktörer endast vänder sig till traditionella leverantörer
"
En annan rapport från OECD.
https://www.oecd.org/gov/digital-government/digital-government-review-of-sweden-2018.pdf
https://computersweden.idg.se/2.2683/1.748296/oppen-kallkod-samverkan-nosad
2021-03 Öppen källkod och bättre samarbete behövs för digitaliseringen av offentlig sektor
"
Potentialen är därav stor samtidigt som svårigheterna är många.
En icke-existerande kultur och tankesätt kring att dela och samverka runt programvara, tillika kompetens och resursbrist är vanligt förekommande argument vi stöter på inom myndighetsnätverket Nosad.
"
När jag tänker efter så tror jag myndigheten för digital förvaltning har en policy med rekommendation om öppen källkod som förstahandsval.
https://nosad.se/tips
> * Diggs policy för utveckling av programvara | DIGG
https://gitlab.com/open-data-knowledge-sharing/wiki/-/wikis/uploads/f101bdec3e1bd05889b02a1c974b3b19/Policy_f%C3%B6r_utveckling_av_programvara.pdf
> Programvara som utvecklas/anskaffas ska i normalfallet publiceras som öppen
källkod. Ett skäl till detta är att villkor för att dela med oss av programvaran,
äganderättsfrågor mm därmed blir reglerade på ett standardiserat sätt.
Licensval ska beslutas innan arbetet påbörjas.
Mer rekommendationer för upphandling finns på samma sida.
> Krav vid anskaffning av IT-system
> * Fem rekommendationer för lyckad upphandling av öppen programvara | Högskolan i Skövde
https://www.mynewsdesk.com/se/his/pressreleases/fem-rekommendationer-foer-lyckad-upphandling-av-oeppen-programvara-3108346
Tack! Jag ber Annika återkoppla till dig så fort hon är tillbaka. Som du förstår så är jag alldeles för dåligt påläst i ämnet för att kunna bidra med något när du och Annika diskuterar! Jag överlåter denna diskussion till proffsen.
Önskemål om att rotera appen
Vill lyssna på P1 Kultur från i tisdags