Pragmatism, not ideology: Historical perspectives on IBM’s adoption of open-source software

Information Economics and Policy 21 (2009) 229–244

Contents lists available at ScienceDirect

Information Economics and Policy journal homepage: www.elsevier.com/locate/iep

Pragmatism, not ideology: Historical perspectives on IBM’s adoption of open-source software Martin Campbell-Kelly a,*, Daniel D. Garcia-Swartz b a b

Department of Computer Science, University of Warwick, Coventry CV4 7AL, United Kingdom Law and Economic Consulting Group, 33 W Monroe St # 2300, Chicago, IL 60603, United States

a r t i c l e

i n f o

Article history: Received 9 April 2008 Received in revised form 3 February 2009 Accepted 24 March 2009 Available online 9 April 2009

JEL classification: L17 O31 O34

a b s t r a c t We track IBM’s approach to software production and commercialization between 1950 and the present. We find that in the 1950s IBM followed what today would be called an opensource model – its software source code was open, free of charge, and written collaboratively with its users. By the mid 1980s, all of these attributes had been reversed – IBM’s software was closed source, sold or leased independently of hardware sales, and written without the collaboration of its users. More recently, the company has been in a state of transition, achieving a balance between free, open-source software and proprietary software that still generates 20% of its revenues. We interpret these radical swings in light of the substantial changes that have taken place since the 1950s in the costs and benefits of open source, bundled, and collaborative software vis-à-vis the alternatives. Ó 2009 Published by Elsevier B.V.

Keywords: Open source Software industry IBM

1. Introduction The growing economic literature on the open-source software (OSS) movement has started to address a number of questions that a priori look somewhat puzzling. For example: Why do individual programmers participate in the process of creating OSS? What incentives do they have to do so? What incentives do commercial software companies have to allow (or even encourage) some of their staff to participate in the production of OSS? What incentives do OSS authors have to release their software artifacts under more or less restrictive licenses? What kinds of business models do companies that ‘‘commercialize” open-source products resort to in order to generate revenues in the marketplace? (Lerner and Tirole, 2000, 2001, 2005; Valimaki, 2003). To our knowledge, however, very little research * Corresponding author. Tel.: +44 24 7667 3963. E-mail address: [email protected] (M. CampbellKelly). 0167-6245/$ - see front matter Ó 2009 Published by Elsevier B.V. doi:10.1016/j.infoecopol.2009.03.006

has been done on the incentives that a company may have to adopt different approaches to the production, distribution, and commercialization of software over time, in light of changing technologies and business opportunities. This paper is an attempt to start filling this gap: we conduct a historical exploration of the ever-changing strategies that IBM adopted vis-à-vis the production and marketing of software between the 1950s and today. To frame this paper, in Table 1 we summarize, by decades, the transitions that IBM has made in software writing and fulfillment since the 1950s. The table also lists some of the key events in IBM’s history that accompanied these transitions. Put succinctly, in the 1950s IBM followed what today would be called an open-source model – its software source code was open, free of charge, and written collaboratively with its users. By the mid 1980s, all of these attributes had been reversed – IBM’s software was closed source, sold or leased independently of hardware sales, and written without the collaboration of its users. It was then operating much as any other independent software

230

M. Campbell-Kelly, D.D. Garcia-Swartz / Information Economics and Policy 21 (2009) 229–244

Table 1 IBM – Chronology: software production and commercialization. Open

Free

Collaborative

1950s

Yes

Yes

Yes

1960s

Yes

Yes

No

1970s

Yes

No

No

1980s

No

No

No

1990s

Both

Both

Both

2000s

Both

Both

Both

vendor (ISV). In the mid 1990s, following the financial meltdown in which IBM famously recorded the largestever loss in corporate history, the company embraced both open systems and the open-source model. Since then IBM has been in a state of transition, achieving a balance between free, open-source software and proprietary software that still generates 20% of its revenues. Why did IBM adjust its approach to the production and commercialization of software so radically over time? We interpret IBM’s switching strategies within the general context of dynamic competition among compatible and incompatible hardware/software platforms. The key conceptual elements of the story are the following. First, in a computing platform, hardware and software are complementary goods. More specifically, the more abundant and varied the software that is available for the platform, the higher the demand for the platform. Therefore, the three key questions that a platform sponsor faces are: Who will produce the software for the platform? Will the software be delivered in a bundle with the hardware or will it be separately priced and marketed? And finally, will the source code for the platform’s software be open or closed? Secondly, the way in which the platform sponsor answers each one of these questions entails costs and benefits for all the players involved (and therefore, for the sponsor itself). Among the players that the platform sponsor takes into account in the process of addressing each one of these issues are the sponsor’s customers, the specialists (if they exist) that supply software for the platform, the sponsors of competing incompatible platforms and their customers, the sponsors of competing compatible platforms and their customers, and the governmental institutions that set ‘‘the rules of the game” and enforce them. Thirdly, the costs and benefits of any given approach to addressing each one of the key questions are not fixed over time. On the contrary, market conditions, technologies, prices, and the competitive position of the platform’s sponsor may change substantially, which in turn may bring about radical changes in the balance of costs and benefits. For example, in the world of the 1950s open-source software made a lot of sense for IBM: hardware was the fundamental source of revenue, customers (who accounted for

Related events SHARE, 1955 Fortran, 1957 Source/object code, 1959 System/360, 1964 OS/360, 1964–1967 DOJ antitrust suit, 1969–1982 Unbundling, 1970 OCO Policy, 1983 Fujitsu arbitration, 1983–1987 SAA, 1987 Participates in OSF, 1988 Financial meltdown, 1993 Apache adopted, 1998 Linux announcement, 2001

most of the programming) needed access to the source code to customize the system software and create applications, and the hardware machines that IBM’s competitors had on the market were incompatible with IBM’s software. In the 1980s the business case for open-source software was much less obvious: software was slowly becoming an important source of revenue in the IT industry, and open-source software was an invitation to many of IBM’s competitors to free-ride on IBM’s intellectual creations. Our goal in this paper is to provide both a historical narrative and an economic analysis of the changing balance of costs and benefits that IBM faced in the process of raising (and answering) the three key questions, with a special focus on question # 3 (namely, the dilemma between opensource and closed-source software). The literature on network industries, platforms, or markets (i.e., industries dominated by so-called network effects) is extensive and varied, and hardware–software systems such as those analyzed in this paper are among the foremost examples of these industries. Besen and Farrell (1994) and Katz and Shapiro (1994) provide early summaries of some of the main issues. Farrell and Klemperer (2007) provide a more recent and comprehensive overview. An early summary of the related literature on compatibility standards is in David and Greenstein (1990). In recent years, hardware–software systems have also been analyzed within the framework of multi-sided platform (or market) theory (Rochet and Tirole, 2003, 2005; Evans and Schmalensee, 2005). In this context, various types of customers (e.g., final consumers, on the one hand, and the creators of platform software, on the other) demand the services of the hardware platform. Direct network effects are present when the addition of a type-I customer, say, benefits other customers of the same type. Indirect network effects are at play when the addition of a type-I customer benefits type-II customers (and may end up benefiting type-I customers indirectly). The addition of one consumer of platform services, for example, makes the platform more desirable for the creators of platform software, who then produce software for the platform and make the platform more desirable for future consumers of platform services.

M. Campbell-Kelly, D.D. Garcia-Swartz / Information Economics and Policy 21 (2009) 229–244

For our purposes, the key issue among the many addressed in this literature is that platform owners (or ‘‘sponsors”) try to make sure that consumers know that (abundant and varied) software for the hardware will be available tomorrow at a reasonable price. In this context, West (2003) analyzes the tension for the platform owner as one between the desire to appropriate at least some of the economic benefits of the platform and the need to encourage the adoption of the platform. In this dialectic the first component points in the direction of proprietary (closed) strategies while the second leads to open-source strategies (West, 2003, p. 1260). In the context of a related literature on ICE (‘‘internalizing complementary efficiencies”), Farrell and Weiser (2003, p. 89) point out that ‘‘even a monopolist has incentives to provide access to its platform when it is efficient to do so, and to deny such access only when access is inefficient.” We see our paper as complementary to West (2003). His perspective, however, is more fundamentally crosssectional than ours (and ours is more fundamentally time-series than his), to put it loosely. He studies three companies – Apple, IBM, and Sun – that have in recent years experimented with hybrid (i.e., proprietary and open-source) strategies, and finds a common denominator, namely an attempt to respond to the Microsoft threat. His study is both more and less comprehensive than ours. It is, on the one hand, more comprehensive because it encompasses a variety of (traditionally proprietary) firms that have resorted to open-source strategies. It is, on the other, less comprehensive because it does not systematically track the evolution of proprietary and open-source strategies for any given company, as we do here for IBM. As far as terminology is concerned, we say that in the 1950s IBM followed a ‘‘collaborative” approach to software development in the sense that it produced software in collaboration with users of IBM machines. We say that through the late 1960s IBM adopted a ‘‘bundled” approach to software marketing in the sense that it did not price software separately from the hardware. We say that through the early 1980s IBM followed an ‘‘open source” approach to software production and marketing because it allowed everybody (customers, independent software vendors, competitors) access to the source code for a wide variety of purposes – customers, for example, could not only inspect the source code but also customize it according to need. The paper is organized as follows. Section 2 covers the 1950s, when IBM produced software in collaboration with its customers, and delivered it in an open-source format, bundled with the hardware. Section 3 covers the 1960s, when IBM’s software was open source and bundled but no longer collaborative. Section 4 focuses on the 1970s, when IBM’s software became unbundled from the hardware but remained open source. Section 5 analyzes the decision that IBM made in the 1980s to radically prevent others from accessing the source code. As a transition into the 1990s, in Section 6 we focus on the SAA and OS/2 fiascos. Section 7 covers the 1990s and onward, that is, the IBM decision to become a mixed (open- and closed-source) company in terms of software production and marketing. Section 8 concludes with a summary and directions for further research.

