DoSoftwareFirmsCollaborateorCompete ... ·...

e-Informatica Software Engineering Journal, Volume 13, Issue 1, 2019, pages: 37–62, DOI 10.5277/e-Inf190102

Do Software Firms Collaborate or Compete?A Model of Coopetition in Community-initiated

OSS Projects

Anh Nguyen-Duc∗, Daniela S. Cruzes∗∗, Snarby Terje∗∗∗, Pekka Abrahamsson∗∗∗∗

∗Business school, University of South Eastern Norway∗∗Sintef Digital

∗∗∗Genus AS∗∗∗∗University of Jyväskylä

[email protected], [email protected], [email protected],[email protected]

AbstractBackground: An increasing number of commercial firms are participating in Open Source Software(OSS) projects to reduce their development cost and increase technical innovativeness. Whencollaborating with other firms whose sought values are conflicts of interests, firms may behaveuncooperatively leading to harmful impacts on the common goal.Aim: This study explores how software firms both collaborate and compete in OSS projects.Method: We adopted a mixed research method on three OSS projects.Result: We found that commercial firms participating in community-initiated OSS projectscollaborate in various ways across the organizational boundaries. While most of firms contributelittle, a small number of firms that are very active and account for large proportions of contributions.We proposed a conceptual model to explain for coopetition among software firms in OSS projects.The model shows two aspects of coopetition can be managed at the same time based on firmgatekeepers.Conclusion: Firms need to operationalize their coopetition strategies to maximize value gainedfrom participating in OSS projects.

Keywords: COSS, coopetition, collaboration, competition, open source software, casestudy

1. Introduction

Increasingly, software products are no longerdeveloped solely in-house, but in a dis-tributed setting, where developers collaboratewith “distributed collaborators” beyond theirfirms’ boundary [1, 2]. This phenomenon in-cludes open source software (OSS) communi-ties, crowd-sourcing, and software ecosystems(SECO). This differs from traditional outsourc-ing techniques in that initiating actors do notnecessarily own the software developed by con-tributing actors and do not hire the contributingactors. Community-initiated OSS projects are an

example of the context in which actors coexistand coevolve.

From firms’ perspective, it is beneficial for thedevelopment of software products whose scopesexceeds their own capabilities by leveraging ex-ternal resources, exploring opportunities to enternew markets [3], performing an inside-out pro-cess [4], and employing strategic recruitments[5]. From communities’ perspective, the partic-ipation in such environment probably causesfirms to open up its successful products andproduct lines for functional extensions by ex-ternal developers [1]. Instead of being exclusiveand localizing product development, firms are

Submitted: 1 May 2018; Revised: 24 June 2018; Accepted: 31 July 2018; Available online: 1 October 2018

http://www.e-informatyka.pl/wiki/e-Informatica

http://www.e-informatyka.pl/attach/e-Informatica_-_Volume_13/eInformatica2019Art02.pdf

38 Anh Nguyen-Duc et al.

exploring different ways to invite contributionsfrom external actors without revealing core tech-nology, business value and customer relation-ships [6].

Before the full potential advantages of opensourcing are leveraged, commercial firms needto consider several concerns. At the organiza-tional level, the firm’s benefit and the commu-nity goals are not always the same [7]. Partici-pation of commercial firms in OSS projects withtheir diverse motivations and business strate-gies might introduce variance, and sometimesconflicts in project evolution [3]. Existing re-search on OSS highlights the role of collabo-ration with extensive research on communica-tion and coordination practices, patterns andlessons learnt from OSS communities [8–11]. How-ever, there seems to be far less research concernsabout the conflicts among firms regarding totheir strategic development. Firms attempt togain competitive advantages from their partic-ipation in OSS projects [12]. When there oc-cur mismatches in term of interests and objec-tives, firms may behave uncooperatively in or-der to prevent others from achieving their goals[13]. The conflict occurs not only at the man-agerial level, such as project governance [14],but also at the operational level, such as codecontribution, bug fixes, and requirement elicita-tion [3, 15–17].

Coopetition, as a business phenomenon, isabout collaborating and handling a firm’s com-petitive advantages when participating in OSSprojects [18, 19]. In a coopetitive environment,firms cooperate with each other to reach a highervalue creation compared to the value createdwithout the interaction. The basic assumptionfor coopetitive relationships is that all activitiesshould aim at the establishment of a beneficialpartnership with other firms, including partnerswho may be considered as a kind of competi-tor [20]. Since coopetition applies to inter-firmrelationships, OSS project offers an ideal con-text for understanding the phenomenon amongfirms that develop and utilize a common softwarecodebase [16].

Empirical research on coopetition is scarce,especially studies in Software Engineering (SE)

and at the organizational level [13]. Research inthis area is probably hidden by the inconsistenttreatment of the cross-disciplinary natures ofcooperation and competition, and their relatedconstructs. Our research objective is to explorehow firms interact and manage the phenomenonof coopetition in OSS projects. To best of ourknowledge, there exists only a few studies thatexamine the phenomenon of coopetition amongcommercial firms in OSS projects [3, 13, 15, 17].Research questions (RQs) were derived from thisresearch objective. Firstly, we aimed at under-standing the basic foundation on firm participa-tion in OSS projects. Based on this knowledge,we explored further theoretical elements of coope-tition. We use here the word “coopetitively” asan adverb of coopetition:– RQ1: How do commercial firms participate

in community-initiated OSS projects?– RQ2: How do commercial firms manage

coopetition with other firms in such context?Our contributions are two folds, firstly we por-trayed the situations where both competitionand collaboration occurs in OSS projects. Con-sidering the body of knowledge about firm partic-ipation in OSS projects, our work confirms somepatterns and also extends them by exploring thefirm awareness, coopetition and their antecedentfactors. Adopting a mixed-method research, wequantitatively examine organizational interac-tion patterns and qualitatively explore how firmsperceive and employ coopetition strategies. Sec-ondly, we theorize constructs of coopetition byproposing a Coopetition in Open Source Software(COSS) model. Previous studies that mention theterm “coopetition” [3, 15], do not investigate theconstructs under this phenomenon. Hence, to ourbest knowledge, this is among the first studiesin SE investigating this concept. The proposedmodel reveals building blocks of coopetition inOSS firms network and its relationship to conse-quent factors.

The study is organized as follows: Section 2presents a background about coopetition andfirm participation in OSS projects. Section 3describes our research methodology, Section 4presents our findings, and Section 5 discusses thefindings. Finally, Section 6 concludes the paper.

Do Software Firms Collaborate or Compete? A Model of Coopetition in Community-initiated OSS Projects 39

2. Background and related work

2.1. The phenomenon of coopetition

The origin of coopetition is from business re-search when investigating buyer and seller rela-tionships within a business network [18,19]. Thetrade-off between cooperation and competitionis emphasized as a mean of creating a progressamong actors involved in long-term relation-ships. Coopetition conceptualizes the interactionamong firms in relation to their strategic devel-opment [18, 19]. Dagnino et al. defined coope-tition as “a kind of inter-firm strategy whichconsents the competing firms involved to managea partially convergent interest and goal structureand to create value by means of coopetitive ad-vantage” [21]. The authors proposed two formsof coopetition, a dyadic coopetition (concernsamong two-firm relationships) and a networkcoopetition (involving more than two firms, i.e.value chain) [21]. Bengtsson argued that a dyadicrelationship is a paradox that emerges when twofirms cooperate in some activities, such as ina strategic alliance, and at the same time com-pete with each other in other activities [19]. Itmeans that actors within a firm need to be di-vided to take charge of either collaboration orcompetition.

Coopetition can occur in a more complexform, with a network of firms. The coopeti-tion strategy can be applied at a micro level(among functional and divisional departmentsin a firm), a meso level (among firms in thesame industry, between vendor and supplier)and a macro level (among cluster of firms orfirms across industries) [21]. Literature also dis-cusses some antecedent factors relating to coope-tition at the micro level, such as shared vi-sion, perceived trust and perceived benefits [22].A study points out some possible impacts ofcoopetition on knowledge sharing and job/taskeffectiveness [22]. By selecting a highly inno-vative OSS project that contributes to firms’strategic values, we illustrate dependencies be-tween competitors due to structural conditions,why and how competitors cooperate.

2.2. Collaboration in OSS projects

Collaboration is an aspect of coopetition thatis much explored in OSS projects. It is com-mon to look at OSS projects’ archives to revealcommunication, collaboration and coordinationapproaches, frequency, patterns and best prac-tices at different level of analysis [2,23–31]. Earlyresearch has observed an onion-like structureof contribution in OSS projects [24–27]. At thecenter of the onion are the core developers, whocontribute most of the code and take care ofthe design and evolution of the project. In thenext ring out are the co-developers who submitpatches (e.g. bug fixes), which are reviewed andchecked in by core developers [28]. Further outare the active users who do not contribute codebut provide use-cases and bug-reports as wellas testing new releases. The awareness of peo-ple and activities through OSS social structuresenhances collaboration effectiveness and ensuresthat little effort is wasted in duplicate work [30].A large amount of studies investigates the com-bination of social and technical aspects of OSSprojects, by analyzing a social network createdby contributors who work and communicate inthe same set of files [32–35]. Bird et al. [34]showed that a socio-technical network of soft-ware modules and developers is able to predictsoftware failure proneness with greater accuracythan other prediction methods. Wolf et al. [35]formed a developer-task network to explore theimpact of developer communication on softwarebuild integration fail. A common assumption ofthese studies is that developers behave regardlessof their commercial affiliations in OSS projects,indicating by unweighted analysis approacheswhen formulating the social networks. In casea significant number of developers from firmscontributes to the project, organizational fea-tures, such as firms’ strategies and governancemechanism might influence the communicationstructures of the OSS projects. In this work, wewill use the social network analysis (SNA) to in-vestigate interaction patterns, i.e. collaborationand competition in OSS projects. While we alsoform the developer-task-developer network, the


