OPEN SOURCE-METODER I

OPEN SOURCE-METODER I SIKKERHEDSKRITISK SOFTWAREUDVIKLING Side 1 ud af 66

Side 2 ud af 66

Standardtitelblad til seminaropgaver, praktikrapporter, projekter og specialer Titelbladet placeres i opgaven umiddelbart efter selvvalgt forside Til obligatorisk brug på alle ovennævnte opgavetyper på: BA - politik og administration BA samfundsfag som centralt fag og tilvalgsfag Kandidat politik og administration Kandidat samfundsfag som centralt fag og tilvalgsfag Cand. it i it-ledelse (Alle felter skal udfyldes) Uddannelse: Cand. it i it-ledelse Semester: 4. Udarbejdet af (Navn(e)) Modul Anders Braüner Nielsen 12 Opgavens art (seminaropgave, projekt, bachelorprojekt, praktikrapport eller speciale): Speciale Titel på opgave: Open source-metoder i sikkerhedskritisk softwareudvikling Vejleders navn: Henrik Eriksen Afleveringsdato: 01/07 2014 Antal normalsider (excl. bilag, indholdsfortegnelse og litteraturliste): 40,11 Antal anslag (excl. bilag, indholdsfortegnelse og litteraturliste): 108287 Tilladte normalsider jf. studieordning/formalia i moodle: 80 OBS! Hvis du overskrider de tilladte antal normalsider, kan din opgave afvises efter aflevering Side 3 ud af 66

Side 4 ud af 66

1 Abstract This master s thesis is conducted as an ethnographic study of the applied development methodology in the cryptographic currency-system, Bitcoin. It has previously been discussed, whether open source development methodologies are appropriate for security-critical software and whether open source software is more or less secure than proprietary software with closed source code, without definitive scientific consensus. An initial questioning on the emerging success of the cryptographic currency-system Bitcoin, despite the application of open source development as the chosen methodology in concurrency with a security-critical nature led to a systematic literature review, to determine under which scientific areas the system has previously been researched. This initial review made it clear that the subject has not been covered in Management of Information Systems or IT in general. During participation of the #Bitcoin2014 conference in Amsterdam an open approach to the characteristics of the system was used and through questions directed at panelists and speakers, more concrete research areas were identified, knowledge gaps considered and contact made with potential interview-respondents possessing knowledge and experience with the system. Based on the Bitcoin Core, which is the base information system in the cryptographic currency, it has been researched whether the application of open source techniques and methodology has been a determining factor for the system s security and the effect of this application. To determine whether the Bitcoin-system s development methodology is comparable to other open source systems and to compare it to general practices in management of information systems, Torkar et al(2011) s development methodology comparison framework is used as inspiration. In this regards it has also been considered whether the Bitcoin Core project contributes with further insight on possible adoption opportunities for commercial software development. Side 5 ud af 66

It is finally concluded through analysis of the development process that significant benefits to using the applied open source methodology are present in the researched case but the benefits are not generally applicable due to the nature of the Bitcoin system s unique characteristics. The identified adoption opportunities in Torkar et al(2011) are validated to a very limited degree, again due to the unique characteristics of the Bitcoin system. The differences between the project case and other open source systems are identified mainly as unique a consensus based decision-making system and a unique financial incentive for high code quality. Lastly it is concluded that only some of the practices used in the Bitcoin project can be beneficially adopted in commercial proprietary software development and only to a limited degree due to the unique characteristics of the Bitcoin system. Side 6 ud af 66

2 Resumé Denne specialeafhandling er udført som et etnografisk studie af den udviklingsmetodologi, der anvendes under udviklingen af det kryptografiske valutasystem, Bitcoin. Det er tidligere diskuteret, hvorvidt open source udviklingsmetoder er egnede til sikkerhedskritisk software og om open source software er mere eller mindre sikkert end kommerciel proprietær software med lukket kode, uden definitiv videnskabelig konsensus. En indledende undren over det nye kryptografiske valutasystem Bitcoin s stigende succes på trods af anvendelsen af open source som udviklingsmetodologi, samtidig med en sikkerhedskritisk natur, ledte til et systematisk litteraturstudie, for at afklare under hvilke fagområder systemet tidligere har været undersøgt. Dette indledende litteraturstudie viste at systemet ikke tidligere har været undersøgt indenfor ledelse af informationssystemer eller IT generelt. Ved deltagelse i Bitcoin-konferencen, #Bitcoin2014, i Amsterdam blev der gennem en åben tilgang til systemets karakteristika og gennem spørgsmål rettet mod debat-paneler og talere identificeret mere konkrete undersøgelsesområder, overvejet videnshuller og skabt kontakt til mulige interview-respondenter med viden om og erfaring med systemet. Med udgangspunkt i Bitcoin-kernen, som er det grundlæggende informationssystem i den kryptografiske valuta Bitcoin, er det derfor undersøgt hvorvidt brugen af open source teknikker og udviklingsmetoder har været udslagsgivende for systemets sikkerhed og hvilken indvirkning denne anvendelse har haft. For at undersøge om Bitcoin-systemets udviklingsmetodologi er sammenlignelig med andre open source systemer og for at sammenligne denne med generel ledelsespraksis i udvikling af informationssystemer er Torkar et al(2011) s development methodology comparison framework anvendt som inspiration. I den forbindelse er det også undersøgt, hvorvidt praksis i Bitcoin-projektet kan bidrage med flere adoptionsmuligheder fra FLOSS til kommerciel softwareudvikling end der tidligere er Side 7 ud af 66

identificeret. Slutteligt konkluderes det gennem analyse af udviklingsprocessen at der findes betydelige fordele ved anvendelse af open source-metoder i den undersøgte case men disse fordele ikke er generaliserbare grundet Bitcoin-systemets unikke karanteristika. De identificerede adoptionsmuligheder i Torkar et al(2011) er i begrænset omfang blevet valideret, igen grundet Bitcoin-systemets unikke karakteristika. Forskellen mellem casen og andre open sourcesystemer er identificeret som en unik konsensusbaseret decision-making proces og et unikt økonomisk incitament for høj kodekvalitet. Sidst konkluderes det at kun nogle af de anvendte praksisser i Bitcoin-projektet med fordel kan anvendes i kommerciel proprietær softwareudvikling og kun i begrænset omfang, grundet Bitcoin-systemets unikke karakteristika. Side 8 ud af 66

