Styrning och organisering av öppen källkods-projekt: Modeller och vägval för ivis Författare: Björn Lundell och Jonas Gamalielsson, Högskolan i Skövde Datum: 2016-08-29 1 Introduktion Denna rapport ger en översikt av hur utveckling av programvara successivt har anammat principer för en öppen samverkan mellan aktörer där individer och organisatorer på olika sätt bidrar. Utifrån en historisk utgångspunkt då enskilda individer i stor utsträckning drev utvecklingen av mycket av den programvara som idag utvecklas som öppen källkod, har successivt kommersiella intressen och enskilda företag tagit allt mera strategiska initiativ inom området. Dagens utveckling av öppen källkod hanterar många utmaningar relaterat till styrning av projekten. I rapporten presenteras olika modeller baserade på tillgänglig forskning för styrning av öppen källkods-projekt. Vidare redovisas ett ramverk som utgörs av sex kategorier som omfattar olika aspekter av styrning. Baserat på detta ramverk redovisas ett antal öppna frågeställningar som behöver beaktas av öppen källkods-projekt generellt och ivis-projektet i synnerhet. Rapporten avslutas med en diskussion om möjliga ställningstaganden kring redovisade öppna frågeställningar avseende styrning för att etablera ett långsiktigt framgångsrikt ivis-projekt. 2 Om öppen källkod 1.0 till professionell öppen källkod Ända sedan slutet av 1960-talet har praktiker och forskare konfronterats med flera olika utmaningar vid utveckling av programvara för att hantera problem i en allt mer komplex omvärld, något som bidragit till att programvara idag många gånger utvecklas i en öppen samverkan och där utvecklad programvara tillgängliggörs under licenser som utan restriktioner möjliggör användning och vidareutveckling (Lundell & van der Linden, 2013). Från att ursprungligen ha varit en rörelse där engagerade individer, starkt inspirerade av Richard Stallmans initiativ som ledde till bildandet av organisationen Free Software Foundation redan 1985 (FSF, 2016), drevs av starka ideologiska förtecken som betonar vikten av att källkod för programvara fritt ska kunna inspekteras, användas, modifieras och vidaredistribueras har allt fler aktörer successivt tagit till sig ett nytt arbetssätt, inte minst efter att organisationen Open Source Iniviative (OSI, 2016) bildades 1998. Genom detta betonas också vikten av en öppen samverkan för att utveckla och tillgängliggöra programvara och i detta sammanhang är den licens som reglerar hur programvara kan nyttjas av central betydelse. Ett öppen källkods-projekt är ett programvaruutvecklingsprojekt där programvaran tillhandahålls under en licens som är erkänd av organisationen Open Source Initiative (OSI, 2016). Programvara som tillhandahålls under en (eller flera) av dessa licenser benämns öppen 1 (14)
källkod 1. Viktiga licenser som utvecklats av Free Software Foundation (som exempelvis GPL 2 ) är också erkända som öppen källkods-licenser utifrån den definition 3 av öppen källkod som ligger till grund för alla OSI-godkända licenser och GPL (i alla dess varianter och versioner) är också erkänd av OSI som en öppen källkods-licens. Centralt för att reglera former och villkor för samverkan är den licensmodell som säkerställer rätten att nyttja, modifiera och vidareutveckla den programvara som utvecklas och tillgängliggörs under denna typ av licenser (Lundell & van der Linden, 2013). Det finns flera olika licenser som kan användas för att utveckla och tillgängliggöra öppen källkods-projekt, även om merparten av all programvara som tillgängliggörs som öppen källkod använder en (eller flera) av ett tiotal vanligt förekommande licenser för öppen källkod 4. Forskning visar att val av licens för ett projekt kan spela mycket stor roll för beslut avseende huruvida enskilda individer och enskilda organisationer väljer att engagera sig i ett projekt samt huruvida de väljer att använda resultat från enskilda projekt, exempelvis finns resultat som visar att små företag kan ha starka incitament och motiv som gör att de föredrar GPLlicensen (Lundell et al., 2011), vilket inte nödvändigtvis är fallet bland större företag. Vidare visar forskning att förändringar av vald licens (vilket endast kan göras av rättighetsinnehavaren) kan orsaka missnöje bland aktörer som medverkar i projektet, speciellt i situationer då förutsättningarna för att använda och engagera sig i ett projekt kan påverkas negativt för enskilda aktörer (Gamalielsson & Lundell, 2013). Från att tidigt primärt intresserat och engagerat enskilda individer och icke-kommersiella organisationer har successivt allt fler företag och kommersiell intressen engagerat sig i denna typ av utveckling (Lundell et al., 2010). Idag finns många exempel på programvara som utvecklats i en öppen samverkan där olika individer och organisationer, på olika sätt, är engagerade. Ett antal myndigheter var tidigt ute med att använda öppen källkod i Sverige vilket framgår av en tidig kartläggning som publicerades av Statskontoret (2003) och av forskning inom området som visar att organisationer i offentlig sektor i Sverige tidigt använde öppen källkod (FLOSS, 2002). Ett sätt att betrakta företags engagemang med öppen källkods-projekt är att skilja på huruvida ett enskilt företag självt eller en öppen gemenskap har initierat projektet. Ett annat sätt är att skilja på huruvida ett eller flera företag är strategiskt involverade i projektet (Schaarschmidt et al., 2015). Följande tabell (inspirerat från Schaarschmidt et al., 2015) illustrerar fyra typfall med typiska illustrativa exempel på öppen källkods-projekt för var och en av dessa. Projekt som initierats av ett enskilt företag Projekt som initierats av en gemenskap (eng. community) Ett företag dominerar MySQL SugarCRM Flera företag engagerade Android Linux 1 Begreppet öppen källkod används i denna rapport med samma betydelse som det Engelska begreppet open source software. 2 https://www.gnu.org/licenses/#gpl 3 Se definitionen för öppen källkod, https://opensource.org/osd-annotated 4 OSI förvaltar en lista med alla licenser och listar även de som är populära, https://opensource.org/osdannotated 2 (14)
Traditionell kunskap om styrning av företag och andra typer av organisationer utmanas av nya former av öppen samverkan och samverkan genom öppen källkods-projekt är ett tidigt exempel på detta (Lundell & van der Linden, 2013; Morgan & Finnegan, 2014). Samverkan kring denna typ av projekt omfattar ofta ett antal intressenter där olika typer av organisationer och individer bidrar och är involverade utifrån olika intressen. Bland utvecklare och andra aktörer som på olika sätt är knutna till ett öppen källkods-projekt återfinns kan enskildas motiv för att bidra till projektet omfatta en rad olika incitament och drivkrafter (Bonaccorsi & Rossi, 2006). Utifrån ett enskilt företags affärsidé kan det finnas en lång rad skäl som motiverar att företaget, på ett eller annat sätt, engagerar sig och bidrar till ett specifikt öppen källkodsprojekt. Beroende på hur målet för ett specifikt projektet relaterar till det enskilda företagets verksamhet och affärsidé kan en lång rad incitament urskiljas, där företagets långsiktiga mål att skapa värde måste relateras visioner och mål för det specifika öppen källkods-projektet. En rad modeller för att skapa värde för företag och arbeta strategiskt med öppen källkod har identifierats i litteraturen (Lundell et al., 2010; Morgan et al., 2012). Ett enskilt företags engagemang i ett specifikt öppen källkods-projekt kan vara av strategisk eller mer perifer betydelse och även variera över tid beroende på en rad faktorer, vilket kan avspegla sig i varierande omfattning och typ av engagemang för enskilda individer, företag och andra typer av organsiationer. 3 Förvaltning av olika typer av öppen källkods-projekt Frågor angående styrning av öppen källkods-projekt som organisationer behöver ta ställning till inkluderar aspekter avseende hur ett företag kan styra och ha kontroll över strategiskt viktiga aktiviteter och processer i projektet samt frågor angående hur det möjligt att samverka med externa parter (Schaarschmidt et al., 2015). Tidigare forskning har identifierat tre huvudsyften med styrning av öppen källkods-projekt (Di Tullo & Staples, 2013). Ett syfte är att uppmuntra samverkan mellan aktörer som medverkar i projektet för att ta sig an gemensamma utmaningar. Ett annat syfte är att koordinera programvaruutvecklingen i ett öppen källkods-projekt. Ytterligare ett syfte är att etablera och stimulera en ändamålsenlig atmosfär i projektet som engagerar och motiverar utvecklare. Betydelsen av dessa aktiviteter varierar beroende på typen av öppen källkodsprojekt, och för många projekt är det en utmaning att uppnå en långsiktigt framgångsrik styrning som stimulerar och tillvaratar aktörernas intressen. I ett ramverk identifieras tre typer av modeller för att styra och förvalta öppen källkodsprojekt (de Laat, 2007), vilka refereras till som: spontan styrning 5, intern styrning 6 och styrning gentemot externa parter 7. Med spontan styrning avses en situation som är typisk då enskilda individer tagit initiativ till att driva utveckling av öppen källkods-projekt på frivillig basis. Det finns olika typer av incitament som ligger till grund för denna typ av projekt och många gånger ser individer den tekniska utmaningen som en drivkraft. Ytterligare drivkrafter kan utgöras av en altruistiska motiv med en vilja att bidra till det allmännas bästa. Individer som bidrar till denna typ av 5 Spontaneous governance (de Laat, 2007) 6 Internal governance (de Laat, 2007) 7 Governance towards outside parties (de Laat, 2007) 3 (14)
projekt har i flera fall en värdegrund som överensstämmer med utgångspunkterna för det arbete som legat till grund för initiativ som lett till framväxten av Free Software Foundation (www.fsf.org), och inte sällan är programvara utvecklad enligt denna modell licensierad under GPL (Gnu General Public Licence). Med intern styrning avses en situation där öppen källkods-projektet har nått en viss omfattning och funnits under en längre tid, samt där den informella styrning som användes vid modellen spontan styrning inte längre anses fungera. Som följd av detta införs olika typer av medel för att ge stärkt styrning och struktur inom öppen källkods-projekt. Medel kan utgöras av: Modularisering av källkod Etablering av olika roller inom projektet Delegering av beslutsfattande Träning och kultivering av underliggande principer för ett öppet arbetssätt Formalisering av arbetspraktiken inom projektet med hjälp av verktyg (exempelvis Git) och procedurer (för användning av valda verktyg) Typ av ledarskap (exempelvis autokratiskt vs. demokratiskt ledarstil) Med styrning gentemot externa parter avses en situation där ett öppen källkods-projekt verkar i en miljö med en ökad grad av samverkan och interaktion. Projekt som drivs inom denna typ av modell kan innebära ökade möjligheter, exempelvis genom att externa intressenter kan tillföra monetära resurser då ett öppen källkods-projekt utgör en viktig komponent i ett större IT-system. Samtidigt kan projekt styrda enligt modellen utsättas för en ökad sårbarhet, exempelvis genom att projekten exponeras för andra affärsintressen som inte nödvändigtvis är kongruenta med visionen för ett specifikt öppen källkods-projekt, samt olika typer av juridiska hot (exempelvis från patent-troll). Det finns ett antal strategier för att hantera dessa potentiella hot. En strategi är fokusera på områden för öppen källkods-projekt där det finns ömsesidiga incitament bland inblandade aktörer att samverka (dvs undvik den lilla 8 del av all programvara som ger konkurrensfördelar). En annan strategi kan vara att etablera en stiftelse som utgör en neural spelplan där en mångfald aktörer har incitament att samverka (exempelvis Eclipse Foundation, the Document Foundation, Linux Foundation, etc.). Utifrån en genomgång av publicerad forskning som behandlar styrning av öppen källkodsprojekt har olika aspekter av styrning analyserats och delats in i sex kategorier som utgör formella och informella strukturer och regler (Markus, 2007). Den första kategorin omfattar aspekter som relaterar ägarskap av tillgångar. Mer specifikt ingår licenser och intellektuell egendom (IPR) samt formella organisatoriska strukturer (exempelvis stiftelseformen). Den andra kategorin omfattar aspekter som relaterar projektets idé och vision. Mer specifikt ingår explicitgörande av den vision som finns avseende projektets mål, samt visioner för den programvara som utvecklas. Den tredje kategorin omfattar aspekter som relaterar ledning av den gemenskap 9 av 8 Endast en liten del av den programvara (5-10 %) som ingår i de flesta produkter ger konkurrensfördelar (van der Linden et al., 2009). 9 (eng. community) 4 (14)
intressenter och aktörer som bidrar och på annat sätt har anknytning till öppen källkodsprojektet. Mer specifikt ingår regler för vilka potentiella intressenter som kan ingå i denna gemenskap, hur deras identitet kan bekräftas, vilka roller de kan ha, samt hur intressenter kan agera i nya roller. Den fjärde kategorin omfattar aspekter som relaterar processer för programvaruutveckling. Mer specifikt ingår strukturer och regler som behandlar viktiga operativa uppgifter inom utvecklingen såsom identifiering av krav, allokering av personal till olika uppgifter, processer för att hantera förändringar i programvaran, och principer för hur olika versioner av programvaran tillgängliggörs. Den femte kategorin omfattar aspekter som relaterar hantering av konflikter och förändring av regler. Mer specifikt ingår regler och procedurer för att lösa och hantera konflikter, samt att skapa nya regler för hantering av konflikter. Den sjätte kategorin omfattar aspekter som relaterar hur information och verktyg används. Mer specifikt ingår regler om hur information kommer att kommuniceras och hanteras, samt hur verktyg och teknisk infrastruktur för programvara och relaterade digitala artefakter kommer att användas. 4 Vägval för en relevant styrning- och förvaltningsmodell till ivis Som ett resultat av ett samverkansprojekt där företaget imcode AB och föreningen Sambruk varit initiativtagare till ett projekt (ivis, innovativt Verksamhetssystem i Skolan) som genomförts i en öppen samverkan för att utveckla en IT-lösning för e-tjänster för skolan. Projektet har resulterat i en öppen plattform där utformningen vägletts av en grundläggande princip om att undvika inlåsningseffekter. Då det för skolans område är viktigt att inte låsa in data, vare sig tekniskt eller avtalsmässigt har projektets genomförande resulterat i en ITlösning som utvecklats i samverkan för att demonstrera hur ett öppet källkods-projekt kan involvera flera leverantörer och många användare knutna till olika skolor i olika kommuner. Lösningen demonstrerar hur ivis basplatta (som innehåller databas för all skolinformation) kan användas av tjänster för olika typer av verksamhetsdata (exempelvis skolskjutsar, närvaro och avvikelsehantering) som utvecklats för skolans behov kan realiseras genom öppen källkod och öppna APIer för att undvika olika typer av inlåsningseffekter. Baserat på kunskapsläget från publicerad forskning avseende styrning av öppen källkodsprojekt utkristalliserar sig ett antal öppna frågeställningar som intressenter inom ivisprojektet behöver ta ställning till för att framgent lansera utvecklad lösning som en långsiktigt hållbar öppen samverkans-plattform där underliggande programvara förvaltas som öppen källkod. Nedan presenteras ett antal öppna frågeställningar centrala för styrning av ett öppen källkods-projekt som lanseras utifrån arbetet i ivis-projektet. Baserat på redovisad forskning presenteras dessa frågeställningar i sex kategorier (Markus, 2007). En första kategori öppna frågeställningar omfattar aspekter som relaterar ägarskap av tillgångar. Dessa frågeställningar inkluderar: Under vilken (alternativt vilka) öppen källkods-licens(er) ska programvaran tillhandahållas? Vilken (alternativt vilka) organisation(er) har (respektive bör ha) upphovsrätt för utvecklad programvara? 5 (14)
Vilken (alternativt vilka) organisation(er) samt vilken (alternativt vilka) typer av juridiska personer (exempelvis ett enskilt företag, en myndighet, en stiftelse, etc.) för dessa organisationer ska ha inflytande på strategiska beslut avseende förvaltning och vidareutveckling av öppen källkods-projektet? En andra kategori öppna frågeställningar omfattar aspekter som relaterar projektets idé och vision. Dessa frågeställningar inkluderar: Har projektets visioner och mål kommunicerats till individer och organisationer som är (samt potentiellt avser bli) involverade i öppen källkods-projektet via en öppen utvecklingsplattform där källkod och andra digitala artefakter från projektet förvaltas och tillhandahålls för omvärlden? Har projektet preciserat en tidsplan (med prioriteringar och ansvarsområden) för planerade aktiviteter relaterat olika versioner av programvaran? En tredje kategori öppna frågeställningar omfattar aspekter som relaterar ledning av den gemenskap 10 av intressenter och aktörer som bidrar och på annat sätt har anknytning till öppen källkods-projektet. Dessa frågeställningar inkluderar: Har projektet en uttalad strategi och stöd för hur potentiellt intresserade individer och organisationer, på olika sätt, kan bidra till projektet och dess gemenskap? Har projektet uttalade roller och ansvarsområden som inbegriper hur kommunikation och dialog inom gemenskapen stimuleras, samt hur förvaltning av gemenskapen hanteras? Hur agerar projektet för att rekrytera individer och organisationer för att stärka gemenskapen? Hur agerar projektet för att attrahera olika typer av externa resurser för att stärka gemenskapen? En fjärde kategori öppna frågeställningar omfattar aspekter som relaterar processer för programvaruutveckling. Dessa frågeställningar inkluderar: Hur organiseras arbetet med stöd av olika teknologier och teknisk infrastruktur i processen att utveckla, förvalta, och tillgängliggöra programvara i dess olika versioner (exempelvis stabila releaser, utvecklingsversioner, etc.)? Hur tillser projektet att olika nödvändiga arbetsuppgifter och aktiviteter under utvecklingen av programvaran blir genomförda inom givna tidsramar? Hur reglerar och föreskriver projektet att överenskomna principer för arkitektur, utveckling, testning, koordinering av aktiviteter, etc., upprätthålls av aktörer som medverkar i gemenskapen? En femte kategori öppna frågeställningar omfattar aspekter som relaterar hantering av konflikter och förändring av regler. Dessa frågeställningar inkluderar: Hur hanterar projektet avvikelser från överenskommet arbetssätt och samverkan inom gemenskapen, samt gentemot externa intressenter? Hur hanteras person- och intressekonflikter mellan individer och organisationer inom gemenskapen av projektet? 10 (eng. community) 6 (14)
Hur uppmuntrar projektet ett konstruktivt och välkomnande klimat inom gemenskapen via dess digitala samt fysiska mötesplatser? En sjätte kategori öppna frågeställningar omfattar aspekter som relaterar hur information och verktyg används. Dessa frågeställningar inkluderar: Hur bestämmer projektet vilken (och när) information om projektet ska kommuniceras riktat till olika målgrupper såväl internt som externt i förhållande till gemenskapen, samt via vilka kanaler detta ska detta kommuniceras? Hur används olika teknologier samt teknisk infrastrukturer i processen att utveckla och förvalta programvara? 5 Diskussion avseende vägval för ivis och dess öppna ekosystem Det finns ett antal öppna frågeställningar avseende styrning av öppen källkods-projekt som varje öppet ekosystem behöver förhålla sig till. Två öppen källkods-projekt (ivis samt Open eplatform) är i nuläget centrala för det öppna ekosystemet, men det öppna ekosystemet kan framgent innehålla ytterligare öppen källkods-projekt som är väsentliga för olika intressenters långsiktiga engagemang i ekosystemet. Inom skolans område finns idag en mängd aktörer och system utvecklade av olika myndigheter som varje nytt initiativ (däribland öppen källkodsprojektet ivis) behöver förhålla sig till, där en framgångsfaktor är en ändamålsenlig styrning av enskilda öppen källkods-projekt samt det öppna ekosystemet som helhet. Utifrån öppna frågeställningar avseende formella och informella strukturer och regler för styrning av öppen källkods-projekt presenteras nedan en diskussion. Centrala frågeställningar som relaterar ägarskap av tillgångar avser hur det öppna ekosystemet ska förhålla sig till användande av olika typer av öppen källkods-licenser och andra villkor som reglerar hur programvara får användas av olika intressenter. Olika typer av licenser för kod som används i ett öppen källkods-projekt ger olika effekter för olika användningsområden och intressenter. En öppen frågeställning avseende ägarskap av tillgångar rör vad som utgör lämpliga licenser för kod som används, utvecklas, respektive distribueras såväl inom som utanför det öppna ekosystemet. För kod som används internt i projektets utvecklingsmiljö, som en kompilator från ett fristående öppen källkods-projekt (exempelvis GCC som tillhandahålls under licensen GPL-2.0) eller ett modelleringsverktyg som tillhandahålls som en del av utvecklingsmiljön Eclipse (exempelvis Papyrus som tillhandahålls under licensen Eclipse Public License 1.0, EPL-1.0), är frågor om licenser förhållandevis oproblematiska eftersom aktörer i det öppna ekosystemet i regel använder kod från dessa projekt inom den egna organisationen. En analys av rimliga svar på den öppna frågan om vilka licenser som kan vara lämpliga leder rimligen till en annan värdering då en organisation i det öppna ekosystemet har behov av att nyttja programvara som utvecklats i det öppna ekosystemet. I en situation då en partner i det öppna ekosystemet distribuerar kod från ett öppen källkods-projekt till en annan organisation i ekosystemet måste denna kod tillhandahållas under en licens som är lämplig för den mottagande organisationens miljö där koden ska användas. Om exempelvis en leverantör ska distribuera kod från öppen källkods-projektet Open eplatform 11 (som tillhandahålls under 11 Open eplatform är ett öppen källkods-projekt (www.openeplatform.org) där programvaran är tillgänglig under en copyleft-licens: All contents of this repository is licensed under the AGPLv3 license 7 (14)
öppen källkods-licensen AGPL-3.0) till en kommun som skall nyttja denna kod för drift på kommunens egen server, innebär detta att distributionen för med sig såväl rättigheter som skyldigheter utifrån det som licensen preciserar. I händelse av att leverantören utöver att distribuera kod från Open eplatform samtidigt distribuerar kod från öppen källkods-projektet ivis (samt eventuellt kod från ytterligare öppen källkods-projekt) som delar av den programvara kommunen behöver för användning på kommunens egen server, behöver all distribuerad programvara vara tillgänglig under samma licens som den som valts för Open eplatform (AGPL-3.0). Ytterligare en öppen frågeställning avseende ägarskap av tillgångar rör upphovsrätt (samt andra rättigheter 12 ) för kod som används, utvecklas, distribueras, respektive vidareutvecklas inom det öppna ekosystemet. För kod som utvecklats och förvaltas av öppen källkods-projekt utanför det öppna ekosystemet behöver en analys göras av rättighetsinnehavarens intentioner för att om möjligt värdera detta projekts framtid. Om det exempelvis saknas en aktiv gemenskap som bidrar till att vidareutveckla koden i projektet samt om upphovsrätten för koden kontrolleras av en aktör vars incitament inte ligger i linje med det egna öppna ekosystemet, kan användning av sådan kod innebära en risk för att själv behöva ta över hela förvaltningen av denna kod. Då endast rättighetsinnehavaren kan omlicensiera kod behöver analys också göras av huruvida befintlig licens för koden är lämplig med avseende på det egna öppna ekosystemet. Exempelvis har en Svensk kommun upphovsrätten för kod som förvaltas i öppen källkods-projektet Open eplatform 13 (som utgör en del av det öppna ekosystemet) som är tillgängligt på den öppna plattformen GitHub. Ytterligare en öppen frågeställning rör upphovsrätt (samt andra rättigheter 14 ) för kod som används, utvecklas, distribueras, respektive vidareutvecklas inom det öppna ekosystemet. För kod som utvecklats och förvaltas i något öppen källkods-projekt inom det öppna ekosystemet behöver en analys göras av på vilket sätt projektet hanterar upphovsrätt för utvecklad kod. Om en leverantör exempelvis anlitar externa utvecklare behöver frågan om vem som skall inneha upphovsrätten för utvecklad kod klargöras, eventuellt genom någon form av contibutor agreement/copyright assignment. I sammanhanget är det viktigt att notera att denna typ av konstruktioner starkt kan motverka incitamentet för frivilliga externa intressenter att bidra 15. Generellt är det väsentligt att tydligt klargöra rättigheter för att underlätta öppen samverkan i denna typ av projekt. Centrala frågeställningar som relaterar idé och vision för specifika öppen källkods-projekt avser i vilken utsträckning olika aktörer och potentiella intressenter agerar utifrån denna idé. Vidare avses att idén med enskilda öppen källkods-projekt är i linje med idén för det öppna ekosystemet som helhet. En öppen frågeställning avseende idé och vision för specifika öppen källkods-projekt rör huruvida mål för projektet har kommunicerats till olika intressenter på projektets öppna plattform och via andra kanaler för kommunikation. Denna kommunikation kan omfatta prioriteringar, överenskommelser och beslut angående tillhandahållande av specifik (https://github.com/sundsvallskommun/open-eplatform/blob/master/readme.md) 12 Exempelvis rättigheter till patent (standard-essential-patents) som belastar specifika filformat som implementeras i programvaran. 13 Upphovsrätten för den kod som utvecklats och förvaltas i öppen källkods-projektet Open eplatform innehas av en Svensk kommun: All contents of this repository is licensed under the AGPLv3 license and copyright the Swedish municipality of Härnösand. (https://github.com/sundsvallskommun/openeplatform/blob/master/readme.md) 14 Exempelvis rättigheter till patent (standard-essential-patents) som belastar specifika filformat som implementeras i programvaran. 15 För ett exempel på en situation då olika syn och olika incitament för enskilda och organisationer inneburit problem för existerande öppen källkods-projekt, se Gamalielsson & Lundell (2014). 8 (14)
funktionalitet för olika versioner av programvaran samt huruvida denna funktionalitet kommer att göras tillgänglig för olika plattformar. Exempelvis har företrädare för öppen källkods-projektet ivis (som utgör del av det öppna ekosystemet) uttalat en underliggande filosofi 16 och en övergripande vision 17 som baseras på en ambition att undvika inlåsningseffekter och att den programvara som finns i detta öppna ekosystem kan samverka genom öppna gränssnitt. Ytterligare en frågeställning avseende idé och vision rör särskilt hur potentiellt intresserade individer och organisationer kan och bör introduceras till ett öppen källkods-projekt. Under en sådan introduktion är det viktigt att arbeta systematiskt för att kommunicera den idé och de värderingar som ligger till grund för projektet så att dess gemenskap bygger samförstånd och utvecklar kreativitet. Flera framgångsrika öppen källkods-projekt drivs inom ramen för en icke vinstdrivande organisation (exempelvis stiftelse) som uttalat en vision för det eller de öppen källkods-projekt som utgör en del av respektive stiftelse. Även om den organisation som förvaltar ett öppen källkods-projekt inte är vinstdrivande kan mycket väl ett antal leverantörer (som var och en har kommersiella intressen) bidra till projektet som förvaltas av stiftelsen (vilket exempelvis är vanligt för projekt inom Eclipse Foundation). För ett långsiktigt framgångsrikt öppen källkods-projekt är det viktigt att systematiskt arbeta med att vidareutveckla och förankra en gemensam vision, oavsett filosofi för vem eller vilka intressenter ges möjlighet att påverka beslut angående visionen. För ett långsiktigt framgångsrikt projekt är det speciellt viktigt att kommunicera och förankra visionen bland alla potentiella nya individer och organisationer som blir del av gemenskapen. Detta kan exempelvis omfatta olika typer av gemensamma aktiviteter (såväl via virtuella som via fysiska möten) där olika intressenter möts i konstruktiv dialog. Det finns flera öppen källkodsprojekt som regelbundet genomför fysiska möten som ett sätt att förankra och vidareutveckla ett projekts idé. Centrala frågeställningar som relaterar ledning av den gemenskap av intressenter och aktörer som bidrar och på annat sätt har anknytning till öppen källkods-projektet avser strategier och agerande för ledning av den gemenskap som finns kring ett projekt. En öppen frågeställning avseende ledning av den gemenskap av intressenter och aktörer som bidrar rör aspekter väsentliga för ledning av ett långsiktigt framgångsrikt öppen källkodsprojekt vilket inkluderar ett systematiskt sätt att arbeta med att introducera potentiella utvecklare. Detta kan exempelvis inkludera tillhandahållande av en uppsättning easy hacks samt gemensamma aktiviteter (såväl via virtuella som via fysiska möten) där utvecklare som redan deltar i gemenskapen har en välkomnande attityd gentemot nya individer som kan delta och bidra. Det finns flera öppen källkods-projekt som tillhandahåller information specifikt fokuserad på att introducera utvecklare (i vissa fall med mentorskap från seniora bidragsgivare) till att bidra på olika sätt till projekt, exempelvis genom att rätta enklare fel i specifika projekt 18 och genom vidareutveckling av kodbasen 19. Ytterligare en öppen frågeställning avseende ledning av den gemenskap av intressenter och aktörer som bidrar rör roller och ansvarsområden för olika intressenter inom öppen källkodsprojekt. Behovet av uttalade roller för att fatta olika typer av beslut varierar beroende på en 16 ivis.se/philosophy 17 Webbplatsen för ivis-projektet uttrycker exempelvis följande vision: Projektet vill skapa ett skolsystem som gör det möjligt för den svenska skolan att digtaliseras snabbare och mer innovativt och flytta kontrollen över informationen från leverantörer till skolans intressenter. (ivis.se/about) 18 Öppen källkods-projektet Firefox tillhandahåller easy bugs (wiki.mozilla.org/good_first_bug) 19 Öppen källkods-projektet LibreOffice tillhandahåller easy hacks (https://wiki.documentfoundation.org/development/easyhacks) 9 (14)
rad faktorer, såsom antalet intressenter i gemenskapen för ett projekt, i vilken utsträckning det finns samsyn mellan olika intressen och typer av individer och organisationer som är involverade i gemenskapen, programvaruarkitektur och kodkomplexitet, samt i vilken utsträckning projektet är av strategisk betydelse för de individer och organisation som medverkar i gemenskapen. Många öppen källkods-projekt tillsätter olika roller utifrån individers uppvisade kompetens och erfarenhet från tidigare projekt, snarare än utifrån i vilken organisation en specifik individ är anställd. För ett långsiktigt framgångsrikt öppet ekosystem, där flera öppen källkods-projekt (som exempelvis ivis-projektet) ingår, är det nödvändigt att identifiera en relevant ansvarsfördelning med relevanta roller som kan leda och på andra sätt bidra till respektive projekt inom ekosystemet såväl som ekosystemets helhet. Centrala frågeställningar som relaterar processer för programvaruutveckling avser hur arbetet organiseras och bedrivs inom ramen för den utveckling som genomförs inom öppen källkodsprojektet. En öppen frågeställning avseende processer för programvaruutveckling rör i vilken utsträckning och på vilket sätt enskilda öppen källkods-projekt anammar etablerad arbetspraktik i utvecklingsprocessen. Typiskt för många öppen källkods-projekt är att utvecklingen bedrivs iterativt i en transparent process där kod och relaterade digitala artefakter kontinuerligt är tillgängliga på en öppen platform. Många utvecklare som bidrar till öppen källkods-projekt är vana vid en iterativ arbetspraktik där beslut om kommande steg i utvecklingsprocessen successivt fattas och där resultat från processen (däribland olika versioner av kod) kontinuerligt tillgängliggörs. Exempelvis har öppen källkods-projekt i ivis öppna ekosystem anammat en iterativ arbetspraktik. inom det öppna ekosystemet. Vidare omfattar denna frågeställning även val av teknologier och teknisk infrastruktur som understödjer denna arbetspraktik, samt överväganden avseende hur valda teknologier konkret ska användas för att bidra till den arbetspraktik och de processer som projektet valt för att bedriva utvecklingen. Exempelvis har olika öppen källkods-projekt valt olika strategier för hur frekvent modifieringar i kodbasen skall tillgängliggöras i projektets kodförråd (eng. Repository) och valda teknologier påverkar möjligheterna för utvecklare inom ett projekt att bedriva utvecklingen utifrån en viss arbetspraktik och process. Beroende på typ av projekt samt föredragna processer och arbetspraktik kan olika teknologier vara att föredra för olika öppen källkods-projekt. Exempelvis har ivis-projektet valt att nyttja ett nyttja ett antal teknologier vanligt förekommande i öppen källkods-projekt, däribland: Java, Spring för Java, Hibernate för Java, Apache Tomcat, MySQL, GitHub, etc. Ytterligare en öppen frågeställning avseende processer för programvaruutveckling rör hur beslut fattade inom enskilda öppen källkods-projekt påverkar (och påverkas av) beslut fattade i andra projekt som finns inom (samt utanför) det öppna ekosystemet. I händelse av att det sker förändringar i ett system som finns inom det öppna ekosystemet så skulle detta kunna få återverkningar på ett annat system som finns inom det öppna ekosystemet. Vidare skulle en förändring av innehåll och representation av de data som levereras till ett system inom det öppna ekosystemet av ett annat system inom samma ekosystem kunna innebära att ett av systemen behöver byggas om. Denna typ av förändringar kan vara utfallet av de processer som förekommer i projekt som finns inom det öppna ekosystemet, vilka bör kunna koordineras proaktivt mellan olika projekt. Däremot kan förändringar i system som drivs och kontrolleras av andra aktörer som finns utanför det öppna ekosystemet få stora konsekvenser för enskilda projekt i det öppna ekosystemet. Denna typ av förändringar i externa system får därmed potentiellt en påverkan som gör att det öppna ekosystemet behöver agera reaktivt. 10 (14)
Centrala frågeställningar som relaterar hantering av konflikter och förändring av regler avser hur öppen källkods-projekt kan förebygga, undvika och hantera konflikter. En öppen frågeställning avseende hantering av konflikter och förändring av regler rör de överenskommelser som på olika sätt reglerar, föreskriver och uppmuntrar beteenden och arbetspraktik av individer inom den gemenskap som är knuten och bidrar till ett öppen källkods-projekt. Utvecklare och andra intressenter som agerar inom en gemenskap har en lång rad överenskommelser att förhålla sig till, som inkluderar allt ifrån juridiskt bindande avtal och licenser som reglerar hur olika aktörer kan agera till uttalade och outtalade förväntningar. De outtalade förväntningarna inkluderar vad som inom gemenskapen är accepterade respektive förväntade beteenden av individer och organisationer som agerar inom (och bortom) gemenskapen. Individer och organisationer som på olika sätt bidrar till öppen källkods-projekt (som ivis-projektet) har behov av att upprätta flera typer av avtal och förhålla sig till olika typer av licenser för att förebygga olika typer av konflikter inom projekt och dess öppna ekosystem. Exempelvis behöver en leverantör som bidrar till ett öppen källkods-projekt i avtal reglera villkoren för hur de väljer att arbeta med underleverantörer och kunder. I situationer då oberoende utvecklare bidrar till ett öppen källkods-projekt kan det finnas behov av att använda olika former av avtal som reglerar individens rätt (gentemot öppen källkods-projektet) att bidra med upphovsrättsskyddad kod. Bland utvecklare och organisationer finns det olika syn på huruvida olika typer av avtal (contributor agreement, copyright assignment, etc.) bör användas av öppen källkods-projekt. För ett öppen källkodsprojekt finns det å ena sidan incitament för att skydda sig mot att få in bidrag som potentiellt skadar projektet (exempelvis då kod som individer bidrar med till projektet har lämnats utan att individen haft upphovsrätt och alla övriga nödvändiga rättigheter för att lämna bidraget) och å andra sidan inte använda avtal som hämmar och begränsar möjligheten för externa individer och organisationer att bidra till projektet genom att ställa krav på att de som bidrar ska ingå denna typ av avtal. Oklarhet angående vad som gäller avseende rättigheter, avtal och licenser skapar frustration, vilket kan leda till spänningar och konflikter inom en gemenskap. Det finns exempel på öppen källkods-projekt där individer i gemenskapen varit djupt oeniga angående rättigheter, avtal och licenser, vilket lett till konflikt och att mängden externa bidrag hämmats 20. Många framgångsrika öppen källkods-projekt betonar vikten av personliga möten för att förebygga oenighet. För projekt i ivis öppna ekosystem är det väsentligt att finna former för regelbundna personliga möten och att utveckla samsyn angående avtal och licenser. Ytterligare en öppen frågeställning avseende hantering av konflikter och förändring av regler rör hur individer och organisationer agerar i öppen källkods-projekt för att etablera ett konstruktivt och välkomnande klimat. Vissa öppen källkods-projekt har genom åren utvecklat en stark meritokrati där dialog och samverkansklimat mellan olika individer ibland kan bli lidande. Det är i detta sammanhang viktigt att motverka risken för konflikter inom öppen källkods-projekt och dess gemenskaper. En strategi för att motverka denna typ av konflikter är att förutom att visa uppskattning för bidrag från engagerade utvecklare med djup teknisk expertis också uppmuntra bidrag från andra individer med andra erfarenheter och kompetenser. För ett långsiktigt framgångsrikt öppen källkods-projekt behövs många olika kompetenser och bidrag såsom kodning, felrapportering, dokumentation, översättning, testning, pr, allokering av nya resurser (exempelvis fund raising ), etc. Centrala frågeställningar som relaterar hur information och verktyg används avser hur öppen källkods-projekt och dess gemenskap utvecklar en praktik för hur individer i projektet 20 För ett exempel på öppen källkods-projekt där spänningar och oenighet avseende avtal lett till konflikt, se Gamalielsson & Lundell (2014). 11 (14)
kommunicerar information (såväl inom som externt i förhållandet till projektet och dess gemenskap) samt utvecklar kod och associerade digitala artefakter med hjälp av olika verktyg. En öppen frågeställning avseende hur information och verktyg används rör beslut angående vilken information som skall kommuniceras (och när) från (samt inom) ett öppen källkodsprojekt, till vilka målgrupper, samt via vilka kanaler denna kommunikation ska ske. Exempelvis är det vanligt att öppen källkods-projekt publikt publicerar en roadmap som tillkännager detaljer om när planerad kommande utveckling kommer att genomföras och vara genomförd. Vidare är det också vanligt att publicera en release plan som detaljerar när olika versioner av programvaran kommer tillgängliggöras. Dessutom är det vanligt att tillhandahålla olika instruktioner och skript för installation och användning av programvara som är anpassade till olika kategorier av användare. Det är också vanligt att ett antal olika epostlistor och forum används för kommunikation mellan utvecklare, användare och övriga intressenter inom öppen källkods-projektet och dess öppna ekosystem. För att ivis-projektet och andra öppen källkods-projekt inom det öppna ekosystemet ska bli långsiktigt framgångsrika är det väsentligt att överväga införande av dessa åtgärder som sammantaget ökar intresset för enskilda öppen källkods-projekt inom det öppna ekosystemet och därmed samtidigt undanröjer hinder för användning av utvecklade lösningar. Ytterligare en öppen frågeställning avseende hur information och verktyg används rör utveckling av kod och associerade digitala artefakter med hjälp av olika verktyg. Många öppen källkods-projekt använder en rad olika öppna verktyg samt utvecklar och förvaltar kod på öppna plattformar. En rad olika typer av verktyg och utvecklingsmiljöer (exempelvis Eclipse) som används vid utveckling inom öppen källkods-projekt tillhandahålls under någon öppen källkods-licens. Många öppen källkods-projekt drivs i en global samverkan där ett stort antal utvecklare (som är geografiskt distribuerade) bidrar. Denna öppna samverkan ställer stora krav på stöd av ändamålsenliga verktyg som stöttar denna arbetspraktik bland utvecklare och det behövs en samsyn bland utvecklare kring användningen av dessa verktyg. En typ av verktyg som är central för denna typ av globalt distribuerad utveckling, som för flertalet projekt kan omfatta många individer, är verktyg för versionshantering. Exempel på öppen källkods-licensierade verktyg för versionshantering är Git, Subversion, Mercurial, Bazaar, etc., där ett av de mest betydelsefulla öppen källkods-projekten (Linuxkärnan 21, som används i Linux-distributioner) använder Git för versionshantering. För långsiktigt framgångsrika öppen källkods-projekt är utvecklad kod transparent tillgänglig under en (eller flera) öppen källkodslicenser 22 och finns tillgänglig på en projektspecifik öppen plattform utan restriktioner 23 eller en specifik plattform (exempelvis GitHub) där flertalet långsiktigt framgångsrika öppen källkods-projekt förvaltas. 6 Sammanfattning För att etablera ett långsiktigt förvaltningsbart öppet ekosystem, i vilket öppen källkodsprojektet ivis utgör en central del, krävs en ändamålsenlig styrning. I detta ekosystem bidrar och agerar en mångfald olika typer av aktörer och intressenter i en öppen samverkan. Utmärkande för det öppna ekosystemet i vilket ivis ingår är ett starkt behov av en öppen samverkan och interoperabilitet utan inlåsningeffekter mellan systemets olika delar. 21 www.kernel.org 22 Exempelvis är Linuxkärnan tillgänglig under GPL-2.0. 23 Vissa projekt ställer krav på registrering för att kunna komma åt kod, vilket inte är förenligt med filosofin i en öppen arbetspraktik som används i långsiktigt framgångsrika öppen källkods-projekt. 12 (14)
En förutsättning för interoperabilitet i ett öppet ekosystem är nyttjandet av öppna standarder. En hög grad av samverkan och interaktion mellan interna och externa intressenter är centralt för ett uthållighet och långsiktigt framgångsrikt ekosystem. Olika parter i detta ekosystem kan tillföra olika typer av resurser, samt få utväxling och nytta av sitt engagemang på olika sätt. Att styra ett öppet ekosystem, där öppen källkods-projekt som ivis och andra ingår, krävs betydande inslag av den styrning gentemot externa parter som identifierats i litteraturen. Framgångsrik utveckling av öppen källkods-projekt och öppna ekosystem för specifika branscher, som exempelvis inom skolans område, förutsätter en rad samverkande kompetenser och ett långsiktigt engagemang som tillvaratar olika intressenters intressen. För ett långsiktigt framgångsrikt ivis-projekt, som tillsammans med andra öppen källkodsprojekt utgör delar av ett öppet ekosystem, är det nödvändigt att regelbundet beakta väsentliga aspekter av styrning som tillvaratar olika individers och organisationers intressen. Referenser: Di Tullo, D. and Staples, D. S. (2013) The Governance and Control of Open Source Software Projects, Journal of Management & Governance, Vol. 30(3), pp. 49-80. FLOSS (2002) Free/Libre and Open Source Software: Survey and Study FLOSS, Deliverable D18: Final Report, Part 0: Table of Contents and Executive Summary, International Institute of Infonomics University of Maastricht, The Netherlands & Berlecon Research GmbH, Berlin, Germany, juni. FSF (2016) Free Software Foundation, http://www.fsf.org/ Gamalielsson, J. & Lundell, B. (2014) Sustainability of Open Source software communities beyond a fork: How and why has the LibreOffice project evolved?, The Journal of Systems and Software, Vol. 89(1), pp. 128-145. van der Linden, F, Lundell, B. & Marttiin, P. (2009) Commodification of Industrial Software: A Case for Open Source, IEEE Software, Vol. 26(4), pp. 77-83. de Laat, P. B. (2007) Governance of open source software: state of the art, Journal of Management & Governance, Vol. 11(2), pp. 165-177. Lundell, B. & van der Linden, F. (2012) Open Source Software as Open Innovation: Experiences from the Medical Domain, In Eriksson Lundström et al. (Eds.) Managing open innovation technologies, Springer, Heidelberg, ISBN 978-3-642-31649-4, pp. 3-16. Lundell, B., Lings, B. & Lindqvist, E. (2010) Open Source in Swedish Companies: Where are We?, Information Systems Journal, Vol. 20(6), pp. 519-535. Lundell, B., Lings, B. & Syberfeldt, A. (2011) Practitioner Perceptions of Open Source Software in the Embedded Systems Area, The Journal of Systems and Software, Vol. 84(9), pp. 1540-1549. Markus, M. L. (2007) The governance of free/open source software projects: monolithic, multidimensional, or configurational?, Journal of Management & Governance, Vol. 11(2), pp. 151-163. 13 (14)
Morgan, L., Feller, J. & Finnegan, P. (2012) Exploring value networks: theorising the creation and capture of value with open source software, European Journal of Information Systems, Vol. 22(5), pp. 569-588. Morgan, L. & Finnegan, P. (2014) Beyond free software: An exploration of the business value of strategic open source, Journal of Strategic Information Systems, Vol. 23(3), pp. 226-238. OSI (2016) Open Source Iniviative, https://opensource.org/. Schaarschmidt, M., Walsh, G. and von Kortzfleisch, H.F.O. (2015) How do firms influence open source software communities? A framework and empirical analysis of different governance modes, Information and Organization, Vol. 25(2), pp. 99-114. Statskontoret (2003) Free and Open Source Software a feasibility study, Appendix 1: Extensive survey, Statskontoret, 2003:8, Stockholm, ISBN: 91-7220-526-1. 14 (14)