difference is that the relationship is analyzed atfirm level.

2.3. Collaboration in OSS projects

A theoretical model links theoretical elementsin a certain semantic manner, i.e. a causal rela-tionship, helping to design data collection andanalysis. Literature reveals factors that lead tothe occurrence of collaboration and competition(antecedent factors), and their impact on firms’outcomes (consequent factors). It is noted thatwe do not aim for model completeness, but fora foundation of further investigation. The furtherinvestigation would discover which factors validin the context of software industry, particularlyOSS projects.

As seen in Figure 1, coopetition is the stud-ied construct, and it is linked to its antecedentfactors, i.e. structural condition, strategic vision,trust and perceived benefits [22,36–41].

Strategic vision: sharing strategic vision isessential for cooperation at team level [22] [35],as the vision reflects important agreements ofbeliefs and assumptions that consequently bringinternal stability to the cooperative attitude [36].At the strategic level, vision typically is about thefirm’s value and business development. Sharedvision draws a roadmap for the organization orfirm, setting the priorities for their team plan-ning and implying its critical determinant rolein lessening malign competition [22]. The visioncan be shared via meetings or workshop withhigh-level managers.

Trust: is considered as a relationship of re-liance among members of a team or an organi-zation. Trust is defined as “the willingness ofa party to be vulnerable to the actions of an-other party based on the expectation that theother will perform a particular action impor-tant to the trustor, irrespective of the ability tomonitor or control that other party?” [42]. Theimportance of trust in the success of interper-sonal relationships is reported previously in OSSprojects [37, 38]. Moreover, trust is the key oftransforming OSS as a community of individualdevelopers, to OSS as a community of firms [39].The cooperation that captures the level of coor-

dinated actions between team members in theirefforts to achieve mutual goals cannot be realizedwithout trust among the members.

Perceived benefit: on one hand, perceivedbenefits are associated with a cooperative at-titude, involving compatible interests as com-mon benefits can motivate collaboration, leverageteam or person’s capabilities for obtaining suchbenefit [40]. In OSS projects, perceived benefitsof participating in the communities are reduceddevelopment cost, community knowledge, andreduced maintenance cost. On the other hand,perceived benefit is also associated with a com-petitive attitude. Individuals are likely to pur-sue their own objective at the expense over allteam’s goal [41]. This could be applicable fororganization in an ecosystems or supply chains.The more benefit a firm perceive for obtaininga conflicting artifact or resource, the more theylikely to compete over the resource [22].

In our theoretical framework, coopetition isalso associated to its consequent factors, i.e.knowledge sharing and task effectiveness [22, 43].

Knowledge sharing at organizational lev-els is seen as sharing of organizational experienceand knowledge, i.e. technical know-how, domainexpertise, work practice, etc with other collabora-tors, and hence increasing the overall knowledgein the joint project [22]. As knowledge is a criticalsource of competitiveness, managing knowledgesharing among members of an organization playsa prominent role in sustainable competitive ad-vantage [43].

Task effectiveness in team collaborationrepresents individuals’ perceived capacity of con-ducting collaborative tasks, whereas knowledgesharing enhances the ability of collaborator’sknowledge exchange.

3. Research approach

3.1. Study design

We conducted this work by using a two-phasemultiple-case study design [44]. The phases inthe research occur due to the discrete continua-tion of our internal research project. Compared


Figure 1. A theoretical framework of coopetition (adapted from [22])

to descriptive and confirmative case studies, ex-ploratory case studies are suitable for the firstphase research as we would like to discover thephenomenon of coopetition, whether it exists,in which form and its relationship to its con-text setting. This phase was done as a part ofa master thesis. In the second phase, we con-ducted a descriptive study on describing collab-oration, competition in the selected cases. Inthe third phase, we found another case studyto confirm the qualitative findings. This stepwas conducted to validate what we observedin the first two cases. We followed the guide-line by Runeson and Höst [45] to execute casestudy, including case selection, data collectionand analysis.

Case selection is not straightforward. Thereare abundant OSS projects available; manyof them are abandoned or individual efforts.A brainstorm session was conducted among thepaper’s authors to decide case selection criteriaas below:– Commercial participation: the OSS project

should have multiple commercial firms par-ticipating in the development. In addition,there must be an adequate way to identifythem.

– Successful and on-going: the OSS projectmust be successful and on-going. This impliesthat the project attracts developers and thedevelopment of the software is progressing.

– Active projects with many activities: the OSSproject must have a high level of communica-tion and code commits in the project, showingby rich data archive.

By reviewing literature on OSS projects inSE, we learnt several OSS projects that were com-monly investigated in SE research, such as Apache,Mozilla, Eclipse and Linux [46]. The selected casesshould not only satisfy the selection criteria, butalso novel in SE research. We were suggested toWireshark by a colleague who participated in theproject. Many reasons contributed to this choice.Firstly, the contributor list and community activ-ity revealed high participation and involvementof commercial companies. Wireshark is a typicalinstance of a OSS project. The project uses soft-ware informalisms for development collaboration,the developers are a mix of firm-paid developersand volunteers, and the software is licensed underthe GNU General Public License (GNU GPL).Wireshark is also a very successful on-going OSSproject, with a high number of contributors andactive users, consistently pushing developmentforward. Having selected Wireshark as the firstcase, we proceeded to find and select the secondcase for our study. To be able to do a literalreplication, the second case should have similarproperties as the first case. After a long period ofsearching, we ended up with three promising casesthat matched the specifications: Horde, Sambaand Wine. From the comparison it was evidentthat Samba was very similar to Wireshark, i.e.both projectswere licensed underGNUGPL, bothprojects had many firms participating, and theyboth had a yearly conference where developerscane together to discuss further development andsocialize. We planned to have the third case tovalidate the qualitative findings from Wiresharkand Samba. Among several OSS projects we


Figure 2. Overview of the research process

attempted to contact, Bootstrap developers werethe one agreed to participate in the study.

The research process is described in Figure 2.At the pre-study phase, literature review andbrainstorming with experts were done to come upwith research objective and study design. At theexploratory and descriptive phase, the first twocases were investigated for understanding howcommercial firms participated in OSS projects, ifthe phenomenon coopetition exists and in whichform. As the explorative nature of this phase,a wide range of topics was discovered, such ascollaboration patterns, firm awareness, competi-tion, code practices, etc. The data were extractedfrom project archive, i.e mailing lists, bug track-ing system and code repository. In this phase, wealso collected qualitative data, i.e. interviewingrelevant stakeholders to explore in-depth phe-nomenon observed from the quantitative data.At the confirmative phase, we conducted someinterviews to confirm and to validate the obser-vation from the first two cases.

3.2. Case description

Wireshark1 is an OSS toolkit developed by a com-munity of networking experts around the worldunder the GNU General Public License. Theproject is officially operated under the Wiresharkname since May 2006. Out of the 802 developers

listed in Wireshark contributor list, 342 wereclassified as firm-paid developers (43%). The re-maining 460 developers (57%) were classified asvolunteering developers. The firm-paid contribu-tions come from 228 firms.

Samba2 is an OSS suite that provides file,print and authentication services to all clientsusing the SMB/CIFS protocol. Samba is licensedunder the GNU General Public License, andthe Samba project is a member of the SoftwareFreedom Conservancy. In Samba, 316 developerswere evaluated, where 182 (57%) of them wereclassified as firm-paid developers. The contribu-tions come from 45 firms. Communication andcollaboration between developers in the Wire-shark and Samba community mainly occur intwo places; the developer mailing list and thebug tracking system.

Later, a third OSS project was selected asa more recent project to provide complemen-tary qualitative data. Bootstrap3 is a frontendJavascript-based framework for developing re-sponsive, mobile first projects on the web. Theproject was released as an OSS project since 2011under MIT license. Bootstrap were contributedby large firms, such as Twitter and GitHub. Atthe time the research was conducted, Bootstraphas been the most-starred project on GitHub,with over 90.000 stars and more than 38.000 forks.The communication in Bootstrap was done via

1https://www.wireshark.org2https://www.samba.org3http://getbootstrap.com


many channels, i.e. StackOverflow, Slack, andGitHub tracker. Source code and issue manage-ment was done via GitHub.

3.3. Data collection

3.3.1. Quantitative data

The main source of quantitative data is frommailing lists, code and issue repositories, as theyare common data sources when studying OSS[8, 15, 23, 47]. We collected three types of data,namely developer profile, firm profile and commu-nication data. The developer profile was foundfrom project public pages, such as project wikiand confluence page. Basic information, like de-velopers’ email addresses and timestamp of filecommits were extracted from JIRA and GIT.From developers’ profiles, we were also able toidentify the list of firms in a OSS project. Aninvitation for interview was sent in a snowballingmanner. After firm-paid developers accepted ourinvitation for interview, basic information aboutthe firm was required by us. Besides, firm infor-mation was also collected from online sources,such as company website, and published materi-als. The communication data was collected fromtwo main sources, namely issue tracking systemand mailing list. These sources contained detailedinformation about events and activities that hadoccurred in the communities several years backin time. Table 1 gives an overview of when thesources were first used and how many entriesthey have today in Wireshark and Samba.

3.3.2. Identification of firm participation

Information whether a participant is a firm-paidor volunteer developer, is not generally avail-able in OSS projects. Consequently, we neededto come up with a classification technique toidentify firms’ participation. The approach hasbeen successfully used in a previous study [48].The following information was evaluated in theprocess of classifying the developers:– Current status in the community: active or

not any more.

– Email domain: The email domain used bya developer can reveal firm association. Weregard it as unlikely that a developer usea job email to participate in an OSS projectif it is not related to the job as a paid de-veloper. This measure is the most distinctiveclassification entity.

– Email signature: Some developers have theiremployment firm name as part of their emailsignature, which they use when posting tothe mailing list or bug tracker.