3 Indholdsfortegnelse 1 Abstract 2 Resumé 3 Indholdsfortegnelse 4 Indledning 4.1 Problemstilling 4.2 Problemformulering 4.2.1 Underspørgsmål 4.3 Begrebsdefinitioner 5 Metode 5.1 Forskningsdesign 5.2 Data- og teori-indsamling 5.2.1 Litteraturstudie 5.2.2 Konferencedeltagelse 5.2.3 Interview 5.2.4 Deltagelse i udviklerdiskussion på #bitcoin-dev 5.3 Analysemetode 6 Teori 6.1 Fordele og ulemper ved open source-teknikker som udviklingsmetode Fordele ved open source-teknikker 6.1.1.1 Sikkerhed gennem peer reviews 6.1.1.2 Fleksibilitet og frihed 6.1.2 Ulemper ved open source software 6.2 Open source- og proprietær udvikling samt adoptionsmuligheder 6.2.1 Torkar et al s framework til sammenligning af udviklingsmetoder 6.2.2 Baggrund 6.2.3 Model 6.2.4 Livscyklus Side 9 ud af 66

6.2.5 Regler og værktøjer 6.2.6 Deltagelse 6.2.7 Aktiviteter 6.2.7.1 Decision making 6.2.7.2 Koordination og kommunikation 6.2.7.3 Krav 6.2.7.4 Planlægning, estimering og kontrol 6.2.7.5 Informationstilgængelighed 6.2.7.6 Verifikation & validering 6.3 Adoptionsmuligheder fra FLOSS til kommercielle projekter 6.3.1 Reducer teknisk gæld 6.3.2 Definer en indgangsvej for nye medlemmer 6.3.3 Øg informationstilgængelighed og synlighed 6.3.4 Omfavn asynkrone kommunikationsværktøjer til kommunikation og decisionmaking 6.3.5 Lad udviklere påvirke arbejdsmetoder 6.3.6 Allow task selection 7 Casebeskrivelse 8 Resultater og analyse 8.1 Bitcoin-projektets udviklingsmetodologi 8.1.1 Baggrund 8.1.1.1 Historie 8.1.1.2 Formål 8.1.1.3 Principper 8.1.1.4 Paradigme og ideologi 8.1.1.5 Anvendelse 8.1.2 Model 8.1.3 Livscyklus 8.1.4 Regler og værktøjer 8.1.5 Deltagelse 8.1.6 Aktiviteter 8.1.6.1 Decision making 8.1.6.2 Koordinationog Kommunikation 8.1.6.3 Krav Side 10 ud af 66

8.1.6.4 Planlægning og kontrol 8.1.6.5 Informationstilgængelighed 8.1.6.6 Verifikation og validering 9 Diskussion Undersøgelsens begrænsninger 10 Konklusion 11 Referencer 12 Bilag Side 11 ud af 66

4 Indledning I løbet af de sidste tredive år er brugen af elektroniske informationssystemer til bankforretninger blevet en nødvendighed og andelen af borgere med et betalingskort er nu det store flertal. Derudover bruger mange borgere netbank til daglige bankforretninger og digitale transaktioner er helt normale. På det øvrige internet, ud over bankernes egne systemer, findes også utallige systemer til at håndtere betalinger mellem forbrugere. Som eksempel kan nævnes det amerikanske Paypal, der ejes af Ebay, som giver muligheden for at sende penge til andre brugere på få sekunder ved hjælp af kreditkortbetalinger som sendes direkte til Paypal. Fælles for alle disse digitale informationssystemer til digitale betalinger er at de afhænger af et centralt system til at verificere og godkende transaktioner samt balancer og kræver derfor en stor tillid fra forbrugerens side til at midlerne er sikre hos den institution man overfører sine penge til. I 2009 begyndte en ny type digitale valutaer og informationssystemer at dukke op. Disse nye informationssystemer er i modsætning til tidligere systemer designet decentralt, hvilket indebærer at alle transaktioner opbevares på et peer-to-peer netværk og en central institution til at verificere og godkende transaktioner derfor ikke er en nødvendighed. På den måde er tilliden flyttet fra centrale institutioner, som banker og Paypal, til et globalt netværk af frivillige der tilbyder regnekraft til at verificere og godkende transaktioner efter et demokratisk fastsat programmeret regelsæt. Da disse systemer hverken er fæstnet til en almindelig valuta eller er styret centralt afgøres prisen udelukkende af markedskræfterne. Over de seneste år har såvel forbrugere, forretninger, lovgivere og skattemyndigheder verden over også undret sig over hvordan de skal forholde sig til disse nye kryptografiske valutaer og særligt den første af typen og mest handlede, Bitcoin, som blev udgivet i starten af 2009. Senest har SKAT og Skatterådet givet et bindende svar på, hvordan Bitcoin indtil videre skal betragtes rent skattemæssigt, men dette svar, der blev udskudt af flere omgange bærer i høj Side 12 ud af 66

grad præg af en mangel på forståelse for hvad formålet egentlig er med systemet. Svaret konkluderer nemlig, på trods af en stigende global interesse i at investere i Bitcoin-relaterede virksomheder, at der ikke kan være en forretningsmæssig begrundelse for at anvende systemet. At Bitcoin som informationssystem er udviklet globalt distribueret og 100% open source og er det første af sin slags der anvendes direkte til behandling betalingstransaktioner gør systemet unikt i forhold til udviklingsmetode og mål, og det formodes derfor at kunne bidrage til den videnskabelige diskussion i IS-ledelseslitteraturen om hvorvidt distribuerede open source projekter kan anvendes til sikkerhedskritiske(se 4.3, begrebsdefinitioner) informationssystemer. I forbindelse med open source-udvikling er der særligt blevet sat spørgsmålstegn ved sikkerheden i denne tilgang til software-udvikling og selvom emnet er bredt diskuteret er der ikke entydige resultater der peger på enten åben eller lukket kode som den mest sikre løsning. På den ene side hævder fortalere for open source-løsninger at disse systemer er mere sikre fordi koden kan gennemgås af både udviklere og brugere, men på den anden side hævder modstandere at den åbne kode også gør det muligt for ondsindede hackere at finde og udnytte sikkerhedsbrister, hvorimod det i lukkede systemer er sværere at finde sikkerhedsbrister og de derfor ikke er til at udnytte. Side 13 ud af 66

