Sammanfattning. Att gaffel ett projekt är att kopiera den befintliga kodbasen och gå i en annan riktning än det tidigare projektledarskapet. Gaffel ger ett snabbt sätt att möta nya krav genom att anpassa en befintlig lösning. Men det kan också skapa en uppsjö av liknande verktyg, och fragmentera utvecklargemenskapen. Därför är det inte alltid klart om forking är rätt strategi. I den här artikeln beskriver vi en blandad metod för att undersöka fallstudie som undersökte processen med att förfalska ett projekt. Undersökningen gällde förgreningen av ett verktyg med öppen källkod för hantering av programvaruprojekt, Trac. Trac tvingades ta itu med olika krav i en akademisk miljö. Tidningen ger två bidrag till vår förståelse av kodgaffel. För det första genererade vår undersökande studie flera teorier om kodgaffel i projekt med öppen källkod, för ytterligare forskning. För det andra undersökte vi en av dessa teorier på djupet, via en kvantitativ studie. Vi antog att funktionerna i OSS-gaffelprocessen skulle göra det möjligt att ta itu med nya krav. Vi visar att gaffelprocessen i detta fall var framgångsrik när det gäller att uppfylla de nya projektkraven. Traditionellt utgör kravanalys den inledande fasen av ett programvaruutvecklingsprojekt och genomförandet den sista. Men vad händer när en kodbas redan finns och fungerar som utgångspunkt för mjukvaruutveckling? Vi studerar denna fråga i samband med programvara med öppen källkod. Programvara med öppen källkod (OSS) har visat sitt värde. OSS driver några av de största webbplatserna i världen (Apache), komplexa företagsservrar (Linux/BSD), och är jämförbar med egenutvecklade skrivbordsprogram (OpenOffice) [1]. Det finns dock fortfarande en uppfattning om att OSS inte är av hög kvalitet, och antagandet av OSS i företags IT-miljöer är fortfarande låg. Goode [2], i sin undersökning av australiensiska företag, diskuterar flera skäl till detta. De inkluderar en upplevd brist på stöd, dolda installationskostnader, och slutligen, en övertygelse om att företagets IT-krav inte uppfylls av några befintliga OSS-verktyg. Att gaffel ett projekt är att kopiera den befintliga kodbasen och gå i en annan riktning än det tidigare projektledarskapet. Genom att länka samman kodbasen kan utvecklare utnyttja befintlig funktionalitet och samtidigt ta itu med nya krav. Även om gaffeln är flexibel, har den inneboende svårigheter, till exempel underhåll, utveckling och sociala faktorer som rör utvecklingsgemenskapen. I det här pappret ser man hur de ser ut. För att studera problemet och utvärdera potentiella lösningar fokuserar vi på ett verktyg för programvaruprojekthantering, Trac. Eftersom Trac hade en ursprunglig målgrupp var den avsedd för utvecklare i en företagsmiljö och släpptes sedan mer allmänt. Under 2005 användes verktyget för att stödja utvecklingen av ett projekt som inriktades på programplaneringsprojekt på grundnivå. Denna process och dess konsekvenser är föremål för denna forskning. Vi följde en sekventiell metod i två faser [3] för att undersöka samspelet mellan gaffel och krav. I den undersökande fasen (avsnitt 1.4.2) undersökte vi kvalitativt karaktären av OSS, krav, och gaffel genom att genomföra undersökningar och intervjuer av deltagare från arXiv:1004.2889v1 [cs.SE] 16 Apr 2010 både det ursprungliga och det kluvna projektet. Med utgångspunkt i grundteori [4] genererade vi flera teorier om problemet. Vi valde sedan en teori och tillämpade bekräftande analys i den andra fasen. I detta främst kvantitativa segment var teorin vi testade om några av de olika krav som motiverade gaffeln uppfylldes. Vi analyserade detta med hjälp av två icke-funktionella krav. Vi använde först en mängd olika kodmått av de två kodbaserna (avsnitt 1.5) för att bedöma underhållbarheten. För det andra använde vi kvalitativa användbarhetsanalyser för att bedöma gränssnittets komplexitet eller användbarhet. Vi utformade denna studie som en undersökande studie eftersom det saknades detaljerad forskning om vadslagningen av OSS för att möta olika krav. På så sätt genererar vi några lämpliga forskningshypoteser för ytterligare testning. Den andra, mer kvantitativa delen av forskningen undersöker om kodgaffel framgångsrikt kan uppfylla vissa nya krav. I vissa avseenden hävdar vi i avsnitt 1.6 att många av de teorier som vi ursprungligen genererade är bäst lämpade för kvalitativ analys eller fallstudieanalys. Vårt bidrag är tvåfaldigt. Ett, vi beskriver några av de processfrågor som uppstår när gaffel OSS. Vi tillhandahåller teorimönster härledda från data som är ett steg mot mer omfattande teorier om denna process. Två, vi beskriver en fallstudie på en produkt av en gaffel, DrProject. I denna fallstudie undersökte vi hur väl det kluvna verktyget kunde anpassas för att uppfylla nya krav, som inte fanns i originalet. Vi börjar med en kort introduktion till de berörda verktygen. För att ge ett sammanhang går vi sedan kort igenom litteraturen. Denna forskning kompletterar den befintliga litteraturen eftersom få personer har tittat på programvara med öppen källkod utifrån ett behovsperspektiv (krav nämns sällan i OSS; ofta initieras ett projekt på grund av upplevt behov). Det har också inte gjorts särskilt mycket arbete med att förfalska. Sammanhanget för denna studie är utvecklingen av en programvara projekthanteringsverktyg som heter Trac 1. Trac är för närvarande (i januari 2006) i version 0.9.3 och stöder bland annat Subversion arkivintegration, Wiki-aktiverade webbsidor, biljetter och felarkivering (en biljett är en uppgift som kan tilldelas projektmedlemmar). Trac utvecklas som ett projekt med öppen källkod, under ledning av två utvecklare på Edgewall Software. I januari 2005 beslutade två fakultetsmedlemmar vid University of Toronto (inte involverade i att bedriva denna forskning) att gaffel Trac för att stödja grundutbildning. Trac valdes, enligt intervjuer med förespråkarna, av tre skäl: 1) det var skrivet på ett bekant språk (Python); 2) det hade enkel teknik (CGI); 3) det hade en liten kodbas och ren UI. Resultatet av gaffeln, DrProject 2, är det senaste i en serie försök att utveckla programvara för att stödja studentprogrammeringsprojekt på grundnivå. Utbildare vid University of Toronto trodde att utexaminerade elever lämnade omedvetna om vikten av felrapporter och versionskontroll. De bestämde sig för att ett verktyg skulle utvecklas för att utvidga detta pedagogiska mål (inte mot bakgrund av rapporter om att ett stort antal företagsprogramutvecklare var lika obekanta med verktygen). Ett antal tidigare försök har gjorts att utveckla ett sådant verktyg vid University of Toronto (se bild). 1.1............................................................................................................................. Denna senaste iteration har varit den mest framgångsrika, med antagande av två separata kurser, ett självupptaget utvecklingsprojekt, och intresse från akademiska forskningslabb på institutionen. Vi framkallade de viktigaste kraven genom intervjuer med förespråkarna. Funktionell 1 http://projects.edgewall.com/trac 2 http://pyre.tredje-bit.com/drproject krav inkluderar, utöver vad Trac erbjuder, flera projektstöd, integrering av testsviter och hantering av sändlistor. Icke-funktionella krav är för en kodbas som är underhållsbar av studenter, och ett gränssnitt som innehåller bara de funktioner som är nödvändiga för kort varaktighet mjukvaruprojekt. Dessa "tidiga" krav presenteras i målgrafen över Bild. 1.2........................................................  Forskning om programvara med öppen källkod har gett upphov till ett stort intresse från en rad olika discipliner, bland annat ekonomi, förvaltning, sociologi och programvaruteknik [1, 6]. Tillgång till källkod öppnade dörren för rika butiker av data om programvaruutveckling, utvecklingsstilar och samhällsbyggande, t.ex., [7, 8]. Det verkar inte finnas särskilt mycket empiriskt arbete med vadningens natur i OSS, utöver diskussioner om psykologiska och sociologiska frågor (till exempel motiv för att bidra till ett OSS-projekt). I den mesta litteraturen nämns forking som en fallgrop, eller något som bör undvikas t.ex. [9].................................................................. Processen nämns i flera böcker, men den är oftast gissningar eller anekdotiska i naturen, t.ex. [10]. En användbar distinktion, om än förmodad, presenteras av Fogel [11]. Han skiljer mellan gafflar som händer på grund av grundläggande skillnader i projektmål (som är fallet här), och de som är vårdnadsstrider om det befintliga projektet. I detta dokument använder vi termen för att hänvisa till situationer där kod från ett projekt dupliceras i ett annat arkiv, och betydande nya krav läggs till det nya projektet. Denna kravcentrerade definition utesluter nedladdad kod som får mindre ändringar (t.ex. ett forskningsverktyg för genuttrycksdata). Vi är mest intresserade av kod som ändras för att möta nya krav. Detta är helt klart fallet i detta projekt. Det har gjorts viss forskning om kraven i OSS. Scacchi [12] tittar på hur kraven hanteras i olika OSS-projekt och ger en bra titt på skillnader mellan OSS-gemenskaper och andra modeller. Till exempel gör han iakttagelsen att kraven i OSS är tätt integrerade med verktygsdesign och implementering. Scacchi m.fl. [13] Utöka det tidigare pappret med en etnografisk analys av kravprocessen i NetBeans-produkten. Vårt arbete skiljer sig åt i sitt fokus på att anpassa befintliga verktyg till nya krav, snarare än att skapa nya verktyg baserade på (eventuellt framväxande) krav. När det gäller frågan om att anpassa OSS till företagens krav presenterar Bonaccorsi och Rossi [14] en undersökning som tyder på att de flesta företagsanvändare av OSS anpassar verktyget för att uppfylla kundernas krav utan att lämna tillbaka sina bidrag till det ursprungliga projektet. Adams m.fl. [15] Ta en liknande takt, men de beskriver hur de anpassar ett verktyg med hjälp av en plugin arkitektur, snarare än att arbeta på den interna nivån av design, som var fallet här. Slutligen förekommer liknande teman i tämligen omfattande forskning om COTS integration med projektkrav, till exempel [16, 17]. Den största skillnaden med OSS verkar vara förmågan att a) utnyttja en befintlig gemenskap av entusiaster, och b) få full tillgång till kodbasen. Gaffel är relativt ovanligt i projekt med öppen källkod, trots uppfattningar. Två huvudorsaker är den öppna och tillgängliga karaktären hos OSS-licenser och de sociala kostnaderna för att dela upp sig från ett befintligt projekt. Ett exempel illustrerar det första skälet [18]. Gcc-kompileringsteamet hade beslutat att inte stödja särskilda optimeringar; ett annat team formade kodbasen, sedan gick vidare och implementerade optimeringarna. Detta alternativ visade sig vara populärt, och det resulterande projektet, t.ex. Det andra skälet, socialt stöd, som beskrivs i Raymond ([10], s. 84-87), är vanligare. När en gemenskap har utvecklats runt ett verktyg, är det svårt att skapa en variant av det verktyget och upprätthålla den kritiska massa som behövs för att hålla kvaliteten hög. Dessa farhågor förekommer också i de kvalitativa studier vi genomförde.
Ernst m.fl. Ref studie forking av öppen källkod projekt, som kan ses som en särskild form av interorganisatorisk kloning genom att sätta hela kodbaser under ett annat ledarskap.
Code forking in open-source software: a requirements perspective
{'venue': 'ArXiv', 'journal': 'ArXiv', 'mag_field_of_study': ['Computer Science']}