Peer Production for Profit

Peer Production For Profit

. 1.0. Objectives  To provide the context of this thesis and introduce the concept of Open Source.  To introduce the Research Question.  To clarify the structure of the thesis.  To describe the methodology applied in the thesis.

. 1.1. Introduction This paper will analyse the relationship between for-profit organisations and knowledge-producing networks of volunteers. One example of such networks is to be found within Open Source. Open Source is a movement that gained considerable credibility over the last decade. It argues to be a viable substitute for commercial software houses, and is opposing the ever strengthening of the Intellectual Property Rights regime. Before introducing the research question, a bit of context information is provided. Hopefully this will give any reader a few strongholds to start with.

1.1.1. Scarcity Competition is what drives the capitalistic economic system. From the early days of the industrial revolution to the mass production era, and now in today’s service oriented economy. Organisations and individuals compete for access to scarce resources like land, capital and human resources. Adam Smith in his theory on the invisible hand (excludability, rivalry, transparency) already identified this scarcity as the one underlying fundamental beneath our economic system.

What would change when scarcity disappears? This might seem a hypothetical or even a utopian kind of question. But it might also be a very relevant question for tomorrow’s economy. In fact, the Internet hype of the 1990s was not solely on the physical evolvement of the Internet and new telecommunications networks, rather the increasing importance of information and knowledge in a “weightless” economy. (Kelly, 1997) It is exactly information that does not share the characteristics of scarcity; everybody knows that he can transfer information to somebody else, without loosing the information. The recent evolvements in ICT made it ever easier to copy information at near zero marginal costs. However this is not a thesis on plain economics and also not about the peculiar features of information only; a business student writes this thesis and therefore the focus is different. It would be nice if we already would be able to distinguish implications that these changes bring forward in the economy. One such possible probe into the future is the involvement of firms in the Open Source Software Community.

o Information is not a scarce good; a high economic dependency on information will cause changes. Open Source may be one probe into these changes.

1.1.2. The Public Domain Open Source is one exponent of the public domain. A domain in which nobody owns the property rights on, say in this case, software. Developments in ICT decrease the marginal cost that are involved in the production and distribution of these goods, which leads to a situation near to non-scarcity, with software as a public good. However since centuries the western world knows a system of intellectual property rights, limiting the scope of the public domain. It is a system developed in order to steer investments in innovation; to make an invention private for a limited time so that the inventor can recoup its initial investment. Exactly these regulations imposed by governments have gained considerable strength during the last decades. Negative consequences of this increased control and limits on the public domain appear in the opportunities for creativity and innovation. The growing influence and success of the Open Source Community advocates for a strengthening of the public domain. Seen in this light it is interesting to reflect on the role of commercial organisations in this community. To question what a situation with limited intellectual property rights could include. Probably

- 1 - Peer Production For Profit

commercial organisations are likely to not be the ones that have strong incentives to maximize public welfare, and rather seek private welfare optimisation. Until now this resulted in a strengthening of Intellectual Property Rights and private control over the (former) public domain, but at the same time business do find several business opportunities in Open Source. o The Open Source Movement advocates a strenghtening of the public domain and a turnaround in the continuing strenghtening of Intellectual Property Rights.

. 1.2. Research Question The Open Source Community has in recent years proven the ability to develop state-of-the-art software. But despite the high quality of the product, the community has largely failed to serve the mass consumer market. Reasons for this failure include economic principles like network externalities; but simultaneous reasons might be internal to the Open Source Community, in that it fails to properly assess the requirements of ordinary end-users.

In the recent years that Open Source has gained credibility, it simultaneously attracted interests from commercial entities. These companies have developed various business strategies in order to utilize the benefits the community offers them. In return they do not necessarily contribute source code, as is usually the contribution received from private users. Nevertheless they do contribute, mainly by performing mundane tasks, tasks that are difficult to carry out in a peer production mode. And secondly by increasing the market for Open Source, which can result in a cycle of positive feedback and network externalities. Nonetheless a tense discussion in the community has aroused, questioning whether or not commercial entities fit in the network of ‘altruistic’ Open Source programmers. In fact their goal is to make money, which can easily contradict with the incentives of programmers.

This thesis will thus explore the commercial side of Open Source Software. The analysis will be structured around the central question “Can a clear division of labour be identified between the Open Source Community and commercial Open Source companies?”

Technology Market

OSS Compan y

Fig. 1.2. Expected Relationships between Open Source and for-profit organisations In this research question it is assumed that one can divide the Open Source Network in three: 1. The Open Source Software (OSS) Community, which has a focus on technologically innovating software development, 2. A market, which constitute of consumers of the software, but who are not skilled enough to actively participate in the OSS Community and 3. A commercial sector, which makes sure that the software is adapted to the needs of the market. Some readers, might prefer to use the term ‘for profit’ instead of ‘commercial’, nonetheless in this paper no such distinction is made. Secondly analysis continues towards the interrelations between the three groups. Companies have probably a much more direct relation with the market. This relation provides them with (valuable) market information. However their product is complementary to the Open Source Software. So probably they would like the OSS community to (partly) develop the software that the market requests. In fact

literature on innovation fosters the importance of communication, as the single most important driver for success. Within large (innovative) organisations it is of utmost importance to have intense communication between marketing and the R&D department. Marketing is there to gather information on the wishes and needs of the consumers, and R&D is to translate this information to developments in technology. Together they should find a balance between technology push and market pull. So how does the commercial sector communicate these market needs to the OSS programmers? Implicitly this thesis thus also questions whether the statement “users are developers”, which is often referred within Open Source, implicates that users are identical to the market. Or counter wise that the term users refers only to a limited group of sophisticated users. With the help of this framework (OSS - Market - Companies), analysis continues. At first concerning the question whether the commercial sector operates complementary to the OSS community. In fact is it possible to make a clear distinction between the OSS community and the market? And do companies then provide services aimed at skilled customers, or rather for the mass market?

o Can one distinguish between market, OSS community and for-profit organisations, with a clear division of labout between the latter two? o “Users are developers”; Are users the market?

. 1.3. Paper Structure To answer the main question: “Can a clear division of labour be identified between the Open Source Community and commercial Open Source companies?” a number of additional questions are stated.

 What tasks and functions exist in the development process of Open Source Software?  How does the OSS community function?  What tasks are carried out in the peer production mode?  Why are companies involved in Open Source?  Why does the OSS community need or not need the involvement of companies?  What task do for-profit organisations perform?  Can a distinction be made between a group of Open Source developers, a commercial sector, and thirdly a (mass) user-market? o “Can a clear division of labour be identified between the Open Source Community and commercial Open Source companies?”

By means of answering these intermediate questions and a small research it is tried to give an overview of all the factors involved and provide an answer on the research question. Furthermore the structure can be divided into two major parts. Chapter 2-4, providing an extensive and broad literature survey into Open Source and for-profit involvement. And Chapter 5-6 providing analysis and case studies. Per chapter this study is structured as follows:

 Chapter 1 provides an introduction to the research question  Chapter 2 is a detailed but simultaneous broad description of Open Source, focussing on the organizational structure and incentives for individuals to contribute to the public domain.  Chapter 3 discusses theoretical concepts. Starting with a short overview of theories underlying the Open Source movement especially on information and networks. After which the focus shifts and becomes more specific when dealing with the organisational structure.  Chapter 4 provides a detailed descriptive overview of business activities for Open Source. In this chapter it is asked what ties commercial companies have with the Open Source Community. The chapter introduces the motives of commercial companies to be involved in Open Source Development and secondly their respective business strategies.

 Chapter 5 gives an overview of the literature survey, organised along the subquestions. The various answers frame expectations for the cases, and form the basis for the propositions.  Chapter 6 will introduce the Debian- and Red Hat/SuSE cases and analyse the propositions for appropriateness in the context of these cases.  Chapter 7 is the conclusion.

. 1.4. Limitations & Methodology As will become clear from this thesis, commercial involvement in Open Source is multiple. It ranges from large multinationals to small ventures and its strategies vary from being a support seller, a platform intermediary to widget frosting. Some companies find their origin directly in an OSS project, while others joined in a latter stage. It is impossible to discuss all options in this thesis paper. Therefore some limitations confine the scope. First on the side of the commercial companies the research is limited to activities of support sellers. Their main activities include retailing/distribution, software support, and publication of manuals, consulting, and training. This choice has been made for a reason; one might point at the importance for Open Source of their alliances with e.g. IBM or HP. Indeed this relationship might well turn out more influential. Nevertheless their motives originate as much from business opportunities as from business strategy, more specific an anti-Microsoft agenda. While support sellers are founded directly because of opportunities available within Open Source.

Secondly on the side of Open Source Projects the research will be limited to Linux. Linux might not be the most suitable, since the (PC - OS) market is still dominated by Windows, and users are thus more likely to include only skilled users. It is at the same time one of the most successful and furthest developed Open Source projects. The like it is expected that also companies involved with Linux have been given time to mature. Thus ‘companies’ in this thesis is as narrowly defined as support sellers for Linux. Where OSS in the research part of this thesis is as narrowly defined as the Linux Operating System (OS). Finally marketing in this thesis is referred to as a set of tasks including branding, distribution & retailing, consulting & support, publication of manuals, and identification of consumer needs.

In order to distinguish the differences between OSS project and commercial projects it is opted to compare two similar activities. Debian on the one hand is the non-commercial Open Source project, and Red Hat/SuSE are its commercial counterparts. The Red Hat/SuSE case is not an ‘one-company analysis’, it is rather an analysis of half a dozen of highly similar ventures. It is opted to examine this entire group, rather than a single company, especially because it provides additional insights. In fact within this group of companies there is a clear distinction between a market leader and the others. This market characteristic influences the various relationships. Both cases. Debian & Red Hat/SuSE are software distributors for Linux, so their activities are directly comparable and both ventures have strong ties with the Open Source Community at large.

. 2.0. Objectives  To understand the concept of Open Source.  To acquire a broad understanding of the functioning of an Open Source Project.  To answer subquestion 2 and 3.

. 2.1. Introduction Linux, Apache, Sendmail, Perl, Bind, GNU, Emacs and also the HTTP and TCP/IP standards are well- known, or at least widely spread, examples of a kind of software development that has gained a reputation during the last decade: ‘Open Source Software’ (OSS). Advocates of Open Source claim that Open Source Software development is more efficient, more innovative and will lead to better quality software, and therefore that it will become more and more influential over time. Open Source1 is not new, its growth has accelerated since the introduction of the Internet, which has decreased costs for distribution, cooperation and coordination, but predecessors of OSS are to be identified since the early days of the computer age. Moreover in the decades after 1945 a considerable amount of software was developed as OSS between universities like Berkeley, MIT and corporate laboratories as Bell Laboratories and Xerox Palto Alto. Over time this community of programmers developed its own patterns, norms and values, eventually evolving towards a culture, the so-called ‘hacker culture2’. Organizations like the Free Software Foundation (FSF) and Open Source Foundation (OSF) got established, to formalize and support the community.

Nevertheless its significant growth over the past decade, it should be mentioned that Open Source Software still covers only a very limited part of software development, most common software development still includes in-house software (e.g. for financial institutions), or software developed for highly specific aims (e.g. controlling software for a microwave oven), and even more programmers are busy maintaining existing (proprietary) software systems. Simultaneously one should realise that software is applied in a dizzying range of products. Not all kinds of software development are suitable to be developed in and open environment, as will become clear. Even if Open Source Software does exist in a particular market, it not automatically means that it dominates the market. By far, even a successful product, like Linux, is confronted with a close-to-monopoly competitor, who has an over 95% of market share for pc operating systems3.

This chapter is supposed to be a descriptive introduction to Open Source, by two main tiers of structure and incentives it is tried to provide an overview of what OSS is about. It deserves hereby a note of caution that a considerable part of the literature concerning Open Source, which is also used in this paper, is written by people from within the community.

. 2.2. Definition What is Open Source Software? In essence it is software of which the source code 4 is made public. This implicates that other people are able (and allowed!) to copy, redistribute and modify the code/program. Open Source is synonym to Free Software5; Free software has in name nothing to do with free, where free is concerned with price, on the contrary distributors are allowed to ask a price for a copy although

1 The term Open Source Software is only in use since the early 1990s, http://www.opensource.org 2 note that a “hacker” is not somebody that breaks into computer systems or is guilty of piracy. This mistake is often made by popular press, but in such a case it is more correct to talk about “crackers”. Barber (2001, Hackers Profiled, Computer Fraud & Security 2: 14-17) distinguishes between script kiddies, hackers and crackers. Hackers are motivated by curiosity, where crackers (try to) create serious damage. 3 Linux has around a 1/3 share in the operating system for computers that host websites (netcraft.com). 4 The source code is not the binary code, the one’s and zero’s readable for computers that are distributed when a software package is distributed. The source code are the actual instructions a programmer has written, and which is readable by humans and of which the binary code is derived. 5 The difference between these two is only a matter of definition and philosophy; some argue that the name change was prompted for marketing reasons; I would like to leave out that discussion and refer an interested reader to publications from both Richard Stallman and Eric Raymond.

this does not occur frequently, free should however be interpreted as freedom, as in freedom of expression6. In the Open Source Definition - as provided by the Open Source Foundation7 (OSF) and which is supplied in Appendix 1 - it is explicitly required that anyone is allowed to copy, redistribute and modify in order for a project to be coined Open Source. Since programmers make their code public, it becomes nearly impossible for programmers to receive direct monetary rewards for the code they write. A lot of development in Open Source is therefore based on involvement of programmers on a voluntary, and often individual, basis. Programmers cooperate virtually, by means of emaillists, buglists, FAQs, howto/readme documents, IRC and discussion forums. “Users are Developers” is a popular expression to indicate the point of gravity of OSS. In the next paragraphs the incentives for people to contribute, the organizational structure of Open Source projects, and the role of intellectual property rights will be discussed. Open Source is one example of what is referred to as a process of peer production. Peer production is a mode of organisation of economic activity in which not a market system of demand, neither a hierarchical command structure, but personal incentive of every individual contributor lead to an efficient allocation of resources (a.o. Benkler 2001). o Open Source: everybody is allowed to copy, redistribute and modify. o Users are developers. o Peer Production . 2.3. Proprietary Software Proprietary closed software is to be found opposite of OSS. Currently a majority of software development consists of the proprietary kind. In between open and proprietary software are different kinds of software located like public domain, freeware and shareware software. Closed software is software of which the source code is kept secret, or protected by Intellectual Property Rights (IPR). The only part of the software made available to customers is the binary code (0/1’s) what enables a user only to run the program; a consumer does not actually buy the product, one only pays for a right-to-use license. The products of the Microsoft Corporation are likely to be the best examples of this kind of software. The programmers, - read Microsoft -, are able to retrieve (huge) direct financial rewards from the written code, exactly because they do not allow others to copy, redistribute and modify. Problems for users with proprietary software include incompatibility, whereas this problem in OSS is easier to overcome since most Open Source projects are based on standards and users have the ability to overcome incompatibility by means of the accessibility to the modifiable source code. On the other hand can incompatibility lead to a strong market position by using the principles of network externalities, lock-in and switching cost. In the next chapters of this thesis these principles get greater attention and it will be explained why it might sometimes be a sensible business strategy to give up a proprietary position for an open position, and why in other cases it is not. o Proprietary closed software is kept secret.

6 Source: http://www.fsf.org/philosophy/free-sw.html 7 www.opensource.org; A problem is Free Software Foundation.

Fig. 2.1. Categories of software, Gacek (2001)

. 2.4.1. Attributes of Open Source Various authors list a number of key attributes of Open Source that make it possibly a feasible competitor for proprietary software. Their main arguments include:  The fact that the user has access to the source code and is allowed to work with that code, gives the users control over the functioning and quality of the code, this is especially of importance when people would like to use the software for highly specific purposes.  Secondly OSS is considerably cheaper compared to closed software, since the human capital is provided on a voluntary basis and other overhead cost are likewise kept to a minimum. Often one can even download the software for free over the Internet. This implies also that improvements in the program can be obtained easily, giving ongoing access to new features, which is not often the case for the proprietary counterparts.  Because the developers are at the same time users of the software, it is believed that the features included in the software packages better resemble consumer preferences. It is believed that proprietary software houses, especially in times of rapidly developing technology, have difficulties in properly identifying the consumer’s needs, or that the cost of obtaining information about such needs is too costly. Pfaff and David (1998) claim the relation in Open Source to be directly reciprocal (developer <-> user), where closed source encourages partitioning of the users and developers (developer <-> firm <-> user) and to introduce (marketing) intermediaries with own agendas. Obviously this touches on the heart of this thesis, and this discussion will return. Pfaff & David (1998) mention furthermore that closed source software houses rely on their brand. When bugs occur, the likeliest strategy of such a house would be one of denial. Additionally leaving bugs could possibly lead to a profitable after-sales service, reducing the incentive to fix (all) bugs.  Development of OSS occurs at a faster pace then development of closed software, because the group of (potential) contributors is larger. This is a general statement, it is first of all limited to the scope of OSS; Open Sourcing does not occur in all different fields of software development. Secondly it is not always true; there are lots of projects that have only a small number of contributors, and due to that have a slower development cycle.

 Finally security is enhanced. Open Sourced security, e.g. algorithms 8 for encryption, are more difficult to crack, since many eyeballs co-developed; many programmers, with full knowledge of the tactics used, tried to crack or see possible flaws, pointing out these weak aspects gives way to improvements, where closed source security relies on a policy of secrecy, with tactics and code only to be checked by a small number of developers and sometimes a number of beta- testers.

o “OSS is cheaper, better and is developed faster?”

2.4.2. Negative Attributes; A word of caution Next to the positive attributes of Open Source as mentioned above, there are simultaneously some flaws. In fact today most people are not using Open Source. Some reasons for this include the lack of compatibility of Open Source with some leading proprietary equivalents, the lack of support for Open Source Software. But also the fact that many people are not aware of the advantages of Open Source, or even its existence and the fact that proprietary software is often packaged together with hardware. In fact most people buy a pc with a pre-installed version of Windows.

Furthermore it was stated that Open Source it is cheaper, but this just referred to the price a user pays for the license. However anybody, especially companies, should take many more costs into account, when making an assessment for the preferable software. Costs for hardware, updates, training, support, migration and implementation should be included. An answer to such a complicated calculation of the Total Cost of Ownership (TCO) cannot be easily generalized.

. 2.5.1. Structure of Open Source Projects

2.5.1.1. Meritocratic Hierarchy Open Source Software is characterized by volunteer production. Since volunteers cannot be commanded to do certain tasks, it implicates that a project should be organized very decentralized. Often Open Source is thought of being a kind of anarchy9. Anarchy, however, is not a proper description of the structure of an Open Source Project. From this paragraph it will become clear that these projects have a hierarchical structure as well. This hierarchical structure needs not so much to be formal, rather is it often a result of unwritten rules, norms, and practices from within the hacker culture. According to Raymond (1998) a project starts with a programmer ‘scratching an personal itch’. This programmer starts out writing an initial code base, in order to provide a start for fellow programmers, and in order to create a credible goal for what the project is about. Note that this credible goal is like an idea and is therefore different from formal planning. Usually planning, just like time-to-market pressures, are lacking in Open Source Projects at all stages of the development process. On the basis of the initial idea, other programmers are expected to join such a project only if their personal needs are in line with the project’s goals. Usually this initial programmer becomes the project leader, who is assigned the task of selecting the code of others that is included, and managing the overall project. Raymond (2000) refers to this leader as a “benevolent dictator”, indicating that it is impossible in a larger group to cooperate on a basis of fully democratic principles. The power of the leader is however limited, and a good leader should ideally try to act from a group consensus view. Moody (1998) states that this consensus view does arise from advices from experts and specialists, rather than e.g. a general opinion poll. When a project grows larger, a single leader is not likely to be able to manage the entire project. Apache and the KDE project for example do not have a single leader, but work with an advisory committee of approximately 20 people, who decide by voting. Other members of the project might be assigned the task of selecting the code for a specific part of the project. These people are usually selected

8 Algorithm: a logical sequence of steps for solving a problem, often written out as a flow chart, that can be translated into a computer program. (Encarta) 9 For example: Sawhney and Prandelli argue that the OSS community, since it is such a completely open and chaotic market, is instable, and therefore ineffective for innovative projects. (Crowston & Scozzi, 2002)

on the basis of their past contributions, and thus their reputation. Open Source Projects are thus meritocracies, hierarchically structured on the basis of skills and effort, measured by the ‘merit’ of your peers. Next to the development path that is described by Raymond, an Open Source can also be the continuation of a closed source project. Netscape for example (mozilla.org) decided in 1998 to open the source of their browser and to continue development as Mozilla10.

2.5.1.2. Developers In larger projects one can identify three categories of developers. First of all there exists a small group of core-developers and project managers. A larger group of programmers. They often contribute occasionally or just once, most often because of a personal need to solve a particular problem. And finally there is a large group of users and beta-testers, which identify bugs, that are afterwards solved by programmers or core-developers. Analysis by e.g. Lakhani and Von Hippel indicates that the number of contributions are highly skewed towards the small group of developers, accountable for the vast majority of postings, however this does not suggest that groups of beta-testers are not valuable, Raymond (1998): “if you treat your beta-testers as if they are the most valuable resource, they will respond by becoming your most valuable resource”. It is nevertheless interesting to note as Johnson (2001b) does that where in conventional management, management generates a distance between their job and the actual production, where in OSS the management consists of the most active programmers.

Fig. 2.2. The classification of Open Source Developers, Source: Gacek et all, 2001

2.5.1.3. Forking Whenever a leader is not able to reach consensus, or is heading in a direction that is not favoured by some other developers, a risk for forking exist; a group of developers may independently pursue a different path of development. Forking is a major concern for OSS. Consequences are mostly negative

10 Incentives for programmers are important. They want to see a payback. This payback can be a running system. Therefore most projects do not start from scratch, but with an initial program that sends a promising goal. It is really difficult to attract programmers if they do not easily see direct improvements. It is far easier when there is a workable version and people make improvements upon that. This story is in practice told by the Mozilla case. Where according to early contributors like Jamie Zawinski (1999) there was a hugely interesting pool of code, but not useful for an individual to really operate a system with it. The fact that Mozilla was able to recover and did not slowly vanish, because of lack of contributors can be attributed to the fact that some programmers were paid by Netscape to work on Mozilla and were able to re-attract the attention of Open Source developers.