231

2. The 1950s: when software was free, open, and collaborative In the 1950s IBM produced software in collaboration with its customers, and marketed it in an open-source format, bundled with the hardware. 2.1. IBM’s approach to software production and marketing in the 1950s IBM introduced its first digital computer, the model 701, in April 1953. Although IBM had long been the dominant vendor of punched-card accounting machines, it was far from dominant in computers in the early 1950s. It had come relatively late into the market – significantly behind its office-machine rival Remington Rand, for example – and vendors such as Burroughs, NCR, RCA, and Honeywell, all had products on the market or waiting in the wings.1 IBM wrote no application programs for its computer and very little in the way of systems programs. What IBM supplied consisted of a rudimentary ‘‘assembly program” and a small set of utility programs – the total probably amounted to no more than a thousand lines of code (Bashe et al., 1986, p. 323–333). IBM’s assembly program translated the written form of a program into the machine instructions the computer executed. The two representations of a program were thus known as the ‘‘symbolic” and ‘‘binary” forms. The terms ‘‘source code” and ‘‘object code” – which have a somewhat different connotation – did not emerge until the end of the decade. IBM supplied its programs in both symbolic and binary forms. A primary reason for supplying the binary version of a program in addition to the symbolic one was that it was faster to read the former into the computer via the standard 150 card-per-minute card reader that came with the 701. Whereas programmers punched one symbolic instruction on a card, it was possible to pack a dozen binary instructions on a card – so that binary programs loaded perhaps ten times as fast as symbolic ones. Thus the distinction between symbolic (open) and binary (closed) programs had nothing to do with protecting intellectual property; it was purely the accident of history that IBM happened to use punched-card technology for its input–output peripherals. The SHARE User Group was the primary means by which the supply of programs was increased. Originally called the Digital Computer Association, the user group was established in Santa Monica in November 1952, as a forum in which 701 users – primarily the West Coast aerospace industry – could share experiences and programs. The user group was renamed SHARE around the time that IBM launched the model 704 computer, the successor to the 701, in 1955.2

1 Flamm (1988: 82) lists a dozen American computer manufacturers in 1954. 2 SHARE, although usually capitalized, was not an acronym (Akera, 2001: 710).

232

M. Campbell-Kelly, D.D. Garcia-Swartz / Information Economics and Policy 21 (2009) 229–244

The overarching problem facing 704 users was to obtain a basic set of programming tools and utilities when IBM had supplied so few of them. According to SHARE’s founding president, Paul Armer (1980), several early adopters of the 701 had spent the equivalent of the first year’s rental ($150,000) in individually creating such a programming infrastructure. In order to avoid this duplication of effort for the 704, SHARE evolved a collaborative programming regime and espoused community values presaging those of the open-source community that emerged decades later. For example, adhering to programming standards was seen to be very important in ensuring that programs could be potentially used on all 704 installations. At its second meeting, in September 1955, the SHARE committee decided to adopt and distribute the SHARE Assembly Program (SAP), which had been developed by United Aircraft, in place of IBM’s lack-luster AP1 assembler. It was estimated that by adopting SAP, the resulting savings to members was ‘‘on the order of $1,500,000.” During the next few months, SHARE created a wish-list of systems programs and proceeded to allocate the task of writing them to volunteer members. The member organizations developed these programs, typically mathematical and engineering subroutines, and then submitted them to the SHARE Program Library. The technical experts within SHARE scrutinized them for quality and conformance to standards. To be accepted, programs had to be rigorously documented: including narrative descriptions, program listings, and symbolic and binary card decks. This full description was necessary because access to program texts was part of the community learning process, and individual members running 704 installations might in any case choose to adapt a program rather than use it exactly as supplied. SHARE’s heyday was the period 1955–1958. The organization continued thereafter, even up to the present day, but only as a conventional user group, mediating between IBM and its customers. After the late 1950s it was no longer an indispensable source of programming wisdom and artifacts. There were several reasons why SHARE reached the limits of collaborative development so quickly. Within the aircraft manufacturers, there was concern that an appearance of collusion in writing application programs would attract the attention of the antitrust authorities (Akera, 2001, p. 727). For this reason, SHARE was constitutionally forbidden to create or distribute application programs. Systems programs, which were regarded as pro-competitive and universally useful, could be freely developed and exchanged. Once SHARE’s wish-list of utilities had been fulfilled, it began to run out of modest projects it could usefully engage in, and instead attempted two grandiose but ill-fated projects, PACT and SOS – a programming language and an operating system, respectively. Neither one was taken up by the core of users. SHARE’s decline as a programming co-operative can ultimately be traced to the introduction of the IBM Fortran programming system in April 1957 (Pugh 1996, p. 190– 196). By about 1954 there had been efforts in many places to simplify programming, but they generally produced code that was very inefficient. Visits by IBM to a number

of 704 installations discovered a widespread skepticism and rejection of automatic programming systems because of this inefficiency. IBM therefore made efficiency the primary goal of the project – Fortran would produce programs that were 90% as efficient as those produced by expert programmers using an assembler. When it was released in April 1957 it was an instant hit with users. IBM had turned a corner: it had become the most capable supplier of software for its own computers. 2.2. Analysis In the 1950s IBM and its competitors set up (‘‘sponsored”) a number of computing platforms. Let us define a platform p to be a compatible combination of computing hardware and software of the following form MW AP PTF p ¼ fHP ; SOS p ; Sp ; SP g

Assuming for now that each sponsor produces only one type of hardware for its platform, Hp stands for the platform’s hardware, SOS p stands for the platform’s operatstands for the platform’s middleing-system software, SMW p stands for the platform’s application ware, and SAP p software.3 A platform is a compatible combination of hardware and software, ‘‘compatible” in the sense that the hardware and the software can be matched, i.e., they function well with each other. Moreover, in the context of a platform, hardware and software are complementary goods – there is no demand for one without the other. Furthermore, the larger and more varied the stock of software that can be matched with a given piece of hardware, the higher the demand for the hardware (and for the platform as a whole). For simplicity, we can think of the 1950s as a world dominated by competition between two incompatible platforms – ‘‘incompatible” in the sense that the IBM software did not work on (could not be matched with) the UNIVAC hardware, and the UNIVAC software did not function on (could not be matched with) the IBM hardware. We refer to this situation as one of between-sponsor incompatibility (to distinguish it from within-sponsor incompatibility, which arises if a given sponsor produces heterogeneous types of hardware that are incompatible with each other). In this context, the demand for each platform is a function of relative prices, relative attributes, and the amount of software that has been produced for it vis-à-vis the amount of software that has been produced for its competitor:

Di ¼ Di ðPi ; Pj ; F i ; F j ; Si ; Sj Þ Here Pi stands for the price of platform i, F i is a vector of features of platform i, and Si is the stock of software that is available for platform i. The demand for the IBM platform depends on its price vis-à-vis the UNIVAC price, its attributes relative to those of UNIVAC, and the stock of software available for IBM vis-à-vis UNIVAC. In this context we can analyse IBM’s approach to dealing with the three 3 We have used the ‘‘middleware” terminology throughout the paper even though the concept did not appear until the late 1960s and the term itself came to life in the 1990s.

233

M. Campbell-Kelly, D.D. Garcia-Swartz / Information Economics and Policy 21 (2009) 229–244

key issues raised in the introduction, namely, (a) the locus of software production, (b) bundling/unbundling of software and hardware, and (c) open/closed source code. 2.2.1. Why bundled? IBM (and all other platform sponsors) bundled not only software but also machine maintenance and training together with the hardware. In this they followed a long tradition in the data processing industry that predated computing platforms: the main objective of providing a bundle was to increase the demand for the platform by supplying a full ‘‘solution” to customers (Pugh, 2002). By means of this bundled solution, customers rented (or acquired) a working machine loaded with some basic software utilities, had the machine regularly maintained so as to avoid disruptions in the normal course of business, and also received training and education that gave them the capabilities to adapt the machine to their own needs. In the early days of computing, bundling raised the demand for a computing platform because it reduced the uncertainties of early adopters of computers (Fisher et al., 1983, p. 205–208). 2.2.2. Why collaborative? For most of the 1950s the computing market was not deep enough to sustain specialist producers of software (ISVs). By 1955 there were only about 240 mainframes in use in the US. Even in 1960 there were only 4400 mainframes and about 1,000 minicomputers in use in the US (Fig. 1 and Phister, 1979, p. 297–298). However, without software there was no demand for the hardware (and for the overall platform). IBM could either produce all the software by itself or co-produce it with its customers. During the 1950s a division of labour evolved in which (a) IBM produced (a first version of the) fundamental pieces of software that allowed each machine to function, (b) IBM sponsored a group of sophisticated users (SHARE) that improved on those key pieces of software, and (c) a broader group of users (of which the SHARE members were a subset) customized and adapted the software for their own company- or industry-specific needs. This division of labour

