open source software and impact on competitiveness: case study · competitive advantages,...

Helsinki University of Technology,

Department of Electrical Engineering and Communications Engineering

Erkko Anttila

Open Source Software and Impact on

Competitiveness: Case Study

This thesis has been submitted in partial fulfillment of the requirements for the degree of Master

of Science in Engineering.

Espoo, September 25th, 2006

Supervisor Heikki Hämmäinen

Professor of Electrical and Communications Engineering

Instructor Valtteri Halla

Master of Science in Engineering &

Master of Science in Economics

Helsinki University of Technology Abstract of Master’s Thesis

Author: Erkko Anttila

Subject of Thesis: Open Source Software and Impact on Competitiveness: Case Study

Date: September 25, 2006

Number of Pages: 91

Department: Department of Electrical and Communications Engineering

Professorship: S-38 Telecommunications Management

Supervisor: Professor Heikki Hämmäinen

Instructor: Valtteri Halla, Master of Science in Engineering & Master of Science in Economics

This study examines how collaborative open source software utilization can impact the competitiveness of product companies. The objective is to examine the impact of substantial collaboration and to provide a framework which describes in detail the rationale for collaboration and leveraging open source software. Open source software has been increasingly adopted as part of the software industry, but it is still unclear how collaborative development can contribute to and be combined with the competitiveness of companies, because of the informal relationship with the community and openness of software. The impact on competitiveness is studied through reviewing literature on theories of competitive advantages, identifying the distinct competitive characteristics of software products, examining the characteristics of open source software, and investigating the prior collaboration strategies of companies. Then two case studies are conducted based on the conceptual understanding. Open source software is defined as an industry wide disruption due to community growth, increased commercial investment, and part of the software asset reaching commercial quality. This has lead to the software industry moving to a transition phase with heterogeneous collaboration strategies across competition. The presented framework details the rationale for collaboration and the different firm-level strategies—integration with existing communities and self-created communities—that can be used to implement collaborative development. Based on the empirical study, collaboration enables companies to concentrate on value creation and more efficient expansion of existing competencies to new markets. The strategic split of software makes possible the reconfiguration of the development value chain and a better match between internal competencies and the external environment. This leads to substantial cost reductions in product development, with the efficiency defined by the firm-level collaboration activities and the characteristics of the chosen communities. The studies also indicate that collaboration does not neglect the companies’ ability to create differentiating value in addition to OSS with, e.g. IPR or network externalities. The research also makes observations and discusses the impact of collaboration on industry competencies, and the possibility of direct competitors converging to similar collaboration strategies. Keywords: open source software, competitive advantage, competitiveness, software products

Publishing language: English

TEKNILLINEN KORKEAKOULU Diplomityön tiivistelmä

Tekijä: Erkko Anttila

Työn nimi: Avoin Lähdekoodi ja Vaikutus Kilpailukykyyn: Tapaustutkimus

Päivämäärä: Syyskuu 25, 2006

Sivumäärä: 91

Osasto: Sähkö- ja tietoliikennetekniikan osasto

Professuuri: S-38 Telecommunications Management

Valvoja: Professori Heikki Hämmäinen

Ohjaaja: Valtteri Halla, DI & KTM

Tämä tutkimus tarkastelee kuinka yhteistoiminnallinen avoimen lähdekoodin käyttö voi vaikuttaa tuoteyrityksien kilpailukykyyn. Tavoitteena on tutkia huomattavan yhteistoiminnallisen tuotekehityksen vaikutusta ja tarjota viitekehys, joka yksityiskohtaisesti selittää syyt yhteistoiminnalle ja avoimen lähdekoodin käytölle. Avoin lähdekoodi on viime vuosina kasvavissa määrin omaksuttu osaksi ohjelmistoteollisuuden kilpailua, mutta on edelleen epäselvää miten yhteistoiminta voi edistää tuoteyritysten kilpailukykyä, koska suhde yhteisöön on epävirallinen ja lähdekoodi avointa kilpailijoille. Vaikutusta kilpailukykyyn tutkitaan tarkastelemalla kirjallisuutta kilpailuteorioista, identifioimalla erityisiä tekijöitä ohjelmistotuotekilpailussa, tarkastelemalla tekijöitä avoimeen lähdekoodin liittyen, sekä tutkimalla aikaisempia yritysten yhteistoimintastrategioita. Käsitteellisen ymmärryksen pohjalta toteutetaan kaksi tapaustutkimusta. Avoin lähdekoodi määritetään toimialan laajuisena häiriönä yhteisön kasvun, kasvavan kaupallisen investoinnin ja ohjelmistojen saavuttaman maturiteetin takia. Tämän johdosta ohjelmistotoimiala on siirtynyt muutosvaiheeseen, jossa on heterogeenisiä yhteistoimintastrategioita kilpailijoiden välillä. Esitetty viitekehys selostaa yksityiskohtaisesti syyt yhteistoiminnalle ja erilaiset yritystason yhteistoimintastrategiat—integraatio olemassa olevien yhteisöjen kanssa ja itseluodut yhteisöt—, joita voidaan käyttää tuotekehityksen toteutuksessa. Empiirisen tutkimuksen perusteella yhteistoiminnallinen tuotekehitys mahdollistaa investointien keskittymisen arvon luontiin ja tehokkaan olemassa olevien kykyjen käytön laajentamisen. Strategisen ohjelmistojenjaon avulla kehitysarvoketju voidaan uudelleen sovitella ja luoda parempi yhteensopivuus sisäisten kykyjen ja ulkoisen ympäristön välillä. Tämä johtaa huomattaviin supistuksiin tuotekehityksen kuluissa, jolloin supistusten tehokkuuden määrittää sekä yritystason yhteistoiminta, että valittujen yhteisöjen piirteet. Tutkimukset myös osoittavat, että yhteistoiminnallinen tuotekehitys ei tuhoa yritysten kykyä luoda differentioivaa arvoa, esim. aineettoman omaisuuden suojalla tai verkostovaikutuksilla. Tutkimus tekee myös havaintoja ja käsittelee yhteistoiminnan vaikutusta toimialan kykyihin ja mahdollista suorien kilpailijoiden siirtymistä samankaltaisiin yhteistoiminnallisuusstrategioihin. Avainsanat: avoin lähdekoodi, kilpailuetu, kilpailukyky, ohjelmistotuotteet

Julkaisukieli: Englanti

Acknowledgements

During the process of writing this Master’s Thesis, I have received valued and indispensable

support and guidance from several people. I wish to express my utmost gratefulness to

• Professor Heikki Hämmäinen, the supervisor of this work, for the needed guidance and

valued advice during the whole project.

• Mr. Valtteri Halla, the instructor of this research, for his continuous positive attitude, ability

to encourage more analytical thinking, and valued insight and feedback despite his tight

working schedules.

• Mr. Jarmo Tikka, for giving me the opportunity to conduct this research despite the never

ending amount of work I should have been doing.

• Ms. Mari Piirainen, for always contributing recommendations and criticism when needed

and being the ultimate source for competitive theories.

• My parents, sibling, cousins, and aunt for supporting and encouraging me during the

research and all of my time at Helsinki University of Technology.

• And most importantly my girlfriend Emilia Koskinen for understanding why I wanted to sit

at home writing during Saturday evenings and supporting me through the weeks and months

the project took.

Table of Contents

Anttila, Erkko 2006. Open Source Software and Impact on Competitiveness: Case Study.

Master’s Thesis, Helsinki University of Technology.

1. INTRODUCTION................................................................................................................................ 7

1.1 BACKGROUND ................................................................................................................................ 7 1.2 RESEARCH PROBLEM ..................................................................................................................... 8 1.3 RESEARCH OBJECTIVES ................................................................................................................. 8 1.4 SCOPE OF THE STUDY..................................................................................................................... 9 1.5 RESEARCH APPROACH AND METHODS .......................................................................................... 9 1.6 RESEARCH STRUCTURE................................................................................................................ 10

2. LITERATURE REVIEW.................................................................................................................. 11

2.1 COMPETITIVE ADVANTAGE.......................................................................................................... 11 2.1.1 Generic Strategies................................................................................................................... 11 2.1.2 Industry Competition .............................................................................................................. 12 2.1.3 Firm Competitiveness ............................................................................................................. 13 2.1.4 Miscellaneous Theories & Definitions ................................................................................... 15

2.2 SOFTWARE PRODUCT APPROACH ................................................................................................ 16 2.2.1 Software Product Characteristics .......................................................................................... 17 2.2.2 Competitive Implications ........................................................................................................ 18 2.2.3 Software Layers and Platforms .............................................................................................. 20

2.3 SOFTWARE AS PRODUCTION PROCESS ......................................................................................... 21 2.3.1 Software Production Characteristics ..................................................................................... 21 2.3.2 Competitive Implications ........................................................................................................ 21

2.4 OPEN SOURCE SOFTWARE............................................................................................................ 23 2.4.1 Open Source Licensing ........................................................................................................... 23 2.4.2 Open Source Development ..................................................................................................... 25 2.4.3 Commercial Open Source....................................................................................................... 28

2.5 SUMMARY OF LITERATURE REVIEW FINDINGS............................................................................ 34 2.5.1 Disruption and Maturity ......................................................................................................... 34 2.5.2 Firm-Level Strategies Model .................................................................................................. 35

3. COLLABORATIVE R&D FRAMEWORK................................................................................... 38

3.1 RELATIVE COMPETITIVE ADVANTAGES ...................................................................................... 38 3.2 STRATEGIC SPLIT BASED ON SOFTWARE VALUE......................................................................... 39

3.2.1 Non-Differentiating Software ................................................................................................. 40 3.2.2 Differentiating Software ......................................................................................................... 43

3.3 COLLABORATION FRAMEWORK SUMMARY................................................................................. 45

4. CASE STUDIES ................................................................................................................................. 47

4.1 DESIGN AND CASE SELECTION..................................................................................................... 47 4.2 OBJECTIVES AND METHODS......................................................................................................... 47 4.3 CASE STUDY 1: INTERNET TABLET SOFTWARE EDITION 2005 .................................................... 49

Table of Contents



4.3.1 Overview & Approach ............................................................................................................ 49 4.3.2 Software Characteristics & Split ............................................................................................ 49 4.3.3 Non-Differentiating Software ................................................................................................. 50 4.3.4 Investment Structure ............................................................................................................... 54 4.3.5 Differentiating Software ......................................................................................................... 55 4.3.6 Analysis ................................................................................................................................... 56

4.4 CASE STUDY 2: MAC OS X .......................................................................................................... 57 4.4.1 Overview ................................................................................................................................. 57 4.4.2 History and Strategic Approach ............................................................................................. 58 4.4.3 Software Characteristics & Split ............................................................................................ 58 4.4.4 Non-Differentiating Software ................................................................................................. 59 4.4.5 Investment Structure ............................................................................................................... 63 4.4.6 Differentiating Software ......................................................................................................... 64 4.4.7 Analysis ................................................................................................................................... 65

4.5 FINDINGS AND GENERALIZATION OF CASES................................................................................ 66 4.5.1 Quantitative Findings ............................................................................................................. 67 4.5.2 Generalization of Findings ..................................................................................................... 68 4.5.3 Framework Assessment........................................................................................................... 69

5. DISCUSSION...................................................................................................................................... 71

6. CONCLUSIONS................................................................................................................................. 73

6.1 MAIN RESULTS............................................................................................................................. 73 6.2 ASSESSMENT OF RESULTS............................................................................................................ 73 6.3 EXPLOITATION OF RESULTS ......................................................................................................... 74 6.4 RECOMMENDATIONS FOR FUTURE RESEARCH............................................................................. 75

7. REFERENCES ................................................................................................................................... 76

APPENDIX 1: CASE STUDY MATERIAL............................................................................................ 90

APPENDIX 2: INTERVIEW PROTOCOL............................................................................................. 91

Introduction 7



1. INTRODUCTION

1.1 Background

Until recently product companies such as Nokia, Samsung, and Microsoft have focused solely

on closed-source software products. This has based competitiveness on e.g. lock-in strategies

(Shapiro & Varian, 1999) and the ability to protect intellectual property (Hall, 2003). However,

an alternative to the dominant development paradigm has been introduced by the emergence of

the open source movement (O’Reilly, 1999). The open source software (OSS) definition states

that the source code of software is distributed with the executable binary, the software is free to

use, and anyone is free to modify and redistribute it (Hansen et al., 2002). This phenomenon has

intrigued academic researchers and companies as it goes against the logic of value in closed-

source software production but seems to be a sustainable development model (Lerner & Tirole,

2000; Johnson, 2002).

The success and outcomes of some OSS projects, like the Linux kernel and the Apache net

server (Mockus et al., 2002; O’Reilly, 2004; Fink, 2003), have disclosed the ability of the open

source community to produce commercial quality software. These free programs have been able

to build substantial market shares, e.g. the Apache net server holds over 60% of the web server

market (Casadesus-Masanell & Ghemawatt, 2003; Johnson, 2002). Academic research has

contributed to the understanding of this phenomenon with studies into the motivations of

developers (Lerner & Tirole, 2000; Lakhani et al., 2002), the innovation process (Krogh et al.,

2003), the strengths and problems of the development model, and the technology areas of the

created software (Ioannis et al., 2002; Scacchi, 2002).

This change in software creation has introduced an opportunity for commercial as well as non-

commercial parties to conduct collaborative development. For example, NASA is utilizing OSS

to cut costs and ensure higher quality (Norris, 2004), IBM and Sun are exploiting OSS to drive

down maintenance costs and speed up the development of their products (West, 2003), and

companies like Red Hat are creating their products almost solely from OSS (Young, 1999).

Despite the existing commercial interest, product companies choosing to leverage OSS are

faced with the issues of understanding the explicit rationale and implementation of this strategy

and the impact on their competitiveness. These issues are caused by e.g. openness of source

code (Henkel, 2003) and the collaboration of commercial and non-commercial parties (Long,

2003).

Introduction



8

1.2 Research Problem

This research tries to understand the impact on competitiveness of substantial collaborative

research and development (R&D), from the viewpoint of product businesses leveraging OSS.

Collaborative R&D is adapted from Dahlander and Magnusson (2005), and defined as the

company extending their R&D to include the OSS community, with a continuous two-way flow

of software, investment, and effort throughout the life cycle of the product. This collaborative

R&D comprises a substantial amount, e.g. 50% or more, of the product source code.

OSS has gathered a considerable amount of academic interest in the recent years, but there

exists a gap in the understanding of the rationale for collaborative R&D and the impact on

competitiveness. Most of the research has concentrated on explaining the motivations of the

individual developers, the development model, or the culture of the community. Some authors

have studied the benefits for commercial companies, but this has not lead to a thorough

understanding of the competitive implications.

The study builds on the previous research on competitiveness, software products, and OSS. The

approach is to identify the distinct competitive factors impacting software products; analyze the

characteristics of OSS; and to synthesize a framework detailing the rationale and

implementation of collaborative R&D, which is then used as the bases of the empirical study.

The research problem can be summarized as the following question: How can substantial

collaborative R&D impact product company competitiveness?

1.3 Research Objectives

The main objective of the study is:

• To examine the impact collaborative R&D has on competitiveness and to form a

framework that details the rationale and implementation of this strategic approach.

To elaborate on the main objective, the following sub-objectives were considered appropriate:

• To identify and examine the characteristics of OSS; firm-level strategies in which

commercial parties have collaborated with the OSS community; the disadvantages,

challenges, and benefits resulting from these strategies; and the industry wide impact of

OSS.

Introduction



9

• Seek empirical validation, feedback, and criticism of the introduced framework with the

help of case studies.

1.4 Scope of the Study

The three subjects of concern— software products, OSS, and competitiveness—are all broad

topics with extensive research related to them. Therefore, it is not in the scope of the study to

build a comprehensive and detailed framework of software business or competitive advantage.

Software has expanded its impact to a critical value adding part in high-technology industries

(MacCormack, 2001), but also in typical manufacturing industries. Therefore we adapt the

definition of Hyvönen (2003), and define that the studies target product businesses include both

individual software products and software produced to be utilized directly with hardware.

The following rules are derived to define the scope of the study:

• The research does not limit itself to licensed software products, but also includes

software meant for consumption with complements, such as hardware.

• Theory of software product businesses is used to examine the competitive factors of

both industry and firm-level phenomenon. However, the questions of specific

characteristics of distinct software markets, when to use OSS, and the evaluation of

different production models are left outside of the scope of the study.

• Collaborative R&D is examined as a tool to create advantages regarding product and

software development. How this advantage is made apart of the whole competitive

dynamism of companies, how it impacts market share, and how it is utilized in the

overall competitive strategy are outside of the scope of the study.

1.5 Research Approach and Methods

The research approach of this study is a combination of a theoretical and empirical approach.

The theoretical approach concentrates on describing software production, OSS, and competitive

theory. The empirical approach tries to assess the findings of the theoretical part, validate the

proposed conceptual framework, and empirically examine the explicit impact of collaborative

R&D.

Introduction



10

For the theoretical part, the conceptual approach was chosen as it meets best the objective of

creating a conceptual framework answering the research objectives and working as the bases of

the empirical study. The theoretical part is based on a review of secondary data acquired from

literature, articles, and the Internet.

The empirical parts research method is comprised of two descriptive case studies (Yin, 2003;

Kasanen et al., 1993). For these studies the methods of data collection are documentation,

archival records, active participation, and interviews (Yin, 2003). Quantitative data is used in

combination with empirical observations.

1.6 Research Structure

Chapter 2 reviews existing literature and theories related to competitiveness, competitive

advantage, software business, software production, and OSS. In chapter 3, the findings from the

literature review are synthesized in the form of a framework introducing how collaborative

R&D can impact competitiveness. Chapter 4 reports the two descriptive case studies, the main

findings, and assesses the validity of the proposed framework. The following chapter 5

discusses the research, and chapter 6 presents the conclusions of the research and

recommendations for future research. The structure is presented in figure 1.

Chapter 1

Research IntroductionChapter 1

Research Introduction

Chapter 3Synthesis as Collaborative

R&D Framework


R&D Framework

Chapter 2.5Findings from Literature


Literature ReviewLiterature Review

Chapter 2.1Competitive Advantage


Chapter 2.2 & 2.3Software ProductsChapter 2.2 & 2.3

Software Products

Chapter 2.4Open Source Software


Chapter 4Case StudiesChapter 4

Case Studies

Chapter 5Discussion of Research


Chapter 6ConclusionsChapter 6

Conclusions

Chapter 1Research Introduction

Chapter 1Research Introduction


R&D Framework


R&D Framework



Literature ReviewLiterature Review



Chapter 2.2 & 2.3Software ProductsChapter 2.2 & 2.3

Software Products



Chapter 4Case StudiesChapter 4

Case Studies



Chapter 6ConclusionsChapter 6

Conclusions Figure 1: Research structure

Literature Review 11



2. LITERATURE REVIEW

The purposes of the following chapters are to review the theories of competition and

competitive advantages and the literature on software products, their distinct competitive

characteristics, and OSS development.

2.1 Competitive Advantage

The understanding of what contributes to the competitive success of companies and what can be

considered as competitive advantage has received many definitions. The present competitive

environment has been defined as containing discontinuous change in demand, competitors,