4.1 Problemstilling Bitcoin er et af de første eksempler på anvendelsen af et 100% åbent og distribueret udviklet finansielt informationssystem. Dette kan muligvis give erfaringer med anvendelsen af FLOSS(Free/Libre Open Source Software)-udvikling i kommercielle finansielle systemer og andre kritiske systemer der ikke tidligere har haft tradition for at anvende FLOSS-metodologier. Bitcoin står ledelsesmæssigt overfor et paradoks, da litteraturen på den ene side anbefaler udvikling af sikkerhedskritiske og livskritiske systemer gennem de plandrevne metoder, men at Bitcoin på den anden side sandsynligvis ikke ville have opnået succes uden anvendelsen af distribueret open source-udvikling, som ligger tættere på de agile metoder.(payne, 2002) I løbet af de sidste fem år har Bitcoin-systemet vist sig at have væsentlige sikkerhedsmæssige brister, men jo længere hen i udviklingsprocessen projektet er nået, des færre og des mindre alvorlige brister er der opdaget. Tidligere hovedudvikler på Bitcoin Core-projektet og medlem af Bitcoin Foundation s bestyrelse, Gavin Andresen, udtalte blandt andet på #Bitcoin2014- konferencen at systemet havde alvorlige fejl i de første versioner, men da Bitcoin som valuta endnu ikke havde nogen værdi, var der ingen der vidste det. I forbindelse med et debat-panel på konferencen udtalte han ligeledes at Bitcoin-systemet simpelthen ikke behøver formel sikkerheds-testning, da der i praksis vil være en gevinst på op til flere milliarder til den der succesfuldt kan gennembryde systemets sikkerhed, og systemet derfor allerede bliver sikkerheds-testet eksternt i rigelig grad og eventuelle sikkerhedsbrister derfor nærmest øjeblikkeligt ville komme til syne.(se afsnit 7) Det interessante er derfor at se på, hvordan Bitcoin-systemet adskiller sig fra traditionelle metoder til udvikling af sikkerhedskritiske informationssystemer samt hvilke fordele og ulemper denne udviklingsmetode har. Side 14 ud af 66

4.2 Problemformulering Ud fra ovenstående problemstilling er nedenstående undersøgelsesspørgsmål formuleret. Hvad er fordele og ulemper ved at anvende open source til udvikling af sikkerhedskritiske informationssystemer? Hvilke muligheder er der for at adoptere open source-udviklingspraksis i kommercielle systemer? Hvorledes adskiller Bitcoin-systemet, og den anvendte udviklingsmetodologi, sig fra andre (større) open source-projekter? Hvilke muligheder er der for at adoptere gavnlige karakteristika og praksis i Bitcoin-projektet, i kommercielle udviklingsprojekter? Formålet med undersøgelsen er derfor at undersøge hvordan anvendelsen af FLOSS-metoder påvirker udviklingen af et sikkerhedskritisk informationssystem og hvordan dette kan påvirke udviklingsmetoder i kommercielle udviklingsprojekter. 4.3 Begrebsdefinitioner I denne sammenhæng er det værd at bemærke at der med sikkerhedskritiske systemer mener sikkerhed som i security-critical og ikke som i safety-critical. Forskellen i de to begreber ligger i at den førstnævnte omhandler software hvor softwaresikkerhed er kritisk i den forstand at det forventes at kunne fungere i et fjendtligt miljø, hvor ondsindede brugere vil forsøge at misbruge sikkerhedshuller eller systemfejl, hvorimod sidstnævnte relaterer til software der kan resultere i tabte menneskeliv, som fx medicinske systemer, rum- eller luftfartssystemer og lignende. (Gutgarts, 2010) Derfor skal sikkerhedskritisk i denne afhandling forstås som den engelske betegnelse, securitycritical, med mindre andet eksplicit er nævnt. For at gøre forskellen tydelig er begrebet livskritisk enkelte steder anvendt for at gøre forskellen tydelig. Side 15 ud af 66

Side 16 ud af 66

5 Metode For at give indsigt i denne afhandlings problemstilling og svar på det definerede undersøgelsesspørgsmål, samt underspørgsmål, beskrives i dette afsnit den anvendte fremgangsmåde og de metodiske udfordringer for afhandlingen. Først vil der blive redegjort for de metodeteoretiske valg som danner grundlaget for den praktiske udførelse og derefter en beskrivelse af den praktiske udførelse. Undersøgelsen udføres som et fortolkende enkelt-case-studie i form af en afgrænset etnografi, med det formål at tolke på aktører og artefakters betydning for problemstillingen. Som beskrevet i Walsham(1995) er det i et fortolkende case-studie nødvendigt at klargøre den filosofiske base for undersøgelsen, epistemologiske og ontologiske antagelser samt en gennemsigtig og struktureret metodologi. Et case-studie er i denne sammenhæng en empirisk undersøgelse der undersøger et fænomen i sin kontekst, særligt hvor grænser mellem fænomenet og omverdenen ikke er tydelige og afhænger af flere kilder. For det første antages det, ud fra et epistemologisk perspektiv, at den indsamlede empiri i høj grad reflekterer interviewpersoners baggrund og referenceramme ved interview og kontekst for feltarbejde, hvilket i praksis betyder at der skal tages højde for at respondenters holdninger i nogen grad kan afhænge mere af ideologiske årsager end egentlige videnskabelige kendsgerninger. Sagt på en anden måde antages det ontologiske perspektiv at det, der er videnskabelige kendsgerninger for én respondent, ikke nødvendigvis formodes at være gældende for øvrige interviewpersoner. Der kan altså være tale om forskellige verdensbilleder. Ligeledes anvendes, i nogen grad, Orlikowski(1994) s begreb om technological frames til at forklare aktørers modstridende forståelser og handlinger med hensyn til problemstillingen, altså en social-kognitiv tilgang til indsamling og fortolkning af empiri. Da undersøgelsen, i nogen grad, også indeholder decideret feltarbejde, i forbindelse med #Bitcoin2014-konferencen i Amsterdam og observation af kommunikation mellem udviklere, er der truffet bevidste valg med hensyn til graden af involvering som forsker. Walsham(2006) beskriver graden af involvering som en skala mellem at være en neutral observatør eller en Side 17 ud af 66