was efficient in the sense that it reflected the distribution of knowledge. IBM and the subset of sophisticated users quickly developed highly valuable knowledge about the core software of the IBM machine, namely about operating MW systems and middleware, ðSOS IBM ; SIBM Þ. However, knowledge about company- or industry-specific applications, SAP IBM , resided with the users – by definition, application software required not only technical knowledge about software but also technical knowledge about the company- or industryspecific needs. For all practical purposes, computer users accounted for most of the cost of producing software from the mid 1950s through the mid 1970s (Phister, 1979, p. 277). 2.2.3. Why open source? In this environment, the natural question was not ‘‘why open source” but rather ‘‘why not open source.” Let us think of the costs and benefits of open-source software in the 1950s from IBM’s perspective. The main benefit was that open-source software allowed users with various levels of sophistication to actively participate in the creation and customization of software for the IBM hardware, which substantially increased the demand for the hardware (and for the platform as a whole). Neither the activities of the SHARE group nor those of individual users who customized IBM software to their company- or industryspecific needs would have been possible without open source. What about the costs for IBM of open-source software in the 1950s? There were not many. Of course, opensource software facilitated inspection and copying. But how strong were the incentives to engage in these activities in the 1950s? Not strong enough for the main actors. First, UNIVAC (and all other sponsors of incompatible platforms) may have benefited from inspecting the code, but they were precluded from actually using the IBM software on their own hardware, since the IBM software did not work on IBM-incompatible hardware. Secondly, the users of incompatible platforms were precluded from using the IBM software on their own machines for the same reason. Thirdly, the users of the IBM platform already