technology, and regulation (Eisenhardt & Bourgeois, 1988), knowledge intensity, positive

feedback industries (Hitt & Bettis, 1995), globalization (Hitt et al., 1998), and hypercompetition

(D’Aveni 1995, 1999). The result is a competitive landscape described by strategic

discontinuities, blurring of industries, short product life cycles, high levels of uncertainty, and

stiff competition (Hitt & Bettis, 1995). Despite this complexity, we define competitiveness

according to D’Cruz and Rugman (1992) as the ability to design, produce, and or market

products superior to those offered by competitors, considering the price and the non-price

qualities; and Barney (1991) as a company having a competitive advantage when they are able

to implement a strategy that creates value not simultaneously implemented by any competitor,

and a sustainable competitive advantage when competitors are not able to duplicate the strategy.

2.1.1 Generic Strategies

Porter (1985) introduced the generic strategies— strategic scope and competitive advantage—

defined along two dimensions illustrated in figure 2.

C O M P E T I T I V E A D V A N T A G E

C O M P E T I T I V ES C O P E

L o w e r C o s t D i f f e r e n t i a t i o n

B r o a dT a r g e t

N a r r o wT a r g e t

1 . C o s t L e a d e r s h i p 2 . D i f f e r e n t i a t i o n

3 A . C o s t F o c u s 3 B . D i f f e r e n t i a t i o n F o c u s

Figure 2: The generic product strategies (Porter, 1985)

Competitive advantage defined the two basic advantages for companies: lower cost or

differentiation. Customer value can be produced by lower costs leading to a cost leadership, or

concentration on providing value by features and products that are perceived as unique through

Literature Review



12

differentiation. There is, however, no generalization of what constitutes differentiation, other

than that the products are not exact copies of each other in relation to the price and all non-price

qualities (Porter, 1985).

Value chain analysis is a general tool that can be used to analyze the general cost and value

drivers of company operations (figure 3) to maximize value and minimize costs. (Porter, 1985)

Figure 3: Model of value chain analysis (Porter, 1985)

Porter (1985) identified ten cost drivers including areas such as economies of scale, linking

among activities, timing of market entry, and degree of vertical integration impacting

competitiveness. By controlling these cost drivers or reconfiguring the value chain companies

can develop competitive advantages.

2.1.2 Industry Competition

The industrial organization (I/O) model (Ansoff, 1965; Andrews, 1971) and five forces theory

(Porter 1980, 1981, 1985; Teece 1984) suggest that firms obtain advantages by exploiting their

internal strengths, through responding to the environment while neutralizing threats and

weaknesses, and impacting the forces that dictate profitability and advantages of a defined

industry. These forces are shown in the figure 4.

Figure 4: The five industry forces impacting competition (Porter, 1985)

Literature Review



13

The aim of a company is to through its actions maintain an ideal industry structure, e.g. low

supplier and buyer power, high entry barriers, and low rivalry to create the largest possible

profit. These models however make assumptions which have later been criticized. Barney

(1986, 1991) has pointed out that the resource homogeneity (Porter, 1981; Rummelt, 1984)

among industry participants, stable industry barriers, and the high mobility of resources (Barney

1986) don’t apply to competition now and therefore the model is not directly applicable

anymore.

More importantly, value chain analysis can be extended to include the whole external industry

value system that comprises of all the upstream and downstream companies, thus the whole

industry can be seen as an interconnected chain (Porter, 1998). Value is created by the

interaction of different stakeholders within the system and therefore competitiveness is

expanded to include the co-operation of the companies and not only the position and functions

of a single company (Brooks, 1997). The key task in a value system is to reconfigure so as to

create new sources of value and find a better fit between the created value and customers

(Normann & Ramirez, 1993). The level of direct control or ownership of the companies’ value

chain upstream inputs or downstream outputs is vertical integration. This can be e.g. ownership

of upstream raw material manufacturing or distribution channel ownership for a product

integrator. Vertical integration can lead to advantages in cost reduction through control and

reduced transaction costs, entry barriers for competition, and improved chain coordination to

increase customer value. Transaction costs are the costs caused by trading with others besides

the price (Carlton & Perloff, 1994). They include searching for the best offerings, contract

negotiations, and enforcing agreements. In general, these costs are high when there are a large

number of companies offering a service resulting in searching costs, and when uncertainty is

high due to changing market demands or specialized requirements impacting the need of

contractual and enforcing costs.

2.1.3 Firm Competitiveness

Firm competitiveness resulting from a company’s internal characteristic has as well inspired a

variety of theories and definitions. Prahalad and Hamel (1990, 1994) have proposed that in the

long run core competencies are the source of competitive advantages. These competencies—

integrated bundles of resources, skills aptituded, or technologies—are the specific things

companies excel at, and they provide the ability to build at lower cost and more rapidly than

competitors. These competencies must fulfill three criteria—ability to produce customer value,

competitive uniqueness, and extendibility—to be considered as core competencies. Some

Literature Review



14

examples can be enhanced abilities in miniaturization, technological experience, or even the

management of logistics channels. Companies’ products and portfolios should be based on their

respective core competencies to maximize the effect of these rare capabilities and leverage the

same competitive advantages in a wide range of markets.

The resource-based view combines the external competitive components (industry structure)

with the internal competitive components (firm competencies). Barney (1991) and Peteraf

(1993) define the resource-based view of the firm as a collection of resources and a set of

functions to utilize these resources as competitive advantages. The definition is based on the

assumption that a firm’s internal environment is critical for competition (Barney, 1991; Peteraf,

1993). The model assumes that resources within an industry can be heterogeneous and that these

resources are not perfectly mobile across companies (Barney, 1991). The resources can include

for example assets, organizational processes, technology knowledge, contacts, and personnel

(Barney, 1991; Porter, 1981; Peteraf, 1993) that are controlled by the firm and can be used to

improve efficiency. The view introduces four theoretical attributes that can be thought of as

empirical indicators of the ability of a certain resource to generate sustainable competitive

advantages: valuable, rare, imperfectly imitable, and substitutability. This is summarized in the

following framework (Figure 5).

Figure 5: VRIN framework for resource-based view (Barney, 1991)

From the resource-based view, a similar model has evolved called knowledge-based view. This

view refers to heterogeneous knowledge bases as the single most important factor in

competitiveness (Kogut & Zander, 1993; Grant, 1996). Companies can integrate the knowledge

of individuals to attain better performance (Grant, 1996), which can be done through creating,

storing, and applying knowledge (Spender, 1996).

The dynamic capabilities theory is as well an extension of the resource-based view, but it

focuses heavily on how the internal and external environment are matched together. Teece and

colleagues (1997) and Eisenhardt and Martin (2000) define dynamic capabilities as “processes

Literature Review



15

that use resources—specifically the processes to integrate, reconfigure, gain, and release

resources—to match and even create market change”. Identifiable examples of dynamic

capabilities (Eisenhardt & Martin, 2000) are the integration of resources in product development

routines (Helfat & Raubitschek, 2000), reconfiguration of resources within transfer processes

(Hansen, 1999; Szulanski, 1996), and gaining and creating resources in routines like alliancing

(Gulati, 1999; Zollo & Singh, 1998). Competitiveness is therefore created through the constant

process of acquiring, integrating, reconfiguring, releasing, and restructuring resources

(Eisenhardt & Martin, 2000).

2.1.4 Miscellaneous Theories & Definitions

Social capital theory proposes that competitiveness can be affected by the acquirement of social

relationships. Bourdies and Wacquants (1992) define social capital as standing for “the sum of

resources, actual or virtual, that accrue to an individual or group by virtue of possessing a

durable network of more or less institutionalized relationship of mutual acquaintances and

recognition”. A relationship that provides access to physical resources can be considered a

competitive advantage (Nahapiet & Ghoshal, 1998). This rational is based on the three

categories offered by Lin (1999): relationships facilitate the flow of information giving

companies easy and low cost access to information hard to acquire; network participants may be

able to exert control over others; and social credentials may tie the parties of a network to each

other reinforcing the network from external access. Research has measured social capital by

valuing the assets embedded in the network and by studying the degree of the ties between

participants. Both of these approaches have been able to prove the relevance of social capital in

acquiring benefits from social networks (Lin, 1999).

In the dynamic competitive environment the advantage from moving first is considered an

important phenomenon. A first-mover can be defined as “an organization, which is first to

employ a particular strategy within a context of a specified scope” (Zahra et al., 1995). The

first-mover advantage has been proposed as the ability to earn positive economic profits

compared to followers resulting from e.g. leadership in product or technology development,

preemption of assets, buyer and supplier switching costs, or technology standardization

(Lieberman & Montgomery, 1988; Porter, 1985; Zahra et al., 1995). First-movers can as well

face disadvantages in the form of late-comers ability to free-ride on their investments, market

uncertainty, technological discontinuities, and incumbent inertia (Lieberman & Montgomery,

1988, 1998; Zahra et al., 1995; Makadok, 1998). The experience curve is a result of the first-

movers advantage (Lieberman & Montgomery, 1988), for as companies continue to perform a

Literature Review



16

task, the cost of it lowers. As the cumulative volume doubles, value added costs tend to fall by a

constant percentage (Figure 6). This advantage can be sustained if the gained process or

production advantage can be kept proprietary or otherwise away from the knowledge of

competition (Ghemawat, 1985).

Figure 6: The impact of experience on the cost of production (Adapted from Lieberman, 1987)

To understand the impact of radical innovations, Christensen (1997) introduced the theory of

disruptive technologies. As incumbents concentrate on incremental innovation, time and again,

disruptive technologies emerge that are typically cheaper, simpler, or different in some other

key category. These technologies enter the market from the low-end. As the technologies

mature and achieve the necessary performance, they ultimately take over the market, replace the

prior technology as illustrated in figure 7, and restructure the whole industry.

Figure 7: Impact of disruptive technologies on the incumbent technology (adapted from

Christensen, 1997)

2.2 Software Product Approach

Software products involve distinct factors and characteristics impacting competitiveness. The

purpose of this chapter is to describe these competitive factors and assess their competitive

implications.

Literature Review



17

2.2.1 Software Product Characteristics

Competition in software products can be described as including short product life cycles,

intense competition, uncertainty, technological discontinuity, changing and growing customer

requirements, and globalization (Cusumano, 2004; Hyvönen, 2003; Hitt et al., 1998; Hitt &

Bettis, 1995; Baker, 1998). As a result, companies have had to react with an emphasis on

innovation, efficient and improved production, faster time to market, and information sharing

and learning (Cusumano, 2004; Athey, 1998; Hoch et al., 1999; Hersleb & Moitra, 2001). The

value system of production is complex because of the range of industries it impacts, but we can

make a simplification according to Hyvönen (2003). The general value system consists of

upstream component producers and outsourcing suppliers delivering software to integrators who

then distribute products downstream.

Software as a product can be described as an information good because it is intangible (Shapiro

& Varian, 1999). This leads to costly initial production, and high fixed costs, but once ready,

reproducing is essentially free. These result in the marginal costs of production moving close to

zero and the marginal revenues growing in pace with the market share, as seen in figure 8.

Figure 8: Development of the marginal cost of software production (Adapted from Shapiro &

Varian, 1999)

Software being an intangible good also leads to issues in differentiating products because

copying is easy (Hoch et al., 1999). Comparing the processes of development and production,

the distinction with manufacturing industries is substantial. Highly knowledge-intensive

development (Armour, 2000; Shapiro & Varian, 1999; Hoch et al., 1999) implies that the most

critical parts are not only processes, but the experience and knowledge of personnel and

companies (Cusumano, 2004; Armour, 2000). Because of the importance of human capital,

there is no way to automate the development process (Hoch et al., 1999).

Literature Review



18

To understand the investment in software product related R&D, the expenditure by some of the

top companies during the year 2004 is presented in figure 9.

Figure 9: Examples of the R&D expenditure by some of the top companies, related to software

production (Technology Review, 2005)

The R&D expenditure of these companies’ sums up to an investment of over $32 billion,

however, a part of it is related to hardware development. Similar R&D expenditures in software

intensive industries during 2004 include the telecommunication sector investment of over $26

billion and electronics and consumer electronics industry’s expenditure of over $30 billion.

2.2.2 Competitive Implications

The characteristics of software as a product lead to the following distinct factors impacting

competitiveness.

For product businesses intellectual property rights (IPR) are a major component of

competitiveness (Nambisan, 2001). IPR is defined as the legal and exclusive ownership of

distinct technology implementations. Companies can use different forms—trade secret, patent,

copyright, and trademark—of IPR to protect their investment and differentiation from

competitors. However, this does not totally solve the issues of copying, as IPR can be

circumvented with non-infringing yet similar implementations. The importance of IPR can be

seen through the enormous patent holdings of companies such as IBM or Microsoft or hardware

vendors such as Nokia. (Nambisan, 2001; Hall, 2003; Messerschmitt & Szyperski, 2003)

Network externalities are a common factor in software related products, as they can form a

virtual network through shared characteristics or functionality. The externalities arise if there is

a complementary relation between the adaptations of the product by different users, impacting

Literature Review



19

the incentive for new users to also adopt the product. Typical examples are communication

products, operating systems, and products that store information. Metcalf’s law proposes an

estimation that the value of a network to one user can be proportional to the number of the other

users. Particular network externalities in software related product markets can be split into two

categories: direct network externalities arise if utility from using a good is directly increased

when other people use this good; and indirect network externalities arise from the availability

and the price of complementary goods. The bigger the network is, the more there are

complementary products and services, and therefore the lower the prices are. If network

externalities are strong, then each user wants to adopt the product which has the biggest network

to appropriate as much value as possible resulting in a positive feedback system or “virtuous

cycle”. (Shapiro & Varian, 1999)

Customers and suppliers are also prone to lock-in. As users and suppliers invest in durable

systems, products, and competence, they acquire high switching costs and it is easier for them to

continue relying on the same product. Lock-in can be introduced by e.g. contractual

commitments, training, learning, and the formation of experience and information. Through

product lock-in, installed user bases are a valued part of competitiveness, and managing and

leveraging lock-in has been a key contributor to the success of companies. (Shapiro & Varian,

1999; Baker, 1998; Nambisan, 2001)

De facto standards are an influential part of product businesses as these are the technologies

that achieve an accepted dominant design in the market. They can form a substantial element in

competition, as products adhering to the de facto standard have a higher chance of succeeding in

the market. This influences costs as products must adhere to the standards, but can also

constitute competitive advantages if companies are able to create and control them. Competition

in many products markets has moved towards competition between systems and not individual

products, where standards have a key role in compatibility. For product companies it is of the

utmost importance to be a part of the de facto standard system and have a relatively good

position in this system. (Shapiro & Varian, 1999; Baker, 1998)

Competitiveness and entry barriers are also based on high initial and continuous investments in

R&D, customer feedback and knowledge, brand recognition, technology lead, and distribution

channel creation (Cusumano, 2004; Nambisan, 2001; Messerschmitt & Szypenski, 2003).

Literature Review



20

2.2.3 Software Layers and Platforms

Software generally consists of layers and modular components, which serve each other and

comprise a total system (Messerschimtt & Szypenski, 2003). A generalization of the layered

form of software can be presented as figure 10.

Applications

Service Layers

Core Technology Dependant Layer

Generic Abstraction Layer

Applications

Service Layers

Core Technology Dependant Layer

Generic Abstraction Layer

Figure 10: General layered form of software products (Adapted from Messerschmitt & Szypenski,

2003)

The layered structure and the nature of software lead to enhanced commoditization of

technologies over time. This is a result from copying of features, stiff competition, and software

characteristics. The proven technologies and components are common across competition and

cannot therefore function as differentiation. This leads to commodity software that we define as

components that cannot be used to differentiate products, but are still necessary for a complete

product. For companies who have invested heavily and continue to invest in these technologies

or components, commoditization is a substantial threat to their business and a continuous issue.

(Cusumano, 2004; Shapiro & Varian, 1999; Augustin et al., 2002)

A recent strategic approach to product businesses, due to the layered form of software, has been

the concept of product platforms or product families. This can be associated to either a software

base that is used to produce derivate products (Meyer & Selinger, 1998) or a platform driving an

ecosystem of products (Gawer & Cusumano, 2002). A product platform can be defined as a set

of subsystems and interfaces that form a common structure from which a stream of derivative

products can be efficiently developed and produced (Meyer & Selinger, 1998; Meyer & Mugge,

2001). This has improved competitiveness with the ability to cut costs, speed up development,

lower risk, and target distinct markets with differentiated products and more precision

(Robertson & Ulrich, 1998; Meyer & Zack, 1996; Meyer & Selinger, 1998).

Gawer and Cusumano (2002) recognized the advantage of driving an ecosystem and enabling

innovation on the complementary applications of the platform, or the components and

subsystems included in the platform itself. Companies can integrate the external innovation

Literature Review



21

ability in a precise scale to their products. This enables the company to expand the market by

leveraging external efforts. The maximum benefit is derived if the complementary product

market is commoditized (Shapiro & Varian, 1999), as this drives up the value of the platform.

2.3 Software as Production Process

The purpose of this chapter is to describe the production process of software and illustrate the

competitive implications.

2.3.1 Software Production Characteristics

The production process can be a defining firm-level activity in company competitiveness.

Software as a logical element is clearly distinguished from producing hardware, because of its

knowledge intensiveness and complexity (Pressman, 2004; Brooks, 1987). It is more of a rule

than an exception that software productions are delayed, overrun cost estimates, produce low

quality, and fail to fulfill customer requirements (Standish Group, 1995; Pressman, 2004;

Haikala, 2001).

Because of these issues, various production processes have been defined as the “establishment

and use of sound principles in order to obtain economically software that is reliable and works

efficiently” (Pressman, 2004). The goal of software processes is simply to create an advantage in

the production process. The process can be broken down to three generic phases to describe the

whole life cycle: definition (system analysis, project planning, and requirement analysis),

development (software design, coding, and software testing), and maintenance (change,

correction, adaptation, and enhancement) (Sommerville, 2001; Pressman, 2004).

2.3.2 Competitive Implications

In spite of the different process models, in practice all of them suffer from the same challenges.

For competitiveness, the keys for production processes are reducing time-to-market and cost of

software, producing feature-rich and high quality products, and controlling the high risk

resulting from sunk costs and customer need uncertainty (Poulin et al., 1993).

The software life cycle cost consists of all the expenses accumulated from the start of the

development until the end of maintenance. This can be illustrated by the figure 11.

Literature Review



22

Figure 11: Cost of software during whole life cycle (Haikala, 2001)

The figure only illustrates how much of the resources are spent on the certain part of the life

cycle, but it doesn’t explain any reasons for these commitments. Boehm (1988) divided the

distribution of costs into four groups: development and rework; code and documentation; labor

and capital; and by phase and activity. A notable part in the continuous cost of software is the

effect rework has on it. This is needed to compensate for bad design, to fix errors in the code, or

not satisfying the customer needs (Pressman, 2004; Denning, 1992). Labor-costs are a key part

because of the nature of software production and the huge gap between the productivity of the

best and average developers, ranging to even 100 fold differences (Boehm, 1981). By phase and

activity, the most cost intensive parts are testing and maintenance, which belong to the end of

the software products life cycle. To understand the cost of software, Boehm (1988) also