and include duplication of work, and a decrease in the group of potential contributors 11. In some cases it might be positive in the sense that a specific software product for a niche market comes about12. o Globally dispersed network of volunteers o Scratching an itch o Hierarchical Structure o Meritocracy o Benevolent Dictator 2.5.1.4. Software Development Model In his famous article “The Cathedral & The Bazaar”, Eric Raymond (1998) describes two modes of software development a) the Cathedral model, and b) the Bazaar Model. In the Cathedral Model production is organized in as a sequential process: “Software needs to be built like cathedrals, carefully drafted by individual wizards or small bands of mages working in splendid isolation, with no beta to be released before its time”. Before the early 1990s this was the prevalent way for developing software, still today most proprietary software is developed using the Cathedral Model. It is assumed that an early release of still buggy software would wear out the patience of its users, and it would negatively influence the image of your product and brand name. Furthermore it is assumed that it is needed to keep development groups rather small, since otherwise adding new developers would lead to increased complexity and to duplication, rather than faster development cycles. This last point comes back in the so-called Brook’s Law, “The idea is that many tasks can only be performed sequentially and that, task by task, more programmers need not hasten progress” and Hasler’s Law, which state that “the costs of duplicated work tend to scale sub-quadratically with team size – that is, more slowly than the planning and management overhead that would be needed to eliminate them”. The Open Source Community, and more notorious Linus Torvalds, the initiator of Linux, adopts a distinct view. Linus’ Law for example “given enough eyeballs, all bugs are shallow” clearly indicates that they prefer both a larger development group, as well as to release buggy beta-versions. In their opinion development and innovation occurs more rapidly when bugs are exposed, since it is very likely that at least somebody has immediately an idea of how to solve the problem especially since everybody has a different set of skills and perceptions and thus a different way of dealing with a problem13. This concept is referred to as peer-review and parallel debugging, and contradicts the sequential process of the ‘Cathedral Model’. Raymond refers here to the Delphi Effect14, where the average opinion of a group of equally expert people is on average better, than the opinion of an at random picked single user. This distinct model is coined the Bazaar Model.

2.5.1.5. The Bazaar Model: Modularisation The Bazaar Model results in a very decentralized, very granulated and very modularised mode of development. Bezroukov (1999) criticized this model for being too simplistic; he proposes to compare Open Source with academic research in combination with a Darwin like model of evolution. Modularisation makes it possible for a project to be divided in small, relatively autonomous subtasks, and granularity determines the size of an individual contribution to a module. Together they determine

11 This is not in contradiction with the earlier statement that standardization and Open Source prevent incompatibility, since the essentials of forking is that two parallel path of development are chosen. With a lot of effort, features of both systems can be integrated, however this would be inefficient. 12 Oliva (2001) correlates forks in OSS with forks in nature. In biology forks are a probing into the future, the resulting diversification is reduced by the Darwinist survival of the fittest. In OSS, forking leads to re- implementation of similar features drawing heavily on limited resources, which reduces the survival chances of each variant. 13 A typical bug fix contribution of a volunteer programmer generally follows this path: 1. a volunteer identifies a bug himself, or decides to fix a bug identified via a bug list. After downloading his copy of the source code, he starts to modify. The end results he collects in a patch file. A patch file states the old and the new code, and points at the modifications in the different files. This patch, together with a short introduction, is then distributed to the developers mailing list. The patch is reviewed by others, and eventually makes it into the source via a project moderator. (Johnson, 2001b). 14 Delphi effect is a concept used in sociology.

how interdependent these modules are in the integration process; thus whether the modules have to be finished either sequential or that it is undefined which module has to be finish first. This modularisation and granularity is of utmost importance to peer production, with it, even massively complex tasks can be accomplished by a large group of just partly knowledgeable participants, and exceptionally even non- expert15 volunteers. The Linux case has for example been analysed by Godfrey & Tu, and although with over 2 million lines of code one expects to have an uncontrollable vastly complex project, they argue that Linux is far less complex then at first sight might appear.16 Instead Linux is highly modularised. It remains however a fundamental question how Open Source will able with ever-larger projects. Huge increases in communication (mailinglist) activity consumes time that programmers could have spend otherwise on programming, and it appears that Brook’s Law at least partly still holds for Bazaar style projects. o Brooks’ Law o Cathedral Model vs. Bazaar Model o Given enough eyeballs all bugs are shallow o Modularization

Fig. 2.3. Godfrey & Tu, (2001) Linux is less complex than it initially appears to be. Drivers are bunches of code, very much independent from the rest of the code. The core kernel itself is one of the smaller other subsystems. Gall et all. (1997) Indicated that although the system as a whole might evolve more slowly, when the system becomes larger and more complex, this not necessarily is true for its different subsystems, one should thus not solely focus on the topmost level.

Fig. 2.4. Godfrey & Tu (2001), The Beta version furthermore witnesses an increase in the number of files, most likely due to new features, while in the stable release the average file size is increasing, likely to be a result of implemented bug fixes.

However most volunteer programmers need to posses expert knowledge, and since many of them have also a regular job in software engineering, most do. It remains however a question how knowledge about a certain project is transmitted. Where in a business environment one would get a mentor in the initial phase of collaboration, a mentor is absent in Open Source Development. Programmers need to be auto- didactic, making use of the source code and historic discussions in the various forums and lists in order to catch up and understand the system. As is said, bazaar style developers prefer to release ‘early and often’; this does not mean that the resulting software is by definition buggy. Most often there are two release paths, a beta and a stable release. Where the beta version is more advanced and with a more extensive array of options, but with the risk of being buggy, and a stable version for ordinary users. By now most fundamental aspects of structure of Open Source projects have been touched upon: Open Source thus is not anarchistic but hierarchically organized, where the hierarchy depends on meritocratic 15 NASA Clickworkers Project for example let ordinary users categorize craters on Mars, the law of high numbers ascertains that mistakes can be filtered out. 16 The size of the Linux kernel is kept to a bare minimum. Most code comprises of drivers, which are highly autonomous bits of code.

principles. Organization of development occurs along the Bazaar model, with high modularisation. In the next chapters the discussion about the structure of Open Source will be extended with a focus on the self-organizing network structure that, next to a hierarchy, emerges within projects.

2.5.1.6. Sophisticated User Bias and the skewed product range of OSS At the end of this paragraph a few additional remarks about Open Source in general are useful. First of all it has to be understood that software in itself is knowledge and that production of knowledge often coincides with innovation. Open Source, especially, is suited to engage in the innovative production of knowledge. Actually it is interesting to note that most OSS projects are sophisticated-user biased; the products are made by the most expert users, and at the same time aimed at these expert users, often creating barriers for ordinary users. Raymond (1998) even claims that only the best 5% of the experts are self-selected to work on OSS. Simultaneously claiming that traditional management is redundant, since its task in traditional software houses is to coordinate the other 95%. The product range of Open Source is skewed towards operating systems, protocols, standards and servers, whereas user-application projects so far were mostly lacking or of non-superior quality. The same goes for games17, which are almost completely lacking. This seems to be a logical consequence, regarding the incentives of programmers. In fact it has been concluded that they carefully calculate their pay off, and often need the program privately. Why then would one develop a computer game; it is no fun at all to play a game where you yourself know the precise outcome, and all the tricks. The skewed product range has proven to be a major hassle in user acceptance in the mass market. Where Microsoft products are easy to install and use, Linux might be more sophisticated but on the other hand it requires at least some knowledge to install and operate, and one still lacks some end-user applications. This barrier for ordinary users is enlarged by the fact that a programmer’s reputation is more enhanced by solving a difficult bug, as compared to answering an end-user question, or writing documentation. The voluntary nature of incentives seems to work well in difficult and exciting tasks, but far less for mundane tasks, like the ones mentioned before.

o Sophisticated user bias o Highly skewed product range, with a focus on operating systems, and infrastructural standards.

2.5.2. Organisation of Production: Peer Production One view on Open Source that deserves its own paragraph is that of Yochai Benkler (2001) with his article: ‘Coase’s Penguin, or, Linux and the Nature of the Firm’. The article handles about Open Source from a view on production methodologies. For long economist have pointed out the benefits of a division of labour, where by means of specialization, production becomes more efficient. In such a case the issue of allocation of resources and the organization of production must be solved. Ronald H. Coase (1937), in his book ‘The Nature of the Firm’, describes two modes for the organization of production. The first one being the market, where the price mechanism, demand and supply take care of an efficient allocation of resources. In the market the ‘invisible hand’ of Adam Smith, as discussed in the preface, is at work. The market functions very well especially for commodities; the only information that one needs from (unknown) others is the price. However in some cases the market system is too costly, the transaction cost are too high, or one needs too many transactions to reach an end. Therefore Coase identifies a second option, which is to have production organized by means of firms. Firms are organized hierarchical, so it also referred to as hierarchical organization. In a firm the actions of different people are co-ordinated by a manager. A firm, as entity, can be a market-participant though. Benkler (2001), argues that for the production of knowledge goods, both the market and the firm system might be too costly, and he points at a third possibility for the organization of production: peer production.

17 Computer games are important in order to gain user acceptance from the masses of desktop pc users.

No property more costly than Property implementation more costly implementation costs of property than opportunity cost of no-property (using IPRs) Market Exchange of x cheaper than Pure market (farmers market) Pure commons (ideas & facts’ organizing / peering x highways?) Organizing x cheaper than market Market with firms Common property regimes (Swiss exchange or peering of x pastures) Peering cheaper than both market Proprietary “Open Source” efforts Peer production process18 (free exchange and organization (Xerox’s Eureka) software; academic science; NASA clickworkers) Table 2.1: “Organizational forms as a function of relative social cost of property vs. no-property and firm-based management vs. market. Copied from Y. Benkler “Coase’s Penguin, or, Linux and the Nature of Firm” 2001

Open Source Software is one example of peer production, as will become clear, this mode of production is in principle suitable for a wide array of information products. Besides other Internet-based projects like the Open Library Initiative, the Open Directory Project19, Slashdot20, Project Gutenberg21, and NASA Clickworkers22 is Academic Research probably the most notable example. Unlike the other examples, does academic research have an extensive historical track record. The basic elements of academic research are shared with Open Source. Contributors are not receiving direct financial rewards for their contributions; they contribute articles to academic journals, while their wage is usually a fixed sum of a university, only indirectly related to articles that appear in academic journals. Broadcasting their findings generates feedback (critics) of colleague researches, which also use the obtained knowledge for further research (references).

What ultimately should be clear is that peer production is the better option, when both market and hierarchical organization are more costly. This knowledge is useless, unless we are able to identify what it is that makes peer production more efficient. According to Benkler (2001) peer production has four attributes that make it a suitable alternative for information production: First being the fact that information is both a purely non-rival product and because it is primary non- human input is information itself. Both characteristics will be extensively covered in the next chapter. Secondly he argues that the introduction of cheap-processor-based computer networks have significantly decreased the amount of capital required to produce information. A third factor is that the human input for information is highly variable. He states that it is only the individuals who possess the necessary information about their personal talent, motivation and focus for a specific production task. Others will have severe difficulties assigning the right people to the right task. He thus does indicate a mismatch, which does occur in the market and within firms. In fact, in a market demand is not determined by the individual, nor is in the allocation of human resources in a firm determined by the individual, more likely a manager determines it. Benkler states that the manager, and the individual demanding in a market do not have the right or ‘perfect’ information. Peer productions main attribute is in acquiring and processing information on human resources.

18 “Cost” here would include the negative effects of intellectual property on dissemination and downstream productive use. 19 Open Directory Project is a project of AOL, where users voluntarily contribute and maintain a collection of links for a single topic. For Dutch readers: it is comparable to startpagina.nl. 20 Slashdot is an online-newsagent. Everybody can contribute articles of interest for the community. At the same time everybody has a rating attached to himself, based on past contributions and valuations by others. The contributed articles are then ranked on the basis of that rating, and simultaneously others can value the contributions, affecting the article and contributor’s ranking. Example taken from Benkler (2001) 21 Project Gutenberg is a project to digitalise books. Books, of which the copyrights are lifted, are automatically scanned, and afterwards volunteers proofread the books in order to correct mistakes made during scanning. This task is perceived as very mundane, but still the project is able to attract volunteers. Example taken from Benkler (2001) 22 NASA Clickworkers is a project in which everybody marks and categorizes craters on the Mars surface. This is a job formerly carried out by academic staff, but with the help of automatic averaging, errors from non-experts can be easily circumvented. In half a year some few millions contributions were received. Example taken from Benkler (2001)

A fourth and final attribute is that communication and information exchange has become both less expensive and much more efficient. In other words the technological advances in ICT, which provide an opportunity to co-ordinate for example widely distributed sources of information and human capital and afterwards the integration of these sources in a single output. o Market, Hierarchy, Peer Production o Labour market information assymetries.

Most interesting in Benkler’s view is the third attribute. The next section will devote attention on the question “why” people would contribute. Benkler regards this not to be the central issue, when the cost of contribution are low enough, and when the population size is big enough, there is always somebody willing to contribute. “Given a sufficiently large number of contributions, incentives necessary to bring about contributions are trivial.” is his personal interpretation of Linus’ Law23. The strength of the peer production system as compared to either a market or hierarchical system is that the (human) resources are not allocated on the basis of price or command structures, but rather directly by the individual, who has the best knowledge about his skills and preferences.

2.5.2.1. Limitations: co-ordination Benkler (2001) continues to indicate what the actual issue is in peer production, not the incentive to contribute, but rather the minimum size of the contribution: “Peer production is limited not by the total cost or complexity of a project, but by its modularity, the granularity of its components, and the cost of integration.” This statement is similar to what already has been concluded in the first chapter on the basis of Lerner and Tirole (2001) that the quantity of contributions is strongly depending on the cost of contributing. However the statement of Benkler is more extensive. It emphasizes the cost of integration as well. Above, the ability of peer production to co-ordinate the sourcing and integration of human and information inputs into an end product has always been assumed. However this co-ordination effort requires closer attention. A collection of contributions is only valuable when it together makes up one end product. The task of integrating all the different contributions is difficult for all individual contributors themselves to arrange. A mechanism is needed that carries this task. Inherently an increase in the number of contributions is likely to increase the burden on that mechanism, and thus to increase cost of co-ordination. o Limitations of peer production are the degree of mularization, granulity and the cost of integration

23 “Given enough eyeballs, all bugs look shallow” (Raymond, 1998)

“Open Source wants not to be consumed, but to be networked.” Popular saying, source unknown

. 2.6 Incentives OSS is based on a development model without firms, but with independent individuals spending their leisure time developing for Open Source Projects. Why would programmers voluntarily contribute to a project? In fact they do not only not expect direct financials rewards, they even incur opportunity cost; the time they spent, could have been used differently, e.g. for a money-making activity. This question of incentives has been discussed widely in the literature. It is important to understand incentives to contribute, when determining whether users free-ride or not.

Returning to the era of the Free Software Foundation in the mid 1980s, an emphasize on a philosophy of freedom can be found, and therefore one could easily come to think that programmers are only induced by social motivations and base their contributions on incentives like altruism. Stallman 1999, for example says: “The idea that the proprietary software social system – the system that says you are not allowed to share or change software – is unsocial, that it is unethical, that it is simply wrong may come as a surprise to some people. But what else can we say about a system based on dividing the public and keeping users helpless?” The Open Source Foundation in the 1990s disagrees and declares that exactly this ideology is where the FSF and OSF differ24. Altruism, most researchers agree, cannot count for all incentives. Altruism might be a motivational factor, but it is not likely to be one of the important ones.

Mainstream economic theory strongly defends the point that actors behave in a rational, non-altruistic, self-interested way, carefully calculating the net payoff, from the sum of benefits minus the sum of costs25 (Lerner and Tirole, 2000). Olsen (1965), even more extensive, states that “rational, self- interested individuals will not act to achieve their common or group interests” and thus have an incentive to free-ride. This seems true for motivations of Open Source programmers as for everybody else. The payoff needs to be positive, but not necessarily in terms of money, and not necessarily in direct rewards only. It could for some programmers include money, but as likely it could be somebody who fixes a bug or modifies a program, because he has a personal need for that modification (above we have concluded that control, the ability to modify, is an important part in the OSS-definition, which thus enables programmers to adapt programs for personal needs and benefits). By doing so, this programmer gains additional use value from the program. He might keep the modification to himself; maybe even try to sell it. However in the last case he would run into trouble. First because his modification is an information good; it is difficult for outsiders to assess its value, especially if the outsiders cannot rely on a reputation from the past. Furthermore if a transaction would occur it usually would involve payments at a micro level. When all contributors to an Open Source project would need to be credited by these micro-payments, transaction cost would sky-rocket, obstructing development. In effect it leaves the programmer with the option either to keep to modification secret, or make it public for free. The last option has three possible outcomes. The first outcome is not exactly fitted to this example; it is an outcome when larger companies decide to turn to Open Source. In that case a possible competitor could use the modification without having to pay for it. This would enhance his competitive position, and in such indirectly harm the original developer. Also in this case the investment made to create the code should be regarded as sunk cost, however. A second outcome could be that the programmer neither wins nor looses. Nothing really happens with his code, but he has not lost anything either. The third option is that the programmer gains by an improved software program, due to downstream contributions of third parties, and/or by an enhanced reputation. In most cases the costs of contributing are really low, which makes that with a few benefits on the payoff side the outcome of the equation is often positive towards contributing. o Philosophy of Freedom o Rational & self-motivated behaviour. o Payoff = current benefit - current cost + delayed benefits. 24 bron ???? 25 Lerner & Tirole (2000) payoff = immediate payoff (current benefit minus current cost) plus delayed payoff.

Eric Raymond (1998) argues that reputation is the return contributors earn. Reputation can be an end, but it can also be exchanged for something else valuable. Clearly if our programmer in the example above keeps the code secret, he will not gain any reputation. If somebody after him would produce a similar modification and open the source for it, this would mean that the proprietary value of the code is zero. Not publishing does not gain anything; he might have missed the opportunity to enhance his reputation though. So, in theory, a programmer should also assess the likelihood of other people having similar skills and producing a similar product in order to define his strategy (Lakhani & Von Hippel, 2000).

Reputation as identified by Raymond is also by most other authors recognized as the single most important incentive. Reputation has strong correlations with trust, a reputation signals trust, or in some cases distrust. Reputation and trust arise both from past events, in the case of Open Source, from contributions in the past26. A reputation is both serving as an ego-gratifier, and can also be exchanged for valuables. Reputation does serve as a reward mechanism, others, including the community at large, provide this reputation. The mechanism is also able to direct the behaviour of individual programmers. In fact reputation is the reward for fitting in the community, when somebody does not comply with the communities’ beliefs and values, his reputation is likely to suffer. In the case of OSS it for example issues subtle pressure not to fork on existing projects (Raymond, 1998).

Lerner & Tirole (2000) strongly focus on signalling incentives27 and delayed payoffs. The desire from a programmer to be recognized by his peers, the ego gratifying incentive, and the career concern incentive, that by contributing his source, possible employers gain a clear ‘signal’28 of a programmer’s capabilities and might be willing to offer a job. An important characteristic of Open Source projects, for this, is that the contributing credits are always mentioned and traceable.

o Reputation is the currency o Signaling incentives

Reputation is an extrinsic motivational factor. On the opposite of the continuum there is intrinsic motivation29. One can enjoy programming, enjoy the intellectual challenge of fixing a bug, having a sense of efficacy, especially when working at the state of the art of software development. Another intrinsic motivation that is rather important is ‘to learn’. By joining a community of programmers, the environment offers opportunity to gain new knowledge30 and skills, which in turn represent an increase in your human capital. Linux, in specific, has been used extensively at universities for training purposes,

26 Reputation is not necessarily directly related to the specific past contributions. Especially for initiators of Open Source Projects count that “the world at large will treat you like you did every bit of the invention yourself”. Raymond (1998, Cathedral & Bazaar) 27 A concept originating from writing by Holmstrom 1999 28 Further on in this thesis the issue of transparency will be discussed. For information as for human skills it is hard to assess the properties of the offered service. Transparency creates a sizable barrier to an efficient functioning of the market. Broadcasting your human resources in code, which can be compared, might make the market more efficient. 29 All authors refer here to Csikszemtmihalyi (1975,1990,1996) 30 Lakhani & Von Hippel explain that even mundane task as a user helpdesk for an important part rely on this incentive of their volunteers. Programmers read the questions and answers in order to acquire knowledge; they answer questions because they most of the time already know the answer, and therefore the cost of the contribution are low. In effect by contributing they not only help an information seeker, they also help fellow information providers. The research was based on an assessment of an Apache Newsgroup, and it interesting to note that the burden of matching is with the provider, for whom the match-up is merely a side effect of his learning effort. In this particular research 76% of the provider browse daily through the new postings. Lakhani & Von Hippel furthermore report a cost-benefit ratio of 35, posting takes a seeker approximately 11.5 minutes while 381 minutes are on average saved in problem solving time.

and interestingly not only did students acquire skills about Linux, they later on as employees often introduced Linux in their work places, enhancing the success of OSS.31 Most of the above motivations are not specific to Open Source, they as easily explain a contribution to proprietary software, except for the fact that in Open Source programmers can choose on what they work on, while if they work for a commercial company they are assigned a task; it is likely that the last category is not motivated as optimal, which is likely to affect the performance.

Furthermore some programmers mention they feel some kind of connection with the other programmers32. There is some kind of group feeling, and a commitment to the group. After becoming involved, some programmers feel a responsibility for a project which acts as a motivating factor in itself. Actually the ‘hacker culture’ is a fairly strong culture, and this strengthens these incentives. This group feeling might contribute to the reciprocity factor. Reciprocity is that one helps somebody, in the expectation to be mutually helped some other time. This transaction does not need to be specific, one individual towards another individual and the other way around. In fact in OSS projects mostly programmers are not acquainted to each other, in such a case generalized reciprocity is at work, one expect to be helped by somebody else, not necessarily the one, who he directly assisted. Finally it has to be mentioned that programmers work on Open Source projects, because commercial companies have assigned them. In such a case financial rewards obviously would enter the picture. Why companies do so, will be explored in upcoming chapters.

From this part the most important conclusion is that volunteers mostly do get some kind of indirect appropriation from their contribution, and secondly that the quantity of contributions is strongly depending on the cost of contributing33, and in general for OSS it applies that these costs are low. o Learning o Reciprocity o Self esteem

31 Lerner & Tirole “Alumni Effect” 32 Source: 33 e.g. Lerner & Tirole, Kollock, Thorn & Connely