aktiv deltager. Det er værd at bemærke at Walsham ikke betragter neutral som uden bias, men blot som en observatør uden egentlige interesser i området. Tæt involvering giver mulighed for dybdegående adgang til aktører, problemstillinger og data. En tæt involvering giver ligeledes mulighed for at observere eller deltage i casen, i modsætning til udelukkende at analysere holdninger, i form af et case-studie udelukkende baseret på interviews(walsham, 2006). Walsham beskriver også gavnlige effekter ved den tætte involvering, i form af andre aktørers anerkendelse af at man som forsker prøver at komme med et gyldigt bidrag, frem for blot at indsamle data udelukkende for at tage den med sig og gøre det til en del af litteraturen. Walsham beskriver også ulemperne ved tæt involvering. Et eksempel er at feltarbejde generelt er en tidsmæssig krævende opgave, hvilket begrænser muligheden for at foretage andre tiltag til indsamling af empiri. En fordel ved den specifikke case er at et mere involveret feltstudie og etnografi, i dette tilfælde, ikke har helt de samme ressourcemæssige ulemper som et traditionelt feltstudie, da aktørerne(udviklerne) i dette tilfælde ikke er fysisk afgrænsede til en bestemt virksomhed eller fysik beliggenhed, da langt størstedelen af arbejdet foregår distribueret og online. Dette betyder at aktiv deltagelse på lige fod med udviklerne ikke bliver begrænset af logistiske hensyn, men på den anden side betyder det også at der ikke er de samme muligheder for fysisk at observere aktører, men udelukkende de artefakter der skabes gennem udviklingsarbejde og diskussion mellem udviklere. Walsham beskriver ligeledes en ulempe ved en mere aktiv deltagelse i form af at aktører muligvis vil være mindre ærlige overfor forskeren, hvis denne vurderes at have en personlig interesse i udfaldet. Derudover er det også nødvendigt at tage faren for at forskeren bliver socialiseret i feltet og dermed taber muligheden for at give et udefrakommende syn på casen eller endnu værre, mister den nødvendige videnskabelige distance til værdien af egne bidrag og derfor vurderer disse i et lidt for positivt lys (Walsham, 2006) Bryman(2012, pp. 441) beskriver forskellige roller og måder at deltage i etnografisk forskning, der hver især har forskellige implikationer for forskerens rolle, der i høj grad minder om Walsham(2006) s syn på graden af involvering. Brymans spektrum spænder fra Covert Full Member, hvor aktører ikke informeres om at de er en del af et studie og forskeren deltager på lige vilkår med andre medlemmer og bliver et fuldt medlem af fællesskabet, til Non-participating observer with interaction, som er en tilgang, hvor der udelukkende observeres og interageres med medlemmerne af det undersøgte fællesskab og ikke deltages i aktiviteter. For det første er der valgt en tilgang med åbenhed overfor de undersøgte medlemmer, i form af at der i de fleste konkrete tilfælde, hvor det er relevant og praktisk muligt, gøres opmærksom på formålet med Side 18 ud af 66

stillede spørgsmål og deltagelse i diskussioner. Denne åbenhed, om at deltagelsen foregår med baggrund i et studie af udviklingsprocessen, skyldes både etiske og praktiske elementer. På et etisk grundlag ses der ikke umiddelbare formål med at deltage misvisende og foregive at deltagelsen sker på et andet grundlag end det er tilfældet og af praktiske årsager er det en fordel, hvis respondenter og medlemmer af fællesskabet er klar over at mange spørgsmål ikke nødvendigvis skyldes uvidenhed om en teknisk detalje(selvom det selvfølgelig godt kan være tilfældet), men et ønske om at få medlemmer af fællesskabet til at reflektere over udviklingsprocessen og forklare den, som de selv observerer den. Sammenlægger man Bryman og Walsham s beskrivelser til en ti-punktsskala, hvor 10 er fuldstændig deltagelse som fuldt medlem af fællesskabet og indlevelse på lige vilkår med alle andre deltagere i fællesskabet og 1 er slet ingen deltagelse og udelukkende består i observation og interview, er der valgt en tilgang hvor forskeren ligger på ca. 3. Denne placering skyldes at der ønskes en begrænset deltagelse, hvor observationen og deltagelsen ikke nødvendigvis er de primære datakilder til empiri, men bliver suppleret med interview og andre kilder. Denne begrænsede deltagelse, skyldes at det ikke forventes at der kan arbejdes på lige vilkår med kodning og beslutninger, som øvrige deltagere der typisk har flere års erfaring, men alligevel ønskes det at komme med input og forslag, hvor forskningen eller den opnåede forståelse af systemet kan give værdifuld indsigt og hjælp til fællesskabet. Walsham(2006) beskriver et eksempel på denne situation, hvor der af moralske årsager blev valgt at give råd og vejledning til en undersøgt organisation, på trods af en indledende beslutning om at forholde sig nogenlunde neutrale. I praksis kan et eksempel på denne hjælp og vejledning, være at hjælpe helt nye medlemmer der har en endnu mindre forståelse af systemet end undertegnede. Ovenstående benævnelse begrænset etnografi, skyldes at denne undersøgelse, af ressourcemæssige årsager, ikke vil have et omfang på linje med en typisk etnografi som beskrevet i Bryman(2011) og for det andet at denne undersøgelse adskiller sig væsentligt fra typiske etnografier da samtlige aktører og medlemmer af fællesskabet ikke mødes og arbejder fysisk, men at fællesskabet er virtuelt i kraft af at deltagelsen i langt de fleste tilfælde foregår online. Ligeledes er det værd at bemærke at selvom Bitcoin-systemet har indflydelse på en lang række områder og fælleskabet i praktis også strækker sig ud over selve udviklingen til den gennerelle interesse for systemet, blandt folk der ikke nødvendigvis er udviklere, så er fokus for denne specialeafhandling udelukkende selve udviklingsprocessen for systemet, og kan på den baggrund beskrives, som det Bryman(2011) kalder en Micro-ethnography. Dertil kommer at den valgte rapporteringsform kun i nogen grad afhænger af retoriske etnografiske værktøjer til Side 19 ud af 66

at beskrive et givent fænomen, men i høj grad anvender teorien som strukturel rygrad for rapporteringen. Beskrivelsen som et etnografisk studie stammer derfor i højere grad fra selve udførelsen end etnografi som rapporteringsform. 5.1 Forskningsdesign Da problemstillingen omhandler en ny, ikke tidligere udforsket, case der tiltrækker en forholdsvis stor mediebevågenhed(se afsnit 5.2, Dataindsamling) og et deraf afledt pres på kerneaktører, samt casens globale natur, blev det indledende vurderet at undersøgelsen ville være problematisk at gennemføre udelukkende ved hjælp af interviews, da adgangen til kompetente respondenter for interviews ville være begrænset. På denne baggrund vurderedes at en vis grad af indlevelse i casens samspil med omverdenen var nødvendig gennem hele undersøgelsesforløbet og at denne indlevelse med fordel kunne udføres som en etnografi, for ikke blot at basere undersøgelsen på en stærkt begrænset mængde interviewpersoner, men også forskerens personlige oplevelse af fænomenet i kontekst. I praksis har denne indlevelse foregået gennem daglig gennemgang af nyhedsmedier og diskussions-fora med et specifikt fokus på casen. Som eksempler på disse medier kan nævnes: Coindesk.com - Nyhedsside med fokus på Bitcoin og kryptografiske valutaer Bitcointalk.org - Diskussions-forum om Bitcoin reddit - Brugerdrevet nyhedsaggregering og brugergenereret indhold. Underafdelingerne /r/bitcoin og /r/bitcoindk er anvendt Zeroblock.com - Bitcoin-relateret nyhedsaggregering fra forummer, Twitter, Reddit, samt øvrige nyhedssider Enkelte benævnelser i den danske dagspresse Ovenstående medier har ikke været anvendt til decideret indsamling af empiri til bearbejdning af casen, men udelukkende til at give en nødvendig baggrundsviden for at kunne forstå systemet, de relevante fagtermer i systemet og den virkelighed systemets udviklere arbejder ud fra. Denne generelle forståelse for systemets omgivelser er nødvendig for at kunne udarbejde en Side 20 ud af 66