– Personal homepage: Searching for a devel-oper’s name on the web can give directionsto a personal homepage or blog that mightreveal company association.

– Social networks: Searching for a developer’sname on social networks like LinkedIn andother professional pages might reveal firmaffiliation.

– Presentations and conferences: Developersthat give presentations commonly includename and firm in the presentation slides,which are easy to find by a web search.Some issues were faced when identifying con-

tributors’ affiliations. Firstly, there is a differentlevel of contributions in OSS projects. There isoften a lack of information about what is requiredto become a contributor. Moreover, majority ofthe participants in the mailing list only postedone mail, which makes it a waste of time and effortto identify these participants as the contributiontowards the firm’s interaction and software devel-opment is minuscule. We decided to exclude devel-opers with less than ten entries in the mailing listor bug tracking system. Secondly, matching name,alias and email address is not always straightfor-ward. In Wireshark, the spam protection policyhides the full email address, for instance: “From:[developer name] <name@xxxxxxxxxxxxx>”.Moreover, entries in the bug tracking system haveemail listed, but no name. The code repositoryentries in Wireshark does not contain name ormail of the developer, instead a username or a nick-name is used. We had to use project wiki pagesand personal contacts with some core developersof the project to provide mapping of most of theusernames to the actual developers.


Table 1. Summary of quantitative data from Wireshark and Samba

Project Data source Date of first entry # of entries

Wireshark Mailing list 31.05.2006 27230Bug tracking system 08.04.2005 7862Code repository 16.09.1998 42794

Samba Mailing list 03.01.1997 90588Bug tracking system 24.04.2003 9659Code repository 04.05.1996 84699

3.3.3. Qualitative data

Regarding to qualitative data, interviews wereselected from a convenient sample consisting ofthe firm-paid developers from Wireshark, Sambaand Bootstrap. Ten interviews were conducted asseen from Table 2. In Wireshark and Samba, wemanaged to have interviews from firms in a corelayer and a peripheral layer (detail as shonw inFigure 6). Due to non-disclosure agreements, wedid not reveal the actual identity of companies(quantitative data was publicly available, hencedid not have this constraint). We used alias D1to D10 to represent for such firms.

As we did not know much about the popula-tion, we aimed for a non-probabilistic samplingtechnique using a conjunction of purposive andsnowball sampling. In Wireshark, we used an ex-isting connection to one of the core contributorsas a starting point, and asked for suggestion ofdevelopers that could be interesting to interviewnext. The core contributor pointed out relevantdevelopers for the research topic, and assistedin contacting them by posting our interview in-vitation on the core contributor mailing list. InSamba, we selected relevant developers in theOSS project based on the quantitative data andsent interview invitations to these by email. InBootstrap, we had a developer actively contribut-ing to the project in our personal network. Fromhim, we got two more interviews with firm-paidparticipants in Bootstrap.

The interview guide consisted of both closedand open questions. The closed questions weremainly used in the introduction phase of the in-terview to solicit background information aboutthe respondent, firm and OSS project context. Inaddition, the closed questionswere used to confirmor attribute statements given by other developers.

The open questions were used to collect informa-tion about: (1) work process/bridge engineer role,(2) firm awareness/organizational boundary and(3) position in the community/contributions. Theinterview guide and interview questions is publiclyavailable. The interviews were conducted in En-glish, except for one inNorwegian. The duration ofthe interviews ranged from 45 minutes to 72 min-utes. All the interviews were recorded to facilitatesubsequent analysis and minimize potential dataloss due to note-taking. These recordings werethereafter transcribed verbatim. Transcribingaudio records resulted in 55 pages of rich text.

3.4. Data analysis

3.4.1. Social network analysis (SNA)

SNA is a common approach to investigate com-munication and collaboration patterns based ondata from mailing lists or issue tracking systems[32–35, 49]. This has been extensively used forconstructing a developer-task network and mea-suring different network features [32–35]. Weadopted this approach in firm level, to under-stand the collaboration pattern among firms viacommunication networks. Consequently, we usedthe firms as nodes and the interaction betweenfirms as edges. Interaction among firms is repre-sented by communication via either a mailing listor comments on an issue tracking system. TheSNA was done in four steps:– Step 1: Construct discussion trees from a mail-

ing list and an issue tracking system. A dis-cussion tree consists of an identifier node,a source node and a set of responder nodes(which can range from none to many). Thedeveloper that initiates a discussion is re-garded as the source, and the developers that


Table 2. Summary of interview profiles

Alias Domain Firm type Firm size OSSs

D1 Telecommunication Corp. 10000+ WiresharkD2 Wireless networking services SME 18568 WiresharkD3 Messaging system SME 11 to 50 WiresharkD4 Telecommunication Corp. 10000+ WiresharkD5 IT security services Corp. 51 to 200 SambaD6 Server and OS development Corp. 10000+ SambaD7 Telecommunication Corp. 10000+ SambaD8 Social media Startup 43374 BootstrapD9 Hosting and file sharing SME 51 to 200 BootstrapD10 Social media Startup 43374 Bootstrap

Figure 3. Constructing SNA from a discussion tree

follow-up on a discussion is regarded as re-sponders.

– Step 2: Filter the discussion trees to removemessages with noises (irrelevant information).As shown in Figure 3, we convert a discussiontree to an undirected graph.

– Step 3: Give firm’s affiliation to nodes inthe graph, so that the interaction could begrouped at a firm level, rather than at indi-vidual level.

– Step 4: Build the social network by usingNodeXL tool.

We were interested in the position of a firm withinthe context of the entire network, leading to theadoption of metrics, i.e. degree centrality, be-tweenness and closeness [49]:– Degree of centrality is a measure of the num-

ber of links incident upon a firm, i.e. howmany other firms that a firm is connected to.

– Betweenness centrality is a measure of thenumber of a shortest path between two firmsthat a firm lies on, quantifying the degree towhich an individual in a network mediatesinformation flow.

– Closeness centrality measures the distancefrom a firm to all other firms in the network.Lower values indicate that the component isfarther away from all other nodes.

3.4.2. Qualitative analysis

The analysis of the qualitative data was under-taken following a guideline for thematic synthesis[50]. Thematic analysis allows main themes inthe text to be systematically summarized andis also familiar by the first two authors of thepaper. The process of how quantitative data fromSection 3.4.1 facilitates the qualitative analysisand the use of the theoretical model to guidethe analysis is shown in Figure 4. The interviewswere prepared for analysis by manual transcrip-tion of the audio recordings to text documents,and the email responses were refined to tran-scripts of the same disposition. This resulted in55 pages of rich text. Segments of text aboutfirms’ interaction, i.e. activities, attitudes aboutcommunication, collaboration and competitionwere identified and labeled. Data from the Boot-


Figure 4. Steps of qualitative analysis and examples

strap case showed a level of data saturation,as there was not much new information fromthe case. After two rounds of reviews of thedata, we ended up with 84 codes. The follow-ing step of the thematic analysis was to mergethe codes and the corresponding text segmentsinto themes. A theme in this context is essen-tially a code in itself, however, a theme is anincreased distanciation from the text, and thusan increased level of abstraction. There are twoscenarios with a theme, the first one is that iden-tified text relates to an element in our theoret-ical model (as in Figure 1). The red arrow inFigure 4 describes such scenario. The secondscenario is the theme could be interpreted asa new concept. The green arrow in Figure 4describes such scenario. By grounded from ex-isting elements and new ones, we are able tocome up with an empirical model describingthe concept of coopetition in three OSS projects(Section 5).

4. RQ1. How do commercial firmsparticipate in community-initiatedOSS projects?

In Section 4 we present the results of the col-laboration pattern analysis. Two elements fromeach OSS project are presented: (1) significanceof firms’ contribution to OSS projects (Section4.1), and (2) the social network structure of firms(Section 4.2).

4.1. The significance of firm’scontribution

Regards to Wireshark project, from the 342firm-paid developers, 228 unique commercialfirms were identified, constituting 43% of totalnumber of contributors. There are only 8% ofthe firms having three or more developers partic-ipating in the community. Firms with the largestnumber of participating developers are Cisco,


Ericsson and Siemen. Whereas, 78% of the firmshave only one developer participating. The coderepository log contained 21927 entries, where12053 of them were committed by firm-paid de-velopers. Regards to Samba project, there are182 firm-paid developers representing 90 differentcommercial firms, constituting of 58% of totalnumber of contributors. In comparison to Wire-shark project, Samba is more dominated by firms’contributions. Nine percent of total number offirms have three or more developers participatingin the community, and 84% of the firms has onlyone developer participating. The top ten firmsparticipating in the community with regard tonumber of developers is presented in Table 3.

4.2. The social network structureof firms

We illustrate the constructed SNA based on datafrom issue tracking systems in Wireshark, asshown in Figure 5. The node represents for a firmand the link between nodes represents for a com-munication link between them. The node degreewas counted, including both in-degree (number ofinteraction received) and out-degree (number ofsent interaction). By looking at the social networkof Wireshark, a firm can belong to one of threecontribution layers: (1) a core layer with highcentrality degree, representing firms that activelycommunicate with others (for instance, Thalesand Ericsson), (2) a peripheral layer with mod-erate centrality degree, representing firms witha medium number of messages to other firms (forinstance, Tieto and Novell) and (3) a passive layerwith low centrality degree, representing firms withsmall amount of message sending in and out (forinstance, Broadcom and Motorola). The contribu-tion from commercial firms in the issue trackingsystems conforms to the same pattern as in themailing list; significant, but highly diversified. Intotal, the issue activity by commercial firms consti-tute 39% inWireshark and 66% in Samba. Figure 5reveals that a small number of firms stay in the corelayer and most of the firms locate in the passivelayer. The similar network structure was observedin case of Samba project. We do not present theSNA figure for Samba due to limited space.

