Sveriges Radio och öppen källkod
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
0
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 ...
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 Utbränt kärnbränsle ska förvaras i Forsmark - Nyheter (Ekot):
"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."
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 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 rörde 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 av 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 referens-app för att visa vårt API i praktiken vara en del av Sveriges Radios uppdrag? Om det behövs en referens-app för att förstå hur vårt API fungerar, har vi absolut misslyckats med dokumentationen och i så fall 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 förstått 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?
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?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 + i för kursiv stil.Det handlar delvis om hur vi som svarar i forumet väljer vad som ska synas. Syftet med forumet ä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 samma allmänintresse 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 frågan 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.
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.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:
Report (europa.eu): Öppen programvara inom statsförvaltningen
Ö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
Öppen källkod och bättre samarbete behövs för digitaliseringen av offentlig sektor” | Computer Sweden (2021-03):
https://nosad.se/tips
Diggs policy för utveckling av programvara | DIGG
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
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.
Public money? Public code!
Free Software Foundation Europe kampanjar för ny lagstiftning inom EU att all offentligt finansierad programva bör släppas som fri- och öppen. Vinsterna samhället kunde åtnjuta av detta är potentiellt rent av enorma.
Man kan föreställa sig effekten ifall all Sveriges Radios, och alla myndigheters, förvaltningars, offentliga bolags, programvara ner till minsta lilla dator, mobil, ljudkort, etc, var 100% GPLv3-kompatibel. Det skulle möjliggöra:
- Att alla andra offentliga eller privata organisationer - i hela världen - skulle ha möjlighet att kopiera, studera, anpassa, använda och vidareutveckla koden för sina egna syften helt utan licensavgift eller byråkratiska avtal.
- Angränsande verksamheter och förvaltningar skulle inte behöva "uppfinna" hjulet eller betala licens till -någon-.
- Att alla barn och vuxna som kan eller kan lära sig ett programmeringsspråk skulle ha full insyn i hur programmen var konstruerade. De kunde ta lärdomar till sina egna studier eller arbete, de kunde upptäcka fel och brister. Vi utgår från att merparten av medborgarna (som läser koden) har goda avsikter, som vi gör med allt annat offentligt.
- Att i stort sett alla yrkesprogrammerare kunde anställas eller hyras in för att vidareutveckla programmen efter enskild organisations behov, tycke och smak, det skulle vara en helt jämställd konkurrens om arbetstillfällena istället för baserat på vilken tech-gigant enskilda programmerare specialiserat sig eller kostsamt certifierat sig inom.
- För att inte tala om den filosofiska aspekten. Idag sitter vi i knät på mjukvaruföretagen, får ta det som serveras och vårt enda styrmedel är genom plånboken. Jag jobbar själv i offentlig förvaltning och ser hur våra värden sipprar mellan fingrarna som sand i ett timglas. Vi behöver ta kontroll över programmen själva enligt principen: Det är användarna som ska kontrollera programmen, inte programmen som ska kontrollera användarna. Till syvende och sist är det en demokratifråga, som jag inte begriper hur den kan komma så långt ner på agendan.
Mvh RobertJust nu är jag ensam i supportforumet och hinner inte ta hand tag i detta på det vis jag vill - där det viktigaste är hur jag för frågorna vidare till dem på Sveriges Radio som har mer att säga till om när det rör strategier. I mitten av juni kommer dock min kollega Ted tillbaka från sin föräldraledighet. Med fördubblad bemanning i forumet hoppas jag kunna ta frågan vidare!
På det hela taget kan man dock säga att de utmaningar som Nosad pekade på i Johannes citat från i juni i fjol i hög grad är relevanta även för oss på Sveriges Radio.
Jag har även bytt rubrik på tråden, från Öppen källkod för SR Play (specifikt om utvecklingen av våra mobilappar) till det bredare Sveriges Radio och öppen källkod, som även inkluderar upphandling av externa tjänster, exempelvis ett supportforum.
Först vill jag sammanfatta vad som skrivits hittills, eftersom tråden påbörjades för snart fyra år sedan ...
Inlägg som skrivs hit anonymiseras efter ett år, så det kan vara lite svårt att hänga med i vem som har skrivit vad, men trådstartaren Rickards förslag rör alltså specifikt ett önskemål om att källkoden till våra, av allmänheten finansierade, mobilappar SR Play skulle släppas som öppen källkod under t.ex. GNU licensen eller liknande vilket bland annat skulle ge en bättre möjligheter att felsöka och också kunna bidra med bugfixar och pull-requests.
En annan lyssnare tillade en mer allmän reflexion:Ytterligare något inspel kom, bland annat från en lyssnare antog att vi kanske inte har rätt att släppa koden fri, ifall vi köper in det hela som en tjänst av tredje part.
Vi på Sveriges Radio var väldigt osynliga tills då (vilket hade med supportens arbetsbelastning att göra, och denna fråga, som det tar tid att formulera sig kring, helt enkelt sköts på framtiden in absurdum), men i juni 2021 berättade jag att mobilapparna visserligen är egenutvecklade, men att det ingår komponenter som inte är våra egna och som vi därmed inte får lägga ut. Dessutom finns det skyddat innehåll i apparna som gör att det skulle bli juridiskt knepigt om vi beskrev exakt hur filerna lagras och vad som styr att de raderas.
Jag berättade även att det finns en komplexitet med oerhört många särfall att ta hänsyn till för mobilapparna, att vi inte har drivit Open Source-projekt i större skala tidigare (och drog en lite förvirrande jämförelse med vårt öppna API, där vi visserligen välkomnar förslag på förbättringar, samtidigt som vi i praktiken inte har varit bra på att tillvarata dessa förslag), samt att öppen källkod kan medföra säkerhetsproblem. Koden blir tillgänglig även för den som vill sabotera.
Jag berättade även om möjligheten finns att "bygga en egen Open Source-app" samt citerade vår utvecklingschef Camilla Jettman som övergripande berättade om erfarenheterna från ett helt annat utvecklingsprojekt med öppen källkod.
Johannes bad mig att förtydliga delar av detta svar, vilket jag gjorde.
(Fortsättning följer ...)
I maj 2022 undrade Johannes om vårt samarbete med EBU, European Broadcasting Union, skulle kunna påverka Sveriges Radio till en ökad användning av öppen programvara, eftersom EBU upprätthåller och publicerar en tämligen omfattande katalog över just öppen programvara för radiodistribution.
Jag beskrev att EBU (som vi har varit en del av i drygt 70 år) utvecklar stöd för många public servicebolag och arr öppen källkod då är ett smart sätt att ge oss medlemmar - och andra - möjlighet att vidareutveckla koden. För Sveriges Radios tjänster finns inte samma behov, eftersom dessa är direkt till för våra lyssnare eller för interna behov.
Jag kontaktade Jørgen Bang på EBU som berättade att open source diskuteras regelbundet inom EBU. Han höll med om att deras uppdrag lämpar sig för öppen källkod på ett annat vis än Sveriges Radios. Dessutom sa han att flera EBU-projekt har ett mellanläge där kod inte är publik, men fri att använda (och vidareutveckla, som jag förstod det) för EBU:s medlemmar.
Johannes tyckte även att 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 misstänkte att det är jag som inte lyckas förklara och förmedla vår inställning, samt berättade om en konferens där många kolleger på utvecklingssidan diskuterade öppen källkod. En av dessa kolleger är Zakarias Faust, som leder arbetet med en ny plattform för streaming. Han berättade att de hade ringat in fem aspekter som kan göra att öppna lösningar är att föredra framför proprietära och att diskussionen hade utmynnat i denna slutsats:
När Open Source är ett bättre alternativ än andra alternativ så ska vi nyttja det.
Zakarias berättade även att hans eget utvecklingsteam har två uttalade mål:
- Utforska Open-source när det är möjligt och relevant
- Publicera egenutvecklade mjukvaror som Open-source när det ökar SR:s utvecklings förmåga
Open Source absolut inte alltid rätt väg, utan vi gör en bedömning från fall till fall, sammanfattade han det hela.(Fortsättning följer ...)
Rekommendationer för lämplig anskaffning och användning av globalt tillhandahållna SaaS-lösningar (Professor Björn Lundell, Software Systems Research Group, Högskolan i Skövde)
Från konferensen Hållbar digitalisering 2023.
Sammanfattning del 3:
Johannes föreslog att Sveriges Radio skulle kunna 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 har framfört detta förslag när vi har kommit med förslag från lyssnare i samband med att utvecklarna har haft kompetensutveckling, men hittills har vi inte gått vidare med det.
Förslaget finns kvar bland sådant vi tipsar om. Som Johannes skrev så faller det inom 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.
Vi kom även in på frågan om skillnaden mellan det öppna API:t och det API vi använder internt, vilket blev en egen tråd.
I juni 2022 lanserade Johannes det förslag som han nyligen påminde oss om, nämligen att Sveriges Radio borde använda ett supportforum baserat på öppen källkod.
Det tog ett tag innan jag förstod att Johannes inte menade att vår nuvarande leverantör skulle övergå till öppen kod i vår nuvarande forummiljö (eller att vi skulle utveckla den här typen av "stödsystem" själva i öppna projekt). Förslag är alltså att vi borde byta plattform till en icke proprietär, där den viktigaste anledningen är att det skulle bli mer resurseffektivt om det som skapas eller inköps för allmänna medel kan användas gemensamt av offentligt förvaltning och andra. Ökad transparens och är en annan fördel. Johannes menar även att öppen källkod skulle leda till 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.
Specifika problem togs upp, där avsaknad av formateringsmöjligheter och en bugg vid blanksteg har med forumets drift att göra medan andra frågor, som att det är svårt att återfinna tidigare trådar och problem som inte blir lösta under lång tid trots bra felrapporter från lyssnare beror på andra faktorer.
Frågan är förstås tillämpbar på fler system hos Sveriges Radio än supportforumet, men även för fler offentligt finansierade verksamheter än Sveriges Radio. Är öppen källkod något som vägs in som en fördel vid upphandlingar? Jag frågade om det idag finns någon svensk kommun, myndighet eller offentligt finansierad verksamhet som har uttalat att öppen källkod är ett plus vid exempelvis en upphandling av verktyg, och Johannes gav som exempel att Skatteverket har en konsult för just öppen källkod:
Computer Sweden, mars 2022: Öppen källkods-konsulten skriver nytt storavtal med Skatteverket
(Fortsättning följer ...)
Johannes skrev i juni 2022:Jag blev nyfiken på om det finns belägg för att Sverige ligger efter jämförbara länder. Johannes länkade till flera intressanta rapporter, lyfte fram bilder och citat från dessa rapporter samt frågade:
... hur upplever ni på Sveriges Radio att utvecklingen har framskridit vad gäller öppna data och öppen källkod de senaste 6 åren?
Johannes återkom sedan och berättade att Myndigheten för digital förvaltning, DIGG, har en policy med rekommendation om öppen källkod som förstahandsval både vid upphandling och egen utveckling av programvara.
Ted svarade att han skulle be mig att återkoppla, vilket han har bett mig göra. Att jag inte har återkommit ligger alltså inte på honom.
I juni i år anslöt sig Robert till tråden och berättade om en kampanj från FSFE (Free Software Foundation Europe), "Public money? Public code!" och jag lovade att jag skulle återkomma, men inte förrän min kollega Ted var tillbaka efter sin tjänstledighet.
Förra veckan påminde alltså Johannes om att en bugg i forumets textredigerare som han har rapporterat in för länge sedan ännu kvarstår och menade att ett forum baserat på öppen källkod skulle medföra att den typen av buggar åtgärdades (snabbare).
Och därmed har jag återkommit till den här tråden, gett den en ny titel och gjort en sammanfattning i fyra delar (mycket för min och mina kollegers skull). Johannes har då även kommit med ett tips på en föreläsning av professor Björn Lundell, Software Systems Research Group, Högskolan i Skövde.
Slut på sammanfattningen! Nästa inlägg blir vanlig återkoppling och nya reflexioner.
Offentligkod.se
Där ges exempel på myndigheter och organisationer som använder olika tjänster, och båda de öppna forumplattformar som vi nämnt tidigare i tråden, Discourse och NodeBB, finns med. Discourse skall användas av Arbetsförmedlingen, men jag har inte hittat var. Det kanske är internt? NodeBB används däremot av Digg, Myndigheten för digital utveckling i deras
Community på Sveriges dataportal
Går det att jämföra hur vi på Sveriges Radio (och vår leverantör) respektive Digg och NodeBB hanterar förslag och problemrapporter som rör själva forumet? Kanske. Den bugg Johannes påminde oss om rör alltså själva texteditorn i forumet:Detta har vi framfört till företaget som utvecklar och driver plattformen, som har svarat att det är en bugg i den version av texteditorn som de använder sig av och att lösningen skulle vara att uppgradera till en nyare version, vilket dock är ett så omfattande arbete att de inte har prioriterat att lösa detta.
I Diggs forum har signaturen jonor i oktober 2021 rapporterat in en bugg:Relativt snart har Digg undersökt det hela:Både vid blankstegs-buggen i vårt forum och ångra-buggen i Diggs forum är alltså orsaken till problemet känd. Lösningen i båda fallen skulle innebära att man byter ut själva editorn (eller, för Diggs del, själva rättar eller hjälper NodeBB att lösa problemet). Någon (vår underleverantör respektive Digg) bedömer dock att arbetsinsatsen är för stor i förhållande till de förbättringar det skulle leda till och har därför inte prioriterar att lösa buggen.
I Diggs fall är det oppen källkod, vilket gör att det finns en teoretisk möjlighet att själv bidra till att lösa felet, men hur man i så fall ska gå till väga verkar vara otydligt. I november 2022, skriver jonor (i samband med en helt annan nedprioriterad bugg):Nu är detta förstås ett anekdotiskt exempel, men även med ett forum baserat på öppen källkod kan buggar uppenbarligen prioriteras ned, trots att man vet vad de beror på.
Det finns dock andra argument för öppen källkod. Du skrev själv:I tråden om blankstegsbuggen ställde du ett par frågor, som jag flyttar hit:
- Vilka kriterier/funktionella krav gällde för upphandling av nuvarande supportforum?
- Vilka alternativ togs i beaktande vid upphandlingen och jämfördes efter sådana kriterier?
- Vem är ansvarig på SR för anskaffande och drift av supportforumet?
- Känner ni själva till och kan ge några exempel på andra offentliga institutioner som driver kundtjänstforum och vad de använder för tjänst. Finns det några alternativa lösningar eller använder alla samma leverantör?
På den sista frågan har vi ju ett tydligt exempel i Digg som använder NodeBB, men jag vill leta upp fler exempel, och gärna då några som inte använder den plattform som vi har (för det känner jag till ett par kommuner och myndigheter som gör).Såvitt jag vet har de inte betalat ett öre till utvecklarna av NodeBB eller den editor som används i forumet.
Sveriges Radio har betalat skattemedel till forumleverantören, som valt att lägga resuserna på annat än att uppdatera en föråldrad editorkomponent.
DIGG har också haft möjligheten att anlita en programmerare för att redigera källkoden och lösa problemet. Jag vet inte varför de inte har gjort det. Vad de menar med att problemet är "by design" och ligger på en djupare nivå är svårt att förstå. De gör inga hänvisningar till själva källkoden, så det är förmodligen andrahandsinformation vidareförmedlad av någon kommunikatör som inte är tekniskt insatt.
Sveriges Radio hade med tillgänglig källkod också kunnat avsätta resurser från sin egen programmeringsavdelning för att lösa problemet, vilket hade kommit även DIGGs forum till del.
Editorn i NodeBB är utbytbar via ett pluginsystem. Är man inte nöjd med standardeditorn så kan man byta ut den mot en annan komponent såvitt jag förstår. Man kan undra då varför det skulle ta flera år för en leverantör av en forumtjänst att åtgärda detta.
https://github.com/NodeBB/nodebb-plugin-composer-default
https://github.com/NodeBB/nodebb-plugin-composer-quill
Ironiskt nog så verkar det råda brist på digital kompetens hos myndigheten för digital förvaltning, då det föreligger flera möjligheter att lösa problemet på eget initiativ, något de valt att inte göra utan bara konstaterar att de inte orkar, begriper eller kan göra något åt det. Istället för att leta upp någon som kan, väntar de passivt på att någon annan ska göra det gratis åt dem.
Problemet ligger alltså på flera nivåer, dels att leverantören drar fötterna efter sig och skyller ifrån sig under det att de fortsätter att ta betalt för driften, dels att "kunden" inte själv har vilja eller förmåga att åtgärda problem på adekvat vis trots att möjligheten finns.
Att vi som arbetar med teknisk support på våra egna tjänster även hanterar felrapporter om ett verktyg vi har köpt är naturligt, men inte ens vi har alltså fått in felrapporter om det här problemet från någon annan än dig, trots att det startas cirka 100-130 nya trådar per månad i forumet. Vår slutsats är att forumets besökare inte ser denna bugg som något större hinder. (Gissningsvis är det få av leverantörens forum som ens får buggrapporter om forumtjänsten. Att rapportera in en redigeringsbugg till ett företag som säljer exempelvis skor kommer inte lika naturligt och om det hypotetiska skoföretaget väl får in något om forumets teknik, är nog deras benägenhet att föra det vidare till leverantören lägre än vår, så min gissning är att dina felanmälningar, filtrerade genom Ted och mig, är den enda återkoppling som forumleverantören har fått om problemet.)Inte jag heller, men jag gissar att de bedömer att den potentiella nyttan är för låg för att motivera kostnaden.Även det hade i så fall baserats på att vi bedömt att det vore väl använda pengar, vilket vi troligen inte hade gjort med vare sig den bugg vårt eget proprietära forum dras med eller med den bugg jag sett beskriven i Digg-forumet. Även om Digg hade löst det och tydligt dokumenterat vilka delar av koden som behöver ses över när man byter plug in, så är det inte säkert att vi hade frigjort utvecklartid och följt deras beskrivning.
Men mer generellt, så stämmer det förstås att en styrka med öppna lösningar är att de resurser som en användare lägger på utveckling (både att lösa buggar och nyutveckling) även kommer andra till godo. Även om jag inte tror att ett forum baserat på öppen källkod innebär att vi snabbt åtgärdar buggar av den här karaktären, så förstår jag argumentet.
Som du skriver hade kanske en tydligare förklaring från Diggs sida till vad som avses med koden är svår att komma åt för att den ligger på en djupare nivå i pluginet och att berätta mer om vilka svårigheter det finns med att byta till ett alternativt plug-in, gjort det enklare för andra att antingen lösa problemet eller acceptera Diggs nedprioritering.
Tack för länken till Arbetsförmedlingens Discourse-baserade forum!
Jag kan förstå att en fråga inte ges särskilt hög prioritet om den bara har rapporterats av en enstaka användare. Dock har ju leverantören tillstått att problemet är känt, så jag borde inte vara ensam om att ha drabbats. Själv har jag svårt att förstå varför jag ska behöva acceptera att använda en editor med redigeringsproblem som inte underhålls med existerande felrättningar på just denna forumtjänst som finansieras av skattemedel, när editorerna på andra forum och tjänster inte beter sig på detta sätt. Särskilt också som leverantörens tjänst verkar användas av ett flertal offentliga institutioner. Jag tycker helt enkelt att pengarna skulle komma till bättre användning genom att spenderas på en hållbar utveckling av öppna programvaror.
Att argumentera om "väl använda pengar" är meningslöst när det inte är tydligt vad pengarna används till i övrigt. Det är bara ett giltigt argument om man kan lägga fram en konkret lista över prioriterade åtgärder, resursfördelning och åtgång, och bakomliggande rapporter och återkoppling som lett till den gällande prioriteringen.
Angående jämförelser med alternativa tjänster och lösningar, så ställde jag även några frågor i tråden om redigeringproblemet angående anskaffandet av den nuvarande tjänsten.
Bl.a.
* Vilka kriterier/funktionella krav gällde för upphandling av nuvarande supportforum?
* Vilka alternativ togs i beaktande vid upphandlingen och jämfördes efter sådana kriterier?
Den avgörande faktorn var "pris i förhållande till kvalitét" (vilket i teorin medför att en tjänst som är gratis skulle rankas oändligt högt). Därutöver fanns det ett antal "skall"- och "bör"-formuleringar som gällde teknik och funktion, för både forumet och kunskapsdatabasen (Lyssnarservice Frågor & svar om Sveriges Radio, där vi på den tekniska supporten håller i delen om teknik & appar. Exempel på dessa ska/bör är
- Support på svenska ska ingå i priset
- Leverantören ska erbjuda gratis utbildning på svenska
- Det ska finnas möjlighet att få fram grundläggande statistik för hur tjänsten används
- Tjänsten ska ha en upptid (SLA) på 99 % och drifttid 24/7/365
- Tjänsten ska vara responsiv och fungera i olika plattformar som smartphones och läsplattor
- Tjänsten bör kunna möjliggöra inbäddning av filmer från youtube
- Användaren ska kunna ställa frågor i forumet utan att den personliga identiteten röjs
- En unik URL ska skapas för alla artiklar i kunskapsdatabasen respektive inlägg i forumet så att det går att direktlänka till respektive forumtråd eller databasartikel
- Forumet bör kunna visa vilka redaktörer det är som svarar på frågor
- Det ska vara möjligt att använda domänen sverigesradio.se för att nå tjänsten
Öppen källkod var alltså inte en del av dessa ska- eller bör- formuleringar.Själva jämförelsen mellan olika verktyg var jag inte med vid och jag vet inte vilka företag som svarade på detta avrop (men försöker se om jag hittar någon som vet). Här är några saker jag vet att de kikade på:
- hur redaktören/administratören skapar ett konto
- hur redaktören skapar en kategori och en tråd
- hur inkommande inlägg kan modereras
- vilka tekniska och grafiska anpassningsmöjligheter administratören kan göra
- hur redaktörer kan delegera uppgifter till andra personer, även utanför Sveriges Radio
Jag återkommer om ämnet.Gratis utbildning på svenska låter kanske vagt, det kan ju vara en broschyr eller tjugo timmars lärarledd undervisning, jag antar att man viktar anbud på något sätt.
Min åsikt är väl att man borde separera driftssidan från underhåll och utveckling av funktioner. Det känns lite märkligt att man accepterar fel i programvaran med anledning av att det är så resurskrävande och komplext att driva servrar och upprätthålla säkerhet. Det finns alltid något som är mer akut och krävande och potentiellt kan ta alla resurser i anspråk, och det som har lägre prioritet kommer då aldrig att åtgärdas.
Även sådant som utbildning och support på svenska kan ju erbjudas separat från utveckling och felrättning av programvaran. Där är väl också skillnaden att det står fritt för vem som helst att erbjuda utbildning, medan drift av tjänsten och underhåll av programvaran i detta fall är exklusivt för leverantören och inte kan delas upp eller utföras av någon annan.
Nedanstående handlar inte om öppen källkod men rör prioritering av utveckling, så jag tar det här:
När det gäller den aktuella blankstegsbuggen, så påverkas naturligtvis forumleverantörens prioritering av att vi på Sveriges Radio (och deras övriga kunder?) i vår tur inte har prioriterat detta speciellt högt, vilket i sin tur baseras på att vi inte ser den som ett hinder i att föra en dialog med oss.
Själv tror jag att det vore en viktigare förbättring att återställa knapparna för formatering, som du också påminde om förra sommaren, i synnerhet möjligheten att visa att delar av texten är citat. Samtidigt vet jag att "för många knappar" kan kan få en del besökare att uppleva forumet som komplicerat. Jag har föreslagit för forumleverantören att dessa knappar kan ligga under en "formateringsmeny", utan att de stjäl fokus för besökare som inte har det behovet.
Jag kontaktade forumplattformens support om detta, men mindes inte hur förslaget landade, och ser nu att de då svarade bland annat:
Bollen ligger alltså hos oss, där den sedan stannade. Mitt fel. Jag och Ted får kika på om vi vill återfå dessa möjligheter, vilka som i så fall är relevanta och om vi vill gå vidare framföra det till utvecklarna. Därefter är det deras prioriteringar som gäller.
Jag påminner om att vissa formateringsmöjligheter finns kvar, trots att det saknas knappar. Markera ett ord och välj ctrl + b för fet stil respektive ctrl + i för kursiv stil. Ctrl + u ger understruken text, vilket jag nyss märkte. Vi har ingen sådan knapp, men det är inte en upptäckt jag tror att jag har så stor nytta av, för på webben signalerar understrykningar "länk". Jag får se om jag kommer på något ställe där det blir relevant! På mobila plattformar ges liknande alternativ genom att "långtrycka" på markerad text.
I den här tråden har vi hittills inte berört frågan om fria ljudformat, men ni som är intresserade av öppen kod kanske kan vara intresserade av att vi numera erbjuder P2 och P4 Plus i det fria formatet Opus:
Använd gärna Opus, ett bra ljudformat
För P2 har vi även en "audiofil-ström" i det fria formatet Flac, se här:
P2 och P4 Plus i högre ljudkvalitet (320 kbps) samt P2 i Flac