interviewguide i et sprog respondenten forstår, for at kunne se konsekvenser af udvikleres valg i en større sammenhæng og sidst men ikke mindst for at kunne analysere fænomenet i en bredere kontekst. 5.2 Data- og teori-indsamling Konkret empiri er indsamlet gennem et litteraturstudie, hvor casens fremtræden i peer-reviewed tidsskrifter er undersøgt, deltagelse i konferencen #Bitcoin2014 i Amsterdam, interview med udviklere, e-mail-korrespondance med udviklere, gennemgang af tidligere diskussioner mellem udviklere i Bitcoin-projektets issue-tracking-system på Github 1 samt observation af, og deltagelse i, diskussion mellem udviklere på projektets IRC-kanal 2 for udviklere, #bitcoin-dev, på chat-netværket Freenode.net. 5.2.1 Litteraturstudie Ved en gennemgang af otte ledende fagtidsskrifter for ledelse af informationssystemer viste det sig at Bitcoin-systemet ikke tidligere har været anvendt som case eller på anden måde er nævnt i faglitteraturen for IS-management. På den baggrund vurderes det som fordelagtigt, i begrænset omfang at undersøge, hvilke andre fagområder systemet er behandlet under. Et indledende litteraturstudie er foretaget gennem Aalborg Universitetsbiblioteks(AUB) artikelsøgningsværktøj, Primo, gav 2675 resultater med søgetermen bitcoin på engelsk, hvoraf de 1884 var avisartikler. Afgrænset til peer-reviewed artikler på engelsk indeholdende termen bitcoin har søgningen kun givet 62 resultater. Tabel 1 viser de videnskabelige journaler de 62 artikler er optaget i. Efter en frasortering af de fleste dubletter og artikler på fremmedsprog er resultatet afgrænset til 55 artikler, hvoraf en stor del(26) udelukkende nævner begrebet kort, som fodnote eller som eksempel på nye teknologier. 1 https://github.com/bitcoin/bitcoin GitHub is a web-based hosting service for software development projects that use the Git revision control system. GitHub offers both paid plans for private repositories, and free accounts for open source projects. (Wikipedia) 2 IRC står for Internet Relay Chat. Freenode.net er et chat-netværk primært fokuseret på chat om gratis og open source software. Side 21 ud af 66

Ud af de 55 artikler har kun 29 artikler Bitcoin eller kryptografiske valutaer generelt som hovedemne eller behandlet specifikt. Resultatet af dette litteraturstudie og emnemæssig kategorisering findes i bilag 11. Da der ikke har vist sig at være litteratur indenfor IS-management-litteraturen direkte relateret til den konkrete case er der også søgt litteratur vedrørende open source udvikling af kritiske systemer og såfremt det ikke findes i sammenhæng vil de to blive undersøgt hvert for sig. Gennem denne anden litteratursøgning blev der udvalgt to teoretiske tilgange, som er beskrevet i afsnit 6. Udvælgelseskriterierne er at finde i bilag 2. 5.2.2 Konferencedeltagelse Da Bitcoin-systemet er udviklet open source og globalt distribueret er det generelt en ressourcemæssig hindring at indsamle primær-empiri fra eksempelvis Bitcoin Foundation, som er den største verdensomspændende Bitcoin-interesseorganisation og er registreret i San Francisco, eller for den sags skyld få mulighed for at interviewe kerne-udviklere personligt. At arrangere digitale interviews, eksempelvis gennem Skype-møder, kan også give problemer da de fleste nøglepersoner indenfor miljøet er travle mennesker, har mange journalister der ofte forsøger at kontakte dem og desuden er det svært at få personlig kontakt med mindre man selv er en del af udviklermiljøet(hvilket igen er et argument for undersøgelsens etnografiske Side 22 ud af 66

udformning). Tilfældigvis var Bitcoin Foundation s årlige konference, #Bitcoin2014 - building the digital economy, planlagt til at foregå 15. til 17. maj 2014, i Amsterdam, hvilket viste sig at være en oplagt mulighed til at komme i kontakt med primærkilder, da det ressourcemæssigt kunne lade sig gøre at deltage i konferencen. På trods af et tætpakket program(bilag 1) gav konferencen mulighed for at stille få udvalgte spørgsmål til kerneudviklere og udviklere der på anden vis har arbejdet med Bitcoin-systemet, i forbindelse med talerne. Begrænsninger ved denne deltagelse i konferencen er beskrevet i afsnit 9. 5.2.3 Interview Der er, med udgangspunkt i Torkar et al s framework, udarbejdet en interviewguide(se bilag 5) med det formål at fungere som ledetråd og guide til semistrukturerede kvalitative interview. Interviewguiden følges ikke stringent, da der i kvalitative interviews skal være mulighed for at komme omkring øvrige interessante områder under interviewet, men anvendes som checkliste, for at sikre at alle relevante områder tilstrækkeligt er afdækket(kvale, 2007) Med hensyn til diskussionen om hvorvidt open source kode er mere eller mindre sikkert end proprietær kode er enkelte åbne spørgsmål tilføjet og det ønskes under selve interviewet, alt efter respondentens viden på området, at indsamle sigende data om den del af problemstillingen. 5.2.4 Deltagelse i udviklerdiskussion på #bitcoin-dev IRC-chat anvendes ofte mellem udviklere og er et vigtigt uformelt værktøj til at kommunikere i real-tid, men stadig at bevare den asynkrone natur ved kommunikationen(se afsnit 6.2.5). Dette værktøj er essentielt i forbindelse med en etnografisk undersøgelsestilgang, da det giver mulighed for at kommunikere med fællesskabets medlemmer på en mere uformel basis end eksempelvis e-mail eller diskussioner om specifik kode. Ved at deltage i og observe realtidschat mellem udviklere forventes det derfor at kunne opnå et værdifuldt indblik i, hvordan udviklere bruger værktøjet, samt hvilken indflydelse det har på beslutningsprocessen. To uddrag fra kanalens chatlog er vedlagt som bilag 8 og 9. Side 23 ud af 66