The collection of identified commercial firmsconstitutes a large fraction of the activity inthe mailing list in both projects, approximately27% in Wireshark and 47% in Samba. However,the individual firm contribution ranges from lowto very high. Table 4 presents the number ofmessages and centrality degree of top 10 activefirms in mailing list. In Wireshark project, themaximum value of centrality degree of Philipsis 48, meaning that they are in contact with 48other firms. In Samba project, the maximumvalue of centrality degree of Red Hat is 71, show-ing that they are in contact with 71 other firms.The top three firms account for 60% and 56% ofthe mails in Wireshark and Samba, respectively.We interviewed two firms in these lists (D1 andD5) for answering RQ2 (Section 5).

Figure 6 presents the map of our interviewedcases in the social structure of OSS projects. Theselection process ensured that interviewees par-ticipated in the projects for a sufficient duration.We can see that the interviewees come from dif-ferent layer of the projects, hence, representingfor the whole projects.

5. RQ2: How do commercial firmsmanage coopetition with otherfirms in such context?

By investigating communication patterns amongfirms in OSS projects and analyzing interviewtranscripts via the thematic analysis, we pro-posed a Coopetition in Open Source Software(COSS). The model is grounded from thematicconcepts that extends our research presentedin Section 2.3. The COSS captures the un-derlying phenomenon of firm participation inOSS projects from coopetition perspective. Themain concepts representing the underlying phe-nomenon have been grouped together to formhigh level categories, as seen in Figure 7. Themodel is centralized around the concept of coope-tition. Beyond the concept of coopetition in busi-ness research that consists of competition and col-laboration, we identify two additional dimensionsof the concept, which are gatekeeping and firmawareness. Coopetition activities are visible with



Wireshark Samba

Firm # of developers Firm # of developersCisco 16 IBM 17Ericsson 11 Red Hat 14Siemens 8 SerNet 8Netapp 6 SUSE 8Citrix 5 EMC 4Lucent 5 SGI 4MXTelecom 5 Exanet 3Nokia 5 HP 3Axis 4 Cisco 3Harman 4 Canonical 2

Figure 5. The social network of Wireshark via issue tracking system

the recognition of firm boundary in the projectsand implemented via gatekeeping mechanisms,which are synchronizing code, strategic filter-ing and navigating information flow. Antecedentfactors that influents coopetition concepts in-clude structural condition, trust, perceived ben-efit, and strategic vision. Structural conditionincludes two sub concepts, public communicationand direct communication. Consequent factorsof coopetition include organizational learning,

knowledge sharing and task effectiveness. Fol-lowing sub-sections below describe the groundedevidence for each model’s elements.

5.1. Public communication

The public communication channels used in ourOSS projects were the mailing list and bug track-ing systems. In both projects, the distribution ofpublic communication is highly right-skewed, as



Wireshark Samba

Firm Entries Degree Firm Entries DegreePhilips 1195 48 Red Hat 4480 71Ericsson (D1) 1322 39 Sernet 3765 66AT&T 756 34 Google 1835 57Trihedral 222 21 IBM (D5) 1701 48Thales 548 19 HP 1408 44Mxtelecom 149 19 Eurocoopter 874 35Gtech 165 13 SGI 335 29Detica 64 10 Padl 82 29Csr 67 10 Zylog 159 28Sequans 31 10 Nokia 104 28

Figure 6. Social positions of interviewees in OSS projects

shown in Figure 8. In Samba project, Sernet hascontributed almost 35% of total number of mes-sage via mailing list. The top three firms accountfor 60% and 56% of the mails in Wireshark andSamba, respectively.

Developers mentioned several incentives forusing such channels, for instance, they usethe public channels for discussing, participat-ing and/or influencing the ongoing development.D4 mentioned that he publicly asked questions,discussed ideas and found collaboration via pub-lic channels: “Basically, the times when I needguidance or I have a problem, or answering otherpeople’s questions, whether it is other develop-ers or users or whatever. Or if I have an ideaabout something. (. . . ) I made a suggestion ‘heymaybe we should do something to catch thisproblem automatically in the build-bots rather

than. . . ’ Anyway, just making suggestions andputting them out basically.” D6 considered mail-ing lists as a traceable information storage thatis useful for his job: “Usually all discussionsare done on the mailing list (. . . ) this way wehave a history of all discussions. I participate indiscussion either to help someone with Sambaor to make my point in area of my interest atthe moment.” Influencing project features byparticipation is one incentive expressed by D1:“If they are working on something that I seeas usable for us internally, we find it interest-ing. It is smart to participate in the discus-sions when they are doing the development, andnot come in afterwards. That is because whilethey are doing the changes and the development,they are more open for suggestions for changesand improvements.”


Figure 7. The model of Coopetition in Open Source Software (COSS)

Figure 8. Distribution of number of mails per firm in Samba

Asking for guidance and support on mailinglists is common, however some developers un-derlined that they did not ask for solutions totheir problems here. Rather, they would ask foruseful advices and a push in the right direction.D3 stated that “Sometimes I have sent emailsto the development list and said that I am con-fused by this, can someone shed some light onit.” Developer D4 expressed a similar approachin: “More often I will ask people ‘OK, I have thisproblem and I am trying to solve it. I can see twoways to solve it, does anybody have an opinionon which way is the better way?’” By this way,technical issues within a firm can be discussedand supported by external people.

D2, D3 and D4 said that they asked ques-tions about architectural decisions in the publicchannels. Posting features requests or interesting

ideas is also common, and some of the inter-viewed developers find it motivating to describetheir ideas and approach to the other communitymembers. By this way the feature expectationis communicated and other developers can comewith suggestions and even join the development.D5 and D6 stated: “I tend to participate in dis-cussions where I feel I have a useful technicalcontribution to make.” (D5) and “I participatein discussion either to help someone with Sambaor to make my point in area of my interest atthe moment.” (D6).

5.2. Private communication

Firms use private communication for many pur-poses, including both cooperative and competi-tive manners. Developers mentioned that they


had used direct and/or private communicationchannels for asking for help from the domainexperts in the project. Communication channelsused are e-mail and instant messaging, Skype andtelephone. D3 said: “I have done it [contacteddevelopers directly] some times in the past. Notjust as a general I am stuck, can you help, butbecause it would be an area I knew the other guywas working on.” The private communication isusually the result from a gradual establishmentvia public communication, as mentioned by D6:“Usually I tend to do R&D tasks myself. I oftenseek for reviews of my work. When I need theassistance, I will go directly to a developer in thecommunity.”

Comparing to public channels, D8 consid-ered private communication as a way to establishhigh-quality contact points and potential collab-oration for further projects. He mentioned thata fork from project mainstream should proba-bly include best developers in the communitywho are not necessarily the guy in the “onioncore”. It is also stated that a private channelis a quick and efficient communication medium.D9 explained that he used instant messaging forcontacting developers in the community whenhe wanted a quick feedback. Private communi-cation seems to be in favor comparing to publiccommunication. D9 mentioned: “We try to ad-dress as much as we can the issues that cometo us . . . Normally if we get a private messageabout an issue, we will take it with higher prior-ity” D5 mentioned that when discussing legal orsecurity sensitive issues, he used a private com-munication channel. The nature of such issuesinvokes the use of private channels as postingit in the public channels may result in securitybreaches or similarly bad situations. Althoughnone of the other developers said anything aboutthe use of direct channels for such issues, webelieve that it is a common procedure in mostOSS projects.

5.3. Trust

Trust is one of the fundamental traits of a success-ful collaborative environment [29, 51–53]. Ray-mond stated that “open-source culture has an

elaborate set of customs?[which] regulate whocan modify software, the circumstances underwhich it can be modified, and (especially) whohas the right to redistribute modified versionsback to the community” [54]. In our cases, inter-viewee stated that the success of OSS projectsis meaningful to them. For instance, with theadvance of the Wireshark tool, D4 can use itto serve for his daily work. Based on trust, de-velopers can collaborate for the sake of theirOSS project. D3 said that they have contactedtrustable developers directly to avoid asking sillyor dumb questions in public: “I got relationshipswith other developers and sometimes we don’twant to ask in mailing list causes it is a reallystupid question and you do not want to ask thewhole mailing list, so you just ask the guy youtrust”. When a developer needs help to designa code or fix a bug, other developers would bewilling to assist. By helping one another, devel-opers demonstrate their skills and knowledge,which develops a positive expectation of com-petence and reliability. Level of trust is relatedto the status of the developers in OSS projects,which is evident in the following section. Theobservation is aligned with previous research onthe role of trust in successful interpersonal rela-tionships [37,38].

5.4. Perceived benefits

Despite the risks associated with competitors,many firms decided to be open in sharing andsynchronizing their source code with OSS com-munities. Source code can be synchronized withupstream development in OSS projects, for in-stance, described by D5: “In general, our phi-losophy is to develop upstream first and thenback-port changes that have been approved bythe upstream community into our products. Westay very involved in the communities and tryto keep the differences between our packagedsoftware and upstream software to the mini-mum necessary.” Firms perceive benefits withsuch involvement as avoiding maintenance andmerging issues when combining public parts ofprivate parts of source codes. D10 illustratedfor this idea: “. . . if you are to make a change


Figure 9. The role of gatekeeper in a commercial firm

in the core, and you want to keep it private,you will have to fork the project and maintainit yourself. (. . . ) I believe, in the general case,that you gain more from contributing to the de-velopment, that retaining your code from thecommunity”. D1 mentioned that “We do nothave to maintain our own code base and syn-chronize it. We just commit code to the sourceand have it there. If we had not had the commitaccess as easy as I do, we could have had ourown version of Wireshark and the sources, butthen we would have to do more work in merg-ing our version with the new releases of Wire-shark.”