. 2.7. Intellectual Property Rights In a world where commercial proprietary software and open software coexist one might wonder what prevents commercial entities from including Open Source code in their products, and with a number of extensions appropriate Open Source? In fact everybody is allowed access to the code. For some projects this is actually true, but most projects make use of licenses and thus intellectual property rights to prevent such infringements. There are numerous kinds of licenses of which GNU GPL 34 and BSD35 are the most prevalent. Open Source does not use the intellectual property rights for means of exclusion, rather many licenses use copyrights to protect the openness; the rights derived from the copyright are used to prevent others from using the software for non-open purposes. This tactic is referred to as ‘copyleft’. Some of the licenses act viral, meaning that any software that includes (parts of) the code is bound to the original open license. This means that if the developers of proprietary software decide to include some Open Source code, bound by this license, he agrees to open the code of the proprietary software itself. o Licenses o Copyleft

. 2.8. Threats to Open Source Software Before concluding this chapter a few sentences on threats that might negatively impact on Open Source Software. The first issue that deserves attention is an issue on intellectual property rights and in specific patents. Not only is software protected by copyrights, it can also be protected by patents, in that case, it usually are algorithms. Patents-holders are able to offer software, with features that are off limits for Open Source, which has it drawbacks on the attractiveness of Open Source. This however is not the biggest threat that patents make. The burden of research for a patent infringement lies with the producer. So, Open Source Projects are responsible themselves, not to include e.g. patented algorithms. It is still unsure who would be held liable, whenever such an infringement would occur. The liability for OSS has never been judged upon, and thus remains and open end. Currently the case that SCO filled against IBM draws much attention to the issue of intellectual property infringements. A second fear that is expressed multiple times is the risk that proprietary companies would try to hire away key developers with attractive offers. So far, no author was able to gather evidence concerning this topic. Some argue, contrarily, that companies encourage involvement in OSS, because of the skills and knowledge the programmers acquire. A third issue that obstructs the marketing of OSS is the hacker stigma it still bears, and Fear Uncertainty and Doubt (FUD) tactics applied by commercial software houses. Many do want you to believe that OSS is error-prone and risky, especially because nobody is responsible36. Personally I am a little sceptic concerning this point, and would like to regard is as just one other example of imperfect information, with which all customers have to deal regularly.

34 GNU General Public License 35 Berkeley Source Distribution License. 36 Hoffman

. 2.9. Additional academic views on Open Source Lots of authors have puzzled with the phenomenon of Open Source Software. A considerable part of the opinions have been discussed in this chapter. Some distinct or additional ones are collected here in short summaries to serve as a completion of the overview description of OSS. Cubranic (1999) regards Open Source to be an extreme example of globalisation. Globalisation is often identified with the business community, and although this paper deals with the sensibility of business strategies on Open Source, the topic of globalisation is not addressed in the analysis; it might be an interesting starting point for somebody else? Rishab Ghosh (1998) gives in his article ‘Cooking Pot Markets’ his view on OSS. He identifies that much of the transactions on Internet occur without money, and thus the monetary incentive. He suggests a rational and self-interested model with barter exchanges. The Internet could be regarded as a huge cooking pot: everybody is able to take out everything that is in there 37, since duplication cost of information are zero, and in return their own contributions to this cooking pot can be regarded as a kind of payment. A payment that is necessary because otherwise the pot stops ‘to boil’, something everybody is aware of. For Ghosh a contribution includes everything, from a state of the art paper, to a junk posting, to even the bare reading of a posting, is said to add value. Also any exchange of information is an act of trade, the currency in the case of a cooking pot is reputation, instead of euros. Johnson (2001) addresses the need for critical mass before OSS development can occur. He assumes that many programmers contribute because of a personal need for the final product, co-development is more efficient. Furthermore he assumes that every programmer calculates the payoff of contributing minus its cost, next the programmer also has an incentive to free ride, and thus assesses the chance that somebody else provides the contribution. Eventually Johnson argues that for a programmer with a high value-to- cost ratio it is often beneficial to start developing himself, instead of trying to free-ride. Simultaneously a high value-to-cost ratio also implies that the cost of development are generally kept low, and free-riding, - the chance that others develop -, in itself serves as a solution to prevent too much duplication. According to Johnson (2001) the usefulness of modularisation is depending on the population size; a small population size, would ask for a non-modular development path, since programmers would then be more or less forced to put effort in high cost, low value tasks, since otherwise the product at large would not be developed at all; this is somewhat equivalent to development occurring at commercial software firms.

o The Internet is a large boiling cooking pot o A programmer’s value-to-cost ratio determine its incentive to develop or to free-ride

37 Ghosh: “You are giving away a million copies of something, for at least one copy of at least one other thing.”

. 2.10. Conclusion This chapter has provided a general overview of Open Source. Open Source is software of which the source code is available, and where users are allowed to copy, redistribute and modify. Opposite of Open Source one finds proprietary software of which the code is kept secret. Programmers are expected to contribute their code back to the community, and thus one could say that ‘users are developers’. Licenses prevent people from appropriating the code.

Although developers contribute voluntarily and are globally dispersed, Open Source development is not anarchistic; instead it is a meritocratic hierarchy. In which software is developed making use of the peer review process in a Bazaar style model. “Given enough eyeballs, all bugs are shallow”. In this development process Open Source is not unique, such peer production process is used for various kind of information goods, most notably academic research. Peer production itself is a mode of organisation of production, which complements the market’s price mechanism and a firm’s hierarchy. It suggest that individuals themselves can best assess their potential for contribution, in doing so it overcomes information asymmetries. Motivation to contribute in that respect does not constitute of altruism, but plain economic principles, a balance of costs and benefits is applicable to nearly every contributor. In general the cost of contribution are really low. Actually this last point indicates a general cornerstone of peer production, and that is the requirement for a high degree of modularisation and granulity. Together with the cost of integration these two determine the boundaries of the system.

The product range of Open Source is highly skewed towards platforms, and operating systems. Furthermore it seems that the high-sophisticated user bias works favourable for the high quality of Open Source but seems a serious problem in reaching the mass market.

. 3.0. Objectives  To understand why Open Source has gained momentum.  To understand the fundamental economic principles underlying OSS development.  To introduce an array of possible interrelations between the market, companies and the OSS community.

. 3.1. Introduction The central question in this thesis is how the interrelations between companies, volunteer programmers and the market can be classified. The second chapter provided a first step towards an answer by providing a descriptive overview of various aspects of Open Source. In the next chapter, 4, the various strategies applied by businesses are considered. This third chapter provides the bridge between the two. This is a theoretical chapter, which describes the theoretical background behind Open Source initially, and gradually introduces aspects of the various interrelations that possibly occur. The discussion will start with an analysis of the software product, from a perspective of public goods. Afterwards discussions will shift a bit towards the organizational network structure of Open Source, in order to introduce the various concepts attached to “network externalities”. This broad economic discussion is succeeded by the introduction of organizational theory concerning a socio-technical network. The structure intends to first introduce the concepts that help explain why Open Source exists at all, and why it is plausible for companies to join; introducing concepts relating to information, public goods and network externalities. Only afterwards the basics of networks are explained, which are intended to explain what possible interrelations are present between different entities in the network; that is between the market, the development community and the collection of companies.

. 3.2. Information Most products in our society are private goods. This means that others can be excluded from use of the product, and secondly that scarce resources are necessary for its production, which makes them rivalrous. Some would argue that software is just as much a private good; in fact a software (license) is often sold as a physical CD-Rom by a software house. However it is easier to argue counter wise and state that software is a public good. In fact software is little more than information; an intangible, thus non- physical, good. Everybody knows that one can pass on information, without loosing it. So, in that sense it is non-rivalrous, one can copy information, and the second version is no better nor worse, it is not even different from the original. Copying, just like the distribution of information is not expensive 38, the cost can even approach zero, especially thanks to the recent developments in the area of ICT. When the cost of copying is zero, obviously the marginal cost are zero.

Nevertheless information needs to be produced. For the production, scarce resource inputs are needed, in particular human resources, but also capital in a lesser extent. But the single most important input for information remains information itself. Information is not only an end product by itself; at the same time it is thé essential input in the process to produce new information. The production cost of information is thus considerable, and it can be concluded that information has low or zero marginal and high fixed cost. The pricing of goods with these characteristics on the basis of costs is irrelevant. The price should ideally be equal to the use value perceived, and since this value is different for different groups, price discrimination would be favoured. Since the high fixed costs are endured during the production stages 39,

38 It is rather seldom that information is sold as information solely. Information in itself it is not a collection of atoms, it is a intangible good. Often information is included in e.g. a music tape or a book, which are both physical goods, and have positive marginal costs. In the 20th century manufacturing and distributing of the information carriers made up for a huge proportion of the monetary capital required for information production; a familiar example are record companies and movie studios. This made that the zero marginal cost of information, would in practice always be overshadowed by the marginal cost of the information carriers.

and not anymore afterwards, economies of scale are considerable. Every additional copy lowers the average fixed cost, which also means that first mover advantages are likely considerable.

o Software is a public good, not scarce, non-rivalous o Information produces Information

3.2.1. Free-Riding A pure public goods is non-rivalrous and non-excludable. It means that everybody will be able to benefit from the product, without anybody else having the opportunity to forbid one other to do so. However, where public goods like sunshine and air are provided to us at zero-cost, other (semi-)public goods incur fixed costs. If nobody is willing to pay for a public good, a public good is not provided at all. This leads to a sub optimum social situation. In fact the sum of all individual benefits is likely to be higher than the total costs associated. Therefore in an ideal situation everybody, benefiting from a public good, should feel obliged to contribute up to his marginal benefit40. When a lot of people contribute to a public good, a few individuals may reason that it pays for their personal benefit, not to contribute, but simultaneously still benefit from the provided public good. This behaviour is referred to as free-riding. As long as not too many people free-ride the public good remains to be provided, when too many people tend to free-ride the end result is likely to be no (public) good at all.

In the Open Source Network only very few people contribute to the development. In fact, most people just use the software, and are not knowledgeable enough to contribute in the form of programmed code41. Although in the strict sense this might be referred to as free-riding, it is not. Gosh on this topic argues even the mere using of software adds value to the network, and thus could be seen as a contribution. In this thesis the contributions of companies to Open Source are under review; what is it that they return to the community in exchange for the public source code? One might question whether firms free-ride on the efforts of the OSS community. Actually their profits from OSS are considerable, especially when compared to the benefits for individual developers. But even in the case they would not return any code, they still might contribute valuable complementary services. Nevertheless this might prove to be an interesting analysis for another student. Public Good Pricing o Use Value o Price Discrimination

39 Fixed cost are not only limited to the production of a product, a product has to be brought to the market, and when a closer look is given to many information products in today’s market one notices that for example in the movie industry considerable amounts of money are spend on marketing. These (sunk) expenses are obviously intended to enlarge the market. 40 Up to the marginal cost, since only the cost have to be distributed among all contributors, who also divide the total (consumer) surplus. 41 they could also contribute money.

. 3.3. Information Rules Varian and Shapiro extensively cover the issue of networks in their book “Information Rules”. They assess a network from the angle of information products, and in their discussions focus on network externalities, economies of networks, positive feedback cycles, standards, lock-in, switching cost, versioning and the like. These are a lot of terms, of which I am sure you have encountered most already somewhere else. But still it will be the next paragraph’s focus.

3.3.1. Network Effects Instead of aiming at the functioning of a network, the focus is still on the value of the network. The number of nodes connected to network determines this value. More connections result in a higher value of the network. However this is only part of the story, the increase in value is not linear; the marginal value-added of every new node continuously increases. The classic example is a fax machine (e.g. Shapiro & Varian, 1999); where a single fax machine on its own, would have no value except maybe scratch value, a second fax machine introduced in the network, would increase the value of both the first and the second machine, since now it becomes possible to send faxes. A third (and so on) further increase the value of machine one and two and thus of the network at large. Since the increases in value of the fourth fax machine is not only enjoyed by the owner of the fourth fax machine, but also by the owners of machine 1, 2 and 3, who themselves do not participate, we refer to this phenomenon as network externalities. Economides (1995) describes network externalities in a more theoretical manner. First one should identify that the different nodes of a network, are not substitutes, but work complementary to each other, at least as long as they are compatible. The externality lies in that fact that “the value of a unit of the good increases with the number of units sold”42.

o Network Externalities: “the value of a unit of a good increases with the number of units sold.” o Network nodes function as complementaries.

These network externalities can be compared to economies of scale in the traditional production of goods. But there is a distinction to be made; in traditional economy production cost would decrease, and thus the effect would take place at the supply-side. In a network, production cost not necessarily decrease, but the benefit for the users, so at the demand-side, ever increases. That is why Varian and Shapiro make use of the term ‘economies of networks’. At a certain level, this can result in a cycle of positive feed back, leading to an ever increasing number of nodes or people connected, because the value of being connected ever increases 43. On the other hand, if somebody leaves the network it reduces the value for all other people, possibly resulting in a cycle of negative feedback. In theory, when two or more networks would be competing, the cycles of positive and negative feedback would eventually leave one dominant network. In practice this process does occur and one could say that firms compete for the market, rather than competing in a market. Microsoft Windows had multiple competitors (like Sun and Apple), but nowadays for the average user the Microsoft networks dominates, in other words it became the standard. This standardization is a widely observable phenomenon in (information) networks. This virtuous process of positive feedback might be amplified by a self-fulfilling prophecy, where the expectation of it becoming a standard, encourages that same standardization process. Another issue is that of compatibility and complementary. When two products are compatible, or when two products are complementary to each other, they do not each create a network individually but together create one single network; one that might enjoy stronger economies of networks. Already it

42 For economics this should raise the question, about how the demand curve would look like. In fact, when the number of goods increases this would usually mean that the price goes down. And this basic principle still holds, the demand curve slopes downward. What happens is that this down sloping demand curve moves upwards. 43 An estimate of the increase in value is given by Metcalfe’s Law: “the value of a network goes up as the square of the number of users.” Varian & Shapiro, 1998, pg. 184.

has been identified that cost structure (high fixed, low marginal cost) of information favours first movers. These first mover advantages apply especially when network externalities are prevalent. Standardization results in a higher social value, even as compared to two competing networks that might result in lower prices during the competition44, and is as such not a negative outcome. It needs to be understood that perfect competition for example would result in a negative outcome, since in such a case, the public would have too small networks and not enjoy the higher social value of a standard network45. A monopoly though, is often the inherent result of a standardisation process. A monopoly, assumed that price discrimination is impossible, will restrict its output in an effort to maximize profits. According to Economides (1995) the theoretically best option for social welfare would be to have perfect price discrimination, but this conclusion is not made specifically for the case of public goods, and as has been indicated in the case of public good the social optimum could also be a price at zero-marginal cost, and thus price discrimination is by definition impossible. Obviously in case standardization occurs it is important to analyse, who has control over the network. If it is a company, this company is most likely to behave like a monopolist. Companies do not always own standards; standards do not even always arise out of the market. Standardization can result out of 1. in the market (ex post), 2. by means of law or 3 by co-ordination and negotiation (consensus based, ex ante) and finally 4 by a combination of one, two, three. The Open Source Community has already produced a number of standards: PERL, SendMail, and HTTP/IP, none of them is or can be exploited in a monopolistic manner, some came about in the market, others were predefined by organizations like the IETF46 and the W3C47 in a consensus based way.

o Economies of networks (demand side economies of scale) lead to positive feedback cycles and eventually standardization. o Ownership of a standard determines the market structure.

Due to fast changing technologies the monopolies in e.g. the software market are not easily sustainable. Even a strong monopoly as Microsoft enjoys, still faces new market entrants, and has to adapt its product range continuously. Actually the behaviour of Microsoft with constant innovation and over time a decrease in price is in contradiction with the behaviour of a theoretical monopolist. But new entrants opposing Microsoft engage in a severely difficult task. Even when they would come up with both a technologically more advanced and cheaper product, they would have great difficulty to compete. First of all because of the internal value of the network, and secondly because of lock-in and switching cost. These two terms are strongly interrelated and also form the basis for the explanation for why standardization does not always occurs. Lock-in is the degree to which a customer is pressured to stay with a certain product or producer. A consumer may have opted in the past for a certain product, he did probably not only invest a monetary amount, for the purchase of the product, but maybe has built a (trustworthy) relationship with a supplier and especially with complex information products invested time and effort in e.g. learning. Eventually more incentives to stay arise: thus “choices in the future are limited by investments today.”48 Switching to another product becomes ever more costly. Not only would one need again an initial investment, one would also need to start a new relationship and put effort in learning. These costs comprise the ‘switching cost’, the cost this customer faces when he decides to leave that product or producer for

44 Both networks want to enter in a positive feedback cycle, and reducing a barrier for entry could be reducing the price (temporarily). 45 Economides (1995): “The marginal social benefit of network expansion is larger than the benefit that accrues to a particular firm under perfect competition” 46 Internet Engineering Task Force, a forum open for all market participants, who jointly discuss and agree on technology standards. The IETF has no real power, their standards can be ignored by everybody, the question always is whether this would be a wise decision for that individual. 47 World Wide Web Consortium, A forum for businesses, academics and others where is decided in advance what technology should become the standard. 48 Varian & Shapiro, 1999

another. Customers often not only carry the burden of switching cost, often supplier and customers share the cost in case of switching. Customers have strong incentives to make use of standards in order to reduce these costs, while (strong) suppliers have incentives to create lock-in and switching cost, since it gives them a strong customer base, and the opportunity to charge price premiums. o Lock-in and switching cost provide for incentives to stay with a product. . 3.4. Networks Kash and Rycoft (2000) argue that complex, self-organizing networks are the only innovative path for the commercialisation of complex technologies49. A closer view at these self-organizing networks reveals a sociotechnical system; an interplay between social developments and technical developments is at work. What is meant here are that the network and the technological development paths are parallel, where the network only develops when the technology develops, and vice versa. Both affect each other, and both determine the quality of the outcome. Recalling from chapter 3 we know that networks have the capability to learn, which is enhanced by a shared set of heuristics and routines, trust, reciprocity and reputation. (Kash & Rycoft, 2000). Open Source development itself is one example of such a self-organizing network. In this thesis, however, analysis focus on a higher scale; not so much the network of programmers is under examination, but rather the interplay between market, developers and companies. For the analysis to be fruitful, the final part of this theoretical chapter focuses on the characteristics of networks.

3.4.1. Definition A network is a collection of autonomous linked nodes. Networks are all around in society, so obviously the autonomous nodes can constitute of every kind of actor, from individuals, to organizations (in alliances), and computers (in computer networks). The fact that individuals are linked to each other is one of the fundamental differences with the market. In a network transaction occur between partners that know each other, where in the market it can occur between two anonymous parties, solely relying on the price mechanism. This chapter is organised such that first it first addresses the properties of the links, and thus focus on the network as a process, and afterwards on capabilities of the network as a whole, thus on the network as a structure. o A network is a collection of autonomous linked nodes. 3.4.2. Network Functions What is it that networks do? Or what is it that networks do better than the market or firms? A network is an efficient medium to transport information. In theory everyone is able to receive all information either directly or indirectly, but most likely directly connected parties know about the (information) preferences of their partners, and serve as a filter. The information transferred can be everything from new developments, to identify possible new partners, to gossip. The information diffused is also not necessarily new information, a network functions also like a database, making it possible to retrieve information. However where the storage of an average database is centralized, a network is decentralized, information is stored at the ‘edge’. A good example of this is the Internet, where the nodes are individual computers/servers, which store a small number of websites, together makes a huge database. A second function of networks is to allocate resources. Collaboration and sharing gives actors access to more resources, and provides them with the opportunity to use them more efficient and to reach economies of scale. A third function is the ability to coordinate. The different actors in a network are autonomous, but still they are interdependent. This interdependency does determine their according behaviour. In the second

49 “Complex technologies are those products and processes that cannot be understood in full detail by an individual expert sufficiently to communicate the details across time and space.” Kash & Rycoft (1999). In my opinion most software products have this characteristic.

chapter we have mentioned that in the Open Source Community, a so-called ‘hacker culture’ emerged, with its own norms and values. These are examples of the coordination function that a network provides. In the case of Open Source Software it is self-organizing, but in other cases it can also be constructed around a dominant firm50 for example. Network Functions o Allocate Resources o Transfer Information o Co-ordinate 3.4.3. Ties A single link between two nodes does not make a network, what actually makes the network is the fact that these two nodes, are connected with multiple other nodes themselves. The reason why not every node is connected to every node directly is just because one is limited in resources, and is only able to maintain a certain number of links. There are thus two kinds of links, a direct tie, directly between two nodes, and indirect links, where there are one or multiple intermediary nodes. Like its environment, a network is dynamic, new relationships are developed, where others are abandoned. This continuous development is not only influenced by external factors, like this environment, but also the network internally signals new opportunities and provides thus incentives to modify. On the other hand, there are strong conservative incentives, in fact a tie between two parties becomes ever more valuable, because of previous interactions. Every successful interaction in the past, adds to the trust between the parties, decreasing the transaction cost. Where in the first interaction, two parties would for example make use of extensive contracts to specify as much as possible, trust may act as a substitute for these contracts. The existence of intermediaries does have a significant impact on the functioning of a network. When somebody is directly connected to the broadcaster of e.g. information, he is better able to assess the validity of the information he receives. Furthermore the broadcaster has arguments to behave trustworthy, first because two connected parties are likely to be interdependent on each other, secondly because he might expect reciprocity and finally because a trustworthy reputation might enhance one’s position in the network, for example by being perceived a preferred partner and thus having more valuable ties. The more intermediaries the harder it gets to Asses the validity of the information and the trustworthiness of the original broadcaster. So far it has just been assumed that information flows through a network like water, however in the literature there is some discrepancy between how the information actually flows. Some authors assume information flows freely through the network, others (Kash & Rycroft, 2000) mention the importance of reciprocity and even others (Grant, Baden-Fuller, 1995) argue that it should be regarded as a transaction, in which both parties have to benefit.

3.4.5. Structure The sum of all direct (and thus also indirect) ties determines the structural shape of a network. This shape varies between a) open networks and b) closed networks. An open network is a network where your direct contacts do not have many identical contacts as that you have. A closed network is a network where your direct contacts, do have many direct contacts with your other contacts. Burt (1992) is strongly in favour of an open network, in his structural hole theory, he prefers organizations to position themselves, between two not connected nodes - the structural hole -, and even more preferable it would be when the nodes that you connect have a similar strategy. Any other position would only result in a duplication of effort and in redundancy of transferred information. It needs a remark that Burt’s theory applies for a network with organizations and firms and is not necessarily applicable to all cases, especially because Burt is concerned in finding business opportunities and creating a control position, rather than a social optimum. Not all agree on Burt’s view, one of them is Coleman (1990), he favours a dense or closed network, in which a culture of shared beliefs, norms and values arise, as well as does trust. It could be that the efficiency gains in the structural hole theory work for stable networks, because it has gains in efficiency,

