Community på Sveriges dataportal
Open source i Sverige - en intervju
-
Open Source Observatory (OSOR) intervjuade mig kring de satsningar som Digg och Sveriges offentliga sektor gjort kring främjandet av open source (öppen källkod).
-
Even if we do not have to procure OSS, most organisations need to procure implementation, modification and support. But since requirements on OSS still is rare, organisations tends to feel uncertainties in how to administrate a procurement with OSS. It feels banal to say that the solution is creating awareness and sharing experiences, but this is exactly what is needed, because it is mostly procedural and not a legal challenge.
Intressant konstaterande, vad är det i praktiken som skulle skilja i hanteringen av en upphandling av open source programvara jämfört med proprietär?
Implementation, ändringar och kundtjänst borde fungera på samma sätt. -
@jonor skillnaden ligger i vad som kravställs och därmed utformningen av affären. En kollega till mig som är upphandlare skrev i Aforis forum. Hon skriver:
"Att börja göra upphandlingar, både där vi tillåter öppna källkodslösningar (både uttalat men också genom en icke begränsande kravställning) eller väljer en öppen källkodsprodukt och sedan upphandlar kringtjänsterna. Vi inser att det blir en ny typ av affär, det är nya saker att ta hänsyn till, nya risker och risker som skiftar. Att kunna se detta och förstå konsekvenserna av olika krav och en ändrad affärsmodell, kräver tid och stöd inte bara till upphandlaren."
Att göra saker på ett nytt sätt skapar osäkerhet. Flera upphandlare och beställare har vittnat om samma utmaningar. Därför hade vi i november en NOSAD workshop på temat Affärsmodeller och leverantörsaspekter av open source. Kolla gärna!
Passar på att också peka på NOSAD lästips. Där finns massor av matnyttigt kopplat till öppen källkod och upphandling.
Vidare har eSAM/dSAM arbetat med att underlätta för upphandling av öppna programvarualternativ genom kravspecifikation för digital samarbetsplattform.
-
@Maria_Dalhage Tack för lästipsen. Av det sagda ovan kan jag inte utläsa vad skillnaderna består i.
upphandlingar, både där vi tillåter öppna källkodslösningar
Är det vanligt att kravställningar inte tillåter öppen källkod?
ny typ av affär, det är nya saker att ta hänsyn till, nya risker och risker som skiftar
... konsekvenserna av olika krav och en ändrad affärsmodellVad är det man syftar på med nya och skiftande risker och ändrad affärsmodell?
-
@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.