Firms also concern about their social posi-tions in the projects. It is apparent that a centralposition in the community is closely related tobeing a core developer in most cases. Two bene-fits mentioned by the interviewees are: (1) easiercode inclusion and thereby avoid the need of hav-ing a private code repository, and (2) receivingmore help from other community members. D4highlights the importance of social position inOSS community: “I think it [having a position]helps a lot. I think there is a difference if, letssay, D2 asks for help, then I will help him ifI can. But if [Developer Name] from I have neverreally heard of, is asking for help then my levelof effort is usually lower. And part of that isbecause I know D2 personally, and part of thatis because I know that he does a tremendousamount of work. My view is that if he needs helphe deserves the help. And I think it goes theother way too, if people are more likely to helpme because of the contributions I have madeand they know that I have been contributing fora long time. I think it helps to have some sort ofstatus within the community.”

5.5. Strategic vision

The role of strategic vision on firm participationis somewhat vague in our cases. Firm’s strategycould be how a firm develops and deploy theirproduct, i.e. how external resources are used toreduce development and maintenance cost. Thevision of firm’s strategy needs to be aligned atnot only managerial but also operational levels.The transfer of strategic visions is not clearlyevidenced in our cases. For instance, a developerD4 mentioned he spent significant office workhours as well as spare time on contributing toWireshark. He acknowledged the benefits otherdevelopers in his firm received from his partici-pation in the OSS project and the fact that hefreely participated in Wireshark: “It is not anofficial part of my job, but a lot of the develop-ers, testers and the customer support people useWireshark extensively.” However, his firm lackedformal strategies to decide how developers shallparticipate and develop the OSS, what code thatshall be contributed back to official sources, andhow to maintain the OSS knowledge base withinin the firm.

5.6. Gatekeeping

The perceptions of a gatekeeper, who navigatesinformation flows between his/her firm and exter-nal actors, were acknowledged by all interviewees.While firms might have different needs and workpractices, gatekeepers are the ones stay in be-tween the firm and the OSS project in someway, as shown in Figure 9. D1 stated that whenhis coworkers found issues with the third partycomponents, they informed D1, but not projectmanagers. D7 expressed a similar perception:


“Yes, I act as a bridge between [Company Name]and Samba and forward bugs/errors to the com-munity.” The gatekeeper is often an active actorin contributing to the community, as mentionedby D2: “Many of our core developers are workingfor smaller companies, and have a responsibil-ity for the internal protocols that their companyneeds. (. . . ) I think most developers work individ-ually, and have the role of providing Wiresharkfunctionality to the other developers in the firm.”

In a cooperative manner, the gatekeeper is thehub of information and issues that can be reachedby different developers across the organizations,as stated by D4: “Yes, everybody definitely knowsthat I am the Wireshark guy. All the developers,testers and customer support people know thatthey can come to me if they have Wiresharkissues (. . . )”. In firms with multiple developersactive in upstream development, i.e. commit-ting to OSS projects, there is often a recognizedgatekeeper role among them. D5 mentioned: “Ingeneral when it comes to contributing patchesupstream each developer in [Company Name]is independent and can directly approach theupstream project? The [Company Name] Sambapackage maintainer usually has a task of beingthe gatekeeper for those bugs that have beenreported against [Company Name] products bythe customers or the support teams (. . . )” In thiscase, while code is contributed independently byindividuals in the firm, the bugs is managed bya gatekeeper who submits bug reports on behalfof the firm into the OSS project’s bug trackingsystem.

In a competitive manner, gatekeepers wouldmake sure that not all private source code berevealed to public. Firms might contribute codethat relate to core components of OSS products,or utility functions. In a typical scenario, firmsmaintain their private repositories, where manycomponents are parts of firms’ core values. Suchcomponents should not be revealed, as mentionedby D4: “The majority of the stuff I have writtenfor Wireshark has been pushed up? But you sortof draw a line in the stuff that is obscure enoughto not push. The only people who should be look-ing at our proprietary protocol should be us?”.Some of the code is regarded as proprietary and is

retained in the firm’s private code repository, dueto technical specific, or legal and authorizationissues D2 mentioned: “Mainly protocol dissectorsfor protocols used in our equipment, if the proto-col is based on open protocol descriptions from3GPP, ITU or IETF (RFC) it is considered OKto make an individual contribution to OSS (. . . )”.Code which is not relevant, sensitive or poorlywritten would be filtered out by gatekeepers, asmentioned by D4: “The stuff we do not send in isstuff that is not of interest to anybody except us(. . . ) And the other part is that I do not thinkthe company would be thrilled by a publicationof these protocols. In order to push those thingsto Wireshark I would need to get authorization”.

5.7. Firm awareness

Several interviewees acknowledged the presenceof at least another firm in the community (D1,D2, D3, D8, D9, D10). However, developers re-mark that it is not the knowledge of what otherfirms work for that is valuable, rather it is theknowledge of what business domain they areworking within. D2 replied when was asked aboutother firm awareness: “Yes, but I do not knowthat much about the firms of the other developers.They typically say that they work for Firm X,and that is it. What firm they are working foris not that important to me.” D3 emphasizedthe potential value of having the firm awareness:“(. . . ) I know that D2 may have some role asa contact for Firm X (. . . ) I know that D2 maybe someone who is good at getting log files forspecific things. In the past when I was workingwith voice over IP, I thought sometimes he wasable to give me some log files from within hiscompany, but I did not really think of him as thecompany representative. I think of him as a com-pany person who may be able to get logs for me,like he does.” In Bootstrap, developers expressedthe concern on how other firms were doing relatedto the web technology, in order to draw lessonslearnt for their product vision. D8 mentioned:“We care about if other company are using thistechnology in their products, so we can learnfrom them (. . . ) We do not care if some guysjust want to play with the technology (. . . )” Ad-


ditionally, the interviewees were asked if they con-sidered that their contributions could be used byother firms to gain competitive advantage. Themajority dismissed this perception, for example:“As Firm X does not directly control Wireshark,I guess we have to be a bit careful when we arein contact with other developers (. . . ) I believe,in the general case, that you gain more from con-tributing to the development, that retaining yourcode from the community”, stated by D2. A finalremark by D5 about the competitiveness is: “Al-though there may be some competition betweencompanies, as engineers we seek collaborationfor mutual benefit. We already know any ad-vancement will be used by everybody, that is nota problem, we get back as much as we give out.”

5.8. Collaboration

Although collaboration within an OSS commu-nity is typically informal and not planned, thereare matters that have to be decided upon. Forinstance, when there is a new post in a mailinglist, a developer has to decide whether to engagein the discussion with the others or not (essen-tially collaborating with them). The awarenessof other firms in this aspect may prosper thecollaboration. Firm- paid developers with similarneeds and interests can collaborate and drawon each other’s abilities. Knowing that a devel-oper works for a certain firm, and that he canprovide certain code artifacts also influences thecollaboration. Establishing relationships to suchvaluable developers through collaboration is key.There is a strong desire to return favors andhonor developer’s positions by assisting themwhen they need help.

Many commercial firms adopt OSS, but donot participate nor contribute back to the OSScommunities. Some of these firms collaborate di-rectly with others to develop OSS-based productsfurther, with or without participating in the OSScommunity. How to perform the collaborationis an aspect firms have to decide. As describedabove, the collaboration can take place within theOSS community using public or private communi-cation channels, or outside the community usingprivate channels and private code repositories.

5.9. Awareness of competition

Firms working within the same business domainare often competitors in the market, and thusit is interesting to see how influential the firmawareness is when firms come together in com-munity based OSS projects to develop softwarecollectively. Surprisingly, firm-paid developerssaid that they perceived other developers as part-ners and/or friends rather than competitors. D5pointed out that he had met many developersat the OSS developer conference, and consideredmany of them as friends. D1 explained that hedid not make any distinction between a firm-paiddeveloper and a volunteering developer: “I thinkof them as developers, and not about which firmsthey represent.” D7 said that he would perceiveothers as partners. D6 mentioned: “I have al-ways thought of others as partners. Even more –I think about them as colleagues.” D4, D8 andD9 shared similar thoughts, and dismissed theperception of other firm-paid developers as com-petitors: “I guess as things have evolved we doactually compete in some aspects with some ofthese people at this point. But that hasn’t re-ally occurred to me much? I have noticed morepeople who tend to be customers of ours, ratherthan true competitors. We might be competi-tors within some areas, but I have never reallythought about it I guess”, stated by D9.

The issue of competition from a firm fromsomewhere else in the world might not be sig-nificant for a startup and a SME who focus onhaving their product released as fast as possible.Without a clear vision on how their market ortechnical advantages are influenced by sharingand using OSS source code, the concern of com-petition is not much relevant. D8 also mentioned:“You think about other firms as your competitors,but I do not think that really comes in to myinteractions really. They have their own userssomewhere around the world (. . . ) I have some-times seen contributions from their developers,but I think that is good (. . . )”. Consequently, thecoopetition concept in these OSS projects mightbe very much cooperation-dominant.

Another observation is that the firm’s socialposition is not used by any firms to dominate


OSS development. D6 mentioned: “Before work-ing on Samba I used to think that big companiesmay have big influence in OSS project simply by’buying’ core developers. Now, that I know mostof the people working on Samba, I know thatthis is not feasible.” Hence, having a position, or’buying’ one, is not the way firms relate to norinfluence the OSS development.

5.10. Consequent factors

Interviewees acknowledged the benefits of par-ticipating in OSS projects, including knowledgesharing, organizational learning and task effec-tiveness. D2 mentioned that many best practicesfound in reviewing code and proper comments oncommits. He also appreciated the activeness levelof the project with fast feedbacks. The practicesare acknowledged and brought into considera-tion for improvement at his team. Maintainingan awareness of the other developers and whatthey are currently working on is also recognizedand is promoted by D6 in his firms for avoidingduplicated code across the whole codebase. Or-ganizational learning also occurs at the projectlevel. When a firm observes the participation andinteraction of core firms in the OSS projects, theycan infer strategic focus areas from, i.e. featurerequests and application cases.