5.3 Analysemetode Det søges at besvare de valgte undersøgelsesspørgsmål ved at analysere og fortolke den indsamlede empiri ud fra den valgte teoretiske ramme. Den praktiske udførelse af analysen foretages derfor ved at anvende Torkar et al s(2011) framework til sammenligning af udviklingsmetoder på den indsamlede empiri. Ved at undersøge forskelle og ligheder mellem de i Torkar et al(2011), Payne(2002) identificerede karakteristika ved FLOSS-udvikling(se afsnit 6, Teori) generelt og den indsamlede empiri vedrørende Bitcoin Core-projektet forventes det derfor at kunne klargøres, hvorvidt Bitcoin-systemet kan give yderligere indsigt i potentielle fordele, men også potentielle ulemper, ved anvendelsen af FLOSS-udviklingsmetoder i kommercielle proprietære projekter. I praksis gennemgås empirien systematisk og det vurderes for hvert enkelt uddrag eller citat om det er sigende for et eller flere af punkterne i Torkar et al(2011) s framework eller Payne(2002) s beskrivelse af argumenter for og imod brugen af open source-kode i sikkerhedskritiske projekter. På den måde bliver det tydeligt, hvorvidt alle sigende informationer er beskrevet og hvad der eventuelt ikke kan kategoriseres meningsfyldt under et af de eksisterende punkter i det eksisterende framework. Det er værd at bemærke at Torkar et al s framework ikke anvendes stringent, men er tilpasset i den forstand at det ikke anvendes til at sammenligne to udviklingsmetodologier, på samme måde som det er gjort i den oprindelige artikel, men at der derimod sættes fokus på de identificerede egenskaber ved FLOSS-projekter og identificerede adoptionsmuligheder. Dette har to fordele. For det første kan denne tilgang anvendes til at validere resultaterne fra Torkar et al(2011) ved hjælp af identificerede sammenfald og eventuelle modsætninger. For det andet kan denne tilgang gøre det lettere at identificere helt nye adoptionsmuligheder eller farer ved at anvende FLOSS-metodologier der ikke tidligere er identificeret. Side 24 ud af 66

Side 25 ud af 66

6 Teori 6.1 Fordele og ulemper ved open source-teknikker som udviklingsmetode I nedenstående er fordele og ulemper ved anvendelsen af open source-teknikker til udvikling af sikkerhedskritisk software. En stor del af internettets grundlæggende infrastruktur afhænger af gratis open sourcesystemer, som fx Apache Web Server, BIND DNS-serveren og de forskellige Linuxdistributioner. Alligevel er der ikke opnået videnskabelig konsensus om hvorvidt brugen af systemer med åben kildekode er mere eller mindre sikkert end centralt udviklet lukket proprietær kode. Payne (2002) behandler de forskellige argumenter for og imod brugen af open source udviklet software og finder en større sammenhæng mellem pro-aktive kode-reviews med hensyn til sikkerhed end blot at koden er open source. Sagt på en anden måde bliver kode ikke mere eller mindre sikker af at koden er offentligt tilgængelig, men har dog potentialet til at blive mere sikker end proprietær kode. Fordele ved open source-teknikker 6.1.1.1 Sikkerhed gennem peer reviews Hovedargumentet for at open source er mere sikkert end proprietær lukket kode, er at koden er offentligt tilgængeligt og bliver derfor kan, og bliver, gennemset og kritiseret af kollegaer og programmører der har en interesse i projektet, på samme måde som akademiske artikler bliver reviewet af eksperter indenfor et givent fagområde, før produktet anerkendes. De programmører som gennemgår kildekoden rapporterer bugs og sikkerhedsbrister til projektets ejer eller fællesskabet generelt og kommer eventuelt med deciderede løsningsforslag Side 26 ud af 66

i form af opdateret kildekode. Argumentet er ofte kort beskrevet som Given enough eyeballs, all bugs are shallow, altså at med tilstrækkelige øjne på kildekoden er alle fejl lette at løse.(payne, 2002) Et godt eksempel på denne styrke ved open source udvikling er at det i praksis er næsten umuligt at indsætte en såkaldt bagdør i koden, som giver utilsigtet(for brugeren) mulighed for at kompromittere det system softwaren er installeret på(payne, 2002), hvorimod denne type bagdøre i lukket kode kan eksistere meget længe, hvis en kommerciel virksomhed bevidst inkluderer denne type ondsindet kode. Dette var eksempelvis tilfældet hos Borland, hvor der i 1992 bevidst blev installeret en bagdør i virksomhedens kommercielle database-system, som først blev opdaget ni år senere, efter systemet blev udgivet som open source. Dertil kommer at de fleste open source systemer udvikles på en måde hvorved det er meget svært at snige ondsindet kode ind i projektet, da kode kun kan inkluderes i den næste version, hvis den er blevet gennemgået af betroede medlemmer af fællesskabet med længere involvering i projektet.(payne, 2002) 6.1.1.2 Fleksibilitet og frihed Et andet vigtigt argument for brugen af open source metoder er brugernes mulighed for at undersøge koden for sikkerhedsrisici. Derudover er det muligt for virksomheder med kompetencerne in house at tilpasse koden til egne formål uden eksplicit tilladelse fra udgiveren og har dermed mulighed for at rette fejl og tilføje funktioner uden at skulle vente på at en opdatering fra udgiveren. Selvom det selvfølgelig ikke er alle virksomheder der har ressourcerne til at foretage sikkerhedsundersøgelser, må det formodes at virksomheder der er helt afhængige af sikkerhedskritiske informationssystemer, som minimum har kompetencerne til at undersøge sikkerhedsbrister og implementere sikkerhedsopdateringer(payne, 2002). Payne(2002) bruger NSA s udvikling af en ny sikkerhedsoptimeret version af styresystemet, Linux( NSA Security-Enhanced Linux 2000 ), som eksempel på denne mulighed for at tilpasse open source systemer til anvendelser der stiller højere krav til systemers sikkerhed. 6.1.2 Ulemper ved open source software Payne(2002) beskriver modstandernes argument mod sikkerheden i open source software, som grundet i et et helt andet filosofisk perspektiv og fortalere for lukket kode har derfor et helt andet synspunkt når det kommer til sikkerheden. Argumentet er nemlig at fordi sikkerhedshuller er Side 27 ud af 66

