IBM and Linux (A)

Carliss Y. Baldwin; Siobhan  O'Mahony; James  Quinn

Case | HBS Case Collection | June 2003

IBM and Linux (A)

by Carliss Y. Baldwin, Siobhan O'Mahony and James Quinn

Abstract

In the fall of 1998, Dan Frye, member of IBM's emerging technologies and business team, is trying to decide whether to forge a strategic alliance with the Linux Development Community (LDC). Just two years earlier, IBM had its first exposure to an "open source" software program when it selected Apache as the web server program for the web site of the Atlanta Summer Olympic Games. Based on its success with Apache, and Frye's intuition that Linux could be a critical, strategic step in the new "network-centric" computing environment, Frye and his colleagues are trying to decide whether an alliance between IBM and LDC would serve their interests--and, if so, how IBM could manage the alliance with a loosely affiliated group of software developers.

Keywords: Mergers and Acquisitions; Open Source Distribution; Problems and Challenges; Alliances; Cooperation; Computer Industry; Information Technology Industry;

Format: Print

19 pages

Educators Purchase

Citation:

Baldwin, Carliss Y., Siobhan O'Mahony, and James Quinn. "IBM and Linux (A)." Harvard Business School Case 903-083, June 2003.

Working Paper | HBS Working Paper Series | 2020

Design Rules, Volume 2: How Technology Shapes Organizations: Chapter 6 The Value Structure of Technologies, Part 1: Mapping Functional Relationships

Carliss Y. Baldwin

Organizations are formed in a free economy because an individual or group perceives value in carrying out a technical recipe that is beyond the capacity of a single person. Technology specifies what must be done, what resources must be assembled, what actions taken in order to convert stocks of material, energy and information into products and services of value to human beings. Technology is the guide, organizations are the means, value is the goal. The purpose of this chapter is to build a robust and versatile language that is capable of representing the value structure of large technical systems. The language is based on elements I have labeled functional components. The language is more abstract than the language of technical recipes and task networks, thus it is capable of hiding details. However, the language also makes it possible to “trace back” from each named functional component to a technical recipe and a corresponding task network. Finally, although the language itself is non-mathematical, the value structure it reveals can be used to specify equations and prove mathematical propositions about the value of technical systems. The plan of the chapter as follows. I first explain why it is difficult to value technologies using standard economic methods based prices, quanities and probabilities. I then describe a methodology that shows how functional components are combined through technology to create a particular artifact or technical system. The methodology uses symbolic notation to clarify relationships between and among functional components. I illustrate these relationships using an ancient technology—the technology for making a garment from pieces of cloth. I go on to describe commonly observed patterns within technical systems, including optional features; composite functions; and platforms.

Keywords: modularity; Technology; Organizations; Value Creation;

Citation:

Baldwin, Carliss Y. "Design Rules, Volume 2: How Technology Shapes Organizations: Chapter 6 The Value Structure of Technologies, Part 1: Mapping Functional Relationships." Harvard Business School Working Paper, No. 21-039, September 2020. View Details

Cite View Details SSRN Read Now

Functional analysis as set forth in the last chapter decomposes a technical system into functional components that do things to advance the system’s purpose and the goals of its designers. Functional analysis in turn can be used to construct value structure maps of technical systems. Such maps reveal targets of potential action and investment in the technical system where value may be created and captured. Value structure maps can be constructed without using numerical estimates based on prices, quanities and probabilities, thus they are an appropriate means of analyzing technical systems subject to radical uncertainty, complexity, and complementarity.

The purpose of this chapter is to illustrate how value structure mapping combined with narratives can be applied to problems of strategy in large technical systems. I first argue that the salient points of value creation and value capture in a large technical system are the system’s bottlenecks. I then use value-mapping methodology to trace the evolution of bottlenecks of three large technical systems: early aircraft; high-speed machine tools; and container shipping. Finally, I distill the lessons of the case studies into four principles for creating and capturing value in large, evolving technical systems.

From the 1930s through today, many economists have conceived of large technical systems for the production of goods and services as a series of transactions. This point of view has led eminent economists to assert that transactions are the fundamental unit of analysis in the economic system.
This conceptualization has been very powerful, but it is also limiting. To truly understand the relationship between technology and organizations we must look “beneath” transactions at the full set of tasks and transfers that must take place to design and produce useful goods and services in an efficient way. The purpose of this chapter is to describe how transactions fit into a larger network of tasks and transfers and to identify the technological determinants of transaction costs.

Faculty & Research

IBM and Linux (A)

Abstract

Citation:

About the Author

More from the Author