presented the value chain of development (figure 12).

Figure 12: Software production value chain (Boehm, 1988)

Literature Review



23

It is evident that the most important part of software costs is introduced during the operations

part, which consists of 80% of the value chain, but a fairly small part of this is direct code

implementation. (Boehm, 1988; Haikala, 2001; Pressman, 2004)

Development time is defined by the size of the product and the resources available to complete

it. Size can be measured by methods including source lines of code (SLOC), or effort in man

years or hours (Armour, 2002). Dividing the size, regardless of the metric, with the resources

results in the time or effort development takes. However, due to the nature of software, this

relation is non-linear, as tripling the amount of resources does not cut down the time into one

third as seen in figure 13 (Armour, 2002).

Figure 13: Effort-time curve of software production (Armour, 2002)

2.4 Open Source Software

OSS is software distributed under open source licenses making the source code of executables

available for redistribution and modifications. The purpose of this section is to examine OSS

based on three characteristics —licensing, development model, and commercial OSS—and to

examine the disruptive impact and opportunity OSS creates.

2.4.1 Open Source Licensing

Copyright protects the original software creation and derivative work by granting the creator the

exclusive right to control the resulting work and enables the licensing model. The owner of the

copyright is the author, or the company whose resources were used to create the software.

However, only written code is protected, not technical innovations or algorithms. (Fink, 2003;

Ruffin & Ebert, 2004)

The main difference between OSS and proprietary software is the licensing model. In licensing

there are two important roles: the licensor as the owner or distributor of the software and the

Literature Review



24

licensee as the software’s user either as an end-user or another developer. Typically the licensee

has to buy the license from the licensor to gain the right to use the program. These licenses

usually deny the right to distribute, modify, or re-engineer the software. However, the open

source definition states that you can freely use, modify, or distribute the software, if you attain

to the restrictions of the open source status (Open Source Iniative, 2002).

2.4.1.1 Open Source Licenses

OSS licensing tries to make software free and ensure that the source code is available. Some

licenses introduced later on have, however, moved away from the original intention, and do not

force people to make the source available, such one license is the Netscape Public License

(NPL). Software can also be licensed under more than one license, which leads to the licensee

choosing the license terms they prefer, with typically an option between an OSS license and a

commercial license. (Fink, 2003)

The most widely used open source license is the GNU General Public License (GPL). The GPL

requires that every modification made to software under GPL and distributed, must also be

available under the same license. This includes all derivative work, so it is enough if software is

linked to code licensed under GPL to cause this “viral” effect, which can also be called the

“copyleft” attribute. It does not, however, mean that if there is closed code running in a product,

which also includes code under GPL that all the code must be made available under the same

license. (Fink, 2003; Capek et al., 2005)

The GNU Lesser General Public License (LGPL) is a lighter version of GPL. It does not

mandate the licensing of software that dynamically links to code under LGPL. This enables use

of the code under LGPL, without the problems of opening the source code of your own software

that links to it. However, direct modifications to software under LGPL must be published under

the same license. (Fink, 2003)

The open source initiative (OSI) has approved a total of 58 licenses as official OSS licenses.

The essential differences between these licenses are related to commercial usage and in what

ways and how widely it is allowed. The difference between some OSS licenses is illustrated in

the table 1 (Perens, 1999).

Literature Review



25

Table 1: Open source licenses and attributes (Perens, 1999)

License

Can be mixed

with non-free

software

Modifications can be

taken private and not

returned to you

Can be re-

licensed by

anyone

Contains Special

privileges for the

original copyright

holder.

GPL No No No No

LGPL Yes No No No

Berkley System

Distribution

license (BSD)

Yes Yes No Yes

NPL Yes Yes No Yes

Mozilla Public

License Yes Yes No No

Public Domain Yes Yes Yes No

2.4.1.2 Legal Risks and Challenges

For companies using OSS there are evident legal risks. OSS typically has many authors and is

developed in a collaborative and informal manner by people with no legal relationship. It is

nearly impossible to later on know reliably whether the person granting a license has the right to

do so. This complexity may cause unintentional copyright or patent infringements. The issue

exists with all software, but with OSS it is much easier to detect the infringement as an external

and it is more likely to happen. (Capek et al., 2005; Ruffin & Ebert, 2004)

The proliferation of OSS licenses is also a problem. None of the licenses have actually been

scrutinized in court and the legal robustness and completeness vary, e.g. licenses are unclear on

their relation with IPR. There are also cases of software projects mixing different licensing

together that are not compatible, resulting in legally faulty licensing that would in all likelihood

be hard or impossible to interpret in court. (Capek et al., 2005)

2.4.2 Open Source Development

The open source community is an international group of people contributing in a mixture of

ways to open source projects. The size of the community has grown significantly with, for

example, one open source repository Sourceforge hosting over 60,000 projects with around

620,000 registered developers in 2003 (Bonaccorssi & Rossi, 2004) and the number growing to

over 1.3 million developers and 115,000 projects during 2006 (Sourceforge). The community

Literature Review



26

has produced diverse software such as Apache, Sendmail, BIND; scripting languages PERL,

Python, PHP; operating system components Linux Kernel, Gnome, KDE; and applications like

Mozilla, GIMP, and GNU software (Benussi, 2005; Schweik & Semenov, 2003; Kogut &

Metiu, 2001).

There is no clear definition of a community participant as the variety goes from unemployed

hackers to people working full time in companies, working on OSS either as a part of their job,

or in their own free time. (Feller & Fitzgerald, 2000; Pavlicek, 2000; Lerner & Tirole, 2002)

The motivation of these developers can be split between extrinsic, i.e. related to indirect

satisfactions, and intrinsic, i.e. directly filling the needs of developers. Extrinsic motivations

include gaining a reputation among other developers (Dalle & David, 2004; Lerner & Tirole,

2001); enhancing career opportunities by proving development skills (Lerner & Tirole, 2004);

learning new skills and technologies (Krogh et al., 2003; Ye & Kishida, 2003); gaining

contributions to development projects (Raymond, 1999); fulfilling technical problems (Feller &

Fitzgerald, 2002); direct monetary rewards (Lerner & Tirole 2000; Hertel et al., 2003); and

because of low opportunity costs of working on OSS, as developers have nothing to gain from

keeping their work proprietary (Bonaccorsi & Rossi, 2003a). The general intrinsic motivators

are enjoying the creation of something (Lakhani & Wolf, 2003); altruism resulting in

satisfaction from helping others, and battling against proprietary software companies

(Raymond, 1999).

2.4.2.1 Development Principles

There is no official model or process of development in the open source community. However,

it can be described regarding characteristics related to the organization, development process,

and control of projects. (Feller & Fitzgerald, 2002)

Unlike any formal organizations, open source communities have zero formal timelines,

deliverables, or requirements. The collaboration is arranged through the Internet with tools to

help the information flow and to ease the development process. The decision making of

collaboration follows a decentralized model, where the core maintainers and developers have

the most influence over the decisions. (Mockus et al., 2000; Feller & Fitzgerald, 2002; Fink,

2003; Krogh, 2003)

The development process is highly parallel with developers working on small components of

larger subsystems. Parallel development makes it possible for developers to collaborate in a

Literature Review



27

distributed manner and utilize a rapid release pattern. The intention is to keep the incremental

process of development going on as fast as possible and to release new versions every time

software has been modified. Because of this rapid release cycle, the community can use rigorous

peer review. Developers and users continuously review the work of others, which can enhance

the development process to produce faster evolving programs. The collaborative model also

enables the intellectual knowledge of thousands of developers globally to be combined. (Feller

& Fitzgerald, 2002; Mockus et al., 2000; O’Reilly, 1999; Raymond, 1999)

2.4.2.2 Impact of Development

According to several authors (Feller & Fitzgerald, 2000; O’Reilly, 1999; Scacchi, 2002) the

open source development model produces better quality, faster growth, more creativity, and

cheaper software, than closed-source production.

Mockus et al., (2000, 2002), Jorgenssen (2001), Ding-Tong & Bieman (2004), Paulson et al.,

(2004), MacCormack et al., (2005), Stamelos et al., (2002), Godfrey and Tu (2000), Koch

(2005), and Kuan (2000) have argued and provided empirical proof from various projects that

OSS included fewer defects than proprietary software, the speed at which found defects are

fixed is substantially faster, the software evolves faster, and is of high modularity. To give

perspective into the growth of open source systems Amor-Iglesias et al., (2005) measured

Debian as one of the largest software systems in the world, despite its young age, at 5 times the

size of Windows XP. Stamelos et al., (2002), Paulson et al., (2004), and Schach et al., (2002)

however have found contradicting proof that OSS is lagging behind industry quality standards

and the speed of development is in no way faster than closed software development.

The open source development has also received direct critique. Caoiluppi et al., (2003) and

Healy and Schussman (2003) have noticed that the majority of projects are small, with 50%

consisting of only one or two developers. This indicates that developers are a scarce resource

and only the most successful projects gain a critical mass. Some authors have also accused OSS

of lacking in usability and customer focus. Nichols & Twidale (2003), Nichols et al., (2001),

and Levesque (2004) have argued that there is a usability problem due to developers

concentrating only on the needs of developers. Security of open source software has as well

been of concern to the software industry because of the open approach (Levy, 2000; Viega,

2000). Payne (2002) contradicted the arguments by stating that OSS can be more secure due to

the heavy peer-review and the speed that defects are fixed with.

Literature Review



28

Scacchi (2002) has summarized that the development model is not an irrational version of the

traditional approach, but instead a private-collective approach to development, which can

provide better results in the right environment. The advantage in cheaper, faster, and better

development is dependant on the target product, used tools, and if the information needed is

well suited for the OSS process.

2.4.2.3 Innovation Model

The innovation model of OSS has been proposed as a novel “private-collective” model (Von

Hippel & Krogh, 2003; McKelvey, 2001). The model is based on private resources invested into

a collective pool, unlike the prevailing models where either, parties invest to gain commercial

returns or public goods produce innovation due to a forced common innovation pool. The

private-collective model is argued to be more efficient, to produce valuable innovations for

smaller costs, and to achieve more useful results than the prevailing models. Users as innovators

are an important part of the proposed model according to Von Hippel (2001). Open source

fulfills the conditions—incentives for users to innovate, to reveal innovations freely, and

innovation diffusion by users—that are necessary for such innovation to take place. Klincewicz

(2005) has, however, challenged the innovativeness of open source development by arguing that

the mass of OSS projects exhibit low levels of technical novelty.

2.4.3 Commercial Open Source

The emergence of OSS to a market populated by commercial software can have an impact on

the value of products. Value is derived from the features, and this value goes down over time

because the features become common among products. As OSS enters a market, the speed at

which the devaluation happens, can be in relation to the features included in the OSS (Figure

14).

Figure 14: OSS impact on the value of commercial software (Fink, 2003)

Literature Review



29

As a result, the time over which value is derived can be shortened and the revenues gathered

from the product lowered. In practice this can mean that software becomes a commodity as fast

as the community is able to produce an OSS substitute. This would imply that from a

commercial viewpoint the most critical impact of OSS is commoditization (Fink, 2003).

However, it is still not completely clear how profit and non-profit production interact. Khalak

(2000) and Gaudeul (2003) proposed that in despite of the characteristics of OSS, the impact on

commercial software is dependant on the software’s ability to gather a critical mass of the

customer base; OSS includes a wide range of shortcomings compared to commercial products;

and customers do not judge products only on their monetary cost.

As evidence of the commodity status of OSS, the business models built around it concentrate on

gaining revenues from complementary products. These business models gather revenues from

support, custom development, training, and consulting or enabling hardware sales, e.g. the

models of Red Hat Software, O’Reilly, and Cygnus solutions (Fink, 2003; Henkel, 2004).

2.4.3.1 Recent Open Source Diffusion by Commercial Parties

As a result of the diffusion of OSS utilization by companies and contributions to open source

projects, the investment in OSS has been growing steadily. Examples in 2005 include Sun

Microsystems (2005) licensing their Solaris 10 operating system under an open source license,

IBM opening 500 patents for free utilization with OSS (IBM, 2005), and committing 100

million dollars to OSS (Vunet, 2005). Hewlett-Packard has also funded foundations such as the

Eclipse Foundation, Gentoo Linux, Gnome Foundation, Open Source Development Labs

(OSDL, 2006), and KDE and contributed to projects including Apache, Debian, Handhelds.org,

and Samba amongst others. During 2005, there was also a movement to solidify OSS utilization

with industry wide collaboration resulting in Alliances like SCOPE including the companies

Nokia, Ericsson, Siemens, Motorola, and NEC collaborating to encourage open source

utilization, and IBM, Novell, Philips, Red Hat Inc., and Sony forming a patent-holding company

to further enhance open source development.

2.4.3.2 Commercial Motivation Drivers

Commercial parties have a range of business drivers to be involved with the OSS community.

OSS especially offers cost and time related opportunities. Madanmohan and De’ (2004) propose

that companies leverage OSS to gain faster access to markets. The use of open source

components considerably shortens the product development time. Companies see similar

advantages in leveraging the OSS code base to cut down the costs of development (Fink, 2003;

Literature Review



30

Goldman & Gabriel, 2005; Aoki et al., 2001). Dahlander (2004) also proposed that an incentive

is the ability to leverage the inventive and R&D actions of the community. This also enables

the companies to access the work of others involved with OSS. West (2003) recognized that

firms release source code in order to get their product widely adopted, and therefore as

adaptation increases they gain a better chance of attracting developers and can accelerate the

technological development of their products. Cutting into the cost of maintenance is also

possible by shifting the cost to the community (West, 2003; Hawkins, 2002).

Companies see OSS also as a tool to gain benefits not directly related to cost or time. Lerner and

Tirole (2002) proposed that parties value the opportunity to enhance the ability of OSS to

reduce the market shares of dominant software firms, and therefore establish independence

from price and licensing policies. Fink (2003) presented the need of companies for talented

resources. This has pushed companies to stay involved in OSS as the developers have the

knowledge of the open source programs and could be valuable if hired. Feller and Fitzgerald

(2002) propose involvement can be used as a way to improve the image of the corporation and

the brand and make a better impression with customers and investors. Osterloh et al., (2002)

also proposed that companies are ultimately involved with OSS only to keep the active

cooperative relationship alive. They see the community as an important part of the future of the

industry and therefore they invest resources in interacting with the community.

A third category of business opportunities is the ability to impact competition. Goldman and

Gabriel (2005) recognized the ability of OSS to act as a tool to form standards. Open code and

a wide circulation of the software are effective forces to form a standard. Standardization with

OSS is less likely to suffer from politics, and the decision making is more likely to center on

technological issues. Some companies also take part in OSS activities to commoditize parts of

commercial solutions (West, 2003; Wichmann, 2002). By providing no-cost offerings they

force the competition to play a commodity game. This is beneficial for the companies that are

on a higher layer of the software stack and can differentiate or gain revenues there.

2.4.3.3 Commercial Involvement and Openness Strategies

The ability to leverage the community to appropriate value is dependant on the strategic

approach the company takes to interacting, managing, and utilizing the available resources

(Dahlander & Magnusson, 2005; Bonaccorsi & Rossi, 2003b). Dahlander and Magnusson

(2005) and Madanmohan and Krishnamurthy (2005) have proposed a three-way categorization

to the different involvement approaches companies can take to OSS utilization.

Literature Review



31

The lightweight approach has been to directly tap into the OSS asset and utilize this either

directly or as internally modified in products. This approach includes no continuous effort to

contribute work back to the community and concentrates only on the short-term benefit.

The second category is implemented through a more commensalistic approach. The

commercial party takes and utilizes OSS, and tries to keep the modifications of software

minimal to stay in synchronization with the community. However, the involvement is kept as

small as possible with very little effort going back to the community, and the goal is not to

benefit the community in any way, just to avoid harming it from continuing work. Because of

the synchronization with the community, the company can appropriate benefits in a continuous

manner, but have very little ability to control or impact the development.

The third category is based on actively collaborating to and participating in the work the

community does. With this approach companies typically have direct involvement with the

community and continuously contribute by sponsoring, contributing software, or even

developing communities around their own software. The OSS asset can be considered as an

extension of the companies’ resources and result in the most efficient development.

Companies can also follow different structural openness strategies that impact their ability to

benefit from OSS. These different strategies can take three forms based on the work of West

(2003). Companies can decide either to make openly available layers of the product or to

concentrate on utilizing open source licenses for distinct technology components. Opening

layers of the product results in the company enabling efficient development in that area, but also

possibly loosing control of it. Again, the strategy to make available distinct components retains

a higher level of overall control, but benefits less from development. A third possible structural

approach is to utilize the openly available architecture provided by the OSS community and

base R&D on it. These strategic approaches can be illustrated with the following figure 15.

Figure 15: Software product categorizing according to level of openness and opened parts (West,

2003)

Literature Review



32

2.4.3.4 Challenges of Corporate Open Source

Collaborating and integrating the open source development into commercial operations poses

problems and issues with defining the community, communication, expectations, and typical

OSS practices.

Long (2003) and Dahlander and Magnusson (2005) identified various challenges companies

faced when managing open source communities and projects. Authority structure was the most

significant problem identified. Companies usually have the last say in decisions regarding

development, code acceptance, and roadmap. This breaks the collaborative model, which causes

friction between the community and the company. Another problem existed with property

rights. Companies usually enforce some kind of licensing model on the development project,

which again goes against the principles of the community. Often developers voice harsh

criticism on issues regarding copyright ownership and licenses, and due to the discontent stop

developing for the project. The third major challenge was community building. This is because

the effort needed to build the community is often neglected. The norms and values of the

community are also a challenge. These protect the community from depletion and are usually in

conflict with the norms of a company. Aligning the nature of the work and getting acceptance to

use the software for commercial purposes also causes issues as commercial interests differ a

good deal from the communities’ interests. If these challenges are not managed, companies lose

the advantages possibly gained through the OSS development activity.

Many authors (Bonaccorsi & Rossi, 2003b; Osterloh et al., 2002) have proposed that the most

significant issue for commercial parties is adhering to the open source norms and rules. The

culture follows a certain set of norms including trust, collaborative thinking, and sharing of

innovations, which must be followed to be accepted as a part of the community. Exploiting the

existing pool of software more than you contribute back still enlarges the pool and raises the

level of motivation for open source producers. It seems that for accepted entrance, the level of

effort can be limited to the minimum and still it is acceptable from the communities’ viewpoint

(Bonaccorssi & Rossi, 2004).

An important challenge is also unintentional information revealing. Companies working with

OSS can accidentally open source software, which includes important IPR, and which is thus

revealed. The copyleft attribute of some OSS licenses can also enforce this revealing, when

code is used in combination with these licenses. (Fink, 2003; Ruffin & Ebert, 2004)

Literature Review



33

2.4.3.5 Strategic Disadvantages of Open Source Utilization

As companies choose to utilize OSS as a part of their product strategy, they are confronted with

strategic disadvantages due to the open availability of the software and the licensing terms of

copyleft licenses mandating openness.

Foremost, this results in the loss of IPR as protection from competition. Both software coming

from the community and made available under open source licenses are openly available. This

implies that the software alone can provide no competitive advantage, it looses most of its sale