lettere at finde når man har adgang til kildekoden vil der blive fundet færre sikkerhedshuller i lukket kode og derfor vil et system med lukket kildekode være mere sikkert. Det interessante ved denne holdning er at fortalere for begge løsninger bruger samme argument(at sikkerhedshuller er lettere at finde i åben kode), men kommer frem til to forskellige konklusioner. Pointen er derfor at hvis sikkerhedshuller forbliver uopdagede, vil de ikke udgøre en sikkerhedsrisiko. Dette bygger på argumentet at sikkerhedshuller rent faktisk er sværere at finde i lukket kode, men Payne beskriver en situation, hvor dette ikke nødvendigvis er tilfældet. Som han beskriver situationen kræver det nemlig blot andre værktøjer til at finde disse sikkerhedshuller, i form af eksempelvis black box-testing, hvor softwaren testes udover sine normale grænser og sikkerhedshuller dermed kommer til syne ved at softwaren reagerer anderledes end den burde. På den anden side skal det nævnes at Payne ligeledes nævner at denne black box-tilgang kun ville være lettere, hvis kildekoden var kendt. Ifølge dette argument gør åben kode det altså lettere at finde sikkerhedshuller og argumentet for at holde koden lukket, støtter altså peer review argumentet præsenteret ovenfor, men spørgsmålet som Payne ser det er derfor om peer review-argumentet overhovedet er gyldigt og om udgivelse af kildekode i praksis er det samme som review-praksissen for videnskabelige resultater. Argumentet i mod open source kode i dette tilfælde er derfor at selvom kildekoden er offentlig tilgængelig, betyder det ikke nødvendigvis at den er blevet reviewet tilstrækkeligt, i modsætning til videnskabelige resultater der først bliver offentliggjort når de er blevet udsat for review af kolleger, analyseret, kritiserede og validerede. En række argumenter mod open source, som Payne nævner, på denne baggrund er eksempelvis at selvom kode bliver offentligt og reviewet er det ikke sikkert at disse reviews overhovedet bliver foretaget af kvalificerede sikkerhedsauditører, men i mange tilfælde blot brugere der ikke nødvendigvis har kompetencerne til at gennemskue software og se komplekse sikkerhedsmæssige problemstillinger. På den baggrund bliver brugere nødsaget til at stole på udgiveren, nøjagtig ligesom på samme måde som brugeren bliver nødt til at stole på udgiveren af proprietær software. Payne nævner desuden en række open source projekter der, selvom de har været bredt anvendt, har haft sikkerhedsfejl og huller i længere tid alligevel og disse eksempler af fortalere for lukket kode tæller som en knæk for peer review-processen og sikkerheden i open source-software. Side 28 ud af 66

Derudover nævner payne problemstillingen i at meget open source-software ofte udgives som binære pakker(altså maskinkode) og brugeren derfor sjældent har nogen garanti for at det program brugeren anvende, rent faktisk stammer fra den kildekode som udgiveren har gjort tilgængelig. Generelt kan argumenterne for og imod åben kildekode derfor kort fremstilles som nedenstående: Argumenter for åben kildekode: Peer review Frihed til at rette koden Fleksibilitet Uafhængighed Argumenter imod åben kildekode: Hvis fejl ikke findes, eksisterer de ikke i praksis Peer review-processen er ikke effektiv nok Manglende ekspertise i open source Ekspertisen findes ofte kun hos hackere Paynes konklusion er derfor at åben kildekode gør det lettere at finde sikkerhedsfejl og sikkerheden i open source software derfor afhænger af, hvorvidt kildekode rent faktisk bliver tilstrækkeligt reviewet i praksis og om der er den tilstrækkelige ekspertise blandt auditørerne. Han pointerer derudover at, hvor open source ikke kommercielt set har noget at tabe, hvis der bliver opdaget sikkerhedsfejl, har kommerciel proprietær software ofte et ry og rygte at beskytte, og har derfor en interesse i at sikkerhedsfejl ikke bliver opdaget overhovedet. I det tripple-case studie, omhandlende Debian Linux(åben), OpenBSD(åben) og Solaris(Lukket), som Payne undersøger konkluderes det på empirisk vis gennem et tidligere sikkerhedsstudie at de to åbne systemer har vist sig at være mest sikre i praksis, men også at der generelt blev fundet flere sikkerhedsfejl i Solaris, på trods af den lukkede kildekode. I den sammenhæng postulerer han desuden at forskellen mellem sikkerheden i åben og lukket kode, muligvis kan ligge i at sandsynligheden for at en sikkerhedsfejl bliver fundet og indrapporteret er større i open source-projekter, da brugere der leder efter fejl i lukkede systemer sjældnere har ædle hensigter. Payne s afsluttende pointe er dog helt tydelig og gør det klar at open source ikke er mere sikker Side 29 ud af 66

end lukket kode, bare fordi den er åben, men kun hvis koden rent faktisk bliver reviewet af nok og tilstrækkeligt kompetente udviklere. Han slutter af med at citere Elias Levy(2000, i Payne 2002): Open source software certainly does have the potential to be more secure than its closed source conterpart. But make no mistake, simply being open source is no guarantee of security 6.2 Open source- og proprietær udvikling samt adoptionsmuligheder Torkar et al(2011) identificerer flere områder hvor FLOSS-teknikker skiller sig ud fra kommerciel softwareudvikling og eventuelt kan anvendes til industriel brug og forklares her med det formål at sammenligne de identificerede adoptionsmuligheder. 6.2.1 Torkar et al s framework til sammenligning af udviklingsmetoder 6.2.2 Baggrund Torkar et al(2011) ser det som nødvendigt at beskrive baggrunden for en udviklingsmetodologi, formålet med den og de grundlæggende antagelser der ligger til grund for den, da ingen udviklingsmetodologi opstår fra et vakuum. Under selve analysen er dette afsnit inddelt i de samme fem punkter som Torkar et al s framework. 6.2.3 Model For model taler Torkar et al(2011) om den konkrete model eller et billede af hvordan metodologien forventer at udviklingen organiseres. Her er typisk tale om roller, processer og procedurer. For Torkar et al(2011) har fokus, i mangel af definitioner for FLOSS-modeller, ligget på at identificere, hvem der gør hvad og bemærket at der i FLOSS-projekter ofte findes en MAINTAINERS-fil der gør det muligt for udviklere og bidragydere at se, hvem der har ansvaret for et bestemt stykke kode. Side 30 ud af 66