In our cases, in-house product developmentdepends on the OSS projects by (1) using toolsas outcomes of the projects or (2) integratingand building their products on top OSS com-ponents. The dependence infers that a taskthat relates to OSS codes is collective per-formed and the task scope is beyond the OSSproject. In a cooperative-dominated environ-ment, the task will be done in an easier way.In a competitive-dominated environment, theawareness of competitors might be harmful forjointly completing the task. However, this is notdirectly evident from our cases.

6. Discussions

Table 5 summarizes our findings in the compari-son with existing literature. While many findings

confirm existing knowledge, they also providesome novel findings. This section will discuss ourfindings based on four topics: centralized com-munication structure in community-lead OSSprojects (Section 6.1), modelling coopetition inthe context of OSS projects (Section 6.2), therole of a gatekeeper in implementing coopetitionstrategies (Section 6.3) and firm contributionstrategy in OSS projects (Section 6.4). Each sec-tion will discuss our findings with related work.The final section presents our actions to addressthreats to validities (Section 6.5).

6.1. Centralized communicationstructure in community-lead OSSprojects

Commercial firms participating in commu-nity-based OSS projects collaborate in variousways across the organizational boundaries. Crow-ston et al. stated that communications structureof a project is an important element in under-standing project’s practices [28]. In our cases,the majority of the activity in OSS projects isgenerated by a small subset of the firms, and thatthe remaining firms participate with little to nonecontribution. Wireshark and Samba demonstratea communications centralization structure as inthe onion-like social structure model [28]. Oezbeket al. [60] investigated eleven OSS projects andrevealed that the role of a developer in the corelayer might be more important than the fact thatthey do (commit code, fix bug, answer emails,etc) more. Our quantitative analysis of Wiresharkand Samba confirmed these results by showingthe dominant contributions of developers andfirms in the core layer. Our qualitative data re-vealed possible importance of these developers inimplementing firms’ strategies, i.e. collaborationor competition. Dewan et al. [57] showed thatthe heterogeneity, which exists between firm-paiddevelopers and voluntary developers shapes theevolution of OSS community and its product.In our case, we showed that even firm-paid de-velopers have significant contributions to codecommits and communication, it is not signifi-cantly different between firm-paid and voluntarydevelopers. From communication structure, this


Table 5. Summary of findings

Findings Type Current knowledge

OSS infrastructure as foundation for bothpublic and private communication amongfirms

Confirmation Structures as those in OSS enables the inte-gration of external resources [55].

Firms activities are visible in OSS projects Confirmation Heterogeneity exists between firm-paid de-velopers and voluntary developers [56,57].

Some firms in the core positions, most offirms contribute little

New Onion-like structure at developers level[27,28].

Coopetition exists among firms Confirmation Strong explicit governance approaches candirectly affect other firm’s benefits [58].

Cooperation-dominated coopetition amongfirms at code and issue levels

Confirmation Competition for the same revenue modeldoes not necessary affect collaborationwithin OSS projects [15–17,59].

Gatekeepers provide a mechanism to per-form coopetition

Contradict Developers within a firm need to be dividedto take charge of either collaboration or com-petition [19].

Trust is the foundation of establishing com-munication, collaboration and also competi-tion

Confirmation Trust as a success factors in collaborationin OSS projects [38,42].

Strategic vision is not significant at develop-ers’ level

New Sharing strategic vision is also critical forcollaboration at team level.

Firms gain social position in OSS projects,avoid merging and bug fixes, impact on in-fluencing development and get supported

New Perceived benefit is associated with bothcooperative and competitive attitudes [22,40,41].

reveals a different finding from Dahlander’s work[56].

6.2. Modelling coopetition in the contextof OSS projects

Business literature mentions the difficulty of iden-tifying coopetition in a real world context [21].Dagnino et al. [21] highlighted that coopetitiondoes not simply emerge from joining competitionand collaboration, but they mix together to forma new kind of strategic interdependence betweenfirms. We agree and illustrate for this view byshowing that in OSS projects, commercial firmsfocus on activities that create a common valuewith an awareness of not sharing their technicaland legal sensitive information. From our cases,COSS validates at the meso level of strategiccollaboration, where firms within the same orsimilar domain collaborate. Among antecedentfactors from literature, we highlight the role ofa structural condition via public and privatecommunication infrastructures. The transparentand effective communication infrastructure pro-

vides a mechanism for coopetition. Our studydescribes a competition-dominated type of coope-tition. Even when firms are aware of their com-petitors, the attitude of collaboration is still over-whelming. Valenca et al. raise a question whetherfirms are collaborators or competitors in softwareecosystems [3]. At the requirement engineeringlevel, the authors found several significant chal-lenges among firms within the same collaborativenetwork [3]. OSS projects and firms might havedivergent interests but firms can manage to dis-cover areas of convergent interest and be ableto adapt their organizing practices to collabo-rate [7]. In our case, this is clearly observable atthe operational level. The finding also matcheswith observations by Linåker [15].

6.3. The role of a gatekeeper inimplementing coopetition strategies

Bengtsson et al. argued that individuals withina firm could only act in accordance with one ofthe two logics of interaction at a time, i.e., eitherto compete or to collaborate [19]. Our observa-


tion on a gatekeeper role gives an alternativeexplanation on how firms manage such scenario.The firm’s strategy can be flexible, for examplefully open core sourcing at one time, and filteringof shared code at another time. The implementa-tion of such strategies is done via the firm gate-keeper, who does actual technical contributionto the community. Therefore, in contrast withBengtsson’s findings, we find that it is possible toimplement a firm-level dynamic interaction via in-dividuals in software projects. The role of a gate-keeper is discussed in the context of commer-cial distributed software teams [61,62]. Marczaket al. found the role of knowledge brokers whowould have a significant impact on informationflow in requirement-interdependent teams [62]. Ina context of firm-to-firm interaction, we showedthat a gatekeeper could navigate the informationflow beyond firm’s boundaries. Nguyen-Duc et al.showed four common tasks of a gatekeeper: tasknegotiation, conflict resolution, task- related in-formation navigation and boundary object setups[61]. While the authors investigated gatekeepersin a software firm and a OSS project separately,this work focuses on boundary spanning activitiesbetween the OSS communities and software firms.By influencing the gatekeepers, managing codeflows and information flows, firms can implementcompeting or collaborating strategies.

6.4. Firm contribution strategyin OSS projects

There exist some studies capturing the phe-nomenon of commercial firms contributing toOSS projects. Linåker et al. investigated con-tribution strategies of firms when participatingin OSS projects [63]. The authors proposed theContribution Acceptance Process (CAP) modelto determine if source code or any types of con-tributions can be contributed or not. The CAPmodel bases on two dimensions: (1) the bene-fits company can receive and (2) the knowledgebehind the contributions to acquire and control[63]. While these two dimensions are similar toour model’s elements: perceived benefits (Section5.4) and gatekeeping (Section 5.6), our modelalso explore other factors that impact the ways

firms contribute to the OSS communities and col-laborate with other firms. Munir et al. discussedhow the openness of software firms might helpthem to gain benefits from OSS communitiesfrom four dimensions: (1) strategy, (2) triggers,(3) outcomes, and (4) level of openness. Themodel is similar with some elements in our COSSmodel, i.e. strategic vision, communication, gate-keeping and consequent factors. However, thesemodels do not capture the competition strategythat firms might adopt in OSS projects. Unlikethe previous work, our COSS model proposeda comprehensive view on factors that impact thestrategy of collaboration and competition.

6.5. Threats to validity

6.5.1. Construct validity

Threats to construct validity consider the re-lationship between theory and observation, incase the measured variables do not providea good measure of the actual factors [45]]. Ina qualitative study, construct validity can bethought of a “labeling” issue, as we mightfind the construct of the outcomes that webelieve we are trying to capture. A main as-sumption in our study lies in the way we iden-tify coopetition among commercial firms. Asthe coopetition concept comes from economicand business research, we did not have a di-rect map from how the concept operational-ize in SE research. Previous studies that men-tion term “coopetition” [3, 15], do not providethe construct of this concept. Hence, to ourbest knowledge, this is the first study in SEattempt to operationalize this concept. We re-duced this risk by a detail review and the iden-tification of characteristics of coopetition, theexploration of the context where the constructis investigated. Both quantitative and qualita-tive data was collected in concept’s elementsand summarized in the end to describe themodel. We also include discussion with co-au-thors and an expert in the entrepreneurship invalidate our observation.

The phenomenon is operationalized based onpublic and private communication among de-


velopers participated in OSS projects. We wereaware of other communication channels, such asprivate messaging, telephone and Skype, however,we do not have a feasible way to quantify this. Welimited the investigation in public collaborationwhere developers responsed to the same mailinglist or comment on the same issue. Regarding tothe identification of firm participation, we usedSNA with density metrics, such as degree cen-trality and closeness [49]. Other network-basedmeasures for the same construct (e.g., transi-tivity, compactness, and connectedness) couldbe considered for enhancing the rigor of thisresearch. We also used an unweight approach toperform SNA, which ignored the firms’ charac-teristics, such as firm size, and business strategytowards the OSS community. This could be con-sidered in future work, especially in firm-basedOSS projects.

The risk of operationalization is reduced byusing a mixed method research, including bothquantitative and qualitative data. The intervie-wees were conducted with firms from differentsocial position in OSS projects, which increasethe credibility in the observation of phenomenon.The data is limited at ten interviews. However,we had reached data saturation [45] when in-terviewing Bootstrap case. Although, intervie-wees were selected from different types of OSSprojects, different company profiles, we foundthat their responses were consistent, which in-crease our confidence in the trustworthinessof the data.

6.5.2. External validity