value, and there is a risk of loosing the development control. Business models concentrating on

complementary products, bundled with software, are as well subject to disadvantages due to

competition providing the complement with less cost or higher quality. (Henkel, 2004)

Judging the loss of competitive protection and advantage is, however, not directly possible, as it

is dependant on the degree of competition, relation of the software to the external domain,

availability of alternatives, and the level of specifity of the software for the company (Henkel,

2003; Harhoff et al., 2003; Johnson, 2004). The external environment evidently defines the

competitive implications of utilizing OSS. As certain IPR is made openly available and the

competitive value of it is neutralized, the value of specific IPR is inflated (Goldman & Gabriel,

2005). This impact of collaborative development by commercial parties has been realized by the

Embedded Linux producers, and lead to an environment where differentiation is hard and the

value of specific IPR has grown enormously.

2.4.3.6 Open Source in Products Theory

Literature has presented two generic strategies that work as the basis for utilizing OSS in

product development. Companies can choose to either bundle OSS with proprietary software or

dual license the products. Companies choosing to bundle the two types of software typically

make a distinction between the open source and the closed source part (Figure 16).

Figure 16: Generic product strategy for combining OSS and proprietary software (Pal &

Madanmohan, 2002)

Literature Review



34

There is no rule to the ratio of open and closed source, but a higher open source ratio typically

signals more benefits but also stronger strategic disadvantages. (Pal & Madanmohan, 2002)

The second generic product strategy is based on dual licensing. In this setting, the commercial

party can continue to sell the software but they can also leverage the community effort to

develop it. If the software is licensed under an open source license, the licensee is typically

forced to license all derivate work under identical terms. The commercial company is therefore

able to maintain control of the commercial usage and development. This forces commercial

users of the software to pay royalties, so that they can keep products that have been modified or

bundled with proprietary software secret. However, dual licensing has certain constraints,

because it is impossible to leverage the effort of the community on a larger scale as software

must be initially self-developed. For third party contributions from the open source

development, the copyright must also either be assigned to the copyright holder or licensed

under terms that are broad enough to enable commercial and non-commercial usage. (Fink,

2003; Henkel, 2003)

2.5 Summary of Literature Review Findings

The goal of this section is to summarize the factors related to the industry level impact;

competitive opportunity resulting from OSS characteristics; and existing firm-level strategies.

2.5.1 Disruption and Maturity

The OSS asset has achieved a higher level of maturity and we can conclude that OSS is a

gradually strengthening industry wide disruption. The software industry is in a transition phase

with commercial parties increasingly recognizing, reacting to, and leveraging the opportunity

presented by this disruption. This happens through heterogeneous collaboration strategies,

defined as direct competitors adapting distinct strategies—full closed source, dual licensing,

direct utilization, or collaborative development—to leverage the OSS asset. The result also

creates a positive feedback system, further increasing the value and maturity of the OSS asset.

The maturation is evident in the diffusion of developers working on OSS, which is estimated at

over 1.3 million, and the dozens of commercial parties investing in the software asset. However,

OSS still exhibits the following identified limitations and characteristics: there is no single

defined development process or output of the development model; a large part of the projects

have only few contributors and do not incorporate the benefits of a strong collaborative

Literature Review



35

development model; and the features of OSS concentrate on the infrastructure or middleware

layers and not the user interface (UI) or tested end-user solutions.

The characteristics and limitations break the impact into two groups. A part of the projects are

still inferior to commercial software, and the assumption of maturity is just an illusion brought

forth by some extremely successful products and the community evangelists. The second

category of mature or active OSS projects rival closed-source products in quality, growth, and

innovation and have a commoditizing impact on the value of software. Through this impact, it is

possible that layers of software stacks are devalued. For commercial usage OSS can only be

considered commodity software, as it doesn’t create customer value through differentiation, but

by matching quality at lower costs. We can conclude the important characteristic of OSS

impacting software product companies in the following table 2.

Table 2: Characteristics of the OSS community impacting software product development

Factor Definition Impact

Community

Growth

The community has reached 1.3

million developers

The resource pool is large enough to

impact the industry

Commercial

Investment

Continuous diffusion of

commercial investment to the OSS

asset

Substantial growth of the value in the

OSS asset and proof of changing

development approach

Software Maturity Part of the OSS asset has reached

commercial quality

Directly usable for product

companies, causing continuous

devaluation

Development

Concentration

Concentrated on the lower layers of

the software stacks and generic

technologies

Opportunity for commercial value to

reside in higher layers or specific

implementations

Commercial

Value

Commodity software due to

openness and relatively low

innovativeness

Does not create product

differentiation, but reduces costs with

equal quality

2.5.2 Firm-Level Strategies Model

As a consequence of the characteristics of OSS and software commoditization, companies can

apply different levels of external collaboration to match the external environment. This can be

presented relative to the level of differentiation software technologies can offer and the level of

Literature Review



36

collaboration with external parties in R&D (Figure 17). The three strategies move from intra

company development, collaboration with gated OSS communities, to total openness.

Figure 17: Software development in relation to the domain of differentiation and external

collaboration (adapted from ITEA, 2003)

Collaborative R&D depending on the strategic approach brings benefits in the form of faster

access to markets, smaller initial and continuous investment in R&D, ability to interact with

experienced and talented resources, and a positive relationship with the community. This can

also impact competition with shorter technology life cycles, moving software faster to the

commodity level and impact the creation of de facto standards. However, collaborative R&D

also features problematic issues and disadvantages, e.g. collaboration between a commercial

party and the community is not trivial; OSS utilization causes challenges in the legal domain

because of a risk of infringing copyright or patents as well as putting the companies own IPR at

risk; and the reduced advantage and protection of IPR mitigates competitive advantages and

diminishes the effect of network externalities and lock-in.

This model works as the basis of the rationale for collaborative R&D. The company attempts to

balance collaborative R&D and its benefits in certain software areas, without risking their

competitiveness in the industry environment. The rationale for the high rate of collaboration can

be based on the level of competition and commoditization moving differentiating software to a

minor part of total products. It must be noted that commoditization in software is a complex

topic, and in some areas the assumption of non-differentiating software can be false, but for the

sake of the framework we make the assumption that the presented model is applicable.

Literature Review



37

We can summarize the advantages and disadvantages of the different firm-level strategies in the

following table 3.

Table 3: Advantages and disadvantages of different firm-level strategies

Internal Development Gated Community

Development Open Development

Advantage

- IPR

- Lock-in

- Systems competition

-High entry barriers

- Reduced maintenance

cost

-Impact on value of

software

- Interaction with

competent resources

- Reduced initial and

continuous investment

- Faster time-to-market

- Direct relationship with

OSS asset

- Impact on industry software

value

- De facto standardization

Disadvantage

- Cost of software

- Time-to-market

- Risk

- Commoditization

- Reduced impact of IPR

- Issues in collaboration

- Challenges in legal domain

- Reduced impact of IPR

- Issues in collaboration

Collaborative R&D Framework 38



3. COLLABORATIVE R&D FRAMEWORK

The goal of this chapter is to create a framework describing the impact of collaborative R&D on

competitiveness and detailing the firm-level strategies. The framework takes a top-down

approach by first presenting the impacts on competitiveness and then describing the firm-level

strategies to achieve them.

3.1 Relative Competitive Advantages

Resulting from collaborative R&D, companies can create relative advantages during the

transition phase of the industry. The advantages are relative, because they depend on the state

of the industry and competition exhibiting heterogeneous collaboration strategies.

Collaborative R&D can reconfigure the internal value chain and the whole value system of

product development to concentrate both the investments and competition to certain areas. The

result is a better configuration between the internal competencies of the company and their

match with the external environment. This is achieved through:

• Defining the value of software in relation to the industry environment;

• Reconfiguring and integrating the external development resources with collaborative

R&D in non-differentiating software; and

• Continuously managing the interface of non-differentiating and differentiating software.

Because of heterogeneous competencies, collaboration strategies, and common technologies in

different product markets, the reconfiguration can result in three relative advantages. Firstly, the

internal investment is concentrated on value creating software and processes resulting in

heightened efficiency. Secondly, collaboration moves software value to the OSS asset and

commoditization continuously impacts the value of software increasing the value of owned

competencies and technologies. Thirdly, the changed cost structure and commoditized software

enable the expansion of the scope of existing competencies to new markets with improved

efficiency. The OSS asset mitigates the differences between companies.

During the transition of the industry, early collaboration can lead to a first-mover advantage.

With the increasing value of the OSS asset and the previously defined relative advantages, it is

possible that part of the industry gradually moves to homogenous collaboration strategies.

Collaborative R&D Framework



39

Competing companies would utilize similar strategies and the same communities and

technologies from the OSS asset. This could lead to a reconfiguration of the forces impacting

the industry, e.g. OSS as the main supplier, entry barriers, substitutes, buyer power, and rivalry.

In the resulting industry, the state of the first-mover advantage from early utilization, pre-

emption of OSS resources, and maturing of collaboration processes, could lead to higher

benefits than late-comers can gain.

The evident limitation is that collaborative R&D does not directly impact the creation of

definable internal advantages in the form of resources or other holdings. It concentrates on

leveraging firm-level activities to gain the most value of existing or otherwise developed

competencies in relation to the industry environment.

We can summarize the advantages and their dependency on the industry phase in the following

table 4.

Table 4: The advantages and their industry phase dependency resulting from collaborative R&D.

Advantage Industry Phase Definition of Advantage

Concentrate

Investment on Value

Creation

Transition

Optimized match of internal and external

competencies, results in concentration of

investment on value creation.

Increase Value of

Internal Competencies Transition

Commoditization and collaborative R&D

increase the value of particular competencies.

Expanding Scope of

Competencies Transition

Higher efficiency in leveraging existing

competencies.

First-mover Advantage Transition &

Reconfigured

Advantage from efficient collaboration in

transition to collaborative R&D.

3.2 Strategic Split Based on Software Value

To be able to leverage collaborative R&D, product software must be split into two strategic

areas based on the differentiating value. This is necessary because the areas follow different

firm-level strategies. This enables companies to manage the strategic disadvantages resulting

from collaborative R&D and gain the maximum benefit.




40

3.2.1 Non-Differentiating Software

The firm-level strategies of non-differentiating software development aim at reconfiguring the

value chain. These strategies follow a specific form of collaboration and result in lower initial

and continuous investment, reduced transaction costs, creation of de facto standards, social

capital, and a first-mover advantage.

3.2.1.1 Collaboration and Value from Existing Communities

The form of collaboration with existing communities is considered upstream vertical

integration mostly based on informal relationships. The internal R&D is extended to be a part

of the external R&D with a continuous two-way flow of software, investment, and effort as

illustrated in the figure 18.

Open Source Software Asset

Commercial Parties

Commercial Parties

Commercial Parties

Commercial Parties

Commercial Parties

Commercial Parties

Vertically IntegratedProduct Development

SoftwareEffort

Investment

Product SoftwareDevelopment Effort

Open Source Software Asset

Commercial Parties

Commercial Parties

Commercial Parties

Commercial Parties

Commercial Parties

Commercial Parties

Vertically IntegratedProduct Development

SoftwareEffort

Investment

Product SoftwareDevelopment Effort

Figure 18: Vertically integrated collaborative R&D

The flow back to the OSS asset is necessary to share the maintenance cost of software; initiate

the collaborative R&D on technologies not yet present in the OSS asset; and hasten the

commoditizing impact on the value of software.

Vertical integration to the upstream OSS asset does not only impact the initial and continuous

investment. As expected, through integration with the OSS asset, the commercial transaction

costs related to software development are reduced. The reduction can be seen in the ability to

utilize openly available development tools, directly interact with the original authors, and seek

highly competent resources, as well as the increased flexibility of not needing to depend on

certain software suppliers. These result in searching costs being considerable lower; contractual




41

costs having less importance, as work is done on an informal basis; more flexibility in situations

of uncertainty and market changes; and reduction of enforcement costs.

Collaborative R&D also has a tendency to enhance the creation of de facto standards due to

openness, low cost, and easy diffusion. This has two valuable implications for competition.

Firstly, in the case of a standard emerging, the company will have a beneficial position in the

created system and raise the value of their internal competencies. These competencies can be

e.g. technology knowledge or IPR related to the standard. Secondly, the creation of de facto

standards increases the amount of effort put into to the OSS asset and therefore directly impacts

the collaborative R&D. The amount of effort can follow the positive feedback system of de

facto standard creation.

3.2.1.2 Social Capital and Experience Curve

In collaborative R&D both the specific OSS communities as well as the commercial party have

ownership of social capital. The capital owned by both parties contributes to the impact of

collaboration.

Social capital common to the community comprises of its relationship to both OSS developers

and commercial parties. This social network defines the R&D capability of the community. It is

vital to integrate with communities, which have a large social network. An important factor is

that the network includes commercial parties as well as individual developers, because they

typically have large resource pools to invest from.

The company specific social capital with the chosen communities can build differentiation and

grow the efficiency of development. Enabling time and cost reductions through the OSS

community is not a trivial task, because of the informal relationship between parties. Through

this interaction there is a level of social capital built in e.g. the formation of direct relationships,

taking part in community decision making, or even hiring or contracting developers from the

community. As a result of the social capital, the commercial party may be able to exert control

over the community, acquire information otherwise hard to gain, and reinforce the

community from external parties, with all factors differentiating from competition.

The process of collaborative R&D can also lead to a cost structure similar to an experience

curve. The continuous development internally apart from the OSS asset is not a trivial task to

manage in parallel. As the process of collaboration matures, the ability to utilize the




42

collaborative R&D can rise, resulting in an experience curve. This leads to an advantage over

competition utilizing the same communities as collaboration is bound to the internal processes,

people, and their relationships with the community.

Social capital and the experience curve can be considered as important parts of the first-mover

advantage during the transition of an industry. Both factors can result in competition not being

able to match the positive results of collaboration.

3.2.1.3 Created Communities

In specific software areas the firm-level strategy can also be based on creating a new

community. This approach is used when components do not fit into the scope of existing

communities or have a strategic meaning in de facto standard creation around company

contributed software.

A self-created community can impact competitiveness but it may also feature disadvantages due

to uncertainty and complexity. The created community can follow the principles of total access

and open availability to all parties, or it can be a gated community with only the company and

chosen parties having development rights. A self-created community can result in the reduction

of maintenance costs, pre-emption of resources to develop company specific software, a first-

mover advantage, and be used to create and lead a de facto standardization effort. However, the

ability to retain these benefits depends on the ability to gather developers and commercial

parties to invest in the development of the community.

3.2.1.4 Summary of Non-differentiating Software

We can summarize the factors related to non-differentiating software and the impact on

collaboration and competitiveness in the table 5.




43

Table 5: Factors in non-differentiating software and their impact on collaboration and

competitiveness.

Factors in Non-

differentiating software Impact on Collaboration and Competitiveness

Form of Collaboration Two-way flow of investment enables collaborative R&D in

continuous development

Commercial Transaction

Costs

Vertical upstream integration reduces the costs of search,

uncertainty, contractual issues, and enforcement

Standardization Creation of standards can raise value of firm-level advantages and

increase the collaborative effort

Community Social

Capital The social capital of the communities defines the R&D capability

Company Specific Social

Capital

Social capital can build differentiation and enhance the R&D

efficiency

Experience Curve Maturing of processes, impacts the cost structure of collaboration

and creates a first-mover advantage

Created Communities

Reduced maintenance cost, pre-empts development resources to

create a first-mover advantage, and ability to lead standard

creation

3.2.2 Differentiating Software

The firm-level strategy of differentiating software development aims to create value in addition

to the collaborative R&D. The drivers of competition are the creation of specific proprietary

software leading to differentiated products and the ability to leverage the firm advantages. The

two key factors are the software control points and the value of the productization process. It

must be noted that the value chain of proprietary development is not altered by collaborative

R&D.

3.2.2.1 Software Control Points

Because of the impact of commoditization relatively few areas of software products are able to

create differentiating value and leverage firm advantages.

Through particular software control points the company can exert competitive control and create

sustained differentiation. The control points implement distinct technologies such as UI

features, data formats, algorithms, or protocols. These are the software areas where customer




44

value is created and the company exerts total control. Ultimately these are bound to the

sustained advantages because they:

• Contain legal protection;

• Contain technologies that are a part of de facto standards;

• Form virtual networks of products; or

• Create customer switching costs and lock-in.

The creation of software control points should in all cases include IPR, unmatched customer

knowledge, or technological lead. Despite the disadvantages of collaborative R&D, the control

points can both create sustained barriers for a large part of the competition as well as leverage

the competencies, the value of which is increased.

3.2.2.2 Productization Process

In despite of the collaborative R&D, product development carries a large investment. As shown

in chapter 2.3.2, the value chain of software products includes a substantial amount of cost

drivers that are not associated with code implementation or testing. These are not impacted by

collaborative R&D. Collaborative R&D also introduces modified cost drivers in the form of

legal and IPR due diligence. These quantify the existing gap between collaborative R&D and

producing end-user products.

Competitively this gap presents the ability to manage the disadvantages of collaborative R&D

and create value in excess of the OSS asset. Potentially areas such as code implementation,

testing, and design are impacted by collaborative R&D, but this covers approximately 60-80%

of the cost drivers. The management process, legal due diligence, operations such as

requirements and detailed design, quality assurance, integration, and supporting activities are

still complete cost drivers. Therefore the software operations can be a differentiating factor, as

either optimizing these cost drivers or reconfiguring them can result in differentiation.

3.2.2.3 Summary of Differentiating Software

We can conclude how the factors related to differentiating software both manage the

disadvantages of collaborative R&D and create added value in the following table 6.




45

Table 6: Rationale on how differentiating software create value

Competitive Factor Rationale to Manage Disadvantages and Create Added Value

Creation of Proprietary

Software Collaborative effort has little impact on development cost and time

Software Control

Points

Ability to create advantages through particular control points

leveraging IPR, standards, or lock-in and control competition

Productization Process Existing gap between collaborative R&D and end-user ready

products creates value

3.3 Collaboration Framework Summary

The collaborative framework can be summarized on both the firm-level and the industry-level.

The firm-level strategies during the transition phase of the industry, resulting benefits,

differentiation, and relative advantages are presented in the figure 19.

Split based on

softwarevalue

Relative Advantages-Concentrate on Value

Creation-Increase Value of Internal Advantages

-Expand Scope of Competencies-First-Mover Advantage in Industry

Transition

Existing Communities- Form of Collaboration

- Transaction Costs- Community Social Capital

-Company Specific Social Capital- Experience Curve

- De Facto Standard Creation

Created Communities-Attract Community Investment

-Gated or Open Community

-Software Control Points-Productization Process

-Software Control Points-Productization Process

Open Software

Closed Software

Existing Communities-Initial and Continuous Investment Reductions-Faster Time-to-Market

-Higher Efficiency Collaboration-First-mover Advantage in

Collaboration

Created Communities-Reduce Maintenance Cost

-First-mover Advantage-Create or Lead De Facto

Standardization

Benefits

-Leverage Existing Advantages-Competitive Control

-Remaining Cost Drivers

-Leverage Existing Advantages-Competitive Control

-Remaining Cost Drivers

Differentiate

Firm-Level Strategies