6.2.4 Livscyklus Livscyklus omhandler den typiske process kildekode gennemgår fra planlægning til en produktionsudgivelse. Dette punkt er videre beskrevet i analysen i sammenhæng med selve casen. 6.2.5 Regler og værktøjer Dette punkt omhandler de nødvendige regler og værktøjer udviklere benytter i deres daglige arbejde. Torkar et al(2011) har for FLOSS-projekter identificeret blandt andet hjemmeside, mailing-lister, versioneringssystem, bug tracking, og realtids-tekst-chat (IRC). 6.2.6 Deltagelse Deltagelse omhandler, hvordan udviklere organiserer sig, på hvilket grundlag deltagelse i projektet foregår samt hvordan nye medlemmer bliver en del af projektet. Torkar et al(2011) har blandt andet identificeret at der i større open source-projekter er en tendens til modulering og gruppedannelse indenfor projektet, for bedre at kunne håndtere en større kodebase. Derudover er der identificeret at open source-udviklere ofte er en del af flere projekter på samme tid, men typisk med forskellig involvering. Derudover er der observeret at nogle FLOSS-projekter har eksplicitte kanaler til at opfordre til deltagelse i projektet og/eller har åbenlyse introduktionsveje til nye medlemmer. 6.2.7 Aktiviteter Med aktiviteter menes de udviklingsaktiviteter der tilsammen udgør selve udviklingsprocessen. Disse er beskrevet i nedenstående underpunkter. 6.2.7.1 Decision making I selvstyrende teams ligger en stor del af beslutningskompetencen hos udviklerne og de enkelte teams, men alligevel identificerer Torkar et al(2011) at en stor del af de adspurgte udviklere mener at øget medarbejderindflydelse vil være gavnlig for det truffede beslutninger. Decision-making i FLOSS-projekter foregår derimod gennem så høj grad af konsensus som muligt, hvor de involverede udviklere har næsten uendelig indflydelse på beslutninger og beskriver kun projektets hovedudvikler som en benevolent dictator, altså en velvillig/godsindet Side 31 ud af 66

diktator, som kun tager direkte beslutninger når det ikke er mulighed at opnå enighed gennem konsensus. I større projekter der afhænger af flere moduler kan dette ansvar fordeles på flere vedligeholdere, som leder enkelte moduler på samme måde som hovedudvikleren leder det samlede projekt. Der kan være flere vedligereholdere, men typisk kun én hovedudvikler. Generelt gør det sig gældende at beslutninger udelukkende gennemføres ved magt når det er tydeligt at fællesskabet ikke opnår enighed gennem konsensus og at beslutninger skal være offentlige, gennemsigtige og eksplicitte, og alle medlemmer af fællesskabet skal kunne deltage, hvis ønsket. (Torkar et al, 2011) Når beslutninger foregår offentligt medfører det ofte at beslutninger kan trække ud, men gør samtidig at beslutnigner tages på et dybere grundlag og er resultatet af flere synspunkter. På denne måde bliver beslutninger lettere accepteret af fælleskabet. Derudover betyder den offentlige beslutningsproces også at nye medlemmer af fællesskabet har mulighed for at se, hvilket grundlag tidligere beslutninger er på og brugen af mailing-lister og FAQ er fremmer ligeledes gennemsigtigheden i beslutningsprocessen og undgår gentagne diskussioner om de samme emner. Torkar et al(2011), beskriver ligeledes hvordan udviklingsdiskussioner på Linux kernen ikke accepteres med mindre de bunder i konkrete kodeeksempler eller pull requests. På denne måde betyder det ofte at beslutninger træffes efter den egentlige udvikling, hvilket kan synes et spild af ressourcer og direkte ulogisk. Det er dog med til kraftigt at begrænse nytteløse diskussioner. Det er dog værd at bemærke at selvom et kodeeksempel ikke bliver optaget i det originale projekt står det enhver udvikler frit for at anvende det til egen brug eller direkte starte en forgrening af projektet. Dette er i modsætning til kommercielle projekter rent licensmæssigt muligt i open source projekter fordi de fleste open source licenser tillader enhver at ændre og udgive koden under eget navn, fx så længe det originale projekt får merit for arbejdet eller at den nye forgrening udgives under samme licenstype. 6.2.7.2 Koordination og kommunikation I traditionelle udviklingsprojekter bruges en stor mængde ressourcer på planlægning og koordination mellem parallelle projekter der er afhængige af hinanden. I forhold til dette kan FLOSS-udviklingens flade struktur virke mere simpel, men i virkeligheden kan de underliggende kommunikationsstrukturer være mere komplekse. Generelt kan kommunikationsformen karakteriseres som heterarkisk, fra et hierarkisk synspunkt er der sjældent mere end tre Side 32 ud af 66

niveauer af udviklere, bestående af en heterogen udviklerbase, en gruppe vedligeholdere og en projektleder eller godsindet diktator (Torkar et al, 2011). Generelt er projektlederen den eneste der bliver i toppen i længere tid, hvorimod vedligeholdere og udviklere kan skifte rolle efterhånden som projektet skrider frem eller personlige interesser skifter. Derudover vil man ofte se at en udvikler kan have flere roller på samme tid, fx udvikler på et modul, vedligeholder på et andet og reviewer på flere øvrige. Overordnet er FLOSSudvikling derfor koordinationsmæssigt et løst sammensat netværk hvor interaktioner dynamisk etableres og forældes. Thus, when observing the network of interactions as a whole, we can see a loosely coupled network where interactions are dynamically established and deprecated Torkar et al (2011) Selvom traditionelle og agile udviklingsmetoder generelt virker mere ordnede og effektive har FLOSS-fællesskaber flere fordele afledt af disse heterarkier. Ved hjælp af ovenstående fordeling i vedligeholdere og generelle udviklere bliver svære opgaver typisk taget af den bedste tilgængelige udvikler og mindre opgaver udføres af mindre erfarne udviklere der søger at opnå anerkendelse. Denne anerkendelse er netop det der holder det meritokratiske system som FLOSS-udvikling bygger på i gang. Torkar et al beskriver derudover fordelen, i at FLOSS omfavner forandring og reducerer afhængigheden af en enkelt udvikler, i modsætning til kommercielle projekter, hvor udskiftning af udviklere generelt ikke er velset. Torkar et al(2011) beskriver ligeledes nødvendigheden for at have passende værktøjer til at facilitere kommunikationen, som fx issue-tracking, mailing-lister, FAQ er(lister over ofte stillede spørgsmål). Derudover beskrives tre informationstyper, som er nødvendige i overflod, nemlig teknisk know-how, adfærdsmæssige retningslinier og tydelige konfliktløsningsprocedurer. Teknisk know-how er nødvendigt for at kommunikationskanalerne ikke bliver oversvømmet med praktiske og tekniske spørgsmål når udviklere skifter opgaver, det er nødvendigt med adfærdsmæssige retningslinier, så udviklere ved hvad der er forventet af dem og hvad de kan forvente af andre og klare konfliktløsningsprocedurer fortæller medlemmerne af fællesskabet hvordan konflikter løses i værste tilfælde, når diskussioner tager så lang tid at de direkte hæmmer udviklingsprocessen. Side 33 ud af 66