50 A good example for the last point is the case of Toyota and its ties with its suppliers. (Org.in Network Economy)

where a closed structure works better in a dynamic setting, making sure that access to information is always guaranteed. In this respect it is a small step to the findings of Robin Cowan (1999), who analysed networks in the ability to enhance knowledge innovation, thus a dynamic environment. Earlier it has been indicated that information is the essential input to produce new information, and it presumably needs little explanation that a network is a suitable structure to steer innovation of knowledge, since a primary role of a network is to diffuse information. Cowan finds that the structure of a network does influence the networks capabilities to innovate. He does so by displaying the pattern of knowledge diffusion. Indicated should be that a single actor is limited in the number of direct links he can maintain, capital and time constrain him. Therefore he also has to rely on indirect contacts. Cowan indicates the existence of cliquishness. A clique is a group of which the nodes are highly interconnected, one node is connected to a large number of other nodes from a group, and these nodes themselves are also interconnected to each other, thus a clique can be considered a closed network as described by Coleman. In this way information can reach a node, not only directly (from the broadcasting node directly to the receiver), but also via multiple short paths (indirect paths), involving just a few intermediaries. Knowledge diffusion within a clique is rapid; a homogenous knowledge base is quickly reached. Cowan holds the view that for knowledge to be transferred via a network, the two parties should have a different knowledge base, in order to make sure that both benefit from trade, but the difference in knowledge base should on the other hand be limited so that both parties appreciate each other’s knowledge. The members of a clique not only have internal ties, in fact for innovation to occur one needs occasionally new input, therefore some links to others anywhere in the network, outside of the clique. The number of these external connections determines the average-path-length. This path length tells how many intermediary nodes are needed to connect to all other nodes; in other words it is the average length of indirect ties51. In a situation where a clique has a considerable number of external connections, obviously this average path length is low, and vice versa. Out of this theoretical framework, Cowan continues by claiming that with a fixed number of possible links, a low average path length leads, to a relative low degree of cliquishness, and to a rapid diffusion of knowledge, but also to homogeneity at a high level in the knowledge base. Different cliques share a similar knowledge base and tend to follow a similar path of innovation. On the other side of the coin one finds a network structure with strong cliques that are hardly related with other cliques. This hampers the process of knowledge diffusion, at the highest level, and obviously leads to a high degree of heterogeneity in the common knowledge base. This heterogeneity likewise obstructs innovation. Therefore the ideal network structure is somewhere in between these extremes, and is depended on the state of development.

51 Guatam (2000) and Gulati (1995) indicate that trust in the information received via an indirect tie is considerably lower, compared to information received directly from the initial broadcaster. For indirectly received information it becomes more difficult to determine it’s legitimacy, diminishing the information utility.

Fig. 3.1. Small World Phenomenon, Cowan (1999) The left circle represents an open network, right a dense. The middle small world shares advantages of both eventually leading to a low average path length, with limited connections.

o A balance between cliquishness and short average path length provide for optimal diffusion of information.

Innovation does not always take place in a network52; a company can establish an R&D department and innovate and develop in-house. Much research has been conducted which has indicated that especially in periods of high technological change, and thus high uncertainty, companies tend to seek partnerships, and co-operation over internal development.

. 3.5. Conclusion This chapter introduced a small variety of economic concepts that underlie the Open Source model. Special attention is devoted to the public good nature of information, with its zero-marginal costs but high fixed costs. Combined with the fact that for the innovation of information, information is needed as an input, serves as the underlying principle beneath the philosophy of Open Source. However it also includes the risk of free-riding, which might apply to the behaviour of for-profit organisations. A second section explained the organisational socio-technical network of which the OSS community is an example. Ultimately leading to a discussion on the findings of Cowan, which were that cliquishness is the most effective network structure for innovation. If his rational is continued it could well be that the involvement of commercial entities within the Open Source Community enhance the innovation efforts; with the individual companies being a clique with ties to the OSS community at large.

52 Note that this is not true, networks exist everywhere, research within a company is done by individual employees, who are themselves part of a network. What is meant here is the level of e.g. independent organizations or companies.

. 4.0. Objectives  To integrate the main conclusions of the second and third chapter.  To introduce and describe the commercial involvement in Open Source.  To analyse the contributions of commercial companies to Open Source.

. 4.1. Introduction The previous chapters provided an extensive description of what Open Source Software is about and its basic underlying theories. In the descriptive second chapter, however, very little is written about the relationship between the Open Source and commercial activities. This relationship does however exist and is the focus of this chapter. Especially since the community has shown that it is able to produce products that can stand the comparison with commercial offerings the relationship is seemingly gaining importance.

Commercial companies have always shown an interest in Open Source, one can think of the involvement of Xerox Palto Alto and Bell Laboratories during the 1960s. But connections in recent years have widened; where in the 1960s companies involved were mainly large multinationals conducting fundamental research, nowadays several companies have been seeking profiting strategies based on the developed software. And not only are companies engaging in the Open Source Community, from the community itself spring new ventures.

Within the community of Open Source developers there exists a dose of ambiguity and even skepticism on the involvement of commercial entities. Members of especially the FSF worry that commercial organizations do not comply with the philosophies of the Open Source Community and therefore eventually harm the community; where others, especially the OSF, argue that as long as entities, thus also commercial companies, comply with the Open Source Definition, they can become part of the network. And that as the network grows it likely becomes stronger.

o Relationship between for-profit and Open Source dates back to the 1960s

. 4.2. Chapter Outline So this chapter will illustrate the involvement of commercial companies in the Open Source Community. It will cover the motives of companies, display the various opportunities and outline a number of business strategies that are applied. After concluding this chapter you are expected to have a practical picture of the dynamics of the Open Source movement. The chapter starts with a short summary of the main points drawn up from the previous chapters. With the help of these conclusions it will be explained why companies might opt for a strategy of co-operation with the Open Source movement, or oppositely why a company would rather like to compete with the movement with a proprietary approach. This discussion is succeeded by a SWOT-analysis, which is meant to systematically list the advantages and disadvantages of commercial involvement from the OSS perspective. Thus in effect the SWOT-analysis simultaneously summarizes the preceding discussion on whether a company would follow an open- or closed strategy, next to listing the advantages and disadvantages of an open strategy in itself. As will become clear from the SWOT-analysis there exist multiple advantages and disadvantages. Around these, companies have built different business models, which each exploit a certain advantage. Paragraph 4.5 lists these business models illustrated with small cases. By then this chapter has seen an analytical and a descriptive part; analytical in explaining why companies want to get involved in Open Source. And descriptive in the sense that the various business models are identified and introduced one by one. These two pillars support the final part of the chapter, which constitutes of an analysis into the exchanges made between companies and the Open Source movement that exists. This part will especially focus on the kind of contributions made by companies to the Open Source Community.

This chapter, together with the previous two chapters should provide enough insights and background knowledge to start answering the problem statement and questions as they are stated in the first chapter. This will be done in the upcoming fifth chapter.

. 4.3. Open or Closed From the second chapter a number of essential conclusions can be derived. First of all it was concluded that granularity and especially modularization is an important feature of a project. A single contribution should be small and inexpensive. Furthermore it was concluded that a project has a hierarchical, meritocratic structure supported by a system of reputation. That volunteer programmers do not behave in an altruistic manor, but have rational incentives. And last that Open Source is sophisticated-user biased. These elements of modularization, meritocratic hierarchy, reputation, rational incentives and sophisticated-user bias are key elements, which, as will become clear, shape the relation between Open Source and commercial entities. The characteristics of this relationship can furthermore be explained by knowledge gathered in the third chapter, in which the fundamental logic behind commercial involvement in Open Source is introduced. In this third chapter it was concluded that this logic springs first of all from the specific characteristics of information. Known is first of all that information builds upon information. So when one knows that Open Source’s primary goal is to have software as a public good, one also knows that the information needed as an essential input is freely available. Furthermore one knows that Open Source derives its information from a large group of developers. So the information sources are both freely available and wide in scope. Compare this with the proprietary model, where the software is produced by a limited group of people, who furthermore have to deal with intellectual property rights protecting the input information. As an intermediate conclusion one would argue openness to be the logic model for innovating software. This is in line with the argumentation of Lessig (2001). However with a strong intellectual property rights’ regime, Open Source faces severe difficulties, in the fact that it cannot make use of patents and the like, which are protected by proprietary colleagues. This hampers the quality of the offering. Thus a strong regime of IPR works counter effective to the benefits of the public domain. Next to the specific characteristics of information, Open Source deals with network externalities. Positive feedback cycles lead to standards. These network externalities play an equally important role next to the peculiarities of information. In fact, when a standard is either agreed upon, or comes about naturally. The benefits of adhering to a standard for an individual user often exceed the benefits of an improved product. Therefore quality of the software is thus not the single determinant of success. Where network externalities arise, Open Source has the advantage that its product is in most of the cases freely available, which likely enlarges the market. And secondly that risks of lock-in are lower as compared to proprietary alternatives. That is, Open Source’s aim for standards, and the openness of the source gives users control over the software, and with this control lock-in can (partially) be overcome. A third factor involved is that Open Source favours co-operation and alliances, again enlarging the market and decreasing the risk of lock-in. Proprietary companies are more likely to succeed in developing non- standard products, which are either a niche or highly specific software for individual clients. Nevertheless where standards occur, a proprietary software house is still able to outcompete all others and achieve a (temporarily) monopoly with its own private standard. In fact advantages of proprietary software include the facts that mundane tasks are carried out, since money works as an incentive 53. And that one does not have to rely on volunteers, but on the other hand is subject to time-to-market pressures. Pyka and Windrum (2000) in their theory about self-organizing networks, indicate that this decision is depending on the technological intensity of the industry. So on the one hand the public good nature, the fact that information builds on information, copyleft- clauses and network externalities make a strong case for Open Source. While intellectual property rights, network externalities, and lock-in favour a proprietary position for companies. Thus there exists a

53 This is different from Open Source, where as has been concluded contributions are small in size and value, and secondly the incentive to contribute is directly rational for an individual. Where the overall benefit thus should be linear with the personal benefit, which is not always the case.

dynamic competition in which companies have to question the nature of the software they wish to produce, and their capabilities to outperform the market.

. 4.4. SWOT Analysis The discussion in the above paragraph focused on the open or closed decision as is made by commercial entities. Nonetheless within the Open Source Community a discussion is alive, which questions the general attractiveness of commercial involvement for the community. Therefore this paragraph is included. It is a SWOT analysis that presents a short overview of the various aspects that play a role. The perspective chosen is that of the Open Source Community, since in that case the coverage of topics is wider. This SWOT analysis is furthermore meant to picture the various advantages and disadvantages, so to enhance an understanding of the business models, discussed in the next paragraph.

Strengths  Access to resources. It has been concluded that contributions by individual programmers are small in effort and small in value. A system of modularization facilitates these contributions. Nevertheless some contributions cannot easily be modularized. For instance this is not possible where it concerns hardware. Companies that have a stake in Open Source Projects, and who are for their business success depending on the success of such a projects, are likely induced to provide these hardware investments. One example are the servers of the Debian Project, which are provided by Sun and HP54.  Growth of Open Source because it is reaching a larger market. The sophisticated-user bias originated from the fact that individual programmers have generally no incentive to write for example easy installation programs, or manuals. In fact they as professionals are fully aware of a program’s feature and are fully skilled to use it. Nevertheless a larger market, would strengthen a positive feedback cycle, and indicate network externalities. Again these effects are too indirect for individual programmers to include in their payoff calculation. Companies can more easily achieve them, especially since they derive direct financial benefits from providing mass-market customers with such services. There are multiple companies that distribute Open Source Software. Sometimes on itself, and often included in software packages or included within a package of consultancy services.  Because companies work with financial incentives, they can easier take care of mundane tasks, and as such complete the OSS offerings. Once more is the volunteer nature of Open Source contribution a barrier for mundane tasks to be executed. Therefore companies which can pay employees to do so, and which can profit directly from such a contribution, are likely candidates for these jobs. This is a strategy applied by so-called support sellers, like Red Hat and SuSE.

Weaknesses  Companies have their own agenda, which likely is different from the agenda of individual programmers and the current OSS community at large. Risks in this respect are multifold: One can be afraid of company employees ending up in managing an Open Source Project and changing the overall direction, which can increase the risk of forking. One can be afraid of companies trying to appropriate Open Source Software, or of companies hiring away key developers.  Companies might temporarily use the Open Source Community in a competitive battle versus Microsoft, and not fully adhere to the commitments of the OSS community.

Opportunities  Alliances with companies might increase the attention and popularity of Open Source. Companies could provide marketing skills, which could offset the mainly technical orientation of most programmers.

54 http://www.debian.org/misc/equipment_donations

 Commercial companies might be able to develop the critical mass of end-user applications/programs that run for example on Linux. They thus develop complementary software supporting and based on an open standard.  Involvement of commercial companies might positively influence the professional image of Open Source.  Large companies, with existing offerings could open the source code and patent rights to the community and in such strengthen the community.  Involvement of commercial companies can give Open Source increased legitimation. Governments and private organizations are likely to gain increased trust in long-term continuity.

Threats  Companies may try to get controlling positions in an Open Source Network.  Companies might try to appropriate Open Source Software.  Companies might try to use a project as a cheap way for production.  Companies might try to introduce more managerial tasks, like formal control and planning.

o Firms enlarge the market o Firms carry out mundane tasks o Risk of own agenda

. 4.5. Business Models and Strategies Till now, the discussion on the relationship between Open Source and firms has regarded for-profit as one homogenous sector. In some sections, like 4.3 these firms seemed little more than modified software houses. However as this section will illustrate, there is not one homogenous group of firm. Actually the flaws and strengths of Open Source have resulted in various business opportunities, which result in different business models. Below a categorization in the difference Open Source business models is provided.

4.5.1. Anti-Microsoft Agenda; the case of the alliance between Sun, Intel, IBM, Oracle The dominant position of Microsoft has led competitors to form (unusual) alliances in order to overcome lock-in and network effects as Microsoft enjoys them. Open Source Software promises to be one of the opportunities. One does not necessarily need a Microsoft to use OSS for strategic motives. Fowler e.a. (2000) list 5 advantages for AT&T Laboratories55 to engage in OSS. a) “Increased influence on national and international standardization efforts.” b) “Creating and supporting alternatives to closed systems.” c) “The ability to attract vendors to distribute and support the software.” d) “Improve software quality due to widespread use.” e) “Increased visibility of AT&T Laboratories in the research community.”

4.5.2. Corporate Source; the case of Hewlett Packard Hewlett Packard (HP) (Dinkelacker and Grag, 2001) has introduced an Open Source structure within its organisation. Whereas in the Open Source Community the base of potential developers is equal to all Internet users, in a corporate source the number of potential contributors is equal to all employees. Employees can browse through and self select project in which they are both interested and have expert knowledge. Goals of HP are to reach faster development cycles, improve the debugging cycles, improve the knowledge diffusion, create some corporate standard practices and to efficiently deploy their human capital. In this case however the business strategy only applies to the production method, it is clearly not the idea to release all developed software as OSS.

55 AT&T Laboratories was involved in Unix development in the 1960s and 1970s, it even enjoyed the intellectual property rights to core elements. At a certain point it decided to appropriate and commercially exploit Unix, which had a huge negative impact on the Open Source Community.

Fig. 4.1. Corporate Source, (Dinckelacker & Grag, 2001)

4.5.3. Widget Frosting A first strategy that really adheres to the philosophy of Open Source is coined ‘Widget Frosting’. Hardware producers, open the code for drivers in order to both enlarge the potential market, but also to insure compatibility and maintenance56. Their revenue is generated not by the software, but by the hardware that is sold.

4.5.4. Loss Leader; the case of Mozilla/Netscape Communicator As a loss leader, you give (temporarily) away your market position for potential future sales of proprietary software. A popular example is Netscape with its Communicator/Mozilla browser. Netscape, faced with ever-fiercer competition from Internet Explorer, turned into a no-charge Open Source product to strengthen/re-establish a position in the market. A firm’s ability to commercialise on software and relate services depends on the diffusion among users. And it is important to realize that users does not necessarily mean buyers, also users that use a program for free, add to the potential of a company McKelvey (2001). Users in turn are important not only to attract other users, but also to attract new developers. This loss leader strategy can be included in a list of some relating strategies. For example some companies promise clients to open the source in an x number of years from now. Which means that risks of lock-in are somewhat diminished, and that continuation of program updates can be provided by volunteering programmers. In general this strategy has the closest ties of all business models with proprietary software houses. In fact it involves companies loosing out on a standardization battle, turning to Open Source, trying to refortify their position.

4.5.5. Support Sellers Business Model; the case of Red Hat & Sendmail This business model is likely to become ever more important, when we are to believe various authors and Open Source advocates. It is indicated that several companies of this kind (Cygnus57, Red Hat etc.) made it to the stock exchange. The business model is easiest to explain with reference to the Lawyer’s Model, where national laws are free and accessibly by everyone, people pay for expertise; the ability to adapt general rules to individual cases. The exchange of value between the business company and customers is continuous, because it is related to the real use of the software. Thus instead of a focus on selling software, these companies focus on delivering complementary services for that software: end-user versions58, helpdesk support, installation programs, consulting etc. The software itself is regarded as a commodity59. Linux has many hundreds of distributors, of which Red Hat

56 Hardware users run usually the risk that their hardware becomes obsolete, after the producer decides to discontinue the support for the product. Open Source might be an alternative to guarantee long term support. 57 Cygnus was later acquired by Red Hat 58 Imagine for example Linux, which has a standard kernel, for which there are multiple optional applications written, for which are many drivers, for which are multiple settings possible etc.etc. A service company is likely to be more expert than the average user, and is better able to assemble an average user version. 59 Michael Tiemann, founder of Cygnus Solutions

in the U.S. and SuSE in Europe are by far the largest. Brand name and first mover advantage play an important role in this market. For a strong brand name, these companies need a good relation with Open Source projects, it is not uncommon for these companies to contribute financially, or to lend out key programmers to work full time on projects. In return the companies can improve their image and their employees participating in Open Source projects stay knowledgeable about state-of-the-art developments and can communicate this information inside the company. Other companies like Sendmail Inc. apply a similar strategy, however with a different target market. Sendmail Inc. not only uses OSS, they are a direct offspring; Sendmail is a commercial company, founded by the core-developers of the Open Source Sendmail standard, which is the leading e-mail handling software. Sendmail Inc. provides consulting activities and produces highly professional and specific email software aimed for large multinationals, based on the open Sendmail software. In this case the expert reputation derived from the Open Source project is providing a competitive advantage. It is the realization of the Lerner & Tirole’s delayed payoff, and career signalling incentive. However it is a realization out of the scope of Open Source. What is produced is a highly professional, highly specific, proprietary version of an Open Source product. It is what Varian & Shapiro mention as a strategy of personalized pricing, group pricing or versioning. Other companies can copy the strategy from Sendmail and start Open Source Projects ‘ex nihilo’; this would result in a strategy comparable to Gillette’s giving away the razor (software code), selling the razorblade (consulting). (Lerner & Tirole) Chapter 5 and 6 will examine the support seller’s business model in greater detail making use of two cases of Linux Distributors. So for the ease of the upcoming discussions the support sellers model is being explored more extensive compared to other models.

4.5.6. Accessorizing; the case of O’Reilly’s Another strategy closely linked to that of the support-sellers is accessorizing. A company provides accessories to complete the software product. One can think of documentation and hardware. O’Reilly is for example a well-known company publishing books and manuals on Open Source. The distinction between the support sellers’ strategy and accessorizing is marginal. Often companies are following both strategies simultaneously.

4.5.7. Platform; The case of SourceXchange & Collab.Net The last strategy to be discussed is practiced by SourceXchange and SourceForge. They build an infrastructure for Open Source Development. They do not, like support-sellers, add enhances for Open Source products, but they create a platform for Open Source developers. SourceXchange, was60 an initiative from Collab.Net and Hewlett-Packard, and tried to be an intermediary between individual programmers and companies. Companies could found an Open Source project, by contributing a source base, and other resources. SourceXchange would manage the project, independently from the founding company, and try to gather a large enough pool of programmers. Sourceforge is still a successful intermediary providing a platform for OSS projects. At the end of April they hosted approximately 60,000 projects and over 600,000 members had subscribed 61. In some other cases this platform function can be organized by non-commercial organizations like the Freenode.net, which provides communication tools for e.g. the Debian project.

o Anti-Microsoft Agenda o Corporate Source o Widget Frosting o Loss Leader o Support Seller o Accessorizing o Platform 60 The project started in the late 1990s and in the early 2000s SourceXchange it stopped its activities. 61 Data from Sourceforge. Sourceforge.com

. 4.6. Commercial but Open… The discussion in this chapter has focused on the involvement of commercial companies in Open Source. The various business models have been identified, the advantages and disadvantages of commercial involvement have been discussed in a SWOT-analysis, and a short paragraph summarized the second and third chapter and devoted attention to why the community is attractive for companies. Still when we look back at the subquestions of the first chapter, we would like to know what the contributions of commercial companies consist of and which market they target. This final part of the chapter will highlight the physical exchanges that do occur between the OSS community and companies. One characteristic of an exchange is that at least two parties are involved. And therefore examination has to include both sides. However examination of the exchange from the Open Source Community to commercial companies will be marginal. In fact the exchange in this direction involves merely the Open Source Software itself. In theory one could extent the array of goods exchanged, but this would be highly theoretical, and out of this thesis’ scope62. The other side of the exchange is more interesting, some bits and pieces have crossed a reader’s eye already. The SWOT analysis for example indicated hardware to be supplied by HP.

Rather than on their respective contribution, the theoretical discussion thus far focussed on why companies would link themselves with the Open Source Community. The continuum of choice was in between a proprietary position and an open (source) one. Most arguments in favour of either position resulted from the nature of their product, which is software. So there were the characteristics of information, network externalities and the like. However a closer look at the various business strategies summarized above reveals that many of the businesses are not true software houses. Support sellers, widget frosters, and accessorizers are more likely to treat software as a commodity, complementary to their products. And even when software is part of the product, like is apparent by widget frosters, and some support sellers, it is not always their primary business activity, but rather a supporting function. So if software in itself is not the primary business activity, it is not necessary that these companies contribute software. This is however only a preliminary thought. But if to this fact it is added that software development is exactly thé strength of the Open Source Community, then one might question why additional support is needed for that activity. So in the remainder of this chapter an initial analysis of contributions by companies is made.