Value Creation-Controlled and Sustained Value on Top

of Collaborative R&D

Value Creation-Controlled and Sustained Value on Top

of Collaborative R&D

Figure 19: The firm-level strategies and resulting relative advantages

The evolution of the industry competition can be presented in the three different phases—

previous, transition and resulting—in figure 20. The impact of collaborative R&D can lead to

redefining the industry competitive forces. With this change the only resulting advantage would

be the first-mover advantage from collaborative R&D.




46

Industry-Level Competition

Previous IndustryPrevious IndustryAdvantage

IPRLock-in

Systems CompetitionHigh R&D Investment

Resulting IndustryResulting IndustryHomogenous Collaboration

StrategiesNewly Defined AdvantagesFirst-Mover Advantage in

Collaboration

Industry TransitionIndustry Transition

Competitive IssuesCost of SoftwareTime-to-Market

Commoditization


Commoditization

Closed Source Collaborative

Relative AdvantageConcentrate on Value

Expand ScopeImpact Value



SubstitutesSubstitutes

Entry BarriersEntry Barriers

SuppliersSuppliers Buyers

Buyers SuppliersSuppliers



BuyersBuyers

Changed SupplierStructure


Changed Entry BarriersChanged Entry Barriers

New SubstitutesNew Substitutes

New Buyers

New Buyers

Industry-Level Competition

Previous IndustryPrevious IndustryAdvantage

IPRLock-in

Systems CompetitionHigh R&D Investment

Resulting IndustryResulting IndustryHomogenous Collaboration

StrategiesNewly Defined AdvantagesFirst-Mover Advantage in

Collaboration

Industry TransitionIndustry Transition


Commoditization


Commoditization

Closed Source Collaborative







SuppliersSuppliers Buyers

Buyers SuppliersSuppliers



BuyersBuyers



Changed Entry BarriersChanged Entry Barriers

New SubstitutesNew Substitutes

New Buyers

New Buyers

Figure 20: Impact of collaborative R&D on the industry-level competition

Case Studies 47



4. CASE STUDIES

4.1 Design and Case Selection

The goal of the case studies is to research implementations of collaborative R&D, and assess the

framework by seeking empirical validation, feedback, and criticism. Therefore the appropriate

approach is a descriptive case study, to produce and analyze relevant data to illustrate the

chosen cases (Yin, 2003).

The selection of the case is a crucial part of the case study approach. In selection, the concept of

a population is important, because it defines the set of entities from which the research is

conducted on. Also the selection controls the generalization, limitations, and expandability of

the research. (Eisenhardt, 1989)

According to Yin (2003), multiple case studies are more likely to lead to better results and a

higher level of expandability, which is considered true even for a population of two cases. This

also gives the opportunity to directly compare the results of the separate cases. Based on these

rationales the multiple-case approach was chosen.

There are not many companies at this point utilizing OSS in the scope of the study, which

enforces a constraint on the case population. This is why the design only uses two cases. As

both case studies concentrate on analyzing a single company and its product, the design is a

holistic view (Yin, 2003). The phenomenon is researched only regarding the target company

and no sub-units inside the company are used.

4.2 Objectives and Methods

The main objective of the case studies is to examine the impact on competitiveness of

collaborative R&D. This objective can further be split into the following sub-objectives:

• To assess the validity of the proposed framework;

• To analyze how the firm-level strategies impact competitiveness; and

• To provide quantitative measures for the advantage of collaborative R&D.

Case Studies



48

In practice the case studies follow the top-down model proposed by the framework. First, the

overall competitive context and overview of the company are presented, and then the

collaborative strategy is assessed in more detail according to the strategic split. Finally, the case

is analyzed in whole based on the presented data.

The methods used in the study are comprised of open-ended interviews with key people in the

organization or industry specialists, active participant observation, and analyzing quantitative

data acquired through web sources and archival records. The sources for the case studies are

presented in Appendix 1. The interviews were open-ended discussions related to OSS utilization

and dependant on the interviewee’s position. Therefore the used interview protocol was adapted

depending on the interviewee. The overall protocol is specified in Appendix 2.

The tools of Wheeler (2001) and Boehm (1981) were adopted to both analyze the software

structure and estimate the value of the collaborative R&D. The software details of OSS,

proprietary code, and company created OSS were gathered from the companies dedicated

development sites. For the Nokia case, the details are based on the total size of all the

components published, calculating the size of patches contributed by Nokia, or the difference

between original and modified source files, and comparing these to the total size of the product

software stack. The total software stack size was acquired from comparing the OSS SLOC to

the byte size of the complete product software and calculating the difference between these two.

The maintenance structure is based on the amount of unmodified software or components in

synchronization with communities. In the case of Apple, the details were derived from the

published sources and then analyzed according to differences in respect of the original source

code, when and which versions of the components were taken from the communities, or if the

code was unmodified. The maintenance structure was based on the amount of unmodified or

components taken numerous times from open source communities. All of the source code

details include a medium level of uncertainty, due to some components having insufficient data

to analyze their origin and amount of modifications, with precision.

The value of collaborative R&D was estimated based on the total amount of source code and

calculating the COCOMO cost of this software. The basic COCOMO model (Boehm, 1981) is a

tool to estimate the total effort, schedule, and cost of software based only on the SLOC. This

model uses pre-defined parameters to provide a simple estimation. As it does not take into

account the different aspects of the development projects and their complexity, the accuracy is

limited, and could be enhanced with more detailed parameters. The resulting COCOMO cost

was then multiplied with 0.6 to match the impact of OSS on 60% of the value chain of

Case Studies



49

development and then with the researched percentual share of OSS code of the total software

stack.

It should be noted that for a comprehensive view on the whole phenomenon, a significantly

larger amount of different cases would have to be researched. Also the focus is on the specific

areas of software R&D and collaboration. The total competitive dynamism and strategies are

outside the scope of the case studies.

4.3 Case study 1: Internet Tablet Software Edition 2005

4.3.1 Overview & Approach

The first case analyzes Nokia’s approach to OSS utilization in development of a software

product for handhelds. Nokia is a world leader in the mobile phone and networks infrastructure

industry, but also known for its competence in software technologies. The hardware products of

Nokia utilize both proprietary software and a licensed software platform. For Nokia, the

creation of a novel product and the collaborative R&D strategy has meant two changes. Firstly,

the expansion of existing competencies to a new market, as the product does not include cellular

connectivity and is aimed to match competitive PDA products. Secondly, an opportunity to

configure Nokia’s internal competencies in software development with the external

environment.

Internet Tablet Software Edition 2005 (ITSE2005) was first made public in May 2005. Four

months later the first hardware product that uses ITSE2005, called Nokia 770 Internet Tablet,

was published. The primary software competition for ITSE2005 includes Montavista Linux

products that provide an OSS based distribution for handhelds; Trolltech Qtopia, which is a UI

toolkit for handheld products; Palmsource Palm OS that is a full proprietary handheld operating

system (OS); and Windows CE which is also a proprietary OS. The competition can be divided

to proprietary products (Windows CE and Palm OS), products dual licensed under OSS and

proprietary licenses (Qtopia), and products based on utilizing the OSS asset (Montavista).

There are also some OSS substitutes available, which however are not at a maturity level, where

they could be considered as commercial alternatives.

4.3.2 Software Characteristics & Split

ITSE2005 is a combination of OSS, Nokia developed OSS, proprietary software, and third party

software components. The architecture is not defined into an OSS area and a proprietary area, as

Case Studies



50

components are placed together on all the general software layers. The strategic split is based on

creating the generic kernel and system or application services utilizing OSS, and only

developing proprietary parts in areas such as the UI and state management. The utilized OSS

software includes a variety of mainstream OSS projects. The high-level list of these projects

includes the Linux Kernel 2.6, Debian package management, X-window, GNOME framework

(GTK+, Dbus, Gconf, Gstreamer, and gnome-vfs), BlueZ connectivity stack, and a variety of

OSS application engines. The development has also been based on tools such as GCC,

Scratchbox, and GDB among others.

The total software stack includes 10.5 million lines of code (product and development tools),

which is split into 85% coming directly from OSS, and 15% either modified or developed by

Nokia. In source code lines the respective amounts are 8.9 Million lines of OSS code and 1.6

million lines of Nokia developed software. Out of the 15% created by Nokia, 50% are made

available to the community as modifications to components or totally new components, leaving

roughly 7.5% of the software stack closed.


Nokia has decided that the least value can be created from the generic kernel, system utilities,

application services, multimedia framework, and UI toolkit. These components share two

evident factors contributing to this approach: they are considered as the basic building blocks of

handheld software products, and therefore common across competition; and these are the

technologies, where the OSS asset includes mature and actively developed components.

The form of collaboration with the OSS asset happens via two channels: maemo.org, the

dedicated development site for the ITSE2005 as a self-created community; and direct vertical

integration with existing communities.

4.3.3.1 Self Created Community

Community Software Flow

The self-created community has been public since May 2005. The community concentrates on

the development of the integrated OSS and the Nokia created UI toolkit components. The

integrated components are periodically released to the community, with long periods of no

visibility to development. The UI components, on the other hand, are continuously developed in

the open, but in a gated community with only Nokia employees able to commit changes to the

software.

Case Studies



51

To date, the community has submitted 405 bugs and enhancement ideas and less than 5 relevant

software contributions. The interaction with the community has inputted useful data in fewer

than 10 occasions to support the development. There have also been zero commercial

contributions.

Community R&D Efficiency

At this point in time, it appears that the effort has not lead to efficient collaborative R&D. This

is due to Nokia not being able to attract a critical mass of contributing developers or commercial

parties, and because of the non-transparent development with the community. However,

especially in the case of the specific UI toolkit components, it is too early to judge if the strategy

has the ability to create beneficial collaborative R&D.

4.3.3.2 Existing Communities

Form of Collaboration

The collaboration with existing communities has followed a form of continuous integration

from the start of development. Nokia has invested effort in contributing software to the OSS

asset as well as funding to communities or individual participants of these communities. Some

of the components have been modified to a large extent, but through the continuous software

flow back to the community, the development has stayed in synchronization. This has left Nokia

in a situation where the mass of their software is maintained in the communities, and

collaborative R&D can be utilized to evolve the components. To illustrate the opportunity in

maintenance, the available versions of some components at the start of year 2006 can be seen in

the table 7. In each of these components, the community has produced both improved

functionality as well as fixes for defects.

Table 7: Comparison of component versions used and available in the OSS asset

Component Used Version OSS Asset Version

GTK+ 2.6.4 2.8.10

GStreamer 0.8 1.0

D-bus 0.23 0.6

Matchbox manager 0.9.4 1.0

Bluez 2.15 2.24

Linux Kernel 2.6.12 2.6.15

Case Studies



52

Community Social Capital

The core communities that Nokia has chosen to integrate with possess large networks of

developers. The GNOME community alone is comprised of over 600 developers with more in

the specific component communities included in the GNOME framework. The Linux Kernel

community has been characterized as including over 1000 contributing developers, and the

Debian community also has close to 1000 dedicated developers.

More importantly, the commercial investment in these communities is substantial. The Linux

Kernel alone gains contributions from companies such as Hewlett-Packard, IBM, Red-Hat, and

Novell. GNOME also receives a stream of investment from the same companies in addition to

Sun Microsystems and Google. The development tools utilized by Nokia, such as GCC, also

harvest a large amount of investments.

It seems that based on the accumulated social capital of these communities with both open

source developers and commercial parties, they are an efficient source of R&D and collect a

substantial amount of investment.

We have continuously worked in collaboration with the OSS projects that we utilize in our

product, which has meant that our software contributions have been integrated into the

mainstream projects. This combined with the work the community has done by their own in the

projects, results in a situation where we can very easily upgrade our software just by taking the

new releases of the projects and integrating them. –Senior project manager-

Open source provides us really a flexibility where we can keep up a continuous stream of

development and upgrading, which cannot really be matched by closed-source production –

Senior Product Manager-

Commercial Transaction Costs

The reduction in commercial transaction costs due to the collaborative R&D is evident. Nokia

has utilized freely available tools that ease the development restraints; has direct interaction

with members of the communities; and most importantly, they have easily found proven

resources to develop the openly available software, which in many cases have been the authors

or main contributors to the components. Examples of this have been companies like Fluendo

with Gstreamer, Openedhand with Matchbox, and Imendio with GNOME.

This impact can be seen in reduced searching costs, flexibility in situations of uncertainty

regarding software implementation or sudden need for resources, and motivated external

Case Studies



53

developers requiring less enforcement costs. Nokia has also employed developers who have

been important parts of the GNOME community, lowering the searching costs for internal

resources, as well.

The advantage of utilizing openly available and modifiable development tools and processes is

a big part of the benefit of our strategy. This removes many bottlenecks which typically hinder

product development. –Operation Director-

When utilizing OSS components, we can just look at the source code and find out who is the

original author of the component. This makes it very easy to find the competent people who

have the best knowledge of these software components. –Software Project Manager-

De Facto Standard Creation

As an emerging phenomenon in 2006, Palm/Access, a direct competitor for ITSE2005,

announced that they will be basing their future products on the same software components and

communities as Nokia. This includes the GNOME framework with GTK+ and Gstreamer as

well as the Linux kernel. Montavista also leverages the same kernel community.

This signifies that the technologies and communities chosen by Nokia are gaining commercial

validity and possibly forming a de facto standard for handheld products. However, it must be

noted that these technologies can still not be considered as an industry standard and the impact

of this phenomenon cannot be assessed in detail within such a short time frame.

Company Specific Social Capital

The social capital between Nokia and the core communities, mainly GNOME and Debian,

seems to exist because of Nokia actively participating and funding the communities, Nokia

developers being active members of the communities, and members of the communities being

either employed by Nokia or contracted for services.

Based on this social capital, Nokia has been able to impact the software decisions of the

community and therefore exert some control on the development to push forward in areas of

importance, e.g. the growing interest of the GNOME community for handheld software. Nokia

has also gained access to technical information otherwise hard and costly to acquire through

informal contacts and relationships.

It also appears possible that Nokia is able to create barriers from competition because of their

first-mover advantage in collaborative R&D and the social capital built between the parties.

Case Studies



54

These factors can result in a maintenance cost structure in line with the experience curve. This

structure is bound to the resources of Nokia, the community, and the maturing of the process of

development and therefore not directly duplicatable by competitors.

4.3.4 Investment Structure

Based on the COCOMO model we can estimate the value of the utilized OSS to be

$228,000,000, including both product software and tools. We can present the initial and

maintenance investment structure with figure 21. This is based on the software developed in the

collaborative R&D or internally (grey area denotes percentual amount developed internally and

not taken from the OSS asset or made available to the OSS asset).

Kernel

Applications

User-Interface

System utilities

Deve

lopm

ent T

ools

9%

61%

21%

52%

Kernel

Applications

User-Interface

System utilities

Deve

lopm

ent T

ools

9%

61%

21%

52%

Kernel

Applications

User-Interface

System utilities

Deve

lopm

ent T

ools

54%

12%

100%

Kernel

Applications

User-Interface

System utilities

Deve

lopm

ent T

ools

54%

12%

100%

Figure 21: Investment structure of ITSE2005 during initial development on the left and continuous

development on the right

The important factors from these figures are the following:

• Through the form of collaboration and the high amount of the software available for

collaborative R&D, Nokia is able to utilize collaborative R&D in the areas it deemed as

providing less differentiating value.

• The investment structure is well aligned with the split of Nokia’s software

competencies, the context of the collaborative R&D, and common across competition

areas in handheld software.

Based on these facts, the collaborative R&D seems to be able to deliver efficiency in

development of the chosen software areas, enable the reconfiguration of the value chain, and

concentrate the investment on software that is deemed as competitively valuable.

Case Studies



55


Software Control Points

The differentiating software is spread vertically among the software stack. The specific control

points are the UI, connectivity protocols, power management, and multimedia technologies such

as video and audio features. These control points share four key factors: Nokia holds existing

IPR or competencies in these areas; they are considered different between competitive handheld

products; implementation is investment-heavy; and they can create customer lock-in, virtual

product networks, and implement de facto standards. In contrast, e.g. the core system

technologies are an area where Nokia holds very little IPR. Through these control points it is

possible for Nokia to exert control over the whole product, even though they only implement a

minority (under 5% percent) of the source code lines.

It is obvious that a high rate of OSS lowers the barriers for competitive entry, but because of

our strong advantages in certain software areas, components and products, this is not a

competitive problem. –Software Architect-

Anyone can take all the OSS and make a product out of it, but it’s just not so simple. You need

to have valuable contributions to the market through your own investment, which is always true.

–Operation Director-

Productization

In despite of the collaborative R&D, the development of an end-user handheld software product

contains a variety of cost drivers that are not altered. As handheld software is utilized in

resource constrained hardware products, the importance of optimization, product design,

integration, and testing grows, and all these factors exist as cost drivers for productization.

Collaborative R&D enables Nokia to concentrate their investment on the processes important

for product creation and fitting to their competencies and not those of the OSS community.

Nokia has also decided that the whole integrated product is not made available freely because of

the value it carries, which will enable them to leverage the value in productization. Competitors

are forced to integrate the parts from the existing communities in the similar manner as Nokia

did and continues to do.

Case Studies



56

Utilizing OSS is really not a way to solve all your competitive and operational issues, but it is a

tool to ease some bottlenecks. –Operation Director-

OSS can efficiently move the competitive concentration to other areas of software operations

than they were previously. In the context of your strategy and goals this can really be a huge

advantage. –Senior Product Manager-

4.3.6 Analysis

Framework Validation

The case of Nokia provides validation for the core theories of collaborative R&D impacting

competitiveness through investment on value creation and expanding the scope of

competencies. We can summarize the supporting and contradicting evidence in the following

list:

• The strategic split of software enables Nokia to reconfigure the development value

chain to match the internal competencies and external environment.

• A significant initial and continuous cost reduction is achieved, because of continuous

vertical integration with large communities gaining from OSS and commercial parties

as well as reduced transaction costs.

• Some of the chosen technologies are emerging as de facto standards.

• Nokia is able to create value on top of the collaborative R&D with software control

points and the productization process.

• The created company specific social capital and the maturing process of collaboration

between Nokia and the communities can be seen as a differentiator, based on a first-

mover advantage and as contributing to the efficiency of collaborative R&D.

• The present impact of the self-created community is minimal due to the uncertainty of

attracting developers and commercial parties.

Case Studies



57

Industry Comparison

The industry is in the transition phase exhibiting heterogeneous collaboration strategies. In this

environment Nokia is able to create relative advantages compared to all parties depending on

their strategies.

• Compared with proprietary development, Nokia is able to concentrate their investment

on value creation, impact the value of competencies, and create a first-mover advantage.

• In comparison to Trolltech’s approach of dual licensed software, Nokia’s advantage

comes in the form of more concentration on value creation, impacting the value of

competencies, and creating a first-mover advantage.

• In the case of Montavista and their approach that is similar to Nokia, the relative

advantage comes in the form of more efficient concentration on value creation because

of more synchronization with existing communities.

As the industry is in the transition phase, Nokia’s strategy has an impact on the value of

software and company competencies, and thus forces the competition to react. Based on the

existing competition utilizing OSS and the move of Palm/Access to leveraging OSS, this seems