Number of machines ('000)

70.00 60.00 50.00 40.00

OTHER IBM

30.00 20.00 10.00 0.00 1955 1956 1957 1958 1959 1960 1961 1962 1963 1964 1965 1966 1967 1968 1969 1970 1971 1972 1973 1974

Year Fig. 1. Number of mainframe installations in the US, 1955–1974, in ‘000 units. Source: Phister (1979, p. 251).

234

M. Campbell-Kelly, D.D. Garcia-Swartz / Information Economics and Policy 21 (2009) 229–244

received the basic software bundled with the hardware and they themselves co-produced the applications (with IBM’s help). What was the point of piracy for them? In addition, IBM regularly accessed the machines for maintenance, and therefore could periodically monitor any changes made to the hardware/software (Sharpe, 1969, chapter 7). Finally, ISVs may have benefited from inspecting the code, but there were not many of them. More to the point, even assuming that the few ISVs that existed had developed software products that competed with IBM’s, who would have paid a positive price to buy from an ISV a software package that IBM loaded on its machines ‘‘for free”?

3. The 1960s: when software was free and open source, but no longer collaborative In the 1960s IBM continued to bundle software with hardware and kept the source code open. It, however, no longer produced software in collaboration with its users. 3.1. IBM’s approach to software production and marketing in the 1960s The term ‘‘software” gained currency around 1960, a development that indicated the growing importance of programming in the overall computing environment. By the early 1960s, IBM had developed a competence in basic operating systems, language processors, and utilities. Although it had ridden on the coat-tails of SHARE initially, it had quickly adapted the lessons for its commercial data processing computers, the model 702 and the ‘‘workhorse” 650 (Bashe et al., 1986, p. 349–358). In October 1959, IBM announced its second-generation, transistorized model 1401. The IBM 1401 machine was a major act of creative destruction, which made obsolete the accounting machines that had been IBM’s primary business since the 1890s (Campbell-Kelly and Aspray, 2004, p. 117–120). IBM supplied a comprehensive suite of systems software for the 1401: a simple operating system, utilities, and language processors (Assembler, Fortran, Cobol, and RPG) (Fisher, 1964). Although IBM had developed a competence in systems programs, it had more difficulty in delivering useful application software. Systems software was essentially homogeneous and could be used with little or no adaptation by all installations – for example, the language processors were used by virtually all of the 12,000 IBM 1401s delivered. By contrast, applications were generally useful only for a single industrial sector, and usually required customization. IBM eventually supplied application software for most of the major industrial sectors, such as manufacturing and banking (Cortada, 2004). Generally, IBM did not provide productized solutions, but rather a framework that users could adapt. The best recorded of these programs is the ’62 CFO (an abbreviation for Consolidated Functions Ordinary, 1962) package developed by IBM for the life insurance industry (Yates, 1995, 2005). Few companies used ’62 CFO without modification. Instead they used it

as a framework and customized the source code, which nonetheless typically saved users tens of programmer years compared with developing an application from scratch. Contemporary estimates indicated that between 200 and 300 US life insurance companies used the package. Had ’62 CFO been sold as a software product at that time it might have cost between $20,000 and $100,000 (depending on the level of customization required by the customer) and it would have generated annual revenues of perhaps $1 million. Even though at the time this would have been enough to sustain an embryonic software product vendor,4 it would also have been barely at the noise level compared with IBM’s $2 billion-plus annual revenues. When IBM announced its third-generation System/360 range of computers in April 1964, the software problem was high on the list of rationales for the new range (IBM, 1961). Up to this time, users had had to reprogram their applications when they changed computers, because the different machines were not software compatible. And of course IBM also had to rewrite or modify all of its programs whenever it introduced a new computer model. System/ 360 was software compatible throughout the range of machines, from the smallest to the largest. Thus, a user requiring a higher performance computer would be able to trade in their existing machine for a larger model with little, or at least minimal, reprogramming. IBM, which now employed a programming staff of 4000, produced a comprehensive suite of systems software (Humphrey, 2002). This consisted of the usual language processors (Assembler, Fortran, Cobol, RGP and a new language PL/1), operating systems, and utility programs. The most ambitious development was the OS/360 operating system, designed to run across the range of computers. Access to source code for IBM’s operating systems and systems programs remained necessary for both users and the emerging independent software industry. Sophisticated users valued the possibility of accessing the source code in the process of customizing the operating system. Large corporations (American Airlines, AT&T, and Kodak, among others) ‘‘filled in gaps in design or function” and thus gained an edge over competitors who just relied on the original IBM code (Carlyle and Moad, 1988, p. 40). In addition, by the late 1960s, a number of ISVs had been established for whom access to IBM source code was essential for creating complementary systems program products. The co-founder of the software-products firm ADR, for example, noted that access to source code was essential for building transaction processing monitors, database management systems, and software for session control management, security, tape management, and various applications (ComputerWorld, 1988, p. 58). 3.2. Analysis Think of a world where each platform sponsor produces three types of hardware – let us call them high, medium, and low, to reflect different levels of, say, processing power

4 Welke (1980: 128) stated that the income of a ‘‘typical ISV” was $3 million.

M. Campbell-Kelly, D.D. Garcia-Swartz / Information Economics and Policy 21 (2009) 229–244

235

and memory. If the various hardware types are incompatible with each other (in the sense that, say, software produced for the ‘‘high” version of the platform’s hardware cannot be matched with the ‘‘low” version), then each platform is fragmented: this was IBM’s situation in the early 1960s. (The description applies to IBM’s competitors as well.) In other words, there was both between-sponsor incompatibility and within-sponsor incompatibility. For IBM, within-sponsor incompatibility (i.e., platform fragmentation) brought about at least two problems. For one, each IBM customer faced individual switching costs when attempting to migrate across IBM hardware types, since the customer was forced to forego the investments made in developing software for the hardware type from which it was migrating. Secondly, software collectively produced for one type of IBM hardware was useless on all other hardware types, so that hardware heterogeneity limited the extent to which a larger stock of software made the platform’s hardware more desirable. For all practical purposes, there were many platforms rather than one. IBM addressed these issues by launching a frontal attack on within-sponsor incompatibility: the System/360 was a family of hardware types that, for the most part, were software-compatible with each other. This made the IBM platform (now one rather than many) extremely valuable and consolidated IBM’s position at the top of the industry. IBM’s share of all mainframe installations oscillated around 80% through 1962 and started to decline thereafter – it was 70% in 1964. The introduction of System/360 allowed IBM to retain a 65-70% share of all mainframes in the context of a soaring industry – the number of installed mainframes grew from 4400 in 1960 to almost 50,000 in 1970 (Fig. 1 and Phister, 1979, p. 297–298).

benefited IBM. In addition, ISVs could create products that were complementary to the platform, which also raised the demand for the IBM platform. As far as the costs of open source are concerned, they remained limited as long as there was no serious compatible-platform threat on the horizon. They also remained constrained by the fact that through the end of the decade IBM continued to supply ‘‘free” software bundled with the hardware: ISVs could potentially gain some advantages from inspecting the IBM code but would have had to supply a dramatically better product to convince the IBM customers to switch. In the early days they prospered by producing software that did not compete directly with IBM’s software. The first software product that did was Autoflow, a product that ADR introduced in 1965 and that competed with the IBM Flowcharter package (CampbellKelly, 2003, p. 58, 113).

3.2.1. Why bundled? At least for a portion of the decade, the costs and benefits to IBM of bundling software (and services) with hardware did not change much: bundling afforded IBM the possibility of offering a complete solution to its customers, which in turn raised the demand for its platform. There were two types of clouds on the horizon, however. In the next section we will discuss the potential costs that RCA imposed on IBM with the launch of the partially compatible Spectra 70 series of machines. We will also analyse the increasing probability that IBM would become the target of lawsuits, essentially because after the launch of System/ 360 IBM became a clearly dominant firm in a soaring industry – many other companies bundled software and services with hardware, but none of them was remotely comparable with IBM in terms of the volume of sales.

4. The 1970s: when software became unbundled

3.2.2. Why open source? Similarly, at least for a portion of the decade the costs and benefits to IBM of allowing others full access to the source code did not change much. The benefits of open source for IBM customers and for the rising number of ISVs were enormous: with access to the source code they could both customize and improve the operating system, the middleware and the applications that IBM supplied – this raised the demand for the IBM platform, and thus

3.2.3. Why no longer collaborative? By the mid 1960s software development at IBM had become a highly bureaucratic endeavour, carried out in a tightly disciplined engineering environment. It is unlikely that IBM would have been able to engage the SHARE members, say, in the development of the operating system for System/360, even if both IBM and the SHARE members had been interested in participatory development. By about 1965, collaborative software development at IBM (in the sense of software development in collaboration with customers) was a thing of the past. Customers, however, kept on tailoring both the IBM operating system and the IBM applications to their own needs. Customers accounted for about 90% of all software development costs in the economy well into the 1970s (Phister, 1979, p. 277).

In the 1970s IBM unbundled software (and services) from hardware and established some protection for its intellectual property through a system of copyright cum license, but left the source code open. 4.1. IBM’s approach to software production and marketing in the 1970s IBM made its first unbundling study in 1964, shortly after RCA announced its Spectra 70 series of computers, which was compatible with System/360. IBM reasoned that if Spectra 70 users decided to make use of IBM software, then IBM would not be able to charge RCA’s customers for the use of the software unless IBM also charged its own customers (Humphrey 2002, p. 59–60). In fact, the Spectra 70 turned out to have limited software compatibility with System/360, and this no doubt reduced the urgency of unbundling. Three or four years later, however, the runaway success of System/360 had consolidated IBM’s dominance of a rapidly growing mainframe market, and its mainframe competitors were urging the Department of Justice to file an antitrust suit. In addition, in the second half of the 1960s, the independent software industry began to take off: there was an explosion of entry into the

236

M. Campbell-Kelly, D.D. Garcia-Swartz / Information Economics and Policy 21 (2009) 229–244

software business between 1965 and 1970 (Computers and Automation, 1970b). These competitors complained that IBM selectively used its bundled services to secure sales and to eliminate competition. In fall 1968, IBM decided that it would need to unbundle software and services from hardware to preempt an antitrust suit, and made an announcement to do so on 6 December. The hope of averting an antitrust action failed, however, and on 17 January 1969, the last day of the Johnson administration, the Department of Justice filed suit. (The suit would rattle on for more than a decade before it was finally dismissed in 1982.) Nonetheless, IBM was now committed to unbundling; the terms were announced on 1 July 1969 and implemented on 1 January 1970. IBM was, in fact, among the first vendors to unbundle. Prior to IBM’s June 1969 announcement, only two vendors (Burroughs and Xerox Data Systems) had charged separately for certain software products. However, the announcement ‘‘prompted several of IBM’s competitors to take similar actions” (Head, 1971, p. 8–10). Within IBM a task force of several hundred individuals was assigned the job of implementing the various aspects of the unbundling program (Grad, 2002). Software unbundling was initially quite limited, consisting of some 17 system and application programs. It was considered that it would not be feasible to charge for programs that were already in the field, and these would therefore remain forever free. But as new products were introduced, and old ones were upgraded, they would be subject to a monthly leasing charge. Controversially, IBM decided not to unbundle its operating systems on the grounds that there was no clear dividing line between hardware and systems control programs and that ‘‘unbundling these programs was not economically or technically sound” (Humphrey, 2002).5 By the late 1970s – when IBM did finally unbundle its operating systems – it had several hundred paid-for software products. IBM had considered various intellectual property (IP) protection strategies in the discussions leading up to unbundling, including patents, trade secrets, and copyright. In the event, copyright was used to protect source and object code, and license conditions provided a limited degree of trade secrecy by requiring users to maintain confidentiality. Source code, however, continued to be supplied to ISVs and customers. IBM’s license agreement clearly stated the extent and intent of source code disclosure (IBM, 1971). Customers were at liberty to make whatever use they wished of the source code, as long as they continued to pay the monthly rental. Source code disclosure to third parties was tightly controlled, however, and was limited to the customer’s employees and IBM systems engineers. Third parties were only permitted access with IBM’s written consent; failure to comply could result in the withdrawal of the user’s license.

5 Developing an operating system involved subtle trade-offs between what could be accomplished by hardware and what would be accomplished by software, which varied from machine to machine in the range. As a result it was difficult to disaggregate hardware and software costs or to conceive of an operating system as a stable product, like a database system, for example.

It took about a decade for enterprise software products, both system and application programs, to mature into closed source, customizable solutions. Until then, users of software products had essentially two choices: to use a package as supplied and adapt their computer operations, or business and accounting practices, to conform to the package; or to tailor the package for their unique environment. Such software tailoring could be done either by the user or the vendor.6 According to a 1975 survey conducted by the industry magazine Datamation and the industry analyst DATAPRO, 55% of 490 respondents conducted in-house tailoring of software packages, while a further 29% purchased customization services from the vendor (Tanner, 1975). However, even when a user had no intention of modifying a program, source code was useful in evaluating the quality and functionality of a package, and potentially useful in investigating problems that arose after the package was purchased. The ability to inspect documentation and source code was thus high on the list of package evaluation criteria, and a potential customer was expected to have access to ‘‘narrative descriptions, flow charts, record layouts, and annotated program listings” (Head, 1971, p. 35). 4.2. Analysis The decision that IBM took at the end of the 1960s (and that led to unbundled software in the 1970s) can only be understood in light of the competitive developments that took place during the 1960s. System 360 led to a dilemma for IBM’s competitors. Those attempting to compete with IBM on the basis of between-sponsor incompatibility faced a number of challenges. For one, current users of the IBM 360 machines – and there were about 24,000 System/360 installations in 1970 out of a total stock of mainframe installations of about 48,000 (Phister, 1979, p. 297–298) – faced individual switching costs: moving to an incompatible platform was equivalent to foregoing the investments they had made in producing/customizing software for the IBM platform (and this waste was now magnified by the fact that, since 1965, the IBM platform was unified). Secondly, current users of the IBM 360 faced collective switching costs (network effects): a large stock of software was being created for the 360, and switching to an incompatible platform implied foregoing the benefits derived from the availability of that stock. Thirdly, future users of computers did not face switching costs but, at the time of deciding which platform to adopt, took into account that the IBM platform was within-sponsor compatible and also that it had the largest stock of software available. In the mid 1960s RCA dealt with these issues by attempting to provide full between-sponsor compatibility (through its Spectra 70 family of computers). This approach promised a number of substantial benefits for RCA (and costs for IBM): on the one hand, it lowered indi-

6 The trade off between using a software package ‘‘as is” and customization persists to the present day. SAP’s ERP software, for example, provides ‘‘customer exits” for a user’s own code. Although users have some access to source code, modifying the standard code is strongly discouraged and no customer support is provided.

M. Campbell-Kelly, D.D. Garcia-Swartz / Information Economics and Policy 21 (2009) 229–244

vidual and collective switching costs for current IBM users; on the other, it lowered considerably the costs to RCA of developing a computing platform. RCA could potentially sell its own hardware with the IBM software installed on it without incurring the costs of developing the software. The fact that the IBM source code was in the public domain made the RCA approach considerably easier to implement that it would have been otherwise. There was one additional element for IBM to consider in terms of the overall competitive landscape: the fact that it had become such a dominant firm had made it a potential target of litigation. In the second half of the 1960s manufacturers of competing platforms started to complain about IBM’s business practices, and the Government started to look into its business activities as well (Grad, 2002). More to the point, some ISVs – and their number grew at a torrid pace between 1965 and 1970 – started arguing that the fact that IBM bundled software with hardware precluded them from developing a viable business model. For all practical purposes the software industry as such was quite limited in 1965. An explosion of entry into software production happened between 1965 and 1970 (Computers and Automation, 1970b, p. 65–91 and 125). In this context, ADR, a small firm with annual revenues of $4.2 million, filed a suit against IBM in April 1969 claiming damages of about $300 million. ADR alleged that IBM’s bundling practices had damaged ADR’s Autoflow product specifically and had suppressed a potentially very large software market for about a decade (Campbell-Kelly, 2003, p. 113). 4.2.1. Why unbundled? The cost of unbundling was essentially operational: IBM had to devote an army of system engineers, computer programmers and the like to the task. The benefits of unbundling, however, were substantial in the context of the late 1960s, at least in expectation terms. For one, unbundling addressed the complaints of the ISVs who argued that bundling was killing their business. Secondly, it potentially improved the probability that IBM would obtain a favourable outcome in other lawsuits initiated by the Government, competitors, or customers – and it even had the potential to completely avoid a Government-initiated lawsuit. Thirdly, if coupled with some sort of IP protection, unbundling would allow IBM to charge compatible platforms (like RCA) and their customers a price for IBM software that up to that point they were obtaining for free. This would both provide a flow of software-based revenue for IBM and decrease the demand for the compatible platforms, since it would increase the price of software for those platforms. Finally, the impact of unbundling on the demand for the IBM platform was somewhat unclear. On the one hand, the price of the IBM hardware went down after unbundling (by about 3%), which had the potential to increase the quantity demanded of hardware (Grad, 2002). On the other, the price of the IBM software ‘‘went up,” at least in the sense that customers would now pay for a product that they were apparently obtaining ‘‘for free.” This had the potential to decrease the quantity demanded of software, which could then in turn lead to a decrease in the demand for the platform.

237

4.2.2. Why still open source? Keeping the source code completely open had the obvious benefit that it facilitated the process by which customers and independent software vendors customized and created software for the IBM platform. This, in turn, raised the demand for the platform. On the other hand, the costs of keeping the source code completely open had increased considerably by the late 1960s. First and foremost, with the Spectra 70 family of computers RCA had brought to the fore the dangers involved in a between-sponsor compatible platform: the fact that software was open source made it much easier for competitors to create hardware that could be matched with IBM software. A competitor could thus develop an IBM-like platform at a much smaller cost than IBM and sell it at a much lower price (Humphrey, 2002). In addition, ISVs – the number of which grew by leaps and bounds in the late 1960s – could inspect the IBM source code and create products for the IBM platform that competed with the IBM software products, since many IBM software products were now unbundled from the hardware and sold in the market for a price. On the one hand, the ISV-created products raised the demand for the IBM platform, since they were complements vis-à-vis the IBM hardware. On the other, however, they were now competing with software products that IBM marketed itself. In addition, in theory the ISV-created products could be used on platforms that were between-sponsor compatible with IBM’s, thus raising the demand for competing platforms and lowering the demand for IBM’s. IBM chose to thread a compromise path: it kept the source code open and protected the intellectual property through a combination of copyright and license. The benefits of the compromise resided in that it facilitated software customization and the creation of complements for the platform. The costs of the compromise were mounting, although still not large enough to tilt the balance. Copyright cum license still made life relatively easy for would-be creators of between-sponsor compatible platforms and for ISVs who wanted to gain a competitive edge by inspecting the code.

5. The 1980s, Part I: when software was no longer open source In the early 1980s IBM finally made the decision to completely close the software’s source code. 5.1. IBM’s approach to software production and marketing in the 1980s In February 1983 – about a year after the antitrust suit was finally dismissed – IBM introduced its ‘‘object code only” or OCO policy. Starting with an immediate ten named system software products, and building up to its entire portfolio over a period of ‘‘at least 10 years,” IBM would no longer supply source code (ComputerWorld, 1988, p. 62). In doing so, IBM was following the general trend of the independent software industry, which had gradually ceased source code disclosure as the technology

238

M. Campbell-Kelly, D.D. Garcia-Swartz / Information Economics and Policy 21 (2009) 229–244

of software customization improved. The primary stated reason for the OCO policy was intellectual property protection. Software products were seen increasingly as valuable IP that needed to be protected. IBM replaced the ability of developers to directly interface with code by ‘‘applications programming interfaces” (APIs). However, objectors – particularly vendors of system software products – considered that these interfaces weren’t ‘‘rich enough” to ‘‘provide third-party developers with the information they needed to produce good on-line and performance monitoring products” (Carlyle and Moad, 1988, p. 44) . More than that, the APIs enabled IBM to exclude more efficient products by erecting ‘‘interface barriers.” The software industry trade association ADAPSO took up the issue on behalf of its system software vendor membership. The association formed a subcommittee to negotiate with IBM to reverse the OCO policy and some bundling practices that IBM had also recently introduced.7 The committee met with senior IBMers on several occasions (including IBM’s president at the first meeting). ADAPSO made a practical proposal for its members to have access to source code on a need-to-know basis and with any reasonable security and safeguards that IBM deemed necessary. IBM was unrelenting on the OCO policy, however. One of the main reasons for the policy was that it did not want ‘‘software companies grazing through IBM’s source code” (Johnson, 2003, p. 202). After five years of fruitless negotiation ADAPSO went so far as to threaten IBM with an appeal to the FCC. In the end, however, the association just gave up; closed-source software had become a fact of life (Schatz, 1988). Furthermore, IBM had introduced measures that came some way to satisfying its critics: for example, it required its own software developers to use the same APIs as independent software vendors, and they too were not permitted access to source code. The issue of ‘‘grazing though source code” was at the heart of a confrontation between IBM and the Japanese plug-compatible mainframe manufacturer Fujitsu. Gene Amdahl, one of the main architects of IBM’s System/360 and founder of the Amdahl Corporation, had introduced plug-compatible mainframes (PCMs) in 1975. An Amdahl PCM could be substituted directly for an IBM processor within an existing installation, providing users with better value in terms of raw processing power. In the late 1970s IBM started charging for its operating systems, ensuring it derived some revenues from users of PCMs. In the early 1980s a more substantial plug-compatible threat came from Japanese manufacturers, who had created their own operating systems but had benefited from the possibility of inspecting IBM’s source code. The OCO policy would close this particular form of IP leakage.8 7 The bundling practices related to the integration of discrete software products and the tying of database middleware with its operating system (ADAPSO, 1987a). 8 Long before the confrontation with the Japanese, the Soviet Bloc had made very heavy use of IBM software in its 360-compatible mainframes. This had no impact on IBM’s sales, however, because these countries did ‘‘not have either the perceived need, or the hard currency to buy large numbers of these machines, even if export controls were lifted” (Davis and Goodman, 1978, p. 118).

In 1982, IBM charged that Fujitsu had illegally appropriated IBM’s mainframe operating system code.9 Fujitsu countered that it had built its own operating system, using only IBM software that was in the public domain. The parties decided to negotiate rather than litigate. The following year, 1983, IBM and Fujitsu reached a Settlement Agreement in which Fujitsu made no admission of copyright infringement but agreed to pay IBM an undisclosed sum, reported to be several hundred million dollars (Gross and Verity, 1988). In July 1985, IBM invoked an arbitration clause in the 1983 Settlement Agreement, charging that Fujitsu had again violated IBM’s intellectual property rights in its operating system software. In July 1987, after more than two years of arbitration, another agreement was reached. By this agreement Fujitsu would be granted access to IBM programming materials in exchange for an up-front payment of $396 million and an annual fee of as much as $51 million, the actual amount to be determined by the number of programs accessed. The agreement covered all IBM mainframe software until July 1997. The manner in which Fujitsu was granted access was highly constrained. Business Week noted: ‘‘Fujitsu can’t just demand to see all 20 million lines of IBM’s operating system. It can only see those parts, or ‘interfaces,’ that define how a particular subprogram interacts with another” (Gross and Verity, 1988). Fujitsu’s developers were given access to IBM source code in a ‘‘Secured Facility Regime” under the supervision of a neutral staff, to ensure that the information taken away complied with the agreement. The agreement did not permit the taking away of source code as such, but only the interface information needed to write programs that worked with IBM’s. As a final protection IBM had the right to inspect Fujitsu’s programs, in another secured facility, to verify that no violations of the agreement had taken place. The IBM-Fujitsu agreement led to a storm of protest from ADAPSO and the independent software industry, which argued that Fujitsu now had a major competitive advantage over U.S. software makers (Miler, 1987; ADAPSO, 1987b). However, as with its protests about the OCO policy, ADAPSO was unable to get IBM to alter its behavior. 5.2. Analysis The main question for the 1980s is thus: why no longer open source? The balance of costs and benefits regarding source code disclosure had dramatically changed by the beginning of the 1980s. Of course, some of the benefits of open source to IBM were the same in the 1980s as they had been in the 1950s. For example, open source made life easier for customers and ISVs that customized and/or produced software for the platform, which raised the demand for the platform. But many other components of the picture were no longer the same. For one, allowing users access to the source code naturally invited users to modify the source code, which in turn raised issues regarding the integrity of software products –

9 The IBM-Fujitsu battle is well documented in the legal literature. See, for example, Clapes (1993).

M. Campbell-Kelly, D.D. Garcia-Swartz / Information Economics and Policy 21 (2009) 229–244

a bug might lie either in the original product or in the user’s modifications. In addition, when a new release of a software product was made, a user’s modifications would likely not work with the upgraded product. With the increasing complexity and sophistication of software products, dealing with the integrity of software code had become quite expensive for IBM by the early 1980s (Homer, 1992). More importantly, the threat of the between-sponsor compatible platform had grown considerably since the days of the RCA Spectra 70 computers. The Amdahl computers of the mid-1970s and, above all, the Japanese plug-compatible machines of the early 1980s were a qualitative leap in terms of competitive threat. The number of Spectra 70 installed machines in the late 1960s was roughly equivalent to 3.5% of all System/360 installations (Computers and Automation, 1970a, p. 67ff). The Amdahl mainframe revenues in the late 1970s were roughly equivalent to 5.8% of the relevant IBM revenues at that time (Datamation, 1980). The Fujitsu mainframe revenues in 1984 represented almost 11% of the IBM mainframe revenues at the time (Datamation, 1985). By 1988, IBM accounted for 40% of the Datamation 100 mainframe revenues and Fujitsu already accounted for almost 14% (Juliussen and Juliussen, 1989, p. 2.38). In short, by the end of the decade Fujitsu generated mainframe-related revenue equivalent to 35% of IBM’s. Toward the end of the 1980s Amdahl, Hitachi, and Siemens were also selling PCMs, so that IBM’s share of all IBM-compatible mainframes was less than 50% (Datamation, 1988). Even though competitors were no longer (legally) allowed to load the software on their machines without paying the product’s price, or to copy the IBM software time and again, open source allowed competitors to gain an edge from inspecting the IBM data structures and algorithms. Furthermore, open source made it easy for ISVs to create software products that competed with IBM’s (and that could potentially be used on the plug-compatible machines). For all practical purposes, the presence of open source made it easy for the rest of the world to create a full

239

hardware–software platform that competed frontally with the IBM platform. Two additional trends must have played a role in shaping IBM’s decision to close access to the source code – a long-term trend of decline in hardware prices, and an explosion of revenues derived from software starting in the early 1980s. Table 2 depicts the trends in hardware prices between 1959 and the late 1970s. The price of mainframes shipped oscillated violently, but the increasing share of minicomputers and small-business computers (which were priced at a significantly lower level than mainframes) drove the weighted-average price of hardware down consistently. In addition, total software revenues (for all companies in the market), which had grown steadily in the 1970s, soared in the early 1980s (Fig. 2). The rate of growth of total software expenditures in the US (including software products and programming services) skyrocketed to about 35% in 1980 and 43% in 1981, and stayed relatively high through the end of the decade. Declining hardware prices and soaring industry-wide software revenues created the expectation at IBM that software would become a major source of revenue. But closed-source software was a precondition for this to happen, or so it was believed at the time. Open-source software was an invitation to everybody that mattered in the market – own customers, customers of compatible platforms, sponsors of compatible platforms, ISVs – to profit from the opportunity of either examining the code, or copying the code, or both. In other words, the perception at IBM was that open-source software could not be the foundation for a profitable software business. IBM software revenues, which represented about 4% of total IBM revenues around 1980, did increase consistently in the 1980s, not to the levels anticipated at the beginning of the decade but enough to become substantial in the overall scheme of things toward the end of the decade. By 1990, software revenues accounted for about 15% of total IBM revenues (Table 3).

Table 2 Prices of computers shipped in the US, 1959–1977: general-purpose mainframes, minicomputers and small-business computers. GP US price (US$) 1959 1960 1961 1962 1963 1964 1965 1966 1967 1968 1969 1970 1971 1972 1973 1974 1975 1976 1977

413,043.48 373,333.33 369,565.22 341,935.48 321,052.63 307,843.14 360,377.36 433,333.33 360,000.00 560,810.81 691,666.67 631,578.95 514,473.68 467,289.72 388,489.21 720,930.23 837,313.43 768,055.56 741,573.03

MINI US price (US$)

75,000.00 30,000.00 27,777.78 28,636.36 23,968.25 20,000.00 20,000.00 19,000.00 17,535.55 18,584.07 21,304.35 24,404.76 25,833.33

Source: calculations by authors on the basis of Phister (1979, p. 601).

SB US price (US$)

Weighted average US price (US$)

37,500.00 44,444.44 51,063.83 58,441.56 50,000.00 37,974.68 39,189.19 38,888.89

413,043.48 373,333.33 369,565.22 341,935.48 321,052.63 307,843.14 350,000.00 375,714.29 309,322.03 438,854.17 349,674.80 262,517.39 246,924.00 189,811.86 162,566.40 153,406.59 135,336.05 111,484.38 99,337.02

240

M. Campbell-Kelly, D.D. Garcia-Swartz / Information Economics and Policy 21 (2009) 229–244 45.00 40.00 35.00

US$B

30.00 25.00

Services Products

20.00 15.00 10.00 5.00 0.00 1970 1971 1972 1973 1974 1975 1976 1977 1978 1979 1980 1981 1982 1983 1984 1985 1986 1987 1988 1989

Year Fig. 2. User Expenditures in software Products and Services in the US, 1970-1989.US$B. Source: Campbell-Kelly (2003, pp. 14–15).

Table 3 IBM – Total revenues and software product revenues, 1980–2006. Year

1980 1981 1982 1983 1984 1985 1986 1987 1988 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006

Total revenues

Software revenues

US$M

US$M

% of total

21,236 26,340 31,500 35,603 44,292 48,554 49,591 50,486 55,003 60,805 67,090 62,840 64,523 62,716 64,052 71,940 75,947 78,508 81,667 87,548 85,089 83,067 81,186 89,131 96,293 91,134 91,424

800 1000 1683 2200 3197 4165 5514 6836 7927 8465 9952 10,524 11,103 10,953 11,346 12,657 13,052 11,164 11,863 12,662 12,598 12,939 13,074 14,311 15,094 15,753 18,204

3.8 3.8 5.3 6.2 7.2 8.6 11.1 13.5 14.4 13.9 14.8 16.7 17.2 17.5 17.7 17.6 17.2 14.2 14.5 14.5 14.8 15.6 16.1 16.1 15.7 17.3 19.9

Sources: 1980–1991: Datamation (1996) 100; 1992–2006: IBM annual reports.

6. The 1980s, Part II: The SAA and OS/2 Fiascos In the second half of the 1980s, IBM made two big bets on its software future, both of which went spectacularly wrong. However, by luck rather than strategic foresight, it also made a little bet – a foray into the world of Unix that would prove the well-spring of IBM’s recovery a decade later. IBM’s first big bet was a plan to rationalize its entire software portfolio with its so-called Systems Application Architecture (SAA). IBM’s software development was in need of rationalization, much as its computer ranges had

needed rationalization in the 1960s (Wheeler and Ganek, 1988). Since the launch of System/360, IBM’s product range had gradually fragmented again so that it was now supporting three ‘‘tiers” of computing – mainframes, mid-range machines, and PCs. The multiple-range problem was common to other computer manufacturers and software vendors, and they too were developing similar solutions.10 The SAA program was initiated in spring 1983, but was not announced until March 1987. SAA was a massive undertaking. In its wake it was reported that IBM ‘‘would add 6,000 employees to its software development staff, raising the total to 26,000 or about 7% of its total work force” (Field, 1987). IBM also encouraged the independent software industry to use the SAA protocols and standards, so that their software products, too, would be usable across the spectrum of IBM computers (Libutti, 1990). In 1994, however, following its profits nadir, IBM formally abandoned the SAA project after a decade of effort, having produced a mountain of specification documents but relatively few products (Bucken, 1994). IBM’s second big bet was its OS/2 operating system. OS/ 2 was a key strategic product within IBM, intended to respond to the rise of client-server systems. Client-server systems would become the dominant computer configuration in the 1990s. Instead of a powerful mainframe surrounded by dumb terminals, which had dominated computer design since the 1960s, the client-server system consisted of a cluster of modestly powered server computers surrounded by a larger number of ‘‘clients,” typically desktop PCs. OS/2 would serve not only as the operating system for the clients but also for the servers. In early 1985 IBM and Microsoft had begun the joint development of OS/2. The collaboration was an unhappy experience for both companies. Their working styles were very different: IBM was bureaucratic and considered software reliability to be paramount, whereas Microsoft’s 10 For example, DEC’s equivalent to IBM’s SAA was its Network Applications Support (NAS) services, while Computer Associates had developed its CA90s architecture (Bunker, 1991; Computer Associates, 1993).

M. Campbell-Kelly, D.D. Garcia-Swartz / Information Economics and Policy 21 (2009) 229–244

development processes were more informal and freewheeling, and more concerned with shipping a useable product than getting it perfect.11 In parallel with OS/2, Microsoft had developed a desktop operating system of its own, Windows, which proved to be a market winner when version 3.0 was released in May 1990. Windows was light-weight, compatible with existing MS-DOS applications, and was overwhelmingly more successful than OS/2. Even though Widows was only suitable for desktop client computers, it effectively closed the market for OS/2, both as a desktop and as a server operating system. Had it won out in the market, OS/2 might have occupied the niche that Windows NT and Windows Server occupied a decade later. The failure of OS/2 was catastrophic for IBM’s software strategy, as it had been ‘‘a cornerstone” of SAA (Coffey, 1988). Had it achieved market acceptance, IBM’s history would have unfolded quite differently in the 1990s. IBM’s little bet was an opportunistic entry into Unix systems. The company introduced its first Unix-based system, the RS/6000 workstation, in 1986, which although out of its usual product line, was perceived as a growth opportunity. Unix was owned by AT&T which licensed the source code to independent vendors, primarily computer manufacturers, who produced proprietary versions of Unix optimized for their own computers. Around 1988, as client-server systems became more popular and OS/2 languished, Unix became a strategic product. At the same time, IBM became a founding member of the Open Software Foundation (OSF), which had the aim of standardizing Unix to minimize the proliferation of incompatible versions (Killen, 1992, p. 33– 56). By 1992 Unix systems were a significant IBM business, generating sales of $2.9 billon or approximately 5% of total revenues. The ascent of Unix was a mixed blessing for IBM, however. Simultaneously with the rise of Unix came the rise of ‘‘open systems.” Open systems enabled enterprise users to purchase computer equipment from multiple manufacturers and bind it together with the Unix operating system. Open systems was a boon to IBM’s competitors, such as Sun Microsystems and HP, and to European vendors such as ICL and Siemens (Flamm, 1988, p. 242–246; Gannon, 1997, p. 237–240). It enabled these smaller manufacturers to shed the burden of providing full IT solutions and instead to specialize in their competencies (Sun in workstations and HP in printers, for example). By the late 1980s, as computer hardware became increasingly commoditized, even the most traditional IBM shops were beginning to use non-IBM equipment. IBM was taken by surprise at the extent to which users were no longer willing to remain fully loyal to IBM. Its hardware sales began to hemorrhage.

7. The 1990s and beyond: when (some) IBM software became open source (again) From the 1990s on, the IBM software strategy combined elements of closed- and open-source software centered on 11 For the contrasting development styles of IBM and Microsoft, see Carroll (1993) and Cusumano and Selby (1995).

241

the Linux operating system. This was in large part IBM’s response to the rise of open systems and the company’s parlous financial state. 7.1. IBM’s approach to software production and marketing in the 1990s and beyond IBM was fortunate in having made its opportunistic foray into Unix and open systems. In 1993, as customers began to reject IBM-only purchasing policies, SAA was formally abandoned and IBM moved increasingly to open systems in order to preserve its market share. In 1997 IBM decided to embark on ‘‘Project Monterey,” an enterprise strength version of Unix that would be suitable for the most demanding applications. IBM’s Unix expertise was somewhat limited, so it partnered with SCO (the leading Unix-on-Intel vendor which had acquired the rights to the Unix source code in 1995) and with Sequent (a high-performance computer vendor, which IBM acquired in 1999).12 The project was, however, overtaken by the increasing popularity of Linux, the open source version of Unix, and IBM again decided to cut its losses in 2001 and formally abandon the project. Linux and the OSS movement had a history quite independent of IBM. In a much told story, Linux had been developed in the early 1990s by a group of amateur coders led by Linus Torvalds, a Finnish computer science undergraduate. As Linux gathered momentum, hundreds of volunteer programmers worked on improving the system and a minor industry of Linux distributors emerged (Fink, 2003, pp. 81–90). IBM did not come to Linux and OSS out of the blue. The open-source culture was imported in a small way in the mid 1990s through new college recruits (Capek et al., 2005, p. 250). IBM’s first commercial involvement with the open-source community was its participation in the Apache web server project. In June 1998, IBM announced that it would use Apache in its WebSphere product. At this time open-source software was gaining much media attention and IBM’s competitors such as Netscape, Oracle, Computer Associates, Sun, and SAP were all experimenting with OSS. Nonetheless, IBM’s embrace of open source was seen as a watershed for the movement – ‘‘probably the single most important boost the proponents of free software could have wished for” (Moody, 2001, p. 206). By early 1999, IBM had come to the view that Linux offered ‘‘the possibility of a unified operating system on our platforms” (Capek et al., 2005, p. 251). In June 2001 the company announced that it would invest $1 billion over the following three years to make Linux more suitable for enterprise applications – in fact, a modest investment compared with the decade long and ultimately doomed SAA strategy meant to achieve a similar end. IBM’s opensource developers – and increasingly those elsewhere – were seemingly no longer amateur programmers, but 12 There has been no significant discussion of Project Monterey in the conventional literature. There has, however, been considerable informal online discussion, particularly in connection with the IBM-SCO lawsuit. Probably the most coherent distillation is the article ‘‘Project Monterey” in Wikipedia.

242

M. Campbell-Kelly, D.D. Garcia-Swartz / Information Economics and Policy 21 (2009) 229–244

rather individuals receiving a salary from their employers to develop open-source software (Capek et al., 2005, p. 257). In addition to participating in the open-source development community, IBM resolved a number of IP-related issues, including the granting of some patent rights (around 500 named patents from its massive portfolio) and framing its Common Public License. IBM’s adoption of Linux had a considerable impact on its operating system revenues, although these were in any case already in decline. Operating system revenues fell some 20% between 1999 and 2002 to $2.36 billion, just 18% of its total software revenues. However, Linux ‘‘[gave] customers another reason to consider IBM middleware,” so that software revenues were buoyed up by a larger middleware market on non-IBM equipment (IBM, 2002, p. 50). Hence, while it was enhancing its reputation in the open-source community IBM was not foregoing significant revenues. For all its advocacy of the OSS model, IBM remains very much a proprietary software developer at heart. In 2005 its total participation in the open-source community numbered about 700 developers, compared with tens of thousands of regular programming staff, and a dedicated software sales force numbering 10,000 individuals. 7.2. Analysis By the mid 1980s IBM confronted the same problem that it had faced in the mid 1960s, namely within-sponsor incompatibility (or platform fragmentation). The costs to IBM of this situation were of the same nature as they had been two decades earlier – individual switching costs for customers migrating across IBM hardware machines, and loss of the full scope of network effects. SAA was an attempt to deal with this fragmentation by re-creating the kind of unified platform that had converted IBM into an undisputed industry leader in the 1960s. The failure of SAA led IBM to consider Linux as an alternative. The question for the 1990s and beyond is thus: why did IBM embrace open-source software again? The differences between the 1950s and 1960s, on the one hand, and the late 1990s, on the other, are as instructive as the similarities. First, in the late 1990s IBM’s push into open-source software relied on embracing, supporting, and improving major pieces of software that had already been created, rather than on producing key open-source software artifacts from scratch (as it had done in the earlier decades). Secondly, in the late 1990s IBM did not provide free access to the source code of all its major software products (as it had done in the earlier decades), but rather supported an operating system that was already open source and provided access to the source code of software artifacts that were not major revenue generators. As regards IBM and open-source software, the period that started in the late 1990s has been more different from the earlier decades than a superficial analysis would lead us to believe. What were the costs and benefits of supporting Linux at the time when IBM made the decision to do so? The benefits were multiple. For one, supporting Linux meant embracing the operating system for the new, client-server era of computing, which was dawning in the 1990s. By

1995, for example, server-generated revenues for the top 10 suppliers in the US (about $27.6 billion) exceeded mainframe-generated revenues for the top 10 (about $23.7 billion) (Juliussen and Juliussen, 1996). Secondly, with IBM’s support Linux could potentially provide the unity to the IBM platform that had been lost between the mid 1960s and the mid 1980s, the benefits of which we have already discussed. Thirdly, supporting Linux would potentially boost the demand for IBM middleware, both on IBM and non-IBM hardware – and middleware was the type of software that IBM kept in closed-source format. Finally, embracing Linux would potentially boost the demand for IBM services – and in the 1990s services were becoming the key source of revenue generation for IBM in the context of the increasing commoditization of all sorts of hardware. The costs were of two types. In the first place, IBM contributed programming resources to the development and improvement of Linux and other open-source software artifacts. Secondly, and more fundamentally, IBM’s commitment to Linux implied an expected cost in terms of a substantial decline in (proprietary) operating system revenue for the IBM mainframes. But the key point in this regard is that, even though proprietary operating systems for the mainframe had represented as much as 45% of all IBM software revenue at some point, in the 1990s mainframes were being replaced by a new computing model, namely client-server computing.13 In other words, embracing Linux meant accelerating the collapse of an old revenue source that was on the way to the grave in any case. 8. Conclusions Here we summarize the essence of our arguments and identify directions for further research. 8.1. Summary In the 1950s IBM followed what today would be regarded as an open-source model. Its software was often written collaboratively, it was free of separate charge (being bundled with hardware), and the source code was freely disclosed to anyone, whether an IBM customer or not. Between the 1950s and the 1980s, IBM morphed into a closed source, proprietary software vendor. Today IBM is something of a hybrid. It still makes up to 20% of its revenues from conventional software products, but it also provides some open-source packages and supports others. The main thesis of this paper is that the company has changed its strategies toward the production, distribution, and commercialization of software in the context of a constant process of adaptation to the technological, business, and political constraints of the day. More specifically, for IBM the tension between openand closed-source software mirrored a tension between 13 Hamilton (1985) reports that about 90 percent of IBM’s software revenues came from system software and 10 percent came from application programs. Of the system software revenue, perhaps 50 percent came from ‘‘captive” operating system sales, so-called because users had no alternative operating system supplier.

M. Campbell-Kelly, D.D. Garcia-Swartz / Information Economics and Policy 21 (2009) 229–244

the need to encourage massive adoption of the platform and the incentive to capture at least some of the rewards from the platform. Open-source facilitated adoption but, at the same time, under certain circumstances it also jeopardized reward appropriation. The core of our argument may be summarized as follows. In the early days of computing, the need to generate massive adoption was strong and the compatibility threat was weak – open-source software reigned supreme. The equation changed dramatically between 1950 and 1980: massive adoption was in fact achieved while, at the same time, the compatibility threat rose to the forefront. In addition, the revenue-generating potential of hardware vis-àvis software collapsed. The result was a slow but radical switch to closed-source software. Along the way from one extreme to the other, unbundling happened – the growing compatibility threat combined with the threat of litigation to force IBM to market software separately from hardware. In the last analysis, the unbundling episode, which brought about copyright cum license (i.e., access to source code under certain conditions), can be viewed as just a step – an important one indeed – on the path from open- to closed-source. The more recent switch to hybrid strategies reveals (a) an attempt to recreate, via opensource software, the single-platform scenario that IBM achieved with System/360 (and that IBM failed to recreate, in a proprietary context, via SAA), and (b) an attempt to boost revenues from middleware and services while allowing the old cash cows (e.g., proprietary operating-system software) to peacefully die an unavoidable death. 8.2. Directions for further research Our study, of course, raises as many questions as it answers. Some of these questions transcend the boundaries of the narrow focus of our paper, which has been the changing balance of costs and benefits of open source, bundled, and collaborative software relative to the alternatives. Our historical reconstruction suggests that unbundling considerations at IBM were driven by (a) the rising threat posed by compatible platforms, and (b) the growing threat of litigation from all corners of the industry (competitors, customers, ISVs) and the government.14 We have not really assessed the extent to which demand factors (i.e., the

243

division of labor is limited by the extent of the market) mattered, although we have presented data (Fig. 1, for example) that suggest that demand did play a role. Furthermore, we have not gauged the extent to which a search for ‘‘modularity” (i.e., an attempt to break a complex system down into components that interact through interfaces) mattered to IBM (Baldwin and Clark, 1997; Langlois, 1999), or more precisely at what point in time it started to matter. These are questions that require further research. Furthermore, an issue that comes up repeatedly in our study is that of the relationships between IBM and the creators of complementary software products for the platform. In their analysis of Intel, Gawer and Henderson (2007) have analyzed the trade-off that platform leaders often face in dealing with creators of complementary products – leaders would like to encourage ISVs to supply complements for the platform but often have internal divisions that create products that compete with those created by the ISVs. What determines how platform leaders deal with ISVs? Our historical reconstruction suggests that IBM did not try to ‘‘win in every market,” simply because it could not have supplied by itself all conceivable applications. We would suggest that IBM attempted to monopolize the bottom of the software stack, compete in the middle, and encourage an efficient supply of applications by ‘‘software partners” at the top (Campbell-Kelly, 2003, p. 178). The issue of the technological and strategic factors that drive different platform leaders to behave differently vis-à-vis the ISVs requires further investigation. Finally, as one of the reviewers pointed out, the role of hardware in the present day’s IBM strategy also requires further exploration. We have hypothesized that IBM’s hybrid software strategies can be understood in light of radical changes in the company’s main sources of revenue. If, as we suggest, the key sources of revenue generation for IBM have completed a historical migration from hardware to software and, more recently, to integration and support services, then the question can be posed: Must IBM maintain a substantial and profitable presence in specific hardware markets in order to continue at the top of the IT sector? Or, in the words of the reviewer, is hardware ‘‘the new software,” namely a complementary business that IBM subsidizes to stimulate demand for its main product? Acknowledgements

14 We acknowledge that the causes and consequences of software unbundling are complex. The testimony of the individuals who were involved with the unbundling process at IBM seems to indicate that the compatibility threat (i.e., the RCA Spectra 70 family of machines) and the litigation threat coming from the ISVs and other industry players clearly played a role in IBM’s unbundling decision. As far as the ISVs are concerned, the evidence seems to indicate that (a) the introduction of IBM System/360 encouraged massive entry into the software industry in the late 1960s; (b) massive entry into software increased the political pressure on IBM to unbundle; (c) unbundling further encouraged entry into software in the 1970s. Interestingly enough, there was substantial entry into software even before unbundling. It is probably the case, however, that most of the players that entered the industry before 1970 supplied products and services that complemented the software products that IBM bundled with its hardware. In other words, the political pressure for unbundling has to have come from those players that wanted to supply software products that competed with those that IBM bundled with its computing machines.

We acknowledge the extremely helpful comments we received from two anonymous reviewers, the associate editor, and the editor of this journal, as well as from Anne Layne-Farrar of LECG, LLC. We also acknowledge the financial support of Microsoft. All opinions expressed in this paper are exclusively our own and do not necessarily coincide with those of the institutions with which we are affiliated. References ADAPSO, 1987a. Position of ADAPSO on Three New Policies of the International Business Machines Corporation. Charles Babbage Institute Archives, University of Minnesota.

244

M. Campbell-Kelly, D.D. Garcia-Swartz / Information Economics and Policy 21 (2009) 229–244

ADAPSO, 1987b. ADAPSO Chairman Seeks IBM Cooperation in Working with US Software Developers. Charles Babbage Institute Archives, University of Minnesota (Press release, September 28). Akera, A., 2001. Voluntarism and the fruits of collaboration: The IBM User group share. Technology and Culture 42, 710–736. Armer, P., 1980. SHARE – A eulogy to cooperative effort. Annals of the History of Computing 2, 122–129. Baldwin, C., Clark, K., 1997. Managing in an age of modularity. Harvard Business Review 75, 84–93. Bashe, C., Johnson, L., Palmer, J., Pugh, E., 1986. IBM’s Early Computers. The MIT Press, Cambridge, Mass. Besen, S., Farrell, J., 1994. Choosing how to compete: strategies and tactics in standardization. Journal of Economic Perspectives 8, 117–131. Bucken, M., 1994. Mills leads charge to unify IBM software. Software Magazine, October, pp. 104–107. Bunker, T., 1991. DEC’s ambitious software strategy. Datamation, 66–69. Campbell-Kelly, M., 2003. From Airline Reservations to Sonic the Hedgehog: A History of the Software Industry. The MIT Press, Cambridge, Mass. Campbell-Kelly, M., Aspray, W., 2004. Computer: A History of the Information Machine. Westview Press, Boulder, Colo. Capek, P.G. et al, 2005. A history of IBM’s open-source involvement and strategy. IBM Systems Journal 44, 249–257. Carlyle, R., Moad, J., 1988. IBM and the control of information. Datamation, pp. 34, 38, 40, 44. Carroll, P., 1993. Big Blues: The Unmaking of IBM. Crown, New York. Clapes, A., 1993. Softwars: The Legal Battles for Control of the Global Software Industry. Quorum, Westport, Conn.. Coffey, M., 1988. Strategies for software. Management Today, 6–11. Computer Associates, 1993. CA90s: Computing Architecture for the 90s. Computer Associates, Islandia, NY. Computers and Automation, 1970a. Monthly Computer Census: Summary as of December 15, 1969. Computers and Automation 19. Computers and Automation, 1970b. Main roster of organizations in computers and data processing, cumulative information as of summer 1970. Computers and Automation 19. ComputerWorld, 1988. Object-code only: Is IBM playing fair? ComputerWorld, February 8, pp. 55, 58–59, 62, 66. Cortada, J., 2004. The digital hand. How Computers Changed the Work of American Manufacturing, Transportation, and Retail Industries, vol. 1. Oxford University Press, Oxford. Cusumano, M., Selby, R., 1995. Microsoft Secrets. The Free Press, New York. Datamation, 1980. The Datamation 100 index. Datamation. Datamation, 1985. The Datamation 100 index. Datamation. Datamation, 1988. The Datamation 100 index. Datamation. Datamation, 1996. Datamation 100: bigger by design. Datamation. David, P., Greenstein, S., 1990. The economics of compatibility standards: an introduction to recent research. Economics of Innovation and New Technology 1, 3–41. Davis, N., Goodman, S., 1978. The Soviet Bloc’s unified system of computers. Computing Surveys 10, 93–122. Evans, D., Schmalensee, R., 2005. The Industrial Organization of Markets with two-sided Platforms. NBER Working Paper 11603. Farrell, J., Klemperer, P., 2007. Coordination and lock: Competition with switching costs and network effects. In: Armstrong, M., Porter, R. (Eds.), Handbook of Industrial Organization, vol. 3. North-Holland, Amsterdam. Farrell, J., Weiser, P., 2003. Modularity, vertical integration, and open access policies: towards a convergence of antitrust and regulation in the internet age. Harvard Journal of Law and Technology 17, 85–134. Field, A.R., 1987. Why the hardware giants are hustling into software. Business Week, July 27, pp. 38–39. Fink, M., 2003. The Business and Economics of Open Source. Prentice Hall PTR, Upper Saddle River, NJ. Fisher, F., 1964. Computer Programming Systems. Holt, Rinehart, and Winston, New York. Fisher, F., McGowan, J., Greenwood, J., 1983. Folded, Spindled, and Mutilated: Economic Analysis and U.S. v. IBM. The MIT Press, Cambridge, Mass. Flamm, K., 1988. Creating the Computer: Government, Industry, and High Technology. Brookings Institution, Washington DC. Gannon, P., 1997. Trojan Horses and National Champions: The Crisis in Europe’s Computing and Telecommunications Industry. Apt-Amatic, London.

Gawer, A., Henderson, R., 2007. Platform owner entry and innovation in complementary markets: evidence from Intel. Journal of Economics and Management Strategy 16, 1–34. Grad, B., 2002. A personal recollection: IBM’s unbundling of software and services. IEEE Annals of the History of Computing 24, 64–71. Gross, N., Verity, J., 1988. Can Fujitsu break Big Blue’s Grip? Business Week, December 19. Hamilton, D., 1985. The ICP Million Dollar Awards. ICP Business Software Review – Europe, 32–41. Head, R., 1971. A Guide to Packaged Systems. Wiley-Interscience, New York. Homer, S., 1992. Battling on with Veteran Computers. New Scientist 14, 32–35. Humphrey, W., 2002. Software unbundling: a personal perspective. IEEE Annals of the History of Computing 24, 59–63. IBM, 1961. Final Report of the SPREAD Task Group, December 28, 1961, reprinted 1983 in Annals of the History of Computing 5, pp. 6–26. IBM, 1971. License agreement for IBM program products. In: Head, R. (Ed.), A Guide to Packaged Systems, Wiley-Interscience, New York, pp. 104–112. IBM, 2002. Annual Report. Johnson, L. (Ed.), 2003. ADAPSO Reunion Transcript, May 2–4, 2002: The Origins of the Multi-Billion Dollar Computer Software and Services Industry. iBusiness Press. Juliussen, K., Juliussen, E., 1989. The 1990 Computer Industry. Almanac. Brady, New York. Juliussen, K. , Juliussen, E., 1996. The 8th Annual Computer Industry Almanac. Computer Industry Almanac Inc. Katz, K., Shapiro, C., 1994. Systems competition and network effects. Journal of Economic Perspectives 8, 93–115. Killen, M., 1992. SAA and Unix: IBM’s Open Systems Strategy. McGrawHill, New York. Langlois, R., 1999. Modularity in Technology, Organization, and Society, Mimeo, Department of Economics, The University of Connecticut, August. Lerner, J. , Tirole, J., 2000. The Simple Economics of Open Source, February 20, Mimeo. Lerner, J., Tirole, J., 2001. The open source movement: Key research questions. European Economic Review 45, 819–826. Lerner, J., Tirole, J., 2005. The scope of open source licensing. Journal of Law, Economics, and Organization 21, 20–56. Libutti, L., 1990. Systems Application Architecture: The IBM SAA Strategy. TAB Books, Blue Ridge Summit, Penn. Miler, M., 1987. US firms complain Fujitsu gained edge in IBM Copyright Decision. Wall Street Journal 7. Moody, G., 2001. Rebel Code: Linux and the Open Source Revolution. Penguin Books, London. Phister, M., 1979. Data Processing: Technology and Economics. Santa Monica Publishing Company and Digital Press, Bedford, Mass. Pugh, E., 1996. Building IBM: Shaping an Industry and its Technology. The MIT Press, Cambridge, Mass. Pugh, E., 2002. Origins of Software Bundling. IEEE Annals of the History of Computing 24, 57–58. Rochet, J., Tirole, J., 2003. Platform competition in two-sided markets. Journal of the European Economic Association 1. Rochet, J., Tirole, J., 2005. Two-sided Markets: An Overview. IDEI Working Paper. Schatz, W., 1988. ADAPSO withdraws opposition to IBM’s object code stance. Datamation. Sharpe, W., 1969. The Economics of Computers. Columbia University Press, New York and London. Tanner, D., 1975. User Ratings of Software Packages. Datamation, 138– 154. Valimaki, M., 2003. Dual licensing in open source software industry. Systemes d’Information et Management. Welke, L., 1980. The origins of software. Datamation, 127–128. West, J., 2003. How open is open enough? Melding proprietary and open source platform strategies. Research Policy 32, 1259–1285. Wheeler, E., Ganek, A., 1988. Introduction to systems application architecture. IBM Systems Journal 27, 250–263. Yates, J., 1995. Application software for insurance in the 1960s and early 1970s. Business and Economic History 24, 123–134. Yates, J., 2005. Structuring the Information Age: Life Insurance and Technology in the Twentieth Century. Johns Hopkins University Press, Baltimore, MD.