4.6.1. Analysis of the relation between the business models and Open Source. Just as most programmers are not driven by altruism as a motive to contribute, it can safely be assumed that the Open Source philosophy in itself does not motivate a majority of companies. Open Source should provide a company with a viable and profitable strategy. A contribution thus should have a positive payoff. For most of the above business strategies it is possible to identify the relation between contribution and pay-off. However this is not true for the involvement of large multinationals like IBM, Sun, AT&T and HP. Some of their strategic considerations are mentioned under the anti-Microsoft agenda. But the variety of their activities is extensive. And for reasons of simplicity and in order to prevent duplication multinationals are left out of the following discussion. The huge variety in strategic models applied by multinationals, would make them fit in nearly every corner of the various representations. For ease of understanding a number of graphical representations are made.

4.6.2. Expected contributions of companies. The first figure will give a graphical representation of the expected contributions to the Open Source Community. This graph is merely a graphical interpretation of what is mentioned in the descriptions of the various business models. What grasps the attention is that the highest code contributions come from the loss leader and widget frosting models. Especially these two indicate the importance of network externalities. The loss leader is losing its standardization battle, and needs to seek new alliances to try to

62 One could for instance start arguing that reputation, image improvement, is an asset earned by a company and provided by the community of Open Source programmers.

inverse the feedback loop. Simultaneously the hardware producer, applying a widget frosting strategy tries to remain compatible with all software systems, to enlarge its network.

Fig. 4.2. Expected code contributions by business model.

So in general code contributions and thus software development are not likely to be the core activities of Open Source companies. In fact this is a logical conclusion from the theory, which aimed at the public good nature of software, and the negative consequences of intellectual property rights. Developing software as a main activity in an Open Source setting is most likely to be successful with a focus on a niche market only, a niche which is highly specific63 or limited in size64.

Next to asking what code they contribute, it can simultaneously be asked what code they use. In fact being involved in Open Source does not necessarily include that one is making use of the software. For example Sourceforge main activity is to operate an infrastructure platform, which has nothing to do with the actual code being developed, and therefore it resides in the down left corner.65

63 When nearly every customer needs a company-specific set of software, Open Source is unlikely to succeed as a development model, and proprietary suppliers are most likely. Similarly it has been shown that Open Source is most successful in the development of standards and platforms. 64 Raymond (1998) Benkler (2001) indicate that the size of a developer’s pool is crucial. 65 The example of sourceforge likewise shows the difficulty of such a graphical representation, would Collab.net instead have been taking as an example, which was operating a similar platform but more or less assigned this task by Hewlett-Packard, one could as easily argue a position higher on both axis. Actually the same goes for the first figure, where one could regard the code contributions from HP to Collab.net.

Fig. 4.3. Expected code use by business model.

The main activity of a hardware producer (WF) is to produce printers, video-cards, scanners etcetera; the drivers66 are a necessary complementary product. The drivers produced by the Open Source Community are not distributed directly by the hardware producer. This is why WF resides in the downright corner. Opposite to for example a Support Seller that actively redistributes the source code, with(in) its products.

Finally a look at the target market of the various business models. In the first chapter a distinction was made within the market, between OSS developers and the mass market. This distinction is continued and again the position of support seller companies and accessorizing companies are dissimilar from the others. Platform operators, loss leaders and widget frosters aim their activities at the Open Source Community itself. Where the support sellers try to reach not only the internal but also a market external to the OSS community. Again also here is some friction in this graph. In fact again the products of the loss leader and the widget frosting eventually end up at the mass market as well, however the focus of the business model is on the production of a code base. Hardware producers’ involvement in Open Source constitutes of a desire to have drivers developed, which eventually can accompany their hardware. While on the other hand support sellers start of with a code base, which is by them accompanied with ‘accessories’.

66 A driver is the software that allows a device to co-operate with the operating system.

Fig. 4.4. Expected target market by business model.

. 4.7. Conclusion This chapter has outlined the stakes that commercial enterprises have in Open Source. Results of the second chapter, in particular the concepts of mundane tasks, modularization, meritocratic hierarchy, reputation, rational incentives and sophisticated-user bias. And the results of the third chapter, in particular the public good nature of information, that information breeds information, network externalities, intellectual property rights, lock-in and standardization. These concepts together assisted in explaining why a company would favour Open Source over e.g. proprietary software. This choice between an open or closed position turned out first of all not to be black or white. Where an open strategy might be beneficial for society at large, a proprietary might yield far higher returns for an individual company.

This chapter furthermore introduced the various business models that have been discovered so far: The anti-Microsoft agenda, corporate source, widget frosting, support selling, accessorizing, and platform operating. The business models differentiate themselves on the basis of a.o. code contributions. Support Sellers’ (SS) strategy, which is under closer examination in the next chapter turned out to be distinct from the other. The business concept is similar to a lawyer’s model. So SS are not specifically software developers, rather their position indicates a focus on distributing and servicing for the mass market. Contributions made by Support Sellers are expected to be skewed towards non-source contributions and their target market is expected to be the non-expert mass market.

. 5.0. Objectives  To summarize the previous chapters by means of answers to the subquestions  To analyse the various function and tasks within Open Source Development.  To state propositions for the case analysis.

. 5.1. Introduction In the first chapter the central topic of this thesis was introduced. It is questioned whether a distinction can be made between the Open Source Community, the market and commercial companies. The idea that the Open Source Community is both self-oriented and focused on technological development next to the idea that companies could be of benefit in order to enlarge the market led to the expectation that a direct relation between the Open Source Community and the market was less strong as compared to the indirect link via commercial companies. Furthermore the role of for profit organisations could be one of communicating market demands to the OSS community and providing complementary services, which are difficult to be developed in a peer production mode of development.

Technology Market

OSS Compan y

Fig. 5.1. Expected Relationships between Open Source and for-profit organisations

In order to examine this framework, the central question “Can a clear division of labour be identified between the Open Source Community and commercial Open Source companies?” is subdivided in a number of intermediate questions:

 What tasks and functions exist in the development process of Open Source Software?  How does the OSS community function?  What tasks are carried out in the peer production mode?  Why are companies involved in Open Source?  Why does the OSS community need or not need the involvement of companies?  What task do for-profit organisations perform?  Can a distinction be made between a group of Open Source developers, a commercial sector, and thirdly a (mass) user-market?

Dispersed over the previous chapters various theories, concepts and facts have been discussed, which, when put together make up the answer on these questions. Chapter 5 will analyse these questions and is simultaneously a kind of summary of the most important characteristics addressed in chapter 2, 3 and 4. The final intention of this thesis paper is to test the central question of the labour division in the Debian and SuSE/Red Hat context. For that purpose are the tasks identifiable in a software development process categorized. Within the discussion on subquestion one, these tasks will merely be identified. After which the section continues with a discussion of the other subquestions. In continuation of this section the discussion returns to the categorization of the first subquestion, and in this new section the different tasks are discussed thorough one by one. This discussion will provide expectations on how the task will be dealt with in the Debian- and SuSE/Red Hat cases. These expectations will be framed as propositions67. 67 Usually in a thesis, hypothesis are based on one true theoratical chapter. In this paper this would mean chapter 3. Also in this paper chapter 3 is the fundamental theoratical layer, however chapter 2 and 4, which are more discriptive in nature, extensify the theory. And should therefore in my opinion be regarded as a continuation of the

Both are Linux distributors, however where Debian has a pure Open Source strategy, SuSE/Red Hat have a for-profit aim. The case analysis itself is the topic of chapter 6. The analysis will eventually thus be case-specific. Which also means that what is applicable at large is not necessarily applicable for the two cases under closer scrutiny. If the case results are in line with our general expectations it will strengthen these, however if negative it triggers further questions. So chapter 5 gives an overview of the literature survey, organised along the subquestions. The various answers frame expectations for the cases, which will be tested in chapter 6’s case analysis.

. 5.2. Subquestions

5.2.1. What tasks exist in the development of Open Source Software? Discussions in the previous chapters touched upon many tasks and functions that are present in Open Source Development. In this paragraph these task will be categorized. The main categorization will include three groups: code development, support services and marketing & distribution. The categorization is first of all based on tasks that could be identified from the literature survey, furthermore the structure of the Debian project revealed a few additional tasks, and finally the list is completed by means of discussion with various people.

5.2.1.1. Code Development Tasks and functions within code development are directly related on how the software is being developed or produced. The main functionalities include:

 Compatibility / Interoperability  Coordination  Documentation  Functionality  Innovation  Integration  Security  Standardisation  Testing  Usability

Compatibility is making sure that the software is running on various platforms, and that users can exchange information with users of different platforms. Coordination is an essential function in the development process of software. Most projects are too large to be handled by a single developer, and therefore multiple developers have to work together, with on the one hand keeping up the speed and on the other preventing duplication. Documentation is providing a written description of the technical specifications of a software program. With functionality it is questioned who decides to include which features and applications, and how new features are developed? Innovation questions who initiates new developments and advances the software. And in relation how new ideas are introduce and developed. Integration is included since it is especially applicable for Linux Distributors. LDs combine software from various sources into one full-featured operating system. Integration can be either internal within one software project, or external. Security is the level of protection against abuse. Standardisation is the level in which the software will interoperate on various platforms. Testing is making sure that the software functions like it is intended. And finally usability is a function that should make sure that software has an easy installation procedure and user-interface.

5.2.1.2. Support Services literture survey.

Support Services include complementary services to the software. With just the source code or binary program many users fail to gain maximum use value out of the product. Within the support services the main distinctions include:

 Consulting  Documentation  Implementation & Migration  Maintenance  Support  Training

Consulting services are almost exclusively oriented on advising businesses in the kind of software and hardware to use for what purpose, and how to modify the existing ICT infrastructure. Documentation in this context refers to manuals and other support documentation. In that respect it distinguishes itself from the technical documentation that has been covered under code development. Implementation & Migration is providing actual hands-on service in implementing a software system within a company. Maintenance is the logical third step, and includes assisting a company in keeping a system operational and updated. Support is a function both applicable for businesses and private users. It is assisting users with their daily use of a program. Support functions include the operation of a helpdesk, mailinglists and user manuals. Finally training is tutoring users in the use of a software program for example by means of workshops and computer courses.

5.2.1.3. Marketing & Distribution The Marketing & Distribution functions are related to how the market is informed over the characteristics of Open Source. Functions include:

 Awareness & Branding  Certification  Customer service  Distribution

With the awareness function one should think of informing people on the characteristics, advantages and the like of Open Source. In order that potential users can make an informed choice on which product is best suited for their purposes. With certification one ascertains a user that the software or a consultant has certain characteristics or skills. Especially with information products it is difficult for a user to distinguish in quality levels, and a certification can help in building the necessary trust. Customer service in this paper deals with issues of complaints and feedback. And finally distribution is the actual deliverance of the software to a user.

o Tasks in Open Source are categorized in three: Code Development, Support Services and Marketing & Distribution

5.2.2. How does the OSS community function? Chapter two gave some insights in the organization of Open Source. The main conclusions included that Open Source is a global network of volunteer developers. Although they contribute voluntarily their motives are not altruistic, but based on a rational pay-off calculation. The contributions are validated and improved by peers, a system that is referred to as peer-review. Nevertheless the loos network structure, it turns out that Open Source is nowhere near anarchistic, but has a hierarchical structure based on reputation or merit. o Meritocratic Hierarchy o Socio-Economic Network o Voluntary Peer Review System

5.2.3. What tasks are carried out in the peer production mode? In general Open Source has a focus on the production of knowledge, which in the particular Open Source case is limited to software and even more specific software like protocols, standards and operating systems. The fact that peer production is especially suited for knowledge production has been clarified in the third chapter and included the public good nature, the fact that one does not loose ones information by means of copying, and the fact that information is the essential input for new information. Within these outer boundaries chapter two provided the insight that a high degree of modularisation, granularisation, and simultaneous a low cost of contribution work favourable for Open Source development. Underlying these three assumptions is that the motivation of individual voluntary contributors is based on a rationally calculated pay-off. Some authors furthermore argue that the task should be challenging. Furthermore when a task returns a fair amount of reputation increase the likeliness of contribution by volunteer developers is increased. In fact each developer is only motivated when his personal cost-benefit analysis is positive and the estimation of somebody else also developing is small. One effect that this individual calculation has on the final product is that it has an orientation on the better skilled users. The requirements as mentioned above make peer production especially suited for information products. Benkler (2001) states that the cost of co-ordination eventually shapes the outer limits of the possibilities for peer production of information goods. o Software Languages, Protocols, Standards and Operating Systems is the best developed Open Source Software

5.2.4. Why are companies involved in Open Source? In the previous chapter the discussion on the motives for commercial organisations to join such a slightly anarchistic network of volunteer developers concludes that the interest from for-profit organisations has amplified, with the increasing success of the community. The companies generally do not seek to profit directly from the source code, except in niche markets, but rather from complementary services; including support, hardware and consulting. In fact many organisations realise the public good nature of information, and the benefit standards can provide. A strong motive also seems to be the loss-leader strategy, and in specific the anti-Microsoft agenda is shared by many. o Public Good Nature/Standards Battle o Anti-Microsoft Agenda

5.2.5.Why does the OSS community need or not need the involvement of companies? The answers above indicate that some tasks are better conducted in the Open Source mode, while others are better conducted by a traditional hierarchy organisation based on profit making. Nevertheless this distinction does not answer why the OSS community would necessarily need interrelations with these organisations providing complementary services. Access to resources is a good reason for Open Source to have interrelations with companies, but they are not the central issue; Open Source can function without them. The division of tasks in itself does not explain any far-reaching interrelation.

The answer in favour is however also provided in the previous chapters. First in chapter two it was made explicit that peer production is a mode suitable to produce information, including software, but it is indicated that Open Source has a focus on standards, protocols, programming languages and operating systems. Chapter three introduced a number of economic principles that apply to this kind of information. Most notorious in this respect are network externalities. Network effects favour the product with the largest network of users. However the internal focus of Open Source communities combined with the sophisticated user bias and the difficulty to carry out mundane tasks, tasks without a direct individual benefit, and tasks with a high costs and non-modular structure form barriers for a cycle of positive feedback. The offerings of facilitating complementary services by for-profit vendors contribute to a wider market reach, and a larger network of users, erasing some of the obstructions.

This question asks why their involvement is ‘needed’, implicitly suggesting that there are negative consequences attached. The main treats have been summarized in chapter 4 and included the own agenda that (can) exists with companies, the risk of appropriation, and the risk of loosing control over projects to companies. Of these threats especially the own agenda, and risk of a transfer of control are the most serious. The current system of licenses, especially with its viral nature, and copyleft clauses make the risk of appropriate less immediate. Supposed that the framework of labour division holds, in that case for-profit organizations would have a distinct target market; a market with their own demands. It would pay for them, when they manage to include these demands in the system. This in fact is not different from the behaviour of any individual eager to have one feature included. However when companies pay employees to be involved in this projects, these employees are likely to gain a considerable amount of reputation and thus because of the meritocratic structure, thus decision making power. It is then questionable whether the opinion of the median volunteer developer will still direct the project. That the number of paid-programmers is considerable becomes clear when looking at figures from Forrester Research 68 where it is indicated that IBM for example pays 250 employees to work on Linux. o Larger market acceptance o Risk of own agenda

5.2.6. What tasks do for-profit organisations perform? The third sub question relates to the tasks performed by companies and their respective contribution to the OSS network. A complete answer on the tasks executed by for-profit organisations starts by knowing what tasks are carried out well by the Open Source Community (§5.2.3.), and thus not likely to be carried out by for-profit organisations, since the OSS community makes their products available to the public domain. Knowing the tasks well executed in an Open Source environment still leaves a wide array of tasks not very well suited for Open Source. Not all these tasks will be conducted by for-profit ventures, nor is it true that companies will not carry out tasks suited for Open Source development. For example the second chapter learned that companies often assign a number of programmers to develop code for a certain project. Arguments for this behaviour were an increased knowledge and understanding of state- of-the art developments from within. Such understanding makes it easier for companies to address the needs of the project, although this code contribution is not likely the core activity. So the tasks that are left idle for companies are mundane task, non-standard (niche-market), non-modular and high cost tasks. The first thing that should be noticed is the fact that these are not all tasks specific for software houses, making a direct comparison between proprietary software houses, with Open Source ventures inappropriate. The array of tasks is broad and various companies have identified these holes, and have taken advantage with the various business opportunities as mentioned in chapter four. It includes software, infrastructure and end-user services. In this paper the focus especially resides with the support seller’s model, so also in this discussion.

68 Forrester Research, Linux is more than ready for the enterprise, June 24, 2003

Mundane tasks consist of the writing of manuals, installation programs, maintenance, and the operating of a helpdesk for instance. In the second chapter mundane tasks were identified as a task that difficult to carry out in the Open Source module, and simultaneously a task that brings little reputational increases to its performers. It is expected that support sellers focus on mundane tasks. In the figures of the previous chapter these mundane tasks have been categorized as “non-source contribution”. It is expected that support sellers’ especially contribute non-source contributions. And the code contributed is highly specific; such a company would make a similar calculation as any individual. What are my costs, what are my benefits, and what is the chance of others developing. Another task that does not fit the definition of a mundane task, but which is closely related to support is that of consultancy. Although a tasks that ought produce information, it is not well conducted in a peer production mode, especially since the information is applied to the circumstances of an individual client.

Next to the task that is performed, it is also important for whom the task is carried out. Or in other words what is the target market? Companies are expected to cover tasks, which are difficult to carry out in a peer production manor. The argumentation behind this reasoning comes from the fact that programmers write code, not from altruistic incentives, but for private, egoistic motives. Since the programmers are themselves the most skilled of all users, they do not need many (introducing) services or tools. This is a result of what has been identified as the ‘sophisticated user-bias’.

Next to this, it is claimed that commercial companies enlarge the potential market, and consequently add to a positive feedback cycle. If this is true, it is supposed that these companies focus more on the mass consumer market, as compared to the community of software developers. It is expected for an Open Source project to have a higher degree of decentralization and a further developed network structure compared to for-profit organizations. This would lead to a focus, which is internal; the goal is not to provide a service for people outside the network, but rather to provide service for each other. Thus creating the community is the overall target. The previous discussion is explicitly limited to individual end users. Business-2-business services are excluded. Nevertheless this is a market in itself. In chapter 4, on the motives of commercial involvement, the advantages of their inclusion included an increased professional image. Large businesses have very different requirements. They need more specialized, custom specific systems and extensive consultancy services. Tasks hard to be delivered by a network of individual developers, but simultaneously the highly specific, and professional nature of the tasks indicate a possibility for profit. o Mundane Tasks o Niche Markets o Non-Modular, High-Cost Tasks o Business Services

5.2.7. Can a distinction be made between a group of Open Source developers, a commercial sector, and thirdly a (mass) user-market? This question serves as a round up from all the subquestions. Preliminary results from the literature study indeed indicate that the task carried out by for-profit organisations is different from that of the Open Source Community itself. With code development assigned to the community and complementary tasks like support, mundane tasks and highly specific code developments better suited for development by for- profit organisations. It still is questionable however, whether or not for-profit organisations are part of the Open Source Community or operate with a certain distance to the community. Or even more so how the division of labour takes shape within the various components of software development and support services.

. 5.3. Analysis of tasks

The first subquestion categorized the different tasks identifiable within Open Source. This categorization will help in answering the thesis’ central question on whether there is a division of labour. From this categorization in tasks, it will not be concluded for each task, whether it is better executed in an Open Source or For-Profit setting. Rather the categorization assists to see the distinctions between the two, and from that explains why certain tasks are developed as they are. In this paragraph, the various tasks will be analysed individually and when possible a proposition will be drawn, stating an expectation for how the task will be conducted in the cases of chapter 6.

5.3.1. Code Development In this thesis the relationship between support sellers and Open Source Software Projects is discussed. Obviously support sellers deliver support and the Open Source projects develop software. Nonetheless Debian, Red Hat and SuSE all operate in the same area, all are Linux Distributors. But Debian is an Open Source Project and Red Hat and SuSE are for profit support sellers. The fact that all are Linux Distributors makes us to believe that although code development might not be their primary tasks, Red Hat and SuSE do need to develop software. So most likely code development is not exclusively a task of the Open Source Community, support sellers are likely to have also a share in development. And in fact the example of the installation program has been used several times. Nonetheless OSS’s philosophy implicates that the software developed is part of the public domain, in which it is very hard to make money from the source code itself. Therefore in general we do not expect for-profit support sellers to develop considerable amounts of software for the public domain. Explicitly in these assumptions software development within an Open Source Project by employees is excluded, since it is assumed that in that respect incentives for a commercial organisations are no different from any other volunteer contributor. What we expect to see is that for profit organisations target highly specific niche markets, or apply a kind of versioning strategy in which they develop a fee-based professional version.

Therefore the first proposition states:

Proposition 1. For profit Support Sellers will develop limited amounts of public domain software, but aim software development at niche markets or professional use.

5.3.1.1. Compatibility The issue of compatibility is closely related to the discussion on standards. However compatibility itself deals in specific with how software can interoperate with other kinds of software or users. Not only does compatibility apply to the current users, also exists backward and forward compatibility, which indicate how well a current piece of software will be supported in the future (forward compatibility) or how an old piece of software is supported today (backward compatibility). For example today reading a Chiwriter of WordPerfect file in Word is backward compatibility, and in a couple of years being able to read Word2000 is forward compatibility. With proprietary software these kinds of compatibility are a cause of trouble. This issue of compatibility is of great importance to the users of software, since the use value is often determined by how many other people use the same program or a similar compatible program. Obviously compatibility is achieved by adhering to standards in programming. The curious thing with Open Source is that often the openness of the code, guarantees compatibility, since everyone is able to write a program to make them compatible. Since in practice compatibility and standardisations have such close links is the proposition for this task left for § 5.4.1.8.

5.3.1.2. Coordination According to Benkler (2001) coordination and integration are one of the boundaries of the peer review process. Co-ordination is especially important since the developers are geographically dispersed, and face-to-face encounters are therefore rare. Proprietary software houses usually centralize their development departments in order to enhance face-to-face co-ordination. The degree of modularisation and granulisation determine how well this coordination effort can be managed.

When we expect for profit organisations to develop less software for the public domain, this does not necessarily include that they do not apply a system of peer-review. But especially when it is true that these support sellers target professional users and are occupied with implementation processes, as is one of the expectations in 5.3.2. In such case co-ordination mechanisms require more face-to-face encounters, and are more likely to resemble that of traditional organisations. When the co-ordination model is questioned, one simultaneously questions the development model at large. Especially to prevent the risk of duplication, it might make more sense for a for-profit Linux distributor to apply the cathedral model of development. Therefore:

Proposition 2. The cathedral model of development is applied by for profit organisations, since a high level of co-ordination is needed as opposed to the bazaar style of development applied by Open Source Projects.