to be happening already. However, this movement is not the result of Nokia’s strategy alone.

Because of Nokia’s first-mover advantage it is possible that they will hold an advantage in

future collaboration. However, this cannot be determined yet due to the short time frame.

4.4 Case study 2: Mac OS X

4.4.1 Overview

The second case concentrates on the collaborative R&D of Apple Computer Inc. in their Mac

OS X operating system and Mac OS X Server (Mac OS X). Apple is one of the global leaders in

manufacturing personal computers, software, and peripheral devices. All of the company’s

computer and server products utilize Mac OS X.

Mac OS X was first released in 1999. After this initial release, 5 major upgrade releases have

been made with version 10.0 in 2001 to 10.4 published in 2005. The direct software competition

comes from Microsoft Corporation in the form of Windows and Windows based servers, Sun

Microsystems with their Solaris Enterprise System and servers, and the various OSS offerings

from the GNU/Linux families and the BSD families. The OSS competition includes a variety of

commercial companies, such as Novell with SUSE Linux and Red Hat Inc. with Red Hat, and

community produced products such as Debian. Mac OS X therefore has competition that is

Case Studies



58

proprietary (Windows), commercial but made available for the OSS community (Solaris) to

leverage the maintenance advantage, and originated from the OSS asset by either commercial

or non-commercial parties (SUSE, Red Hat, Debian amongst others).

4.4.2 History and Strategic Approach

The history of Mac OS X leads back to 1996 when Apple bought NeXT Software for roughly

$400 million. The main part of this sale was the ownership of NeXTSTEP the OS, which was

heavily based on OSS—4.3 BSD and the Mach kernel 2.5—, and subsequently formed the base

of Apple’s development leading to Mac OS X. The rationale behind this approach was that

Apple had software competencies in UI design and interaction, but technically the base of their

existing OS had grown old and was never considered reliable. Because the need for a new OS,

Apple would have had to license an external product if they had not opted for buying

NeXTSTEP. This enabled Apple to stay competitive without developing a totally new product,

stay independent of a software supplier, and utilize their existing competencies.

As NeXT had developed their OS by leveraging OSS, Apple inherited this approach. Apple

chose to utilize OSS to configure their internal competencies with the external environment and

to concentrate their investment on value creation.

4.4.3 Software Characteristics & Split

The evolution of Mac OS X has included a range of BSD components as the core of the product.

The main points of this history can be shown in the figure 22.

Mach Kernel 2.5

4.3BSD

NeXTSTEP 1.0 (1989) Rhapsody DR2 (1997)

4.4BSDLite 2

NetBSD 1.3

FreeBSD3.2

OpenBSD2.5

NetBSD1.5

Mac OS X 10 (2001)

Mach Kernel 3.0

Mac OS X 10.4 (2005)

FreeBSD5.21

Mach Kernel 2.5

4.3BSD

NeXTSTEP 1.0 (1989) Rhapsody DR2 (1997)

4.4BSDLite 2

NetBSD 1.3

FreeBSD3.2

OpenBSD2.5

NetBSD1.5

Mac OS X 10 (2001)

Mach Kernel 3.0

Mac OS X 10.4 (2005)

FreeBSD5.21

Figure 22: Software evolution history of Mac OS X

From the original software in NeXTSTEP, Apple has evolved the product by integrating parts

from NetBSD, OpenBSD, FreeBSD, and adding a new version of the Mach kernel. Ultimately,

as development on the Mach kernel was abandoned by the community, Apple developed their

own kernel called XNU that included pieces of Mach and BSD kernels. During the life cycle of

Case Studies



59

Mac OS X, Apple has also decided to utilize other OSS communities not associated with BSD,

as they have added MYSQL, Apache, Rsync, and Samba amongst others. Apple’s development

has also been based on OSS tools such as GCC, Perl, Python, GDB, and Ruby.

The architecture of Mac OS X comprises of two parts, the Darwin Core and Apple’s proprietary

application services and UI. The strategic split has been implemented by focusing the

development of the core technologies in the collaborative R&D and leaving the higher levels of

the product for internal development. However, as an exception, the engine of Safari browser

has also been developed with the OSS community, even though it is included in the otherwise

proprietary application parts of the product.

The Darwin core and the OSS development tools consist of 17 million lines of source code. This

can be split in 80% developed by the community and 20% created or modified by Apple. In

source code lines, these amounts are 13.6 million lines of OSS and 3.4 million developed by

Apple. The numbers do not include the software details for the proprietary closed layers.


Apple identified the Darwin core as the competitively less valuable area where collaborative

R&D could be used. This includes the kernel, device drivers, file systems, networking

functionalities, and other general system utilities. It is evident that this split is based on both the

OSS asset’s concentration of mature and high quality technologies in these areas as well as

these technologies commonly being shared between competitive products and thus not offering

the ability to create competitive value.

The collaboration has been implemented through two channels. Firstly, The Apple developer

site and Opendarwin.org, a community site dedicated to open source development of Darwin,

have been used as a channel to create a community that is directly working on the Darwin core,

and secondly, direct collaboration with existing communities.

4.4.4.1 Self-created Community

Community Software Flow

The self-created community has varied in size, since it’s founding in 2002, with the most

interest gathered during the first two years. At the peek of the community, the amount of active

developers could be estimated at around 150. However, a share of nearly 10% of these

developers was always Apple employees. The source code of Darwin is only made available for

Case Studies



60

developers when a product release is made for customers as well, resulting in long times of no

development visibility for the community.

The contribution flow back to Apple from the community has included roughly 500-700 defect

reports and 300 software commits. Also modifications from Opendarwin have been integrated

to the main software by Apple employees, but this number can be assumed to be relatively low

based on the overall effort on Opendarwin.org. The community activity has almost completely

died in the last year, resulting in close to zero contributions coming back to Apple. The last

release at Opendarwin.org is based on the OS X v. 10.3.2, which is close to two years old. This

is mostly a result of the community not having enough resources to stay up with the internal

development of Apple and the failure in attracting enough mass to contribute to the effort.

The Darwin team has some developers who have originally started as pure OSS hackers, but

have proved their competence in the community and joined the Darwin team afterwards.

–Darwin Developer-

Collaborative R&D Efficiency

It seems that Apple has not been able to benefit from a collaborative effort due to non-

continuous development. The community is not able to keep up with the development and

therefore can not contribute value to Apple. There has also been zero commercial interest into

contributing to Darwin. The community has not been a valuable source of collaborative R&D

and the impact has been in the form of resource hiring and positive PR. This, however, makes

the assumption that the flow through the Apple employees in the Darwin community has not

been substantial enough to change the result of R&D efficiency.

4.4.4.2 Existing Communities

Form of Collaboration

Direct collaboration with existing communities has included varying strategies. Originally

during NeXTSTEP development very little synchronization with the core communities,

especially the BSD communities, was done, which resulted in the software being branched from

the collaborative effort. With kernel technologies Apple developed their own kernel based on

BSD and Mach kernels, which is not in direct synchronization with collaborative R&D, and

therefore is almost exclusively maintained by Apple.

Case Studies



61

Close to the first release of Mac OS X, Apple started to actively contribute work to the

FreeBSD project. Every Mac OS X release since is in synchronization with the matching

FreeBSD releases, as versions 3.2, 4.5, 4.8, and 5.21 have been utilized as the base (table 8).

Table 8: Mac OS X releases and synchronization with FreeBSD

Max OS X release FreeBSD release Date

10.1 3.2x October, 2001

10.2 4.5x October, 2002

10.3 4.8x October, 2003

10.4 5.2x April, 2005

The synchronization effort has, however, been a result of Apple hiring BSD developers to do

internal work, and these employees keeping the internal and external development in

synchronization. It appears that through this informal flow of software, Apple is able to leverage

the FreeBSD development. However, software originating from OpenBSD and NetBSD is still

partially maintained by Apple.

In addition to the core BSD and abandoned kernel communities, Apple has continuously

worked with Apache, Samba, GCC, J-Boss, Rsync, and MySQL communities that provide

important features of Darwin. This work has followed a form of collaboration where the Darwin

development version stays in synchronization by contributions to the collaborative effort or

avoiding forking and therefore easing maintenance. As proof of this work, Darwin has grown by

close to five million lines of source code in the last 3 years with the growth concentrating on

additions from these communities and not the core technologies from BSD.

We continuously recycle projects to the community and again back to our products. Through

this symbiotic development we can implement a development model unlike anything we could

in-house have accomplished. –R&D Senior Manager-

Community Social Capital

The communities Apple chose to collaborate with can be split into two categories based on their

social networks. In the core technologies, the FreeBSD community is actively developed by

roughly 500 developers and the Mach kernel community has been abandoned during the 90’s.

Up to date Apple is the only major commercial party involved in these communities and

therefore Darwin does not gain from commercial investments through these communities. It

Case Studies



62

seems that FreeBSD offers Apple an efficient source of R&D, but suffers from lacking other

commercial contributors.

However, the other communities such as GCC, Apache, Samba, and MySQL have gathered

both active OSS communities and more importantly gain a continuous investment from

commercial parties such as IBM, Hewlett-Packard, Novell, Suse, Nokia, and MySQL. The

amount of OSS developers varies from Apache with close to 100, to Samba and Rsync

estimated at close to 40 developers. It is evident that these communities are a source of effective

collaborative R&D due to community characteristics and commercial investment.

Through the Open source we gain access to contributions of other commercial companies.

-Senior product manager-

Commercial Transaction Costs

Apple has also gained from reducing the transaction costs of development. The Darwin core is

totally built on freely available development tools that ease the bottleneck of working with

commercial parties and can be modified when necessary. Apple has also had direct technical

discussions with BSD communities, but more importantly roughly ten of the core BSD and

Mach kernel developers have been hired by Apple to work on Darwin.

These activities prove Apple’s ability to lower searching costs for competent resources,

enforcement costs, and in uncertain situations lessen the burden of contractual costs in

development or resource hiring.

We have utilized open tools such as GCC which form the foundation of our development work.


The Darwin team has some developers who have originally started as pure OSS hackers, but

have proved their competence in the community and joined the Darwin team afterwards.


De Facto Standard Creation

Mach kernel and the BSD technologies have not been able to achieve a status of de facto

standards and therefore this does not impact Apple’s competitiveness. However, some of the

less crucial components, such as Apache, can be considered as a de facto standards, where

Apple mostly benefits from the large collaborative effort the components gain through their de

facto standard status.

Case Studies



63

Company Specific Social Capital

Considering the social capital built between Apple and the existing communities, the main link

is the hired developers. Through these resources, Apple has access to the source trees of

FreeBSD, information on technical issues, and ability to impact the decision making of

development. As core developers of the community are bound to Apple, the efficiency of

development is enhanced when compared with other companies. It appears that a first-mover

advantage, based on the experience in the process of collaborative R&D and the internal and

external people being apart of this process, more than likely leads to costs of maintenance

exhibiting similar to an experience curve like structure.

With other communities other than the core BSD, there are more influencal parties included,

which is the case with e.g. Apache, diminishing the role of Apple and resulting in minimal

social capital. However, there are existing relationships and processes to work with these

communities, pointing towards an advantage in the efficiency of collaborative R&D.

4.4.5 Investment Structure

Based on the COCOMO model the total cost of internally developing the OSS included in the

Darwin core and the used development tools would be $350,000,000. This gives a rough picture

of the value of the effort in collaborative R&D. The value does not, however, take into account

that this development has spread over a longer period of time and is not split into initial

development and the maintenance part of development. The initial and maintenance investment

structure can be illustrated with figure 23, presenting how the software is spread into closed and

collaborative R&D (grey area denotes percentual amount of software developed internally on

the left or not made available for the collaborative R&D on the right).

Kernel

Applications

User-Interface

System utilities

Deve

lopm

ent T

ools

10%

95%

40%

34%

100%

Kernel

Applications

User-Interface

System utilities

Deve

lopm

ent T

ools

10%

95%

40%

34%

100%

Kernel

Applications

User-Interface

System utilities

Deve

lopm

ent T

ools95%

100%

100%

40%

Kernel

Applications

User-Interface

System utilities

Deve

lopm

ent T

ools95%

100%

100%

40%

Figure 23: Investment structure of Mac OS X during initial development on the left and

maintenance development on the right

Case Studies



64

The following factors are evident from these figures:

• Because of the form of collaboration and the initially chosen kernel community, Apple

is forced to carry the investment burden for software deemed as non-differentiating.

• In regard to the system utilities Apple is able to move a large part of the maintenance

cost to the collaborative R&D.

• The investment structure is not well aligned with the split of software value, the context

of collaborative R&D, and the value in the external environment.

Concluding on these facts, the investment structure is not the optimum regarding the

opportunity provided by OSS and the external value of software. Even though making openly

available a large part of their software, Apple continuously invests into non-differentiating

software, and fails to fully reconfigure the value chain.


Software Control Points

Apple’s software control points are positioned into the UI design and toolkit, and provided

applications. These applications include e.g. social networks and content services owned by

Apple and multimedia features. Most importantly, the control points are based on Apple’s

strong IPR holdings and competence in UI design; applications, which implement virtual

networks and create customer lock-in; and are considered different among competing OS

products. Through these software points Apple holds control over the product, as the underlying

Darwin core is of very little customer value without them.

Apple is differentiated by the ease of use, robust support, and tight integration between its

hardware and software products. It provides a very unique experience that cannot be matched

by imitation or partial duplication, even with access to some of the core technologies we share

with the open source community. – R&D senior manager-

Our open source strategy has made it possible to get more out of the investment into software

engineering. Because of the OSS utilization, we have been able to move more scarce resources

and concentration to the things that are unique for us. –Senior Product Manager-

This enables us to focus on the innovative projects in-house, rather than the commodities.


Case Studies



65

Productization Process

Despite the collaborative R&D, the productization process carries differentiating value. The

released OSS is far from an end-user product and the designing of an end-user product,

integration of open and proprietary components, testing process, and related cost drivers still

exist. Apple contributes value into the processes that are necessary, but which the OSS

community is not considered competent in, such as requirements management, usability, and

testing. The process of productization, where openly available components are integrated to a

tested product, is very similar to the business model of companies such as Red Hat Inc.

OSS enables Apple to focus its engineering efforts on the "hard" problems and the "boring"

problems, neither of which seems to be easily tackled using the open source model. You can't

have a "one size fits all" approach to software development. Commercial development is good

for certain things, such as user interfaces and debugging. Open source development seems to be

good at building core technologies that serve very specific, well-defined purposes. – R&D

Senior Manager-

Our products are differentiated by what the customers perceive and the level of experience and

usability. – Senior Product Manager-

4.4.7 Analysis

Framework Validation

The case of Mac OS X provides both supporting evidence of collaborative R&D impacting

competitiveness as well as factors leading to less efficient collaboration. These are summarized

in the following list:

• Apple is able to leverage existing competencies through control points and

productization to create value in addition to collaborative R&D.

• The strategic split of software makes possible the reconfiguration of the development

value chain to better match with the external environment.

• There is a substantial cost reduction in initial and continuous development. However,

the reductions are less than optimal because of not staying in synchronization with

certain communities as well as choosing communities that proved to be unsustainable

or unable to gather commercial investment. Reduced transaction costs are also evident.

Case Studies



66

• Apple creates social capital through hiring BSD developers, which impacts the

efficiency of collaborative R&D and creates a first-mover advantage in collaborative

R&D.

• The self-created community has given very little contribution in the form of

collaborative R&D because of Apple’s failure in keeping the created community at

pace with the internal development and in attracting sufficient developer mass.

Industry Comparison

The industry is in a transition phase, with companies exhibiting various collaboration strategies

ranging from closed-source software to active collaboration. In the context of this competition,

Apple is able to create relative advantages in comparison to the defined competitors:

• With proprietary products, such as Windows, Apple is able to concentrate on value

creation, impact the value of proprietary competencies, and create a first-mover

advantage.

• In case of OSS originated products, e.g. Red Hat, Apple does not gain a clear

advantage from collaborative R&D, but has more control over their product and a

greater ability to create value with control points and productization.

• Compared to Sun’s approach of creating their own community to reduce maintenance

costs, Apple holds an evident advantage with more efficient and wider collaboration

leading to concentration on value creation, impact on competencies, and a first-mover

advantage.

It can be argued that collaborative R&D has a direct impact on the industry-wide competition as

well as on the value of software. There is a gradual industry-wide movement going in the

direction of collaborative R&D, which might over time result in homogenous strategies and

redefined advantages. This movement is, however, not solely the result of Apple’s strategy, but

it is more than likely that Apple’s approach contributes to it.

4.5 Findings and Generalization of Cases

The following section presents the key findings from the two cases, the possibility of

generalizing these findings, and the assessment of the framework. The cases are first directly

Case Studies



67

compared to each other based on the quantitative data, then based on the factors observed. On

this basis conclusions are drawn and discussed.

4.5.1 Quantitative Findings

Both cases include quantitative data, which works as validation and criticism for the impact of

collaborative R&D on competitiveness. The unmodified data is presented in the following table

9.

Table 9: Empirical data from case studies

Empirical Factor Nokia Apple

OSS Originated Code (SLOC) 8.9M 13.6M

Company Created OSS Code (SLOC) 0.8M 3.4M

Duration of Collaborative Development 4-5 years ~10 years

Value of Utilized OSS $228M $350M

Share of Source Code in Collaborative development (Kernel) ~100% ~0%

Share of Source Code in Collaborative development (System) ~88% ~60%

Share of Source Code in Collaborative development (UI Toolkit) ~46% 0%

Developer amount (Existing Communities) ~2500 ~700

Commercial parties (Existing Communities) >10 0-10

Created Community Duration 1 year 4 years

Created Community Size ~10 ~150

Created Community Contribution

(Code contributions) ~5-10 ~300-500

The empirical data plainly presents the similarities and differences of the collaborative

strategies. The conclusions are:

• The cases are similar in the amount of OSS-originated code and the substantial value it

contributes. Both companies are able to leverage large OSS communities, but Apple is

at a disadvantage because they maintain their own kernel technologies.

• There is a substantial difference between the continuous scope and effectiveness of the

collaborative R&D. Nokia utilizes less OSS lines of code; with a higher share available

to existing communities for collaborative R&D; and more OSS developers and

commercial parties contributing to this development.

Case Studies



68

• Apple, on the other hand was able to gather more developers in the self-created

community, but the difference here does not contribute a crucial advantage because

Apple’s community has since been abandoned.

These findings establish the difference in collaborative efficiency and explain Nokia’s ability to

benefit more from their collaborative R&D and have a more evident impact on the industry

environment.

4.5.2 Generalization of Findings

Although just two cases were studied, they both revealed characteristics of collaborative R&D

that impact competitiveness and are shared between the two cases. It is evident that based on the

proposed firm-level strategies companies can reconfigure the value system, create value in

addition to collaborative R&D, concentrate on value creation, expand the scope of existing

competencies more efficiently, and to some extent impact the value of competencies in the

industry. However, both of the case studies environments shared two critical factors that strictly

define the ability to make direct generalizations. Firstly, they both are environments that exhibit

large quantities of existing mature OSS, which is not self-evident in all software environments,

and secondly the software stacks are complex enough to allow value to reside in either higher