This threat considers the ability to generalizeour findings. The goal of this study is not toachieve statistical generalization, but rather ananalytical generalization. This is particularly im-portant when studying a complex phenomenon,in our case is coopetition in OSS projects. Toavoid the bias on findings from a single case, weanalyzed two OSS projects. Qualitative data wasfurther collected from the third OSS project toimprove the generalization. With the in-depthinvestigation in both community and firms’ sidesof the projects, we are confident about the ex-

planation power of the COSS model for sim-ilar contexts. Our OSS projects produce a li-brary, a framework and an application, employ-ing GPL and MIT licenses. Our cases representfor a community-initiated OSS projects, that areinitiated and lead by the community. Furtherresearch should replicate our method on othertypes of OSS projects to explore other collabo-ration and competition scenarios. They are alsopopular OSS projects with years of operation,hence the products and collaboration processhave been stable. The findings might not be di-rectly applicable to emerging OSS projects, orprojects initiated by firms. Research on projectswith different types of OSS licenses might leadto a variety in our model.

6.5.3. Reliability

This threat concerns about the level to which theoperational aspects of the study, such as datacollection and analysis procedures, are repeatablewith the same results. The main data collectionwas done as a part of a master thesis. All inter-views were recorded and transcribed verbatimin order to make sure that no data reductionoccurred prematurely. The transcription of theinterviews was reviewed and interpreted by theother author. In case of vague statements, oneauthor is responsible for follow-up discussionswith interviewees for clarification. We used bothquantitative data about communication amongfirms in the project and qualitative data frominterviews of firms from different contributionlayers. The data triangulation allows our find-ings represent the true situation of investigatedprojects. Moreover, the paper has gone throughproof-read from several senior researchers in thedomain. Their feedbacks help us to improve thepaper significantly since the first draft.

7. Conclusions

Coopetition is an important topic in economicsand business research [19, 21], but it is over-looked in other domains. In modern softwareindustry, the popularity of developing software


products beyond firm’s boundary makes coopeti-tion a relevant theme. In this paper, we usedboth qualitative and quantitative data to in-vestigate coopetition in OSS projects. Firstly,we found that commercial firms participatingin community-initiated OSS projects collabo-rate in various ways across the organizationalboundaries. While most of firms contribute lit-tle, a small number of firms are very active andaccount for large proportions of contribution. Itis also evident that firms interact across theirboundaries in OSS projects. Secondly, we pro-posed an empirical model COSS to explain forroot causes of coopetition in OSS projects. TheCOSS model shows that coopetition is basedon the firm awareness, structural condition ofthe OSS projects and operated by gatekeepers.The coopetition is cooperation-dominated evenamong firms working in the same business do-main with similar business models.

The findings have implications for research.We offer a descriptive explanation of how coope-tition occurs and impacts in OSS projects.We observe that software firms emphasize theco-creation of common value and partly react tothe potential competitiveness in OSS projects.The highlight of our findings is the COSS model,which argues that competition and collaborationcan both be handled by gatekeepers. The roleof gatekeepers in crossing organizational bound-aries is still an interesting research topic. ForSE with abundant research on OSS collabora-tion and communication, the study on inter-firmcoopetition is a novel way of looking at the samedata sources and infrastructures.

The study also has implications for practi-tioners. We offer software firms insights aboutdifferent coopetition strategies observed in a com-munity-driven OSS project. For instance, not allcommunication goes through the public channelsin OSS projects. Legal and security sensitiveissues commonly go through private or closedchannels because of their natures. Furthermore,firms should consider a gatekeeper as an impor-tant role when they plan to participate and gainbenefit from OSS projects.

For future work, the next step would beto validate the COSS model with a larger set

of cases. Our research here only uses threecommunity-driven OSS projects, which limitsthe generalization of findings. Moreover, a longi-tudinal observation on how coopetition evolvesamong firms can provides knowledge that goesbeyond cross-sectional observations. Last but notleast, further investigation about employing therole of gatekeepers for coopetition is needed toprovide actionable guideline for successful opera-tion of inter-firm coopetition. Future work canalso investigate OSS project settings that affectfirm collaboration, i.e. OSS license, and featurerequest mechanism. It would be interested to seehow these factors could play a role in our model.

References

[1] D.G. Messerschmitt and C. Szyperski, Soft-ware Ecosystem: Understanding an IndispensableTechnology and Industry. Cambridge, MA, USA:MIT Press, 2003.

[2] S. Jansen, A. Finkelstein, and S. Brinkkemper,“A sense of community: A research agenda forsoftware ecosystems,” in 31st International Con-ference on Software Engineering – CompanionVolume, 2009, pp. 187–190.

[3] G. Valença, C. Alves, V. Heimann, S. Jansen,and S. Brinkkemper, “Competition and collabo-ration in requirements engineering: A case studyof an emerging software ecosystem,” in 22ndInternational Requirements Engineering Confer-ence (RE), 2014, pp. 384–393.

[4] J.F. Lorraine Morgann and P. Finnegan, “Explor-ing inner source as a form of intra-organisationalopen innovation,” in 19th European Conferenceon Information Systems, 2011.

[5] K. Manikas, “Revisiting software ecosystems re-search: A longitudinal literature study,” Jour-nal of Systems and Software, Vol. 117, 2016, pp.84–103.

[6] H.H. Olsson and J. Bosch, “Ecosystem-drivensoftware development: A case study on theemerging challenges in inter-organizationalR&D,” in Software Business. Towards Continu-ous Value Delivery, C. Lassenius and K. Smolan-der, Eds. Springer International Publishing,2014, pp. 16–26.

[7] S. O’Mahony and B.A. Bechky, “Boundary orga-nizations: Enabling collaboration among unex-pected allies,” Administrative Science Quarterly,Vol. 53, No. 3, 2008, pp. 422–459.


[8] B. Andrea and R. Cristina, “Comparing moti-vations of individual programmers and firms totake part in the open source movement: Fromcommunity to business,” Knowledge, Technology& Policy, Vol. 18, No. 4, Dec. 2006, pp. 40–64.

[9] A.H. Ghapanchi, C. Wohlin, and A. Aurum, “Re-sources contributing to gaining competitive ad-vantage for open source software projects: Anapplication of resource-based theory,” Interna-tional Journal of Project Management, Vol. 32,No. 1, 2014, pp. 139–152.

[10] A.H. Ghapanchi, “Rallying competencies in vir-tual communities: A study of core processes anduser interest in open source software projects,”Information and Organization, Vol. 23, No. 2,2013, pp. 129–148.

[11] R. Riehle, “The single-vendor commercial opencourse business model,” Information Systemsand e-Business Management, Vol. 10, No. 1, Mar2012, pp. 5–17.

[12] A.H. Ghapanchi, C. Wohlin, and A. Aurum,“Resources contributing to gaining compet-itive advantage for open source softwareprojects: An application of resource-basedtheory,” International Journal of Project Man-agement, Vol. 32, No. 1, 2014, pp. 139–152.[Online]. http://www.sciencedirect.com/science/article/pii/S0263786313000380

[13] S. Ghobadi and J. D’Ambra, “Coopetitive re-lationships in cross-functional software devel-opment teams: How to model and measure?”Journal of Systems and Software, Vol. 85, No. 5,May 2012, pp. 1096–1104.

[14] K. Manikas and K.M. Hansen, “Software ecosys-tems? A systematic literature review,” Journalof Systems and Software, Vol. 86, No. 5, 2013, pp.1294–1306. [Online]. http://www.sciencedirect.com/science/article/pii/S016412121200338X

[15] L. Johan, R. Patrick, R. Björn, and P. Mäder,“How firms adapt and interact in open sourceecosystems: Analyzing stakeholder influence andcollaboration patterns,” in Requirements Engi-neering: Foundation for Software Quality. Cham:Springer International Publishing, 2016, pp.63–81.

[16] J. Teixeira, “Understanding collaboration in theopen-source arena: The cases of WebKit andOpenStack,” in Proceedings of the 18th Interna-tional Conference on Evaluation and Assessmentin Software Engineering, 2014, pp. 52:1–52:5.

[17] J. Teixeira, S. Mian, and U. Hytti, “Cooperationamong competitors in the open-source arena:The case of OpenStack,” in International Con-ference on Information Systems (ICIS), 2016.

[18] A.M. Brandenburger and B.J. Nalebuff.,Co-opetition. New York, USA: Doubleday, 1996.

[19] M. Bengtsson and S. Kock, “‘Coopetition’ inbusiness networks? To cooperate and competesimultaneously,” Industrial Marketing Manage-ment, Vol. 29, No. 5, 2000, pp. 411–426.

[20] M. Zineldin, “Co-opetition: The organisation ofthe future,” Marketing Intelligence & Planning,Vol. 22, No. 7, 2004, pp. 780–790.

[21] G.B. Dagnino and G. Padula, “Coopetition strat-egy, a new kind of inter firm dynamics for valuecreation,” in The 2nd conference on EuropeanAcademy of Management, 2002.

[22] C.P. Lin, Y.J. Wang, Y.H. Tsai, and Y.F.Hsu, “Perceived job effectiveness in coopetition:A survey of virtual teams within businessorganizations,” Computers in Human Behav-ior, Vol. 26, No. 6, 2010, pp. 1598–1606.[Online]. http://www.sciencedirect.com/science/article/pii/S0747563210001792

[23] W. Scacchi, “Free/Open Source software devel-opment: Recent research results and emergingopportunities,” in The 6th Joint Meeting on Eu-ropean Software Engineering Conference and theACM SIGSOFT Symposium on the Foundationsof Software Engineering: Companion Papers, ser.ESEC-FSE companion ’07. New York, NY, USA:ACM, 2007, pp. 459–468.

[24] J.Y. Moon and L. Sproull, “Essence ofdistributed work: The case of the Linuxkernel,” First Monday, No. 11, 2000.[Online]. http://www.firstmonday.dk/ojs/index.php/fm/article/view/801/710