5.3.1.3. Documentation Next to the source code, documentation is an essential part of a software development process. Documentation refers in specific to the technical documentation complementing the source code. Although the source code is self-explaining to some extent, a written description of the code will assist any programmer on the nature of the code and in such prevent errors. Since Open Source is highly depended on modularisation, it is expected that also the individual programmers, only for their contribution, will provide the technical documentation. Where one would expect to see a more integrated kind of documentation for software developed by for profit support sellers. However the task of documentation is closely related to the development model applied in software development. Previously a possible distinction between Bazaar and Cathedral development has been indicated. Exploring this issue more thoroughly by means of an extensive discussion on the technical documentation seems awkward when the central subject of this thesis is concerned with the division of labour.

5.3.1.4. Functionality Functionality is one of the tasks in software development that exhibit a close link to the central question. In fact functionality is all about what features are developed and included in the software. In chapter 2 it was concluded that volunteer developers have a personal incentive to contribute, which often included a personal need for the program or a feature. So an Open Source Network has most likely an internal orientation; trying to suit the needs of its members. The goal of a company is rather to make profit, and for profit they depend on customers. So, in contradiction with OSS developers the orientation is external. What is expected is:

Proposition 3. Open Source Projects will develop features on the basis of internal demand, where for profit organisations will develop on the basis of market demand.

5.3.1.5. Innovation Open Source advocates argue that Open Source is better suited for innovation, as compared to proprietary software. In this paper this theme is linked to the organisational network structure (Chapter 3, Cowan). Especially since the pool of contributors is highly diverse, which should necessarily lead to a multitude of ideas69. Additionally technologically challenging tasks are recognized with a large reputational increase. A reward that would likely spur motivation. So our first assumption would be that any for profit organisations would be less innovative as compared to an Open Source equivalent.

69 Notice that in Open Source developers contribute voluntarily, so any new leader should make its idea attractive and plausible in order to attract contributors.

But the problem is that the relationship between innovation and Open Source is still not well understood70. First of all one should differentiate within the innovation process, and separate between radical, and incremental innovation. Furthermore chapter three provided an extensive discussion on the relation between network structure and the rate of innovation. From this theoretical discussion it was derived that a network, which on the one hand is open, but on the other hand has cliques of interconnected members is the most effective in innovation. It might well be that companies who deploy multiple programmers look like such a clique.

In the cases selected the topic is difficult to research, since a major task of Linux distributors is to assemble one package out of Linux, GNU etcetera. This is not an innovative task in itself. Nevertheless the following proposition will be taken to chapter 6:

Proposition 4. Open Source Projects are more innovative compared to for-profit firms.

5.3.1.6. Integration Integration is a task closely related to co-ordination; where co-ordination especially deals with who develops what code, and to make sure that duplication is prevented, integration refers to how to coordinate the finished pieces of code into one package. The literature provided the insight that in most Open Source Projects this process was organised in a meritocratic structure with a benevolent leadership. Where everybody is allowed to write patches, but where a voting procedure or technical committee determines which patches are included in the official release. Obviously this is the kind of structure that is expected for an Open Source Linux Distributor as well. However it is not likely a structure for a commercial company, which make use of a command kind of structure. Eventually this leads to a similar expectation as under 5.3.1.2 that a different model of software development is expected. Therefore:

Proposition 5. Open Source Software uses a meritocratic hierarchy structure to integrate the various software components.

5.3.1.7. Security Although security is a key part in any software program, the issue of security is left out of this discussion. Again because Linux Distributors make use of code written by various Open Source Projects, and therefore inherit quite a bit of their security measures. And also because it is unlikely that considerable amounts of data on the issue will be found.

5.3.1.8. Standardisation Usually software that is suited for development in the Open Source mode exhibits a considerable influence of network externalities. And thus play standards and standardisation an equal important role (Chp. 3). Therefore participants in peer production in general have a high incentive to adhere to standards. In fact one of the limits to Open Source is the ultimate scarcity in developers. Not adhering to a standard would most likely lead to two or more competing systems, which would only result in a duplication of effort. It is for a reason that forking in ‘hacker’ ethics is ‘not done’. Also from a social value perspective, standards result in an optimalisation of social welfare as has been indicated in chapter three. Nonetheless a private standard, or a slight deviation of a standard can be beneficial for an individual company; if a company is able to create a lock-in situation for its customers it can charge a surplus. This is one of the risks, which have been discussed in chapter four: an example of a firm’s own agenda. These two thoughts, on the importance of standards, but also the possibility for extra profit for not adhering to a standard lead to the expectation that standards will generally be adhered by support sellers. However in their specific market, they will try to distinct their offering from the competitors and in that try to disobey the standard. Nevertheless in general it remains a strange strategy for a support seller to try to distinguish itself by means of offering a different software package, since their prime activity ought to 70 Some point at the similarities between Microsoft Windows and the graphical interface of many Linux versions in order to indicate that Open Source is not as innovative as is claimed.

be one of complementary service. The risk exist that not so much one gets incompatibility, but rather a diversification of systems.

Therefore:

Proposition 6. For profit organisations will adhere to the standards set by the Open Source Community, but will try to blur on standards where their specific offering is concerned.

5.3.1.9. Testing The peer review system has been discussed in the second chapter. The fact that multiple people check the code, make slight adaptations and especially give feedback on the existence of bugs makes, according to OSS, that the quality of the software is exceptional. However peer production is only possible when many people have excess to the code, which means that one, has to release the software early. Usually Open Source therefore has two release tracks, a test release and a stable release. This is what we expect to find in the case of Debian. However before the expectation for for-profit Linux Distributors was that they are more inclined toward a cathedral mode of development. In this respect it is unlikely to observe a peer-review testing process for their software.

Proposition 7. For profit organizations will test the software internally and thus have a cathedral model of development.

5.3.1.10. Usability A final characteristic of software development that deserves attention is that of usability. Usability is the easy or difficulty with which a user uses a program. It includes the installation procedure, but also the interface. Actually the interface for many programs is a fairly detached skin, but extremely important for the user’s perception. Again it is know that Open Source is sophisticated user biased, which means that the interface and installation procedure is less determining, since most users will be sufficiently skilled to use the program anyway. Together with the assumed internal orientation this leads to:

Proposition 8. The usability feature in software developed by for profit organisations will outperform that of Open Source Projects.

5.3.1.11. Conclusion The above analysis has covered a broad range of tasks and functions identifiable within software development. Although software development is expected to be a task of secondary importance for for- profit support sellers (in fact support services most likely are their primary activity) it is still appropriate to find out where the main differences are located with Open Source Development. The expectations collected from the analysis indicate first a likely difference where co-ordination is concerned, expecting a cathedral versus bazaar model of development. A second distinction concerns the functionality function; Open Source Projects will be driven by an internal demand, as opposed to a market driven demand in for-profit organisations. Finally the third major contradiction is expected in the field of standardisation; Open Source projects will not have any incentive to blur a standard, where for- profit organisations have an incentive to distinguish their offering from competitors. o Internal Orientation vs. Market Orientation o Bazaar Model vs. Cathedral Model 5.3.2. Support Services Support services are complement to the developed software. Where this software development is likely the primary task of any Open Source Project, support services are the primary activity of support sellers. In chapter four it has been indicated that especially support is one of the functions that is difficult to carry out in a peer-production mode. It is therefore a source for business opportunities.

The users of these support services can be categorized in three, including OSS developers, businesses and consumers71. In the framework that has been constructed in chapter one, the expectation was that support sellers would likely focus on this last consumer market and businesses; OSS developers would be sufficiently skilled to use the software, or would find sufficient levels of support within Open Source projects. Therefore:

Proposition 9. For profit organisations will offer support services for less skilled users.

Proposition 10. For profit organisations will offer support services for businesses.

Proposition 11. Open Source Projects will focus support services on the community of developers.

5.3.2.1. Consulting For companies the decision on what software to use is often a highly complicated one. Such a decision not only will require a huge investment, but will also directly affect all departments and organisational units. All the different organizational units will have different requirements, related to their specific function, next to the fact that often many different kinds of hardware are in use. A careful examination of the issues and problems is essential in such case, and this is a prime function for consultants. Due to its complexity and the many interrelations it is not a task suited to be modularised, and therefore unsuited for peer development. Actually consulting is a fine example of the lawyer’s model as described in chapter four. Therefore:

Proposition 12. Consulting services will exclusively be offered by for profit organisations.

5.3.2.2. Documentation Often support services are information goods, just like software. In that respect documentation would fulfil one of the requirements a successful implementation of a peer-production system. An although in chapter two Benkler’s (2001) view is discussed that such a task possibly can succeed in Open Source, it is generally accepted that documentation is a mundane task. If this statement hold then:

Proposition 13. Documentation from for-profit Linux distributions will be more extensive as compared to Open Source documentation.

5.3.2.3. Implementation & Migration If one were to describe the characteristics from implementation and migration as a good or service, this would only marginally include it as sharing components with information goods. Implementation just like consultancy is an application of the software product. In such it is not a likely task for peer production. Most often implementation and migration is a task required by larger firms. Nonetheless individual users also need some support, one can think of upgrading to a newer version. Nonetheless our assumptions:

Proposition 14. Open Source projects will have limited support in implementation..

Proposition 15. For profit organisations will have extensive implementation services.

5.3.2.4. Maintenance In the literature one of the advantages of Open Source compared to proprietary software was that older, or even outdated systems would be longer supported and maintained in the OSS environment. However this is not the kind of maintenance that is referred to here. What is meant with maintenance is essentially the second phase after successful implementation and migration. Maintenance is keeping an individual system up-to-date. 71 The distinction between individual consumers and individual developers is the level of skills.

Concerning expectations these do not differ fundamentally from the implementation and migration. Therefore to prevent excessive duplication no propositions are set.

5.3.2.5. Support The issue of support has been extensively covered especially in the second chapter. Open Source Projects deliver a certain level of support. This support is just as the software development entirely based on communication over the Internet. Support from Open Source Projects takes the shape of mailinglists, frequently asked questions, forums and the like. Mailinglist seem to be the favourite communication tool, they are stored in order that new users have access to an array of previously discussed topics. Any projects expects a certain degree of autodidact ness and skills from it users. In order to interpret the message correctly communication relies on procedures and routines. In general the support function looks like the development co-ordination process; in fact it is peer-production based. The incentives of information/support providers are as is indicated in chapter two motivated since they learn more about the program, and because cost of a contribution are low, since they know the answer in advance. Since the support function is peer production based, an answer is never assured. In fact people add voluntarily. It is expected that the support function of Open Source Projects differs fundamentally from that of for- profit organisations. For profit organisations are not likely to rely on a system that leaves a chance that a question is neglected; it will rather provide a service with paid employees. The consequence is that users are expected to pay for this service likewise.

Therefore:

Proposition 16. Support from Open Source Projects will be limited to online forums and mailinglist.

Proposition 17. For profit organisations have skilled employees to answer consumer questions (fee/subscription based).

5.3.2.6. Training Businesses but also individuals require training, in order to use a program efficiently. It can safely be assumed that this training function is lacking in an Open Source environment, in fact even the developers need to be autodidact. One of the prime reasons is again the fact that the peer-production system is unsuited; training is hard to modularise. For-profit organisations face a different situation. First of all because they are expected to have a focus on the business market, and secondly because training is related to a process of implementation and migration. Therefore most likely a commercial Linux distribution will pay close attention to training, whether this task is internally organised, or outsource to third party remains a question. But since the for- profit organisations have the knowledge internally I would opt for the first possibility.

Therefore:

Proposition 18. Open Source Projects will have no training; even developers need to autodidact themselves.

Proposition 19. For profit organisations will have extensive training services.

5.3.2.7. Conclusion OSS has support but is limited to online communication and only suitable for at least moderately skilled users. For for-profit organisations support will a core activity, particularly consulting and implementation are likely to be the source of a large percentage of turnover.

5.3.3. Marketing & Distribution Since network externalities play such an essential role in the Open Source Software, marketing is one of the functions that should have full attention of the community. Unfortunately the effect is indirect. New

users add value for all other users, but an individual user has a too small incentive to market the offering to attract new users, except for the personal pride they take in having as many people as possible use their code. In this respect it shares some of the aspects of the tragedy of the commons. Simultaneously an individual Open Source project does compete for the interest of developers, and in such has to be attractive and promising. Especially where Debian competes with Red Hat and SuSE, an Open Source Project needs some kind of awareness creation. In this section the differences concerning this marketing and distribution will be analysed.

5.3.3.1. Awareness & Branding Awareness creation is a task on informing possible users about the characteristics and especially the benefits of a certain program. A commercial organisation will spend considerable amounts of money on this marketing function. In such it has a well-known array of possibilities. For an Open Source project it is close to impossible to spend large amounts of money on advertising, word of mouth advertising is more likely to be part of the marketing mix. Both Linux distributors nevertheless need to strive to an ever-higher awareness. The brand name of a Linux distribution will play a significant role in any awareness strategy, especially for for-profit organisations. In fact a well recognized brand name provides for a degree of trust, particularly useful to overcome problems of the unknown nature of information goods. Open Source Projects I expect to be much more inclined to rely on partnerships with other organisations to improve their awareness. A problem concerning Open Source Projects might again be the internal orientation of development.

Proposition 20. The internal orientation of Open Source Projects means that little effort is put in generating public awareness.

Proposition 21. For profit organisations will spend considerable resources on awareness and branding.

5.3.3.2. Certification Since software is an information product, it suffers from information asymmetries. Users are not aware of all the capabilities and qualities, unless they start using and learning a program. Certification is a tool in order to overcome some of the information asymmetries and ascertain a user a level of quality. LinuxCare is for example offering certification services to certify Linux Distributors72. Most certification within Linux however deals with certifying individuals in their Linux skills. Certification relies on the reputation of the certifier. It is a task important for all Linux Distributors, however it is not a task that can be dealt with in isolation. In this paper no effort will be made to analyse the information asymmetries that exists, nor the way the individual Linux distributors try to overcome these. Unfortunately it is a topic out of scope of this thesis.

5.3.3.3. Customer Service A third task is that of customer service. Included under this heading are especially after sales service, like handling feedback and complaints. In Open Source Projects this task is most likely lacking. Actually the producers are simultaneously the users. Complaints on the performance are only accepted in the form of a bug report. For a company customer service is an important tool in enhancing their image and the relation with the customer. Nevertheless this paper will not discuss this issue in-depth, since at this point it is difficult to distinguish the task from regular paid support service, and especially for Open Source it would require a detailed discussion on the relationship between testing and customer service. Both of which are out of scope of this thesis.

5.3.3.4. Distribution 72 http://www.linuxcare.com/labs/certs/

Next to a process of awareness creation, a proper distribution network can enhance the acceptance of a program by the market. In fact one of the major problems for Open Source Software is the fact that Microsoft has entered partnerships with hardware manufacturers; Microsoft Windows and Office is often pre-installed and consumers buy the hardware and software license as a bundle. Unfortunately the literature survey did not provide much insight in how the distribution in Open Source projects is organised. What is know is that the source code is available as a download from the website. But a large group of consumers will not have excess the a broadband Internet connection, and for this group downloading via for example a telephone line would be slow and expensive. Therefore Open Source projects will distribute their software also on CD-ROM, most likely via a network of distributors. Where for profit organisations are concerned it is know that they usually charge a user a small fee for the software. Or in fact they bundle the software with their support.

Proposition 22. For profit organisations will bundle the software with support services and charge for their distribution.

5.3.3.5. Conclusion It is expected that the marketing and distribution function is important for both cases. Nevertheless branding is more likely to be an issue for the for-profit organised Linux Distributions. Concerning distribution it is expected that for profit organisations charge for the software, since they bundle it with support services. Open Source Projects are more inclined to find partnership in order to distribute their software and create awareness.

. 5.4. Conclusion This chapter has provided a brief summary on the main issues of the literature survey as discussed in the previous chapters. With regard to the functioning of the Open Source Community it is indicated that it is has a network structure, but simultaneously has some meritocratic hierarchy. The prime mode of communication is by means of the Internet, in which a system of peer review pushes development. This same system makes that only high quality contributions are accepted, which leads to a sophisticated user bias. Prerequisites for developers to contribute originate from a rational pay-off calculation, which results in tasks needing to be modular, and of low cost. Suited in this respect is especially information production. The software becomes part of the public domain. Commercial organisations do not have many incentives to produce for the public domain, their primary goal is to make money, and within Open Source they can make money by performing task that do not come about in a peer production system, mainly mundane tasks and support services. From an economic perspective this involvement is beneficial since Open Source produces in particularly software with high network externalities, and companies can assist in expanding the market. Nonetheless the risk of project appropriation by commercial organisations needs close attention. Furthermore this chapter provided the outline of analysis, which will be continued in chapter six. The tasks within Open Source Development have been categorized according to three prime functionalities: code development, support services and marketing & distribution. After an in-depth analysis of the various tasks belonging to each functionality, a number of tasks have been excluded and for others propositions are stated. Eventually the categorization that will be continued into chapter six includes:

Code Development:  Co-ordination / Integration / Testing  Standardisation / Compatibility  Functionality  Innovation  Testing  Usability Support Services:  Consulting  Documentation  Implementation, Migration & Maintenance  Support  Training Marketing & Development:  Awareness & Branding  Distribution

This categorization left some 20+ propositions, each of which is specific to a single task, but also evolving from the theoratical concepts that have been covered in the earlier chapters. To stress these theoratical interrelations the table below presents for each proposition the connection with various theories. Simultenuously this table thus indicates what propositions are closely related.

Proposition Theory 1 A public good is non-scarce and non-rivalrous. 2 The peer production process, Cathedral Model vs. Bazaar Model. 3 Incentives of developers. 4 The peer production process, peer review, characteristics of information. 5 The peer production process. 6 Firms have an own agenda. 7 Peer revie process. 8 Incentives of developers. 9 Incentives of developers, sophisticated-user bias, mundane tasks. 10 Personal incentives of developers. 11 Incentives of developers, Reputation. 12 Incentives of developers, mundane tasks, modularisation, Lawyer’s Model. 13 Incentives of developers, sophisticated-user bias mundane tasks. 14 Incentives of developers, sophisticated-user bias mundane tasks. 15 Complementary services. 16 Low cost of contribution, peer review process. 17 Complementary services, sophisticated-user bias, mundane tasks. 18 Incentives of developers, sophisticated-user bias. 19 Mundane tasks. 20 (none) 21 (none) 22 (none) Table 5.2. Proposition with their corresponding theories.

“Linux is like a Mercedes Benz, Windows like an economy car; if an economy car breaks down in a small remote village, every mechanic can fix it, however with a Mercedes you remain stuck.” Bangalore saying, quote from: Sunil Abraham Ayrookhuziel

. 6.0. Objectives  To introduce the Debian and Red Hat/SuSE cases  To analyse the propositions in the context of the cases.  To interlink the case analysis’ conclusions to the central question.

. 6.1. Introduction The last chapter analysed the initial sub questions based on a literature survey. Simultaneously propositions were derived of how the situation in the Debian and Red Hat/SuSE-cases would look like. In this chapter these expectations will be tested. The analysis start with a formal discussion concerning the methodology, research design and limitations of this analysis, after which the two cases are introduced, as well as is the market in which they operate. The final analysis is a discussion of the cases in connection with the propositions.

. 6.2. Methodology, Research Design & Limitations

6.2.1. Methodology The prime goal of this thesis is to analyse the relationships that are present within Open Source. Special attention is given to the relationship between for-profit and not-for-profit participants. This relationship has only developed itself over the last decade, and so the subject is a relatively new phenomenon. Not yet are all characteristics and motives within the relationship identified, and therefore a statistical analysis of data was perceived to be unsuited. Rather this thesis tries to provide a complete overview of the various characteristics of the relationship. For a reason does chapter two describe the Open Source Community extensively, does chapter three introduce various economic theoretical principles, does chapter four ultimately introduce the commercial aspects of Open Source. This kind of research structure can be classified as an exploratory research (Cooper & Schindler, 1998). The main purpose of the thesis is to answer the question whether a labour division can be distinguished between the Open Source Community and for-profit organisations. Therefore the analysis is structured along a categorization of tasks necessary in software development. This categorization includes a division in three broad functions: code development, support services and marketing & distribution. Each of them is subdivided, where possible expectations for the Linux Distributor’s cases are formally stated as propositions. This chapter will discuss each of the propositions.

6.2.2. Data Sources For this research data is collected from a wide range of sources. Where much information for the literature survey could be gathered from academic papers. Concerning the academic papers it should however be mentioned that some of the standard works are not written by academics, but by people from the Open Source Community, and therefore they might be a bit less objective; this is especially true for the writings of Eric Raymond. The literature on Open Source can furthermore be divided in three blocks, lots of articles deal with the incentives of developers to contribute voluntarily, while a second block especially focuses on the Intellectual Property aspects of Open Source. A third, much smaller block deals with the economic aspects of Open Source. Next to these written sources, I have attended a number of lectures and conferences on Open Source, in which some perceptions were formed. Information on the research cases was a bit scarcer. Most information is gathered over the Internet. This not only includes the websites of the cases, but valuable information is also gathered by means of posting in Internet forums. This data collection method can be referred to as observational (Cooper & Schindler, 1998). Published articles on the two cases, where furthermore gathered by a search in

Ebscohost, The Economist and various other magazines. Keywords used include: Debian, SuSE, Red Hat, Linux Distributor, and Open Source etc. A problem in the collection of data, but simultaneously valuable information in itself, was the skewed ness of availability of information; much more information was available from the Open Source Linux Distributor as compared to the for-profit Linux Distributor.

6.2.3. Limitations Although the thesis tries to cover the many aspects of the relationship between Open Source and for- profit organisations the research itself is limited to labour division between an Open Source and commercial Linux Distributors. This implicates a limitation in scope; that is for example the relationship between large multinationals and Open Source is eventually excluded. In fact from the various business models as mentioned in chapter four, only the support sellers model is analysed in the research part. A second limitation results for the fact that a number of tasks are discontinued after an initial discussion in chapter five. Either because they are out of scope of the thesis, or not sufficient data is available for a proper discussion. This makes that in the final overview of differences some tasks are omitted, which could result in a bias. Finally what is researched is one of the finest Open Source Projects. In fact both cases are part of the larger Linux family. Linux is one of the more successful Open Source Projects in terms of project scale. It is not sure, whether the relationships are identical in other projects. Especially since the kind of software may differ; Linux is an operating systems, and secondly the size might matter. The argument to opt for the Linux community is mainly inspired by the relatively long history, which results in a much more developed structure.

. 6.3. Market Description