layers or specific implementations. These factors strictly limit the generalization of the findings.

We can conclude the main differing and impacting factors of the two cases in table 10.

Table 10: Main factors from cases impacting competitiveness

Main Factors Nokia Apple

Form of Collaboration Vertical upstream integration with all

existing communities

Vertical integration only with

some upstream communities

Community Social

Capital

Communities have large OSS and

commercial party networks

Diverse size and amount of

commercial investment

Company Specific Social

Capital

Contributes to efficiency and creates a

first-mover advantage

Efficiency with FreeBSD and


Investment Reduction Initial and continuous investment

greatly reduced

Initial investment greatly

reduced, continuous to a lesser

extent

Resulting Relative

Advantages

Concentration on value; expanding

scope; substantial impact on external

value; and first-mover advantage

Concentration on value; some

impact on external value; and


Case Studies



69

In leveraging collaborative R&D, the most important factors are the split of software, form of

collaboration, community-owned social capital, and the existence of control points and value

in productization. The form of collaboration and community-owned social capital dictate both

the amount of available collaborative R&D as well as the continuous impact. The split of

software enables the combination of different collaboration strategies. If these three factors are

not implemented successfully, the ability to leverage collaborative R&D is substantially

handicapped. It also naturally follows that company specific social capital; reduced transaction

costs; and emerging de facto standard creation impact competitiveness.

Both cases bring forth evidence that the self-created communities for integrated products are not

an efficient source of collaborative R&D. This is a result of the complexity in creating a large

enough development community around commercially controlled software, creating total

transparency in development, and attracting commercial parties to invest in the software.

However, in Nokia’s case it will only be possible to determine the impact of component

development in the self-created community over a longer period of time.

It can be argued that collaborative R&D can also be considered a source of differentiation.

Both cases exhibited maturing collaboration bound to internal processes and employees, thus

creating differentiation. Dependant on how collaboration strategies converge in the future, the

first-mover advantage can result in a substantial advantage and a beneficial position in the

resulting industry.

It is also evident that the firm-level collaboration strategies can have an impact on the value of

industry competencies. Especially in Nokia’s environment there is a movement towards

collaborative R&D and homogenous collaboration around the chosen technologies, which is a

result of their success in collaboration and devaluing of external competencies. In Apple’s case

there is heterogeneous collaboration across competition with only one party concentrating

purely on closed-source products. Over time it is possible that a large part of the strategies will

mold around the most successful collaboration strategy, but it cannot yet be determined.

4.5.3 Framework Assessment

The proposed framework seems to be robust enough to handle different cases and is to a large

extent validated by the empirical studies. Most importantly it brings forth the critical factors and

the most common shortcomings in relation to the successful implementation of collaborative

R&D during the transition phase of an industry. Successful implementation includes taking the

Case Studies



70

maximum advantage of the OSS asset, managing the disadvantages, and being able to create

value on top of collaboration. All the proposed relative advantages are also, to at least some

extent, proven or discussed.

The cases do, however, present feedback and criticism, which should be applied or taken into

account in the framework. The role of the self-created communities is not empirically proven,

and therefore cannot be considered as important as collaboration with existing communities.

Also the cases and the framework do not take into account the impact of collaborative R&D on

the external complementary innovation or application development. It could be argued that this

can be a part of the created advantage and even result in company specific impact. Also the

impact of the form of collaboration and social capital owned by communities should be

emphasized and directly linked to the resulting continuous R&D efficiency and the other

naturally following factors, such as reduced transaction costs.

There is evident criticism towards the impact of collaboration on industry competencies. In both

cases the movement towards OSS collaboration is a result of a phenomenon larger than these

single companies, which impact competence value. Especially in the case of Apple, it is

impossible to argue what the impact of collaboration has been on the industry-level based on the

presented data. Also, because both cases exhibited heterogeneous collaboration strategies

among competition, there is no clear proof if the first-mover advantage is in fact realizable. This

can only be determined during a longer research time and an industry moving to homogenous

collaboration. These two shortcomings of the studies, lead to insufficient data to prove the

future convergence to homogenous collaboration strategies.

Discussion 71



5. DISCUSSION

The research reveals some general observations that are not thoroughly empirically proven, but,

however, warrant further discussion because of their possible impact on the competitiveness of

single companies and the whole software industry.

Through the research disclosing the gradually growing disruptive impact of OSS and the

growing investment in the OSS asset, it is more than likely that this phenomenon will continue

to strengthen. We can make a general hypothesis that more commercial companies will attempt

to leverage the OSS asset and more developers will join the mass of individuals working on

OSS. However, it is still unclear how wide spread the impact of this disruption will be and if it

will only impact specific industries, such as embedded software products.

Considered on the firm-level, during the growth of the disruption, companies choosing to

leverage OSS may have the possibility to dictate the value of their competitor’s competencies

and to build a beneficial position in the future industry. The case studies bring forth that

successful collaborative R&D may actively commoditize software and impact the competencies

of competition, forcing them to react. In this scenario, social capital and the first-mover

advantage could prove to be valuable competitive assets, if the impact is strong enough to force

competition to also adopt collaborative R&D. In any event, it must be taken into account that

such an impact is more likely a result of more than a single company leveraging OSS. The value

of competencies is also defined by a significant amount of factors not thoroughly considered in

the research, making this a complex topic to evaluate and defining it on a level of an

observation, not a subjective research result.

On the industry level, with more companies adopting collaborative R&D and leveraging OSS, it

is possible that this could over time lead to converging homogenous collaboration strategies.

The growing amount of collaborative R&D would create a positive feedback system, where

companies not utilizing the same strategy and communities, would clearly be at an inferior

position regarding their R&D efficiency. The start of this phenomenon is witnessed in handheld

software, through the actions of Nokia and Palm/Access moving to homogenous collaborative

R&D. This phenomenon could in the long-run result in a complete reconfiguration of software

R&D in the specific industries, and in the continuous transformation of product-based

businesses into service-based businesses, as software is transformed into a commodity.

Discussion



72

Despite the indication from one of the case studies, the homogenous collaboration strategies

across an industry and the transformation of R&D are highly speculative. Based on the

researched effectiveness of collaborative R&D and the growing disruptive force of OSS, there

are rationale to consider this happening, but at this stage there is no proof to validate this

observation. This is because of the limited amount of companies actually conducting

collaborative R&D inside direct competition and to date the non-existent evidence of large scale

homogenous collaboration.

Conclusions 73



6. CONCLUSIONS

This study has examined how collaborative R&D can impact the competitiveness of product

companies. The objective was to examine the impact on competitiveness of substantial

collaborative R&D and to form a framework, which can be used to understand the impact and

detail the implementation and rationale of the strategy. This objective was addressed by

reviewing relevant literature on competitive advantage, software production, OSS, synthesizing

the findings, and empirical case studies of Nokia and Apple.

6.1 Main Results

The main results of the study are the collaborative R&D framework and the findings from the

case studies.

The framework dictates the different firm-level strategies and the rationale to implement

collaborative R&D, during the transition phase of an industry. Importantly based on the

empirical study, it brings forth the factors and shortcomings to successfully impact

competitiveness and to evaluate the opportunity in collaborative R&D on the firm-level.

The primary result from the case studies is that collaborative R&D can impact competitiveness

with the ability to concentrate the development investment on value creation and more

efficiently expand the scope of existing competencies to new markets.

The case studies indicate that based on the strategic split of software, the companies are able to

reconfigure their development value chain with collaborative R&D. This leads to a better match

of internal competencies and the external environment, and substantial cost reductions in both

initial and continuous development. Quantitative findings indicate that the extent of the impact

is defined by both the firm-level activities, due to complexity in collaboration, as well as the

characteristics of the chosen communities, dictating the effectiveness of collaborative R&D. It is

also proven that substantial collaborative R&D does not destroy the companies’ ability to create

differentiating value and leverage existing advantages, such as IPR or network externalities, in

addition to OSS.

6.2 Assessment of Results

Both of the two case studies provided directly usable results to validate the content of the

proposed framework, in their context. The collected data in both cases is extensive, as it is a

combination of quantitative data from source code analysis and findings from interviews, and it

Conclusions



74

conforms well to the proposed factors in the framework for the firm-level strategies and the

firm-level impact.

Despite of the extensiveness of the data, the findings in the cases are subject to some general

limitations because of the assumptions and simplifications necessary to research this complex

topic. To accurately measure the resulting advantages and overall competitiveness, more in-

depth studies of the competing companies, their internal development and cost structure, and the

overall competitive dynamism, e.g. in the form of market share development, would have been

needed. The empirical factors of OSS value based on the COCOMO model and the exact

amounts of software maintained in the collaborative R&D can be also criticized because of the

uncertainty in the software source details and the COCOMO model. Therefore, the results must

be perceived as qualitative because of the nature of the interpretation from the data.

The number of empirical case studies, their uncertainties, and similar nature, limits the ability to

generalize the main results of the research. The results only provide thoroughly reliable

evidence of the impact of collaborative R&D in the context of the studied industries or nearly

identical competitive environments, in relation to OSS maturity and software complexity. To

warrant extensive generalization to different environments, more in-depth research into the topic

and the applicability of the framework would be needed.

6.3 Exploitation of Results

Taking into account the limitations of the research, the results of the study are directly

exploitable only to the industries, which were included in the empirical study. In these

industries, both the framework and empirical findings can be used as a rationale to evaluate and

implement collaborative R&D, understand the present and possible future impact of OSS, or

mold existing collaboration to be more efficient.

For industries outside of the scope of the empirical studies, the results of the research cannot be

considered reliable and directly exploitable. In cases, where the maturity of OSS is already high

and differentiation can lie higher in the software stack, the results can, however, be used as a

starting point for the evaluation and an indicator of the possible competitive impact of

collaborative R&D now or in the future.

Conclusions



75

6.4 Recommendations for Future Research

Close to the scope of this study there remain valuable and vital questions. Primarily, the

proposed collaboration framework should be further developed. It would be important to

understand how the proposed factors and collaborative R&D are applicable in taxonomies of

competitive environments, how they can be extended to the overall competitive dynamism of

companies, what is the exact impact on the value of competitor competencies, how they impact

customer value, and applied to a larger quantity of cases. Parallel to this, more in-depth research

into the competitive development of both proprietary and dual licensing should be conducted to

further validate the proposed framework. Further understanding of the details of collaboration

efficiency could also produce valuable results. There are many important details, e.g.

contribution flow, contribution sizes, communication channels, and level of formality that

define the efficiency.

IPR strategies of companies are a continuous question mark when assessing OSS and more in-

depth research into this topic would be justified. To understand these questions, the relationship

of software for hardware companies as a competitive advantage or disadvantage is also an

important topic. It is a clear trend that functionality continuously moves to software, but how it

is driving the competition is still somewhat unclear.

With the case studies concentrating on heterogeneous collaboration strategies, an important

future research area may be the impact and forming of homogenous strategies, the ability for

companies to create advantages in this domain, and the transformation of product businesses to

service-based businesses. Research could also concentrate on an industry-wide dedicated effort

to produce an open software platform and its implications to competition, suppliers, and

customer value.

References 76



7. REFERENCES

Amor - Iglesias J., Gonzales-Barahona J., Robles-Martinez G., Herraiz-Tabernero I., 2005.

Measuring libre software using debian 3.1 (Sarge) as a case study: Preliminary results.

Upgrade Vol. 6(3). p. 13-16.

Andrews K.R., 1971. The Concept of Corporate Strategy. Homewood, IL: Dow Jones Irwin.

Ansoff H.I., 1965. Corporate Strategy. McGraw-Hill, New York.

Aoki A., Hayashi K., Kishida K., Nakakoji K., Nishinaka Y., Reeves B., Takashima A.,

Yamamoto Y., 2001. A case study of the evolution of Jun: an object-oriented open-source 3d

multimedia library. In Proceedings of International Conference on Software Engineering

(ICSE).

Armour P., 2000. The Case for a New Business Model. Communications of ACM Vol. 43(8), p.

19-22.

Armour P., 2002. Ten Unmyths of Project Estimation. Communications of the ACM, Vol.

45(11), p. 15-18.

Athey T., 1998. Leadership Challenges for the Future. Software, IEEE, Vol. 15(3), p. 72-77.

Augustin L., Bressler D., Smith G., 2002. Accelereting Software Development through

Collaboration. Internation Conference Software Engineering, Orlando, FL, 559-563, May.

Baker S., 1998. What every business should learn from Microsoft. The Journal of Business

Strategy, Vol. 19(5), p.36.

Barney J.B., 1986. Strategic Factor Markets: Expectations, Luck, and Business Strategy.

Management Science, Vol. 42, p. 1231-1241.

Barney J.B., 1991. Firm Resources and Sustained Competitive Advantage. Journal of

Management Vol. 17(1), p. 99-120.

References



77

Benussi I., 2005. Analysing the technology history of the Open Source Phenomenon. Stories

from the Free Software Evolution. Working paper University of Turin, Available at

http://opensource.mit.edu as of February 15, 2006.

Boehm B., 1981. Software Engineering Economics. Englewood Cliffs, N.J.; Prentice-Hall, Inc.

ISBN 0-13-822122-7, 768 pages.

Boehm B., 1988. Understanding and Controlling Software Cost. IEEE TOSE, Vol. 14(10), p.

1462-1477.

Bonaccorsi A., Rossi C., 2003a. Why open source software can succeed. Research Policy

Vol.32, p. 1243-1258.

Bonaccorsi A., Rossi C., 2003b. Comparing motivations of individual programmers and firms

to take part in the open source movement: From community to business. Working Paper,

Available at http://opensource.mit.edu as of November 10, 2005

Bonaccorsi A., Rossi C., 2004. Contibuting to the common pool of resources in Open source

software. A Comparison between individuals and firm. Working Paper, Available at

http://opensource.mit.edu as of November 10, 2005

Bourdieu P., Wacquant L., 1992. An Invitation to Reflexive Sociology. University of Chicago

Press: Chicago IL. ISBN 0226067416, 348 pages.

Brooks F.P., 1987. No Silver Bullet: Essence and Accidents of Software Engineering. IEEE

Computer, Vol. 20(4), p. 10-19.

Brooks I., 1997. Creating Sustained Competitive Advantage Through a Seamless Value System.

Organization and People, Vol. 4(3), p. 24-30.

Caoiluppi A., Lago P., Morisio M., 2003. Characteristics of Open Source Projects. IEEE

Proceedings of the Seventh European Conference on Software Maintenance and Reengineering

Capek P., Frank S., Gerdt S., Shields D., 2005. A history of IBM’s open-source involvement and

strategy. IBM Systems Journal, Vol. 44(2), p. 249-257.

References



78

Carlton D., Perloff J., 1994. Modern Industrial Organization. 2nd edition. New York, Harper

Collins College Publishers, ISBN 0-673-46902-6, 973 pages.

Casadesus- Masanell R., Ghemawatt P., 2003. Dynamic Mixed Duopoly: A Model Motivated by

Linux vs. Windows. Harvard University: Strategy Unit Working Paper No. 04-012.

Christensen, C.M., 1997. The Innovator's Dilemma: When New Technologies Cause Great

Firms to Fail. Harvard Business School Press. ISBN 0-87584-585-1, 225 pages.

Cusumano M., 2004. The Business of Software. Free Press New York, ISBN 0743266633, 422

pages.

Dahlander L., 2004. Appropriating the Commons: Firms in open source software.

Working Paper, Available at http://opensource.mit.edu/papers/Dahlander2.pdf as of November

10, 2005.

Dahlander L., Magnusson M., 2005. Relationship between open source software companies and

communities: Observations from Nordic Firms. Research Policy, Vol. 34, p. 481-492.

Dalle J.-M., David P., 2004. The allocation of software development resources in open source

production mode. Available at http://ideas.repec.org/p/wpa/wuwpio/0502011.htm as of

November 10, 2005.

D’Aveni R. ,1995. Coping with hypercompetition: Utilizing the new 7S’s framework. Academy

of Management Executive, Vol. 9(3), p. 45-60.

D’Aveni R., 1999. Strategic Supremacy through Disruption and Dominance. Sloan

Management Review, Spring Vol. 3(40), p. 127-135.

D’Cruz. J., Rugman A., 1992. New concepts for Canadian competitiveness. A Working Paper,

Kodak Canada.

Denning P.J., 1992. What is software quality, Communications of the ACM, Vol. 35(1), p. 13-

15.

References



79

Ding-Tong T., Bieman J., 2004. Open source Software Development A Case study of FreeBSD.

IEEE Proceedings of the 10th International symposium on software metrics.

Eisenhardt K.M, Bourgeois III L.J., 1988. Strategic Decision Processes in High Velocity

Environments: Four cases in the Microcomputer Industry. Management Science, Vol. 34(7), p.

816-835.

Eisenhardt K.M., 1989. Building theories from Case Research. Academy of Management

Review, Vol. 14(4), p. 532-550.

Eisenhardt K., Martin J., 2000. Dynamic Capabilities: What are they? Strategic Management

Journal, Vol. 21(10-11), p. 1105-1121.

Feller J., Fitzgerald B., 2000. A Framework analysis of the open source software development

paradigm. ICIS, p. 58-69

Feller J., Fitzgerald B., 2002 Understanding open source software development. NY: Addison

Weasley, ISBN 0-201-73496-6, 224 pages.

Fink M., 2003. The Business and economics of Linux and Open source. Prentice Hall, ISBN 0-

13-047677-3, 242 pages.

Gaudeul A., 2003. Competition between open-source and proprietary organizations. CCP

Working paper, no. 05-3

Gawer A., Cusumano M., 2002. Platform Leadership. Harvard Business School Press, ISBN

1578515149, 336 pages.

Ghemawat P., 1985. Building Strategy on the Experience Curve. Harvard Business Review

Mar/Apr Vol. 63(2), p. 143-149.

Godfrey M., Tu Q., 2000. Evolution in Open source software: A Case Study. Proceedings of

International Conference on Software Maintenance, p. 131-142.

Goldman R., Gabriel R.P., 2005. Innovation happens elsewhere: Open source as Business

Strategy. Elsevier Science & Technology Books, ISBN 1558608893, 402 pages.

References



80

Grant R., 1996. Toward a knowledge-based theory of the firm. Strategic Management Journal

Vol. 21(3), p. 369-386.

Gulati R., 1999. Network location and learning: The influence of network resources and firm

capabilities on alliance formation. Strategic Management Journal 20(5), p. 397-420.

Haikala I., 2001. Ohjelmistotuotanto. 7th ed. Talentum Media Oy, ISBN 951-762-769-6, 414

pages.

Hall B., 2003. On copyright and patent protection for software and databases: tale of two

worlds, In Granstrand, Ove (ed.) Economics, Law and Intellectual Property. Kluwer Publishing

CO., Amsterdam, NL.

Hansen M.T., 1999. The search-transfer problem: The role of weak ties in sharing knowledge

across organization subunits. Administrative Science Quarterly (March) 44, p. 82-111

Hansen M., Köhnstopp K., Proftzmann A., 2002. The open source approach – opportunities

and limitations with respect to security and privacy. Computer Security, Vol. 21(5), p. 461-471.

Harhoff D., Henkel J., von Hippel E., 2003. Profiting From Voluntary Information