[25] A. Mockus, R.T. Fielding, and J.D. Herbsleb,“Two case studies of Open Source Software de-velopment: Apache and Mozilla,” ACM Transac-tions on Software Engineering and Methodology,Vol. 11, No. 3, Jul. 2002, pp. 309–346.

[26] G.K. Lee and R.E. Cole, “From a firm-based toa community-based model of knowledge creation:The case of the Linux kernel development,” Or-ganization Science, Vol. 14, No. 6, Nov. 2003, pp.633–649.

[27] J. Xu, Y. Gao, S. Christley, and G. Madey, “Atopological analysis of the Open Souce Softwaredevelopment community,” in Proceedings of the38th Annual Hawaii International Conference onSystem Sciences, Jan. 2005, p. 198a.

[28] K. Crowston and J. Howison, “The social struc-ture of Free and Open Source Software develop-ment,” First Monday, Vol. 10, 2005.

[29] L. Dabbish, C. Stuart, J. Tsay, and J. Herb-sleb, “Social coding in GitHub: Transparencyand collaboration in an open software reposi-

http://www.sciencedirect.com/science/article/pii/S0263786313000380


http://www.sciencedirect.com/science/article/pii/S016412121200338X

http://www.sciencedirect.com/science/article/pii/S016412121200338X



http://www.firstmonday.dk/ojs/index.php/fm/article/view/801/710

http://www.firstmonday.dk/ojs/index.php/fm/article/view/801/710


tory,” in Proceedings of the ACM Conferenceon Computer Supported Cooperative Work, ser.CSCW ’12. New York, NY, USA: ACM, 2012,pp. 1277–1286.

[30] C. Gutwin, R. Penner, and K. Schneider, “Groupawareness in distributed software development,”in Proceedings of the ACM Conference on Com-puter Supported Cooperative Work, ser. CSCW’04. New York, NY, USA: ACM, 2004, pp. 72–81.

[31] W. Scacchi, Free/Open Source Software De-velopment: Recent Research Results and Meth-ods. Elsevier, 2007, Vol. 69, pp. 243–295.[Online]. http://www.sciencedirect.com/science/article/pii/S0065245806690050

[32] R. Abreu and R. Premraj, “How developercommunication frequency relates to bug intro-ducing changes,” in Proceedings of the JointInternational and Annual ERCIM Workshopson Principles of Software Evolution (IWPSE)and Software Evolution (Evol) Workshops, ser.IWPSE-Evol ’09. New York, NY, USA: ACM,2009, pp. 153–158.

[33] T. Zimmermann, R. Premraj, N. Bettenburg,S. Just, A. Schroter, and C. Weiss, “What makesa good bug report?” IEEE Transactions on Soft-ware Engineering, Vol. 36, No. 5, Sep. 2010, pp.618–643.

[34] C. Bird, N. Nagappan, H. Gall, B. Murphy,and P. Devanbu, “Putting it all together: Us-ing socio-technical networks to predict failures,”in 20th International Symposium on SoftwareReliability Engineering, Nov. 2009, pp. 109–119.

[35] T. Wolf, A. Schroter, D. Damian, and T. Nguyen,“Predicting build failures using social networkanalysis on developer communication,” in Pro-ceedings of the 31st International Conference onSoftware Engineering, ser. ICSE ’09. Washing-ton, DC, USA: IEEE Computer Society, 2009,pp. 1–11.

[36] C. Ferioli and P. Migliarese, “Supporting orga-nizational relations through information tech-nology in innovative organizational forms,” Eu-ropean Journal of Information Systems, Vol. 5,No. 3, 1996, pp. 196–207.

[37] M. Antikainen, T. Aaltonen, and J. Väisänen,“The role of trust in OSS communities? Caselinux kernel community,” in Open Source De-velopment, Adoption and Innovation, J. Feller,B. Fitzgerald, W. Scacchi, and A. Sillitti, Eds.Springer, 2007, pp. 223–228.

[38] S.Y. Ho and A. Richardson, “Trust and distrustin Open Source Software development,” Journalof Computer Information Systems, Vol. 54, No. 1,2013, pp. 84–93.

[39] P.J. Ågerfalk and B. Fitzgerald, “Outsourcing toan unknown workforce: Exploring opensourcingas a global sourcing strategy,” MIS Quarterly,Vol. 32, No. 2, Jun. 2008, pp. 385–409.

[40] M. Bengtsson and S. Kock, “Cooperation andcompetition in relationships between competi-tors in business networks,” Journal of Business& Industrial Marketing, Vol. 14, No. 3, 1999, pp.178–194.

[41] D. Tjosvold, Team organization: An enduringcompetitive advantage. Wiley-Blackwell, 1991, ch.Forging Synergy, pp. 219–233.

[42] R.C. Mayer, J.H. Davis, and F.D. Schoor-man, “An integrative model of organizationaltrust,” The Academy of Management Review,Vol. 20, No. 3, 1995, pp. 709–734. [Online].http://www.jstor.org/stable/258792

[43] M. Levy, C. Loebbecke, and P. Powell, “SMEs,co-opetition and knowledge sharing: The roleof information systems,” European Journal ofInformation Systems, Vol. 12, No. 1, 2003, pp.3–17.

[44] R.K. Yin, Case Study Research: Design andMethods (Applied Social Research Methods).USA: SAGE Publications, Inc., 2014.

[45] M.J. Gallivan, “Striking a balance between trustand control in a virtual organization: A contentanalysis of open source software case studies,”Information Systems Journal, Vol. 11, No. 4,2001, pp. 277–304.

[46] H. Wang and C. Wang, “Open source soft-ware adoption: a status report,” IEEE Software,Vol. 18, No. 2, March 2001, pp. 90–95.

[47] M. Cataldo and J.D. Herbsleb, “Architecting insoftware ecosystems: Interface translucence asan enabler for scalable collaboration,” in Pro-ceedings of the Fourth European Conference onSoftware Architecture: Companion Volume, ser.ECSA ’10. New York, NY, USA: ACM, 2010, pp.65–72.

[48] Q&A with the founder of Wireshark andEthereal, 2008. [Online]. http://protocog.com/gerald_combs_interview.html

[49] L. Freeman, The Development of Social NetworkAnalysis. Canada: Empirical Press, 2006.

[50] D.S. Cruzes and T. Dyba, “Recommended stepsfor thematic synthesis in software engineering,”in International Symposium on Empirical Soft-ware Engineering and Measurement, Sept 2011,pp. 275–284.

[51] K.J. Stewart and S. Gosain, “The impact ofideology on effectiveness in open source softwaredevelopment teams,” MIS Quarterly, Vol. 30,No. 2, Jun. 2006, pp. 291–314.



http://www.jstor.org/stable/258792

http://protocog.com/gerald_combs_interview.html

http://protocog.com/gerald_combs_interview.html


[52] P.B. M. S. Lane, G. Vyver and S. Howard,“Inter-preventative insights into interpersonaltrust and effectiveness of virtual communities ofopen source software (OSS) developers,” OpenSource Systems: Towards Robust Practices, 2004.

[53] P.B. de Laat, “How can contributors toopen-source communities be trusted? on the as-sumption, inference, and substitution of trust,”Ethics and Information Technology, Vol. 12,No. 4, 2010, pp. 327–341.

[54] E.S. Raymond, The Cathedral and the Bazaar.Sebastopol, CA, USA: O’Reilly & Associates,Inc., 1999.

[55] S. Grand, G. von Krogh, D. Leonard,and W. Swap, “Resource allocation be-yond firm boundaries: A multi-level modelfor open source innovation,” Long RangePlanning, Vol. 37, No. 6, 2004, pp. 591–610.[Online]. http://www.sciencedirect.com/science/article/pii/S0024630104001177

[56] L. Dahlander and M.W. Wallin, “A manon the inside: Unlocking communities ascomplementary assets,” Research Policy,Vol. 35, No. 8, 2006, pp. 1243–1259.[Online]. http://www.sciencedirect.com/science/article/pii/S0048733306001387

[57] A. Mehra, R. Dewan, and M. Freimer, “Firms asincubators of open-source software,” InformationSystems Research, Vol. 22, No. 1, Mar. 2011, pp.22–38.

[58] M.J. Gallivan, “Striking a balance between trustand control in a virtual organization: a contentanalysis of open source software case studies,”

Information Systems Journal, Vol. 11, No. 4,2001, pp. 277–304.

[59] J. Teixeira, G. Robles, and J.M. González-Bara-hona, “Lessons learned from applying social net-work analysis on an industrial Free/Libre/OpenSource Software ecosystem,” Journal of InternetServices and Applications, Vol. 6, No. 1, 2015,p. 14.

[60] C. Oezbek, L. Prechelt, and F. Thiel, “The onionhas cancer: Some social network analysis visual-izations of open source project communication,”in Proceedings of the 3rd International Workshopon Emerging Trends in Free/Libre/Open SourceSoftware Research and Development, ser. FLOSS’10. New York, NY, USA: ACM, 2010, pp. 5–10.

[61] S. Marczak, D. Damian, U. Stege, andA. Schröter, “Information brokers in require-ment-dependency social networks,” in 16th IEEEInternational Requirements Engineering Confer-ence, Sept 2008, pp. 53–62.

[62] A. Nguyen-Duc, D.S. Cruzes, and R. Conradi,“On the role of boundary spanners as team co-ordination mechanisms in organizationally dis-tributed projects,” in 9th International Confer-ence on Global Software Engineering, Aug. 2014,pp. 125–134.

[63] J. Linåker, H. Munir, K. Wnuk, and C.E.Mols, “Motivating the contributions: An openinnovation perspective on what to share asopen source software,” Journal of Systemsand Software, Vol. 135, 2018, pp. 17–36.[Online]. http://www.sciencedirect.com/science/article/pii/S0164121217302169







DoSoftwareFirmsCollaborateorCompete ... ·...

Documents

Transcript of DoSoftwareFirmsCollaborateorCompete ... ·...