6.3.1. Software Distributors Debian and SuSE are categorized as Linux Software Distributors (LD’s). The function of LD’s is to compile a full-scale operating system based on the Linux kernel. For both the Linux kernel is thus the core code. However a stand-alone kernel will not bring an individual user much to joy about. A full operating system requires a range of additional functions. The choice in addible functions is massive; it would not make any sense to include all, since it would only make a system unnecessary big and complex. Therefore LD’s make a selection which features to include. In fact the additional functions are mostly not developed within the Linux project, but by others. One example of such function are desktop office packages, where three main Open Source projects exist: KOffice, GNOME Office and OpenOffice. So the Linux Distributors select a short list of functions, of which they make sure they cooperate together. This explains why Linux is not distributed as just ‘Linux’, but rather as ‘Debian Linux’ or ‘Red Hat Linux’. This is not pure a difference in brand name, it is a different, but binary compatible 73, operating system. Nonetheless this diversification in Linux Operating Systems seems to start causing problems of diversification and duplication.

6.3.2. Market Boundaries. This paragraph goal is to set the boundaries of the market. The market under analysis is limited to Linux operating environments. This thus includes for-profit and not for profit implementation of Linux systems. It is possible to subdivide the market according to both target market and product category. With respect to target market the most sensible division is between business clients and private individuals. Where the individual users are on a continuum from poorly skilled to highly skilled. Next a division in product category would result in a sub-market for desktop applications and server applications. The above market definition is limited to the horizontal scope. From a vertical market, or supply chain, view the market would be bounded by the true software developing projects as there are Linux, GNU, KOffice and the like, above the Linux distributors and the vendors further down the chain.

73 Binary compatible means that a program runs on a ‘foreign’ distribution.

Market

Business Users Private Users

Linux Server Linux Desktop

Fig. 6.1. The Linux Market

6.3.3. Market size. In monetary terms the market is relatively small. Looking at the figures of stock market listed Red Hat for instance, revenues are in the range of 80m dollar (2002). And although the share-price has tumbled (1/30 of peak value) their market capitalization as of August 2002 is still at approximately $860m. Computerwire Magazine estimated the revenues of all competing Linux distributors at 180 million. However small the relative market, research companies like IDC 74 (Int. Data Corp.) expects an annual market growth of 28% resulting in combined market revenues of $280m in 2006. Various articles (a.o. in The Economist) indicate a downward trend from the years 2001/02 onwards, with various LD’s announcing lay-offs. However small the market may seem, a Forrester Research 75 indicates that 17% of large North American companies already use Linux.

Fig. 6.2. Market share of Linux, servers running Linux as operating system: http://www.netcraft.com, Feb. 10, 2003) Note however that in the biggest market, the market for desktop pc, Microsoft is still a near monopolist with a share of around 90-95%!

74 www.suse.com/us/company/press/services/information/linux/market.html May, 16, 2003. 75 Forrester Research, Linux is more than ready for the enterprise, June 24, 2003

Fig. 6.3 Expected increase in Linux use for $1 billion-plus firms. Source: Forrester Research 2003,

6.3.4. Market Players It has been indicated before that Debian, Red Hat and SuSE are not the only players in the market. There is a multitude of offerings, however the main market resides with half a dozen of suppliers. Of which Debian is the only true Open Source player. The largest Linux Distributor is Red Hat Inc., with its main market in Northern America. Other competing companies include Mandrake/SCO, TurboLinux, and Correll. Next to these true Linux Distributors exists a few companies that have operations closely related, they include VA Linux and Linuxcare. VA Linux is a supplier of hardware, which delivers hardware fully suited for Linux and with Linux pre-installed. Linuxcare is a service provider, without an own distribution, rather supporting all major Linux distributions. Furthermore the Linux Distributors face competition from large multinationals like IBM, HP, BMC, Dell, Oracle etc. These companies provide Linux support together with their hardware.

. 6.4. Cases.

6.4.1. Case I: Debian In this thesis paper it has more than once been mentioned that especially standards, languages/protocols, operating systems are best suited to be developed in an Open Source mode. It is thus not a surprise that as a study case an Open Source operating system has been selected. In fact these projects exist for a longer period of time and are better developed. In specific this section introduces the Debian project. Debian is an operating system; nonetheless it is not a competitor of Linux. Actually it is a project taking Linux a bit further. Linux has a focus on the core part of an operating system: the kernel. Debian builds basic functionalities around this Linux kernel. But this is not the end of the story, instead of developing all the tools itself, the project uses a great deal from the GNU Project. Debian thus is a Linux and simultaneously GNU distribution, and therefore also referred to as Debian GNU/Linux software distribution76. As a Linux distribution it is a direct competitor of its commercial equivalents like Red Hat, MandrakeSoft and SuSE. Where the GNU project started as early as 1984, Debian started just after the introduction of Linux (1991) in 1993 being founded by Ian Murdock77. Since 1993 development has been rapid, and by 2002 the project counted around 900 volunteer developers, which together have developed and maintain an operating system with over 8500 different features (packages).

76 Debian.org, gnu.org, linux,org 77 http://www.debian.org/doc/manuals/project-history/

Debian Development

10000 1200 8000 1000 s r s 800 o t e

6000 u

g packages b a

600 i k r t c 4000 contributors n a 400 o P 2000 200 C 0 0 5 6 7 8 2 6 9 0 9 9 9 0 9 9 9 0 9 9 9 9 9 9 0 0 1 1 1 2 1 1 1 2 ------1 6 2 7 7 3 8 7 1 0 1 0 0 0 0 0 Years (not incremental)

Fig. 6.4. Graphical representation indicating the speed of development since 1993. The figure is based on data per software release originating from Debian.org.

Debian is the only major LD that is itself an Open Source Project. Debian thus is a network of volunteers operating jointly over the Internet to produce software. The project has close ties with the Free Software Foundation, which is reflected in the project principles. These principles are joined together in a ‘social contract’ (Appendix.3). Next to the social contract Debian has published ‘The Debian Free Software Guidelines’ (DFSG). Together these two documents function as the basic set of rules, governing the Debian project, and various elements of the documents will appear frequently in the case and the analysis. It has been tried to keep the case description brief, nonetheless many characteristics will be touched upon, divided in four general topics. To start with a description of the services, the organizational structure, their target market, and finally Debian’s alliances.

6.4.1.1. Services A discussion on the services starts with the central product, obviously the Debian Linux Software Distribution. This product is assembled and kept up to date by a group of approximately 900 volunteer developers. The product is offered in three types. There is a stable, testing an unstable version. The stable version is aimed at end-users; all the functionalities have been thoroughly tested. However because of this stability-requirement and extensive testing it lacks the latest project developments. These are included in testing version that is meant to become the next stable version. The unstable version is an offering for true development purposes. The product includes over 8000 packages. Most of which are open, and in line with the Debian license. Nevertheless some 350 are not-open, or not in line with Debian’s software license. These packages are not formally part of Debian, but are supported and configured for Debian. In such Debian is not an opponent to closed software, nevertheless it makes sure that Debian itself never becomes dependent on such applications. Next to the core product, Debian offers a range of facilitating services, especially support. As well as the code development, is the support function maintained by volunteers. So users do not have any formal right to service, but nevertheless Debian did build a reputation of proper support. The project includes FAQs, forums, manuals but especially mailinglists. Mailinglists are the central communicating tool among Debian developers and users. There are some 250 mailinglist, with on average some 700 members, but individual lists up to over 30,000. Debian claims that on average questions are obtained within 15 minutes, and that is has superior quality over helpdesk/telephone support, since they respondents are far higher skilled.

Mailinglists may not serve every user properly; especially companies that want to implement Debian in their organization might require additional support. This is not provided by Debian itself, but there exists again external consultancy companies offering such support.

6.4.1.2. Organizational Structure The organizational structure of Debian is similar to that of other major Open Source Projects. It is a loosely connected network of volunteer programmers, however not anarchistic; a hierarchical structure formally governs the network. The project’s structure is divided in four areas: officers, distribution, publicity and support & infrastructure. Nevertheless this structure is not especially strong. Volunteers cannot be commanded, especially not if they are as globally dispersed as the Debian users are; communication between members predominantly takes place over the Internet. On top of the pyramid is a single leader, who serves for one year only. This leader is selected via a voting procedure, in which all developers have a vote. In the second chapter it was indicated that this leader would be selected on the basis of his past reputation; interestingly the current Debian leader, Martin Michlmayr, joined Debian as late as 2000. His reputation originates thus from participating in other Open Source projects. His role is mainly one of co-ordination, especially with respect to delegation or areas of responsibility for individual developers. As opposed to for example the Linux Project technical decisions are not part of the leader’s job description, they are left for the technical committee.

Fig. 6.5. Distribution of Debian (Linux) programmers over the world. This figure gives an impression of the distribution of OSS over the globe. Source: http://www.debian.org/devel/developers.loc, Dec. 23rd, 2002

6.4.1.3. Target Market It is hard to define the target market, easy at the same time. In fact Debian does not behave like a regular company. It has not defined its target market explicitly. Nonetheless in the social contract it is stated, “We will be guided by the needs of our users and the free-software community.” This might be perceived as a very general statement; in fact clients also guide a regular company. But within Debian the users are the developers, which makes that Debian has an internal orientation, rather than an external market orientation. For example a close look at the tasks carried out by ‘publicity’ reveals that press contacts, the partner program and events are there main tasks. Especially these events, conferences of users, clearly indicate the importance of the internal focus.

Interesting in this respect is that some volunteer developers take Debian to highly specific markets in what are called vertical distributions. One example is Debian Linux-Ham, containing additional programs requested by radio amateurs, but using the Debian base. Among the major users mentioned on the Debian website are especially high numbers of educational institutions, next to ngo’s, companies, and governmental institutions. Distribution of Debian is either by a direct download from a website, or by purchase of a CD. These CD’s are not sold by Debian themselves. Rather there exists a reliance on third-party vendors. In principle Debian does not make any money on these CDs, but the website explicitly mentions and recommends to buy CDs from vendors that donate part of the revenue.

6.4.1.4. Alliances Next to the relationships with CD vendors and support consultancy firms as they are mentioned above, Debian engages in multiple partnerships with firms. Two kinds of partners can be distinguished: development and service partners. Development partners are expected to contribute (hardware) equipment on preferable terms, or include vendors, who maintain key Debian packages, or include hardware manufacturers assisting and leading efforts to port and maintain Debian for their products, and finally include companies offering technical service to Debian at preferable terms. Major partners include Hewlett-Packard, Sun Microsystems, Progeny and Trustec. Service partners assist in distribution, non-technical services and publicity. All these partners are credited on the Debian site. The closeness of the ties between Debian and its alliances remains questionable to some degree. It is first of all awkward that the partner program is belongs to the publicity part of the organization. And next to this it is hard to maintain close personal relations, since Debian contributors are especially globally dispersed and the organizational structure is weak.

6.4.2. Case II. For Profit Linux Distributors.

“Linux is not nameless, faceless, and it’s not charity. Nor is it solely a community effort. What you see today is a technology revolution driven ever forward by market demand.” RedHat.com, May 2003

The second case description is not limited to one organisation, since such a limitation would not benefit the eventual discussion and analysis. In fact, the for-profit Linux Distributors have a lot in common, but differ in some aspects on which a discussion is valuable. Nonetheless this general remark, two companies have been singled out; Red Hat, because it is the first-mover and today is the market leader, and secondly SuSE, not only because it is the second largest LD, but especially since it is leading an attempt to unify a number of distributions.

6.4.2.1. Red Hat Red Hat Software Inc. is founded in 1995, when Bob Young’s company ACC Corporation takes over Marc Ewing’s Red Hat Linux Distribution. By now () the company has approximately 600 employees and a worldwide network of 60 offices. Since August 1999 the company is publicly held, being listed on NASDAQ. Revenues are in the range of 80m a year.

6.4.2.2. SuSE In 1992 university students founded SuSE (Gesellschaft für Software- und System- Entwicklung mbH) in Nuremberg, Germany. Currently () SuSE Linux AG has approximately 380 employees, and 4 international subsidiaries.

6.4.2.3. Services All Linux Distributors have compiled an own Linux Operating Systems (OS), this OS is the spill of their offerings. A subdivision should be made between the OS for servers (mainframes) and ordinary computers, or pc’s. Around the OS a web of complementary services has been constructed, including installation support, support-, consulting-, implementation-, and training services.

Where Debian has subdivided the OS between stable- and beta releases, both Red Hat and SuSE apply a strategy of versioning with a free, personal and professional or enterprise version. In the first quarter results of 2003, Red Hat states that it has sold a total of 23,000 subscriptions for the Red Hat Enterprise version. Actually the standardized professional version is aimed for small- and medium sized firms, for even larger firms the offer includes custom-tailored implementation. For nearly all distributions money is charged. That is the distribution is bundled with a certain period of support service. A user is still allowed to copy, even under the license78 of the professional version, except for some special arrangements for proprietary features79. What a user is not allowed to do, however, is to use the Red Hat Brand name, trademark or logo with a re-distribution, neither is the re- distribution entitled to support services. How important the brand name should be subject of further investigation, nevertheless there is a general assumption that brand name is especially important. In fact quality and service differences between the various commercial Linux Distributions seem marginal. Still Red Hat is able to charge a premium price of over $140 for a CD-ROM.

6.4.2.4. Organizational Structure With respect to the organizational structure not enough information is gathered to give a detailed description. However the specific structure does not matter for the analysis to come. In fact, the structure of SuSE and Red Hat is similar to that of other commercial companies. What is interesting for us to know is how the software development is organized. Where Debian explicitly welcomes developers to contribute, both SuSE and Red Hat seem to rely on their own personnel.

6.4.2.5. Target Market The paragraph on services shows that the product range includes the entire market. Products are supplied for private users, but simultaneously for large firms and for desktop applications just like server-based applications. However true this broad perspective, there exist clear preferences for each Linux Distributor. In general it can be stated that the business market is preferred over the private market. A small citation of Red Hat clarifies: “Retail consumers are usually enthusiasts who want the latest features, upgrade often, and require little or no technical support”. In terms of size SuSE indicates that although approximately 15m80 (SuSE.com, May 2003) people use SuSE Linux of which most are desktop users, the market for corporate servers is still the most lucrative. A second aspect in target market relates to the geographical dispersion. A clear geographical pattern can be observed, with Red Hat, especially leading in the United States, SuSE in Europe and particularly in Germany and TurboLinux in Asia. Such dispersion is not as much observed in the case of Debian, where users are globally spread, only a little skewed towards Europe.

6.4.2.6. Alliances Both companies have entered in multiple partnerships. For example SuSE has engaged in close relationships with HP/Compaq, IBM, SAP, Intel, Fujitsu Siemens, Oracle and Silicon Graphics. These partnerships make certain that SuSE can deliver their services worldwide. And co-operation furthermore makes sure that SuSE’s product line is compatible with for example SAP.

A recent development is the founding of UnitedLinux. Four Linux distributors (SuSE, SCO/Caldera, Conectiva and Turbolinux/SRA) have decided to produce one Linux server platform. The intention of this partnership is to prevent a further diversification of Linux versions, and to jointly develop one standard. The goal is to speed up technological development by preventing duplication

78 http://www.redhat.com/licenses/rhl_9_pro_us.html?country=United+States& 79 This is not different from the Debian distribution, which also includes some proprietary features. 80 Figures from Red Hat, (“Red Hat Trick’’ The Economist Oct. 1st 1998) indicate that a mere 10% of the users actually paid for a distribution.

. 6.4.3. Conclusion The results of the two case studies have been put together in a single table. In this table the distinctions between for-profit and open Linux Distributors are indicated, for various subjects.

Open Linux Distributor For-Profit Linux Distributor (Debian) (Red Hat/SuSE)

Several, ± 6 larger Number of LD’s One (UnitedLinux Initiative) Services Linux Linux/Consulting/Implementation Developer Oriented Market Oriented Versions Beta / Stable Free/Private/Professional Vendor Network Distribution Vendor Network Bundling with support services Helpdesk (extensive) Support Mailinglists charged support Business Clients and Linux Target Market Debian Developers Enthusiasts (limited) Several, to create a worldwide Development & Service service network and to integrate Alliances Partners Linux with major business software systems. Table 6.1. Case Comparison

. 6.5. Discussion The final part of this paper consists of an analysis of the cases above. In this discussion the propositions as stated in chapter five will be evaluated on the knowledge gathered from the case descriptions above. For ease of understanding, the analysis is structured similar to the structure of chapter five. That is a discussion per task, where the tasks are categorized within one of three functions. In the conclusion of chapter five the outline looks like:

Code Development: (UnitedLinux not open enough)  Co-ordination / Integration / Testing  Standardisation / Compatibility  Functionality  Innovation  Usability Support Services:  Consulting  Documentation  Implementation, Migration & Maintenance  Support  Training Marketing & Development:  Awareness & Branding  Distribution

6.5.1. Code Development The first proposition questioned the amount of public code developed by commercial Linux distributors. The first thing to become apparent in this respect is the distinction in product assortment between Debian and Red Hat/SuSE. Debian has just one version, leaving out developing and testing versions, where Red Hat and SuSE have multiple versioned offerings. Nevertheless the source code is available even with the professional versions, and rights to copy are granted. So in that respect most code is public, this is no surprise; it is just a direct implication of the Linux GPL-license. However this is not true for customer specific implementations and increasingly less true for other high-end features. In “Going Hybrid” The Economist81 points out that the downward trend forces LD’s to become more proprietary. A second source indicating this trend comes from within the Open Source Community where developers complain about the degree of openness in Red Hat and UnitedLinux (Computerwire, 2002).

So the first proposition is at least partly true. For-profit organizations do have an incentive to develop non-public source code. Nevertheless the main distributions for users remain public as a result of the GPL. Proprietary code therefore is only viable in the upper market segments. No references to specific niche markets, other then customer-specific, were found.

6.5.1.1. Co-ordination / Integration / Testing The second proposition questions the development model within for-profit organizations. A first indication that a cathedral model is to be expected comes from the geographical centralization of the companies. Although sales offices are spread around the globe, development is concentrated in the central offices. Secondly none of the websites of Red Hat, SuSE or any other provided entrances for active contributions of volunteer developers. A citation of the Red Hat website (May 2003) may clarify: “Red Hat’s dominant position in the Linux market has enabled it to assemble the world’s most talented group of Open Source engineers. They assemble the Linux kernel and other elements of the Linux operating system, compile it, and test it for performance and reliability. Then they add new features test for compatibility – all while sharing the software with customers, partners and software vendors, and members of the Open Source Community in a structured feedback cycle. No other Linux company has a process this complete or meticulous.” This quote indicates that indeed Red Hat internally applies the cathedral and that the advantages of the bazaar model are achieved by participating in Open Source Projects like Linux.

For these reasons the second proposition can be accepted that Red Hat internally applies the Cathedral model of development. But this not without the explicit remark that the software developed at least partly is exchanged with the Open Source Community, which is bazaar-like. Concerning the specific proposition on testing not enough data was found to support the proposition. Nevertheless most indicators still point in that direction.

6.5.1.2. Standardisation / Compatibility Our expectation is that for-profit organizations do generally have incentives to adhere to standards, but in their specific markets would seek slight deviations to create a lock-in for their users. On the one hand de facto standards seem to arise from the use of one (Red Hat) file packaging system. But on the other hand a number of case-results indicate in the direction or the proposition. First of all one might question why there is only one Open Source Linux Distribution, where multiple for-profit equivalents exists. This might be because of OSS ethics preventing forking, but not necessarily. What is even a stronger indication is the UnitedLinux initiative. SuSE one of the initiators itself writes that, because of the different distributions, there exist a risk of Linux becoming to fragmentised. Which lead first of all to a duplication of effort, but also to complex problems concerning compatibility. What is especially striking is that all major distributions join the UnitedLinux initiative, except for the market leader Red Hat. In this respect it appears a bit like a loss-leader strategy, where only the risk of loosing the battle forces companies to line up behind a single standard. Once again this indicates the existence of a firm’s own agenda.

81 “Going Hybrid”, The Economist, July 25th 2002

For these reasons there are strong indications that the proposition can be accepted.

6.5.1.3. Functionality Thus far the discussion centered on the mode of development. This discussion on functionality shifts the point of view towards the question ‘by whom and for whom certain functions are introduced?’. Recalling the proposition the expectation stated was ‘Open Source Projects are pushed by internal demand, where for-profit organizations are driven by external market demand’. Reviewing the Debian case support functions, development versions, manuals all are aimed for developers. Furthermore the department of publicity has as one of its major tasks to organise events and conferences for these developers. This point strongly in the direction that Open Source Projects are indeed internally oriented. Where commercial LD’s are concerned one finds various clues, among others from the Linux Distributors themselves: “Red Hat also provides a voice for our customers in the Open Source Community. We originate and support many projects that our customers feel are critical to their business.” (RedHat.Com, May 2003). Furthermore it is a logical consequence from the fact that both Red Hat and SuSE develop custom-tailored systems. Therefore also this proposition should be accepted.

6.5.1.4. Innovation The subject of innovation turned out to be very hard to be assessed. Some news reports82 quote business people dealing with Open Source and there it is claimed that OSS is especially suited to ‘optimising existing programs’, where on the other hand it is argued that radical innovation is better achieved within a tight group of programmers within an single company. Unfortunately no case-related data were found that either supported or did not support the proposition. For this reason no valuation is provided concerning this proposition. So, I would suggest leaving it for further research.

6.5.1.5. Usability The final component of the code development process is that of usability. First it was tried to collect data from Linux certifiers like LinuxCare, since data from Debian, Red Hat and SuSE will all be too subjective. Unfortunately the certification information only included the usability per hardware variant. Another difficulty arose because of various interfaces are developed within Open Source Projects like KOffice. Eventually this leaves us with barely more than the reports on easy of installation, which favours Red Hat and SuSE over Debian. However this is by far not convincing enough to reject or support the proposition.

6.5.2. Support Services The initial discussion on support services yielded a number of general propositions, in particular concerning the intended users of the software. Since already in the discussion above in § 6.5.1.3. on functionality it is concluded that Debian is pushed by the internal demand from the project, it requires little more discussion also to support the proposition that the support services of Debian are internally oriented. And in fact the online manual refers often to technical development documentation, and a considerable number of the 250 mailinglists are intended for developers. Where for-profit organizations are concerned the analysis should be more extensive. First the expectation that they would offer support services for less skilled users. This proposition needs to be rejected. And with that the idea that commercial organizations extend the market towards less skilled users. By now none of the Linux Distributors targets the market of the average desktop user. A quote of Red Hat illustrates: “Retail consumers are usually enthusiasts who want the latest features, upgrade often, and require little or no technical support”. Correll in a recent press release states an intention to build a desktop OS for this market on the based on the Debian distribution. What might be the cause of this omission might be the fact that Linux is a relatively young operating system, and therefore in the beginning of its lifecycle. As with all new developments, early adopters precede the masses. Especially in such circumstances the market size is small, and thus unprofitable for the current Linux Distributors.