Spillovers: How Users Benefit by Freely Revealing their Innovations. Research Policy Vol. 32,

p. 1753- 1769

Hawkins D., 2002. The Economics of Open source software for a Competitive Firm. Kluwer

Academic Publishers.

Healy K., Schussman A., 2003. The Ecology of open-source software development. Working

Paper, Available at http://opensource.mit.edu as of November 10, 2005

Helfat C.E, Raubitschek R.S., 2000. Product sequencing: Co-evolution of knowledge,

capabilities and products. Strategic Management Journal, Vol. 21(10-11), p. 961-979

Henkel J., 2003. Software development in embedded linux – informal collaboration of

competing firms. Proceedings of the 6th International Conference on Business Informatics,

Physica, Heidelberg.

References



81

Henkel J., 2004. Open source software from Commercial Firms – Tools, Complements and

Collective invention. CEPR Discussion Paper.

Hersleb J., Moitra D., 2001. Global Software Development. IEEE Software March/April, Vol.

18(2), p. 16-20.

Hertel G., Niedner S., Herrman S., 2003. Motivation of software developers in Open source

projects: an internet-based survey of contributors to the linux kernel. Research Policy Vol.

32(7), p. 1159-1177.

Hitt M.A., Bettis R., 1995. The New Competitive Landscape. Strategic Management Journal

Summer, Vol. 16, p. 7-19

Hitt M.A., Keats B., D’Marrie S., 1998. Navigating in the new competitive landscape: Building

strategic flexibility and competitive advantage in the 21st century. Academy of Management

Executive, Vol. 12(4), p. 22-42.

Hoch D., Roeding C., Purkert G.,Lindner S., Muller R., 1999. Secrets of software success. HBS

Press, ISBN 1578511054, 312 pages.

Hyvönen E., 2003. Ohjelmistoliiketoiminta. WSOY, ISBN – 951-0-26996-4, 248 pages.

IBM Press, 2005. IBM Pledges 500 U.S Patents to Open Source. Available at http://www-

03.ibm.com/press/us/en/pressrelease/7473.wss, as of January 1, 2006.

Ioannis S., Lefteris A., Apostolos O,. Gergios B,. 2002, Code quality analysis in open source

software development. Information Systems Vol. 12, p. 43-60.

ITEA, 2003. Co-development with inner and open source in software intensive products.

Information Technology for European Advancement Publishments, on going project leaflet.

Johnson J.P., 2002. Open source Software: Private Provision of a Public Good. Journal of

Economics & Management Strategy, Vol. 11(4), p. 637-662.

Johnson J.P., 2004. Collaboration, Peer Review and Open source software. Johnson Graduate

School of Management, Cornell University.

References



82

Jorgenssen N., 2001. Putting it all in the trunk: Incremental software development in the

FreeBSD open source project. Information Systems Journal, Vol. 11, p. 321-336.

Kasanen, E., Lukka, K., Siitonen, A., 1993. The Constructive approach in Management

accounting Research. Journal of Management Accounting Research, Vol.5 Fall, p. 243-264.

Khalak A., 2000. Economic model for impact of open source software. Working paper


Klincewicz K., 2005. Innovativeness of open source software projects. Working paper,

Available at http://freesoftware.mit.edu as of January 2, 2006.

Koch S., 2005. Evolution of open source software systems – a large-scale investigation.

Proceedings of the Frist international Conference on Open Source systems. Genova 11th-15th

July.

Kogut B., Zander U., 1993. Knowledge of the firm and the evolutionary theory of multinational

corporations. Journal of International Business Studies, Vol. 24(4), p. 625-645.

Kogut B., Metiu A., 2001. Open-source Software Development and Distributed innovation.

Oxford Review of Economic Policy, summer Vol. 17(2), p. 248-264.

Krogh G., 2003. Open source Development. MIT Sloan Management Review, Vol. 44(3), p. 14-

18.

Krogh G., Spaeth S., Lakhani K., 2003. Community joining and Specialization in Open-Source

Software innovation: A Case study. Research Policy Vol. 32, p. 1217-1241.

Kuan J., 2000. Open source software as a Consumer Integration into Production. Working

Paper, Available at http://opensource.mit.edu as of November 10, 2005

Lakhani, K., Wolf, B., Bates, J., DiBona C., 2002. The Boston consulting group Hacker Survey.

Available at www.osdn.com/bgc, as of November 10, 2005.

References



83

Lakhani, K., Wolf, B., 2003. Why hackers do what they do: Understanding motivation and

effort in Free/open source software projects. MIT Working paper, Available at

http://freesoftware.mit.edu/papers/lakhaniwolf.pdf as of November 11, 2005.

Lerner J., Tirole J., 2000. The simple economics of Open Source. NBER working paper

no.w7600 (Cambridge, Massachusets: National Bureau of Economic Research, March 2000)

Lerner J., Tirole J., 2001. The open source movement: key research questions. European

Economic Review, Vol. 45(4-6), p. 819-826

Lerner J., Tirole J., 2002. Some Simple Economics of Open Source. The Journal of Industrial

Economics, Vol 50(2), p. 197-234.

Lerner J., Tirole J., 2004. The economics of technology sharing: Open source and Beyond.

Available at http://opensource.mit.edu as of November 10, 2005.

Levesque M., 2004. Fundamental issues with open source software development. First Monday

Vol. 9(4).

Levy E., 2000. Wide open source. Available at www.securityfocus.com/commentary/19, as of

January 15, 2006.

Lieberman M., 1987. The learning curve, diffusion and competitive strategy. Strategic

Management Journal, Vol. 8, p. 441-452

Lieberman M., Montgomery D., 1988. First-mover Advantages. Strategic Management Journal

Vol. 9 Summer, p. 41-58.

Lieberman M., Montgomery D., 1998. First-mover (Dis)Advantages: Retrospective and link

with the resource based view. Strategic Management Journal Vol. 19(12), p. 1111-1125.

Lin N., 1999. Building a Network Theory of Social Capital. Connections, Vol. 22(1), p. 28-51.

Long A., 2003. How Firm Initiation and Control of Projects affects Open-Source Development.


References



84

MacCormack A., 2001. Product development practices that work: How internet companies

build software. MIT Sloan Management Review, Vol. 42(2), p. 75-84.

MacCormack A., Rusnak J., Baldwin C., 2005. Exploring the structure of complex software

design: An empirical study of Open source and Proprietary Code. Harvard Business School,

Working paper Number 05-016

Madanmohan T.R, Rahul De., 2004. Open Source Reuse in Commercial Firms. IEEE Software,

Vol. 21(6), p. 62-69.

Madanmohan T.R., Krishnamurthy S., 2005. Can the Cathedral co-exist with the bazaar? An

analysis of Open Source Software in commercial firms. Firstmonday, Special Issue, October.

Makadok R., 1998. Can First-Mover and Early-Mover advantages be sustained in an industry

with low barriers to entry and imitation. Strategic Management Journal Vol. 19(7), p. 683-696.

McKelvey M., 2001. Internet Entrepreneurship: Linux and the dynamics of open source

software. CRIC Discussion Paper, No. 44 June.

Messerschmitt D., Szyperski C., 2003. Software Ecosystem – Understanding an Indispensable

Technology and Industry. MIT Press, 2003, ISBN 0-262-13432-2, 432 pages.

Meyer M., Zack., 1996. The Design and Development of Information products. Sloan

Management Review, Vol. 37(3), p. 43-59.

Meyer M., Selinger R., 1998. Product platforms in Software Development. Sloan Management

Review, Vol. 40(1), p. 61-74.

Meyer M., Mugge P., 2001. Make platform innovation drive enterprise growth. Research

Technology Management, Vol. 44(1), p. 25-39.

Mockus A., Fielding R.T., Hersleb J., 2000. A case study of Open Source Software

Development: The Apache Server. Proceedings of the 22nd International Conference of

Software.

References



85

Mockus A., Fielding R.T., Hersleb J., 2002. Two Case studies of open source software

development: Apache and Mozilla. ACM Transactions on Software Engineering and

Methodology, 11(3), p. 309-346, July.

Nahapiet J., Ghoshal S., 1998. Social Capital, Intellectual Capital and the Organizational

advantage. Academy of Management Review, Vol. 23(2), p. 242-266.

Nambisan S., 2001. Why service businesses are not product Businesses. MIT Sloan

Management Review, Vol. 42(4), p. 72-80.

Nicholson D., Thomson K., Yeates S., 2001. Usability of open source software development. In

E. Kemp, C. Philips, Kinshuck., J. Haynes (editors). Proceedings of the symbosium on

computer human interaction. Palmerston North, New Zealand: SIGCHI New Zealand.

Nichols D., Twidale M., 2003. The usability of Open source software. First Monday, Vol. 8(1).

Normann R., Ramirez R., 1993. From Value Chain to Value Constelation: Designing

Interactive Strategy. Harvard Business Review, July-August, p. 65-77.

Norris J., 2004. Mission-Critical Development with Open Source Software: Lessons Learned.

IEEE Software, Vol. 21, p. 42-49.

Open Source Iniative (OSI), 2002. The Open Source Definition. Available at

http://opensource.org/docs/definition.html as of February 14, 2006.

O’Reilly T., 1999. Lessons from Open source Software Development. Communications of the

ACM, Vol. 42(4), p. 33-37.

O’Reilly T., 2004. Open source Paradigm Shift, Available at

http://tim.oreilly.com/articles/paradigmshift_0504.html , as of November 10, 2005.

OSDL, 2006. Available at http://www.osdl.org/ , as of 12 Christmas, 2005.

Osterloh M., Rota S., Wartburg M., 2002. Open source – New rules in Software Development.

Working Paper, Institute for Research in business, University of Zurich.

References



86

Pal N., Madanmohan T.R., 2002. Competing on Open Source: Strategies and Practice. Working

Paper, Available at http://opensource.mit.edu as of November 10, 2005.

Paulson J., Succi G., Eberlein A., 2004. An Empirical study of Open-source and Closed source

software products. IEEE Transactions of Software Engineering, Vol. 30(4), p. 246-256.

Pavlicek, R.C., 2000. Embracing Insanity: Open Source Software Development. Sams

Indianapolis, IN, ISBN 0672319896, 192 pages.

.

Payne C., 2002. On the security of open source software. Information Systems Journal, Vol.

12(1), p. 61-78.

Perens, B. 1999. The Open source definition. In: DiBone, C., Ockman S., Stone, M. (editors).

1999. Open sources: Voices from the Open Source Revolution. Sebastopol, O’Reilly. P. 171-

188.

Peteraf M., 1993. The Cornerstone of Competitive Advantage: A Resource-Based view.

Strategic Management Journal, Vol. 14(3), p. 179-191

Porter, M. E., 1980. Competitive strategy. New York: The Free Press, ISBN 0029253608, 396

pages.

Porter, M. E., 1981. The contributions of industrial organization to strategic management.

Academy of Management Reviews, Vol. 6, p. 609-620.

Porter, M. E., 1985. Competitive Advantage: Creating and Sustaining Superior Performance.

Press Ganey Associates, ISBN 0029250900, 557 pages.

Porter, M.E., 1998. Competitive Advantage: Creating and Sustaining Superior Performance.

With New introduction, originally published in 1985. New York: The Free Press. ISBN

0684841460, 592 pages.

Poulin J., Caruso J., Hancock D., 1993. The Business Case for Software Reuse. IBM Systems

Journal Vol. 32(4), p. 567-594.

References



87

Prahalad, C.K., Hammel G., 1990. The Core Competence of the Corporation. Harvard Business

Review, May/June, p. 79-91.

Prahalad C.K., Hamel G., 1994. Competing for the future. MA: Harvard Business School Press.

ISBN 0875844162, 352 pages.

Pressman R.S., 2004. Software Engineering a Practitioners Approach. 6th ed. McGraw-Hill,

ISBN 007301933X, 880 pages.

Raymond E.S., 1999. The Cathedral and the Bazaar: Musing on Linux and Open Source by an

Accidental Revolutionary. Sebastopol, O’Reilly Associates Inc., pages 268.

Robertson D., Ulrich K., 1998. Planning for product Platforms. Sloan Management Review,

Vol. 39(4), p. 19-31.

Ruffin M., Ebert C., 2004. Using Open source Software in Product Development: A Primer.

IEEE Software, Vol. 21(1), p. 82-86.

Rummelt R., 1984. Towards a strategic theory of the firm. In R. Lamb(ed.), Competitive

Strategic Management: 556-570. Englwood Cliffs, NJ: Prentice- Hall

Scacchi W., 2002. When Is Free/Open Source Software Development Faster, Better, and

Cheaper than software Engineering. Discussion Paper at the 2nd Workshop on Open Source

Software Engineering, Orlando, Florida.

Schach S.R., Jin B., Wright D.R., Heller G.Z., Offutt A.J., 2002. Maintainability of the Linux

Kernel. IEEE Proceedings-Software., Vol. 149(1), p. 18-23.

Schweik, C.M., Semenov A., 2003. The Institutional Design of 'Open Source' Programming:

Implications for Addressing Complex Public Policy and Management Problems. First Monday,

Vol. 8(1).

Shapiro C., Varian H.R., 1999. Information rules: A strategic guide to the Network Economy.

Boston, Harvard School Press. ISBN 087584863X, 352 pages.

Sommerville I., 2001. Software Engineering. Addison Wesley, ISBN: 0321210263, 784 pages.

References



88

Sourceforge, 2006. Available at http://sourceforge.net/index.php , as of March 15, 2006.

Spender J.C., 1996. Making Knowledge the basis of the dynamic theory of the firm. Strategic

Management Journal, Vol. 17 Winter, p. 77-91.

Stamelos I., Angelis L., Oikonomou A., Bieris G., 2002. Code quality analysis in open source

software development. Information Systems Journal, Vol. 12, p. 43-60.

Standish Group, 1995. The Standish Group Report Chaos. Available at

http://www.projectsmart.co.uk/docs/chaos_report.pdf, as of March 2, 2006.

Sun Microsystems, 2005. Sun Announces Open Source License for Solaris Operating System.

Available at http://www.sun.com/smi/Press/sunflash/2005-01/sunflash.20050125.1.xml, as of

March 14, 2006.

Szulanski G., 1996. Exploring internal stickiness: Impediments to the transfer of best practice

within the firm. Strategic Management Journal, Winter special issue Vol. 17, p. 27-43.

Technology Review, 2005. Corporate R&D Scorecard. Available at

http://www.technologyreview.com/documents/05/09/rd_scorecard.pdf as of February 7, 2006.

Teece D.J., 1984. Economic analysis and Strategic management. California Management

Review, Vol. 26(3), p. 87-110.

Teece D., Pisano G., Shuen A., 1997. Dynamic Capabilities and Strategic Management.

Strategic Management Journal, Vol. 18(7), p. 509-533.

West J., 2003. How open is open enough? Melding proprietary and open source platform

strategies. Research Policy Vol. 32, p. 1259-1285

Wheeler D., 2001. More than a Gigabuck: Estimating GNU/Linux’s size. Discussion Paper,

Available at www.dwheeler.com/sloc/redhat71-v1/redhat71sloc.html as of November 10, 2006.

Wichmann T., 2002. Free Libre open source software: Survey and study. Part 1 & 2. Final

report, international Institute of Infonomics, Berlecom Research GmbH.

References



89

Viega J., 2000. The Myth of open source security. Available at

http://developer.earthweb.com/journal/techfocus/052600_security.html as of November 15,

2006.

Von Hippel E., 2001. Innovation by user communities: Learning from open source software.

MIT Sloan Management Review, Summer Vol. 42(4), p. 82-86.

Von Hippel E., Krogh G., 2003. Open Source Software and the ”private-collective” Innovation

Model: Issues for Organization Science. Organization Science, Vol. 14(2), p. 209-223.

Vunet.com, 2005. IBM Promises $100 million Linux Investment. Available at

http://www.vnunet.com/vnunet/news/2126787/ibm-promises-100m-linux-investment , as of

January 4, 2006.

Ye Y., Kishida K., 2003. Toward an understanding of the motivation of open source software

developers. Proceeding of the 25th International Conference on Software Engineering, IEEE.

Yin R.K., 2003. Case study Research: Design and Methods, 3rd edition. Thousand Oaks, CA :

Sage. ISBN 0761925538, 200 pages.

Young, R., 1999. Open Sources: Voices from the Open Source Revolution, Giving It Away: How

Red Hat Software Stumbled Across a New Economic Model and Helped Improve an Industry.

Available at http://www.oreilly.com/catalog/opensources/book/young.html, as of Christmas 12,

2005.

Zahra S., Nash S., Bickford D., 1995. Transforming technological pioneering into competitive

advantage. Academy of Management Executive, Vol. 9(1), p. 17-28.

Zollo M, Singh H., 1998. The impact of knowledge codification, experience trajectories, and

integration strategies on the performance of corporate acquisition. Academy of Management,

Best Paper Proceedings, San Diego CA.

Appendix 90



APPENDIX 1: Case study material

Nokia software details

Http://www.maemo.org. Source for ITSE2005 case software details and statistics, accessed

during Christmas 2005.

Http://gnome.org . Details on GNOME community activity and software, accessed during

Christmas 2005 and March 2006.

Http://debian.org . Details on Debian community activity and software, accessed during

Christmas 2005 and March 2006.

Nokia Interviews:

Open Source Senior product manager, Date of interview 23.01.2006

Open Source Software architect, Date of interview 18.01.2006

IPR & Legal Manager, Date of interview 18.01.2006

Open Source Senior Project Manager, Date of interview 15.01.2006

Operation Director, Date of interview 17.01.2006

Apple software details:

Http://www.opensource.apple.com . Primary source for Mac OS X case software details and

statistics, accessed during January 2006.

Http://www.opendarwin.org . Secondary source for Mac OS X case software details and

statistics, accessed during January 2006.

Http://www.freebsd.org . Details on FreeBSD community and information on Apple’s

contributions there, accessed during February 2006.

Http://apache.org . Details on apache community and software, accessed during March 2006.

Http://samba.org . Details on Samba community and software, accessed during March 2006.

Apple interviews:

R&D senior manager, Date of interview 2-3.02.2006.

Open source senior product manager, Date of interview 5.02.2006

Darwin Development Lead, Date of interview 25.01.2006

Darwin Developer, Date of interview 10.01.2006.

Appendix



91

APPENDIX 2: Interview Protocol

Main discussion areas for interviews, depending on position, and role of interviewee:

1. Personal job, task or relationship with the company.

2. Company approach and rationale in utilizing OSS.

3. Main direct competitors for software products

4. Defined split between proprietary and OSS.

5. Role of self-created community, functioning of this community, and flow of software back to

internal development.

6. Collaboration with existing communities, the chosen communities, and process of

collaboration.

7. Advantages and disadvantages from OSS utilization to the process of software development

and overall competitiveness of the approach.

8. Role of other commercial companies in existing communities.

9. Impact of legal process and risk in utilization of OSS.

10. Impact of substantial OSS utilization to entry barriers of competition and creating

differentiation in excess of collaboration.

11. Impact on industry competencies and strategies, and long-term outlook.

12. Resulting definable advantages from OSS utilization and the collaboration strategy.

open source software and impact on competitiveness: case study · competitive advantages,...

Documents