- 0.1 Game Theory and the Chicken-and-Egg Problem
- 0.2 Organization of the Book
This chapter is from the book
This chapter is from the book
This chapter is from the book
0.2 Organization of the Book
Without a clear and connected understanding of some basic concepts, readers will have a more difficult time grasping the dynamics of the game. As such, the first part of the book provides the building blocks for the analyses presented in the second part of the book; that is, the earlier chapters, Chapters 1 though 4, provide readers with the information they need to know about the basic elements of technology systems, technology adoption, and the players themselves that characterize the venue in which the Hardware–Software Game is played.
Network systems and network effects are central features of the technology platforms within which the Hardware–Software Game is played. Network effects play a crucial role in deterring software providers and users from immediately adopting new technology systems. As such, it is crucial for readers to have a comprehensive, well-connected understanding of the basics of networks and network effects in order to grasp all the implications of the analysis. In fact, before coming to this project, I myself thought I had a good understanding of networks and network effects. However, throughout my modeling and analysis of the Hardware–Software Game, I found myself continually researching the basics so as to understand what my analyses were telling me. What’s more, much to my chagrin, I discovered that the resources available seemed to discuss the concepts surrounding networks and network effects in only a disconnected and disjointed manner. For these reasons, I provide a discussion in Chapter 1 of the features of networks, network effects, switching costs, and technology compatibility as they relate to the Hardware–Software Game. Readers who already have a good understanding of these concepts might want to skip to the last paragraphs of sections 1.1, 1.2, and 1.3 for a summary of the information discussed within each of these sections, or just read the summary at the beginning of section 1.4, which discusses the general role of network effects in the Hardware–Software Game.
As with networks and network effects, lifecycles play a crucial role in the Hardware– Software Game. Technology adoption lifecycles and lifecycles of network effects are both cause and effect, in that they both determine and are determined by the timing of new technology introduction by hardware providers and new technology adoption by software providers and users. As with the discussion of networks and network effects, readers who are familiar with the topics might want to skip to the summary paragraphs at the end of sections 2.1, 2.2, and 2.3 or just read the summary at the beginning of section 2.5, which discusses the general role of technology adoption life-cycles in the Hardware–Software Game.
Technology adoption lifecycles include the point of critical mass, known less formally as the tipping point. Readers familiar with technology adoption lifecycles will know that having new technologies achieve critical mass, in and of themselves, can be considered the definition of successful adoption. Given that the point of critical mass plays such an important role in technology adoption lifecycles, one would think that there would be much information in the literature about achieving critical mass. What I found during my research turned into the prototypical joke often told about economists assuming away any problems; that is, when discussing equilibrium points in the technology adoption process, economists note that there are two stable equilibria, the first corresponding to no adoption and the second to successful adoption, the latter of which entails achieving critical mass. Frustratingly enough, the economists then go on to say, “Assume the technology has reached critical mass . . .” and continue with the discussion. This handling of the adoption issue very conveniently skips right over one of the most essential aspects of the analysis, namely, how do you get your new technology to reach critical mass? Section 2.4 provides a discussion of critical mass dynamics, so readers unfamiliar with the subject can better understand its role in the analyses presented later in the book. Again, readers familiar with the subject might want to skip to the summary at the end of section 2.4 or at the beginning of section 2.5.
Chapter 2 ends with section 2.5, which discusses the general role of technology adoption lifecycles in the Hardware–Software Game.
The next two chapters, Chapter 3 and Chapter 4, discuss each of the players in the Hardware–Software Game, technology system users in Chapter 3 and hardware and software providers in Chapter 4. These chapters provide a discussion of what factors affect players’ decisions to provide new technologies (in the case of hardware providers) or to adopt new technologies (in the cases of users and software providers) and how these factors change over time and in response to actions taken by the other players. I discuss the factors affecting users’ decisions relating to new technology adoption in rather meticulous detail in Chapter 3, because it is the users who are the primary determinants of if and when hardware and software providers will end up being successful in the marketplace. Readers who are more familiar with user demand functions and how the size of the installed base, the stock of content, and hardware/software prices affect user demand for new system hardware might want to skim through sections 3.1.1, 3.1.2, and 3.1.3 quickly and/or skip to the summary paragraphs at the end of each of these sections. Likewise with user demand for new system content, users may want to skim through sections 3.2.1 and 3.2.2 quickly and/or skip to read the summary paragraphs at the end of each of these sections. However, even readers familiar with the topics should find the numerical examples in sections 3.1.4 and 3.2.3 useful for understanding how I apply my simulation model to specific scenarios.
Once the users’ motivations are clearly understood, the hardware and software providers’ motivations follow relatively easily and quickly in Chapter 4.
Chapter 5 gets into the meat of the book. It defines the structure of the Hardware– Software Game and analyzes its dynamics and outcomes. The analysis shows how the structure of the incentives faced by users and software providers (the chicken-and-egg problem) often leads to delays in adoption of new technology systems introduced by hardware innovators.
Chapter 6 provides readers with methods for addressing the delays in new technology adoption that result in many of the games. The chapter discusses general responses by hardware providers, together with scenario-specific means of speeding up the pace of adoption of their new systems.
Finally, Chapter 7 provides readers with a summary of key points from the analysis, tools to help readers apply the model to their own technology systems, and further areas of research that stem from the analysis.
For those who are interested, the underlying mathematical model I developed and used in the analysis is presented in Appendix A, and there is a list of further readings organized by topic in Appendix B.