82 The Economist, “Going Hybrid’, July 25, 2002

The final proposition argues that for-profit organisations deliver services for business clients. This statement is strongly accepted. Red Hat, SuSE and others indicate that the corporate server market is the most lucrative.

6.5.2.1. Consulting It is thus expected that Debian would not deliver any consultancy services. And indeed within the Debian project there is no part or group responsible for consulting possible users on how to use Debian. So, in that respect the proposition is accepted. Peculiar is, although, that Debian, itself again is involved in partnerships. Some of these partners do provide consultancy services. Among others one can think of the alliance with SAP, for whom consulting and implementation is a major source of revenue. But within the Debian project you won’t find any reference to a Debian Consultancy effort, and therefore the proposition should be accepted.

6.5.2.2. Documentation Documentation from the Debian project is available in four forms: manuals, howto’s, FAQs, and other shorter documents. For the purpose of user support, especially manuals (user manuals) are interesting. Howto’s and FAQs are generally more suited for a skilled user, knowing what to look for. Manuals by Debian are indeed scarce. Basically all available manuals are developed by enthusiasts, and actually are available just like Open Source Software, under the GPL license. Interestingly one finds also commercial Debian manuals. O’Reilly’s both sells manuals for Debian Linux and Red Hat Linux. Red Hat itself provides extensive documentation with its product. An interesting difference is the fact that the Debian manual contains lots of references to the development process. Where Red Hat makes a distinction in user functions: installation guide, customisation guide, security guide and getting started guide. For both organisations the manuals are available from the Internet for free. Eventually the proposition that commercial organisations have more extensive documentation should be accepted, the amount of available manuals and the variation in topic is more diverse for both Red Hat and SuSE as compared to Debian.

6.5.2.3. Implementation, Migration & Maintenance The topic of implementation, migration and maintenance is closely related to that of consultancy. It has been observed that an Open Source Project does not deliver any consultancy services itself. Only taking this conclusion further implicates that is highly unlikely that implementation services are then provided. And indeed browsing through the pages of Red Hat and SuSE yields many references to consulting, implementation, migration and maintenance services. Although mainly oriented at larger firms; small firms usually should do with standardized packages. Within Debian little of such reference is found, one could include updating documentation, as a form of migration, but this seems a far relation. Therefore I would suggest accepting this proposition.

6.5.2.4. Support An answer to this proposition is actually already given, and is positive. Within Debian the support function is organised in a peer production manor. What eventually results in the fact that it is only useful for people knowing what to search for. Online Forums and especially the 250-or so mailinglists are the primer tools for support. This as opposed to both Red Hat and SuSE. They also maintain a number of mailinglist, however support is also provided to individually consumers. Support tools include email/www-forms, the telephone, regular mail, and fax. For the telephone service SuSE for instance charges around 1.80 Euro.

6.5.2.5. Training Already in the first chapter it is indicated that the volunteer programmers should be auto-didactic. That is there is no scheme of mentors available. From that the general expectation on training, also for users, is that no training is provided. When browsing over the user support of Debian, indeed nothing is found concerning training. Once again, support is only provided by either external parties, or by Debian itself, but in the latter case it only involves documentation, mailinglist and forums.

6.5.3. Marketing & Development

6.5.3.1. Awareness & Branding The proposition concerning awareness and branding, have in itself little relation with the theoratical concepts discussed over the chapters. Nevertheless they still might turn out to be assisting in answering the central question. In the theory (chp. 4.5) it is once indicated that the brand name plays an important role in signaling trust to the market. On the website of Debian very little is stated concerning its name. There is a colletion of logos and the page on partnerships says that one of the contributions of partners can be increased brand awareness. Even the page from the publicity committee provides little information concerning a possible marketing strategy. Therefore these missing arguments point in the direction of accepting the proposition, that is that brand awareness creation is hazardous for Open Source Projects. However reaching the market, and having users is for Debian as important as for Red Hat. In fact also some of the users might eventually become developers. For Red Hat and SuSE, the situation is quite different. They not only derive direct profits from a larger market, they also compete for business clients among eachother. A strong argument for the importance of brand name is the huge difference in marketshare. By far is Red Hat the market leader, while there are no references that Red Hat might have a vastly superior Linux distribution, nor support services.

6.5.3.2. Distribution Finally distribution. Debian distributes it version of Linux via its website, and via a network of vendors. This is a first indication that distribution indeed is a task unsuited for peer production. Both Red Hat and SuSE also make use of the website and a distribution network in order to be able to have a worldwide reach. Nonetheless it is difficult to find a free version of either SuSE Linux or Red Hat Linux. Everybody is allowed to distribute these version, however without the brandname SuSE or Red Hat. The companies seem to prefer to charge for the software with a certain period of ‘free’ support.

. 6.6. Suggestions for further research This thesis touched upon a wide array of topics, many of which are not fully understood yet. In the suggestions for further research I will not try to be complete, rather will I just introduce a number of issues that I perceive to be of interest. First of which is the communication patterns within Open Source. Users are globally dispersed, which makes that face-to-face contact is lacking. So communication is mainly a matter of emails, chat and forums. This seems to be a low-cost system, but simultaneously asymmetric information between two parties is harder to resolve. In this respect I especially wonder how new ideas get acceptation among a large group of developers. Another issue is the question how Open Source will behave when it in a certain sector becomes the market leader. Especially for Linux currently it holds that the common interest of an anti-Microsoft motivation helps to hold everybody together. Would not companies have incentives to blur co-operation when Linux would be the market dominator?

. 6.7. Conclusion In chapter 5, one subquestion is postponed. This last question asked whether a distinction could be made between the market, the OSS community and a for-profit sector. The results from the propositions do point in that direction. However the distinction is not as rigid, as initially expected and secondly the concept of a ‘market’ is not correct. Commercial Open Source organisations at the moment do not aim their product at less skilled users, but rather they aim for the business market. The ordinary user is still to be discovered. This very well can be a result of the stage in the product life cycle of Linux. In fact Linux took off very recently and only in the last few years desktop applications are being developed. Furthermore it is interesting to note that Debian is developing alliances with companies to support Debian Linux. This includes vendors, and independent Debian consultants, but also large software (SAP/Oracle) and hardware manufacturers.

Equally interesting is the founding of UnitedLinux, this project very well resembles the tense relationship between the public domain and private interest. Especially the non-involvement of Red Hat gives weight to argumentations of caution from within the Open Source Community.

Table 6.2. Overview of the main differences between peer production and for-profit organisations. Task Peer Production For-Profit Closed & Open, versioned Open Code Development products Compatibility/Interoperability Open Standards

Co-ordination Meritocratic Cathedral Model

Documentation (excluded) (excluded)

Functionality Internal Demand Market Demand

Innovation (optimising) (???)

Integration Meritocratic Hierarchy Cathedral Model

Security (excluded) (excluded)

Standardisation Single standard Diffusion (UnitedLinux-case)

Testing Peer review process Cathedral Model

Usability ( ???) ( ???) Business clients, not mass- Internal Orientation Support Services user market. Consulting No consulting Extensive consulting Developer oriented Documentation User oriented documentation documentation From standard package to Implementation & Migration No implementation client-specific Maintenance Only update to newer version Extensive Charged & Free support, Support Mailinglist helpdesk Training No training Global training centres

Marketing & Distribution

Awareness (???) Branding

Certification (excluded) (excluded)

Customer Service Limited / internal orientation Extensive Website & vendors, usually Bundled, vendors, usually Distribution uncharged charged

♣ Conclusion Where in the first chapter it is still questioned what Open Source is all about, the previous chapter already explores the relationship between Open Source and for-profit organisations in great detail. The path from this beginning to such an end, took shape with a continues reference to the central question of “Can a clear division of labour be identified between the Open Source Community and commercial Open Source companies?” It was questioned whether one could distinguish between the Open Source Community, a mass market, and a collection of for-profit organisations. The idea that the Open Source Community is both self-oriented and focussed on technological development, next to the idea that companies could be of benefit in order to enlarge the market led to the expectation that a direct relationship between the Open Source Community and the mass market was less strong as compared to the indirect link via commercial companies. Thus the role of for-profit organisations could be one of communicating market demands to the OSS community, and implicitly question the saying of “users are developers”.

Discussions have been broad, dealing with the general characteristics of Open Source in the second chapter, the theoretical background in the third, the issues related to business involvement in the fourth chapter and the cases and analysis in the fifth and sixth chapter. In the second chapter Open Source was categorized as a mode of a peer production system, with the peer review process driving the development of software. Chapter three explained why the specific characteristics of information as a public good, make software, and information in general well suited for a system of peer production. Within Open Source, peer production takes the shape of a global network of volunteers, communicating via the Internet. The theories on network externalities and standards extended our knowledge base, and could in combination with incentives of these volunteer developers, explain why certain kinds of software are being developed within Open Source, and others neglected. For example special attention is devoted to software languages, protocols, standards and operating systems.

Furthermore the peer review system is self-selecting only the most skilled users. Together the personal incentives and the self-selecting peer review system lead to a sophisticated-user bias. This voluntary nature of Open Source, together with the sophisticated-user bias, lead to the fact that certain tasks are largely overlooked. These tasks are categorised as ‘mundane tasks’ and include manuals, installation programs, support etc. Each of these tasks implies limited reputational enhancements for the developer, nor is there a demand from the highest skilled users. Peer production in general is simply not able to carry out all task. Benkler (2001) identified three boundaries for the peer production process; these include the level of modularisation, granulisation, and the cost of integration. These flaws of Open Source did not prevent Open Source from flourishing since the early 1990s. Actually numerous developments in ICT spurred its rise. This in turn led to attention from the business community. Identifying the flaws and strengths of Open Source as business opportunities. Therefore in this paper it is expected that firms carry out mundane tasks, that have a low level of modularisation and granulity, a high cost of integration and which represent low incentives for developers.

As a result of the growth of Open Source the relationship between firms and the Open Source Network started to take shape. This relationship has been the main concern of this thesis. Sometimes tense, where the OSS Community is afraid that companies do not adhere to the OSS philosophy, and will rather follow their own agenda. In other cases beneficial, where firms supply complementary products and strengthen the market position of Open Source. Involved in this relationships are various kinds of businesses, each operating from a different business model. The prevalent business model researched in this thesis, is the so-called support sellers model, in which firms supply complementary support services to users of Open Source Software. In concreto this paper analysed the case of the Debian, Red Hat and SuSE Linux Distributors. Eventually this case ought to find out whether there is a clear division of labour between for-profit organisations and Open Source Projects.

This case analysis provided an array of useful findings. Especially the relatively internal orientation of Debian and the business-to-business markets that are explored by both Red Hat and SuSE lead to the conclusion that (in the case of Linux) there is no mass market, and a such the distinction suggested in the first chapter is incorrect. This internal orientation of Debian does however strenghten the theory that developers do develop for a personal need and as a community are sophisticated user biased. Commercial Open Source organisations do not aim their product at less skilled users, in fact they aim for the business market. The ordinary user is still to be discovered. This very well can be a result of the stage in the product life cycle of Linux. In fact Linux took off very recently and only in the last few years desktop applications are being developed. This also implicates that the only user-demands that can be communicated by for-profit organisations to the Open Source Community are the needs of business users. However it seems that for-profit organisations develop a considerable amount of code themselves, especially suited for business users.

Unfortunately the results concerning innovation are lacking. This is a major drawback of this thesis, since the preliminary thoughts of the first chapter included a technological orientation for the OSS community, and a market orientation for support sellers. Nonetheless it was found that support sellers develop relatively large amounts of code, specially suited for the business market. Such finding gives rise to a number of questions concerning our preliminary thoughts. In fact it was assumed that for profit organisations would regard the source code largely as a commodity. This also leaves the suspicion that support sellers might have a larger stake in innovation. In fact when linking these results to the Cowan’s small world theory one possibly finds correlations. The software developers employed by commercial organisations to work on Open Source Projects most often operate from a single location; most likely they are in close contact with each other, and share a common knowledge base. Such a group of developers is in contradiction with the general idea of a volunteer Open Source developer, who is geographically relatively isolated. In that respect firms might be regarded as cliques within the Open Source Network, and this may enhance the innovative capability of Open Source, as is indicated in Cowan’s small world theory.

Equally interesting is the finding of the UnitedLinux initiative, this project very well resembles the tense relationship between the public domain and private interest. In fact, where there is just one Open Linux Distributions, there are many commercial equivalents, which leaves the market fragmented. Especially the non-involvement of Red Hat gives weight to argumentations of caution over firms own agendas. Concerns that are wide spread within the Open Source Community.

In the end one can say that there exist a division of labour between Open Source and for-profit organisations. Especially support functions seem very well detached from Open Source Projects, and conducted by for-profit organisations. Even Debian has alliances with various firms, which deliver complementary support services. There is however one exception, and that is support provided by and for developers themselves. Within the task of code development, the division is much less obvious. Both Open Source Projects as for-profit organisations develop considerable amounts of code. Companies like Red Hat and SuSE develop not only software for individual clients, they also develop software licensed under GPL.

. Bibliography

 (!) My personal short list, which I tip an interested reader to read as well.  This is a list, with literature read in preparation of this thesis paper, together with a list composed out of the various references in the text.

References

1. Benkler Y. Coase’s Penguin, or, Linux and the nature of the firm. 2001 (!) Available at: http:// www.benkler.org/CoasesPenguin.PDF

2. Brooks F.P. The mythical man-month: essays on software engineering. Addison-Wesley publishing company, USA, anniversary edition. 1995.

3. Burt, R.S. The contingent value of social capital. Administrative science quarterly, 42 (1997), 339-365. 1997.

4. Cooper, D. R. and P.S. Schindler, Business Research Methods, Sixth Edition, Irwin McGraw- Hill, 1998. (original 1976)

5. Cowan R. and N. Jonard. The dynamics of collective invention. Technical Report 2000-018. MERIT/Maastricht University, Maastricht, The Netherlands, 2000.

6. Cowan R. and N. Jonard. Network structure and the diffusion of knowledge. Technical Report 1999-028, MERIT/Maastricht University, Maastricht, The Netherlands 1999. (!)

7. Cowan R. and N. Jonard. The working of scientific communities. Technical Report 2001-031. MERIT/Maastricht University, Maastricht, The Netherlands, 2001.

8. Cowan R. and E. Harison. Intellectual property rights in a knowledge-based economy. AWT/MERIT Maastricht University, Maastricht, The Netherlands, 2001 (!)

9. Cowan R., P.A. David and D. Foray. The explicit economics of knowledge codification and tacitness. 1999-027. MERIT/Maastricht University, Maastricht, The Netherlands, 1999.

10. Crowston K. and B. Scozzi. Open Source Software projects as virtual organizations: competence rallying for software development. 2002. Available at: http://crowston.syr.edu/papers/iee2002.pdf

11. Čubranić D. The ramp-up challenge in open-source software projects. University of British Columbia. 2001. Available at: http://opensource.ucc.ie/icse2001/papers.htm

12. Čubranić D. Open Source Software development. Presented at 2nd workshop on software engineering over the Internet, Los Angeles. 1999.

13. DeLong, J. Bradford and A. Michael Froomkin. Speculative microeconomics for tomorrow’s economy. First Monday. 1999. Available at: http://www.firstmonday.org

14. Dempsey, B.J., D. Weiss, P. Jones and J. Greenberg. A qualitative profile of a community of Open Source Linux developers. University of North Carolina at Chapel Hill, 1999.

15. DiBona C., S. Ockman and M. Stone. Open Sources: voices from the Open Source revolution. 1999. Collection of articles by various authors. O’Reilly Press, Sebastopol, CA. (!) - Bradner, S. The Internet engineering task force. In DiBona: Open Sources - Hamerly, J., T. Paquin and S. Walton. Freeing the source: the story of Mozilla. - McKursick, M.S. Twenty years of Berkeley Unix; from AT&T-owned to freely redistributable. - O’Reilly, T. Hardware, software, infoware. - Perens, B. The Open Source definition. - Stallman, R. The GNU operating system and the free software movement. - Tiemann, M. Future of Cygnus Solutions: an entrepreneur’s account. - Torvalds, L. The Linux Edge - Young, R. Giving it away: how Red Hat Software stumbled across a new economic model and helped improve an industry. Available at http://www.dibona.com

16. Dinkelacker J. and P.K. Garg. Corporate Source: applying Open Source concepts to a corporate environment. Presented at the 1st ICSE international workshop on Open Source Software engineering, Toronto. 2001..

17. Economides N. The economics of networks. International journal of industrial organization vol. 14, no. 2 (March 1996).

18. Fowler G.S., D.G. Korn, S.S. North and K.-P. Vo. The AT&T AST Open Source Software collection. AT&T Laboratories. 2000

19. Gacek, C., T. Lawrie and B. Arief. The many meanings of Open Source. University of Newcastle. 2001.

20. Gall H, M. Jazayeri, R. Klösch and G. Trausmuth. Software evolution observations based on product release history. ICSM Conference Paper, 1997.

21. Ghosh R.A. Cooking pot markets: an economic model for the trade in free goods and services on the Internet. First Monday, 1998. Available at http://www.firstmonday.org/issues/issue33/ghosh/index.html

22. Godfrey M.W. and Q. Tu. Evolution in Open Source Software: a case study. Presented at The 2000 International Conference on Software Maintenance, San Jose, California. 2000.

23. Granovetter M. The strength of weak ties. American Journal of Sociology volume 78 p.p. 1360- 1380, 1973.

24. Grant, R.M. and C. Baden-Fuller. A knowledge-based theory of interfirm collaboration. Academy of Management Best Papers Proceedings, 1995

25. Hagedoorn, J., A.N. Link and N.S. Vonortas. Research Partnerships. 2000. Elsevier’s Research Policy 29 (2000), 567-586.

26. Hardin, G. The Tragedy of the Commons. Science, 162(1968):1243-1248. 1968.

27. Hecker, F. Setting up shop: the business of open-source software. 1998. Available at: http://www.hecker.org/writings/setting-up-shop.html

28. Johnson, D.R. and D.G. Post. The new ‘civic virtue’ of the Internet. First Monday 1997.

29. Johnson, J.P. (2001a) Economics of Open Source Software. University of Calgary, Alberta, 2001.

30. Johnson, K. (2001b) A descriptive process model for Open Source Software development. University of Calgary, Alberta, 2001.

31. Kash, D.E. & R.W. Rycoft. Patterns of innovating complex technologies: a framework for adaptive network strategies. 2000. Research Policy 29 (2000) 819-831.

32. Kelly, K. New rules for the new economy. 1997 Available at: http://www.wired.com/wired/archive/5.09/newrules_pr.html

33. Lakhani K. and E. von Hippel. How Open Source Software works: “free” user-to-user assistance. Working Paper #4117. MIT Sloan School of Management. 2000.

34. Lerner, J. and J. Tirole. The simple economics of Open Source. Working Paper #7600. NBER 2000. (!) Available at http://www.nber.org/papers/w7600

35. Lerner, J. and J. Tirole. The Open Source movement: key research questions. European Economic Review 45 (2001) 819-826. 2001.

36. Lessig, L. The future of ideas. Random House Publishers. 2001. (!)

37. McKelvey, Internet entrepreneurship: Linux and the dynamics of open source software. Unknown origin. 2001

38. Monga, M. A Dynamo for computers: how Open Source can help software markets. 2000. Available at: http://www.elet.polimi.it/Users/DEI/Sections/Compeng/Mattia.Monga/index.html

39. Nichols, D.M., K. Thomson and S.A. Yates. Usability and open-source software development communities: a comparative case study. Available at: http://www.comp.lancs.ac.uk/computing/users/dmn/docs/oss.html

40. Oliva, A. The competitive advantages of free software. 2001. Available at: http://www.dcc.unicamp.br/~oliva/papers/free-software/selection-html/

41. Olsen, M. The logic of collective action: public goods and the theory of groups. Cambridge, MA: Harvard University Press. 1965.

42. Pfaff B. and K. David. Society and Open Source: why Open Source Software is better for society than proprietary closed source software. 1998

43. Powell, W.W., K.W. Koput and L. Smith-Doerr. Interorganizational collaboration and the locus of innovation: networks of learning in biotechnology. 1996. Administrative Science Quaterly 41 (1996), 116-145

44. Prins, A. 2000. Final Thesis. Maastricht University

45. Pyka, A. and P. Windrum, The self-organisation of innovation networks. 2000-020. MERIT/Maastricht University, Maastricht, The Netherlands, 2000.

46. Raymond E.S. The new hacker’s dictionary. Definitions for technical jargon and slang. MIT Press, 1996.

47. Raymond E.S. Homesteading the noosphere. 2000. Available at: http://www.tuxedo.org/esr/writings/

48. Raymond E.S. The Cathedral and the Bazaar. O’Reilly & Associates. 1998 & 1999. (!) Available at http://www.tuxedo.org/esr/writings/cathedral-bazaar

49. Raymond. E.S. The Magic Cauldron. 1999 Available at http://www.tuxedo.org/esr/writings/magic-cauldron/

50. Scharff E. Applying Open Source principles to collaborative learning environments.

51. Schmidt D.C. and A. Porter Leveraging open-source communities to improve the quality & performance of open-source software.2001 Available at: http://www.cs.wustl.edu/~schmidt/

52. Sewell, D.R. The internet oracle: virtual authors and network economy. First Monday 1997. Available at: http://www.firstmonday.dk/issues/issue2_6/sewell/

53. Shapiro C., H.R. Varian. Information Rules: a strategic guide to the network economy.. Harvard Business School Press, Boston, Massachusetts U.S. 1998

54. Strauss, F., J. Schoenwaelder and J. Quittek. Open Source components for internet management by delegation. Unknown origin.

55. Wegberg, van M. and P. Berends. Competing communities of users and developers of computer software: competition between Open Source Software and commercial software. NIBOR 2000.

Internet Sites

 http://www.ebscohost.com  http://www.economist.com  http://www.firstmonday.org  http://www.fsf.org  http://lessig.org/freeculture/free.html (!)  http://www.osdir.com  http://www.opensource.org  http://personeel.unimaas.nl/m.vanwegberg  http://www.publicknowledge.org  http://www.redhat.com  http://www.slashdot.com  http://www.suse.de  http://www.unitedlinux.com

- 74 -