HBS Open Source Case: Salvation or Suicide

Harvard Business School recently published a case on whether a software game company, KMS, which makes a device which permits amateurs to sound like professional musicians should adopt an open source business model.http://harvardbusinessonline.hbsp.harvard.edu/b02/en/common/item_detail.jhtml?id=R0804XThe case demonstrates the increased recognition of the strategic importance of decisions about the adoption of the open source software business model. Unfortunately, the case does not reflect the developments in business models for commercial open source software. The case focuses on an open source business model based primarily on providing technical services. Yet most commercial open source companies have adopted a dual distribution model. Moreover, as Marten Mickos noted in his 2007 keynote at OSBC, commercial open source companies have thirteen ways to make money, with four of them which he identifies as “scalable”. In addition, the analysis in the case if confused because KMS’ product includes hardware as well as software. Such hardware could give KMS a substantial advantage against competitors trying to provide an open source version of the product. In my experience, virtually all decisions about the adoption of open source business model deal solely with software products. Consequently, I think that the case would have been more powerful (and more realistic) to focus on case in which the product was solely software.

The Case Commentaries are very interesting. Jonathan Schwartz of Sun Microsystems, Inc. makes the critical point that KMS needs to determine its business goals before the company can make a meaningful decision about adopting an open source business model. He draws a contrast between Apple and Nokia in the handset market: Apple is trying to define what a handset should be and they sold 4 million iPhone handsets last year. On the other hand, Nokia is trying to be the largest handset maker in the world, has adopted an open platform and sold 400 million handsets last year.

Gary Pisano of Harvard Business School was also very insightful about the necessary elements for success in converting to an open source business model: ensuring that your software architecture is “modular” and creating a developer community. The creation of a developer community is a significant challenge for a new product and quite different from the skills required for developing and distributing proprietary software. He also notes that natural advantages conferred on KMS by its role as the creator of the “platform”. Finally, he focuses on the new reality for all “proprietary” software vendors: they need to be prepared for competitors who adopt an open source model.

Eric Levin makes good points about the importance of being able to control the brand and the strategic life cycle, but concludes that KMS has alternatives to adopting an open source business model such as adding personalization. However, I think that this alternative is an illusion and it seems to contradict his prior points.

The final Case Commentary by Michael Bevilacqua focuses on legal issues and, from his view, the significant additional risk of intellectual property infringement in an open source business model. I don’t agree with his conclusions. First, most “proprietary software” includes significant amounts of open source code which would carry risks similar to a pure open source business model. Second, he notes the increased risk of patent infringement in open source software. I disagree that the risk of patent infringement is greater in open source companies than in proprietary software companies. Most proprietary software companies do not undertake patent searches prior to writing software, so both types of companies are equally at risk of infringing a third party’s patents. However, the open source business model does entail legal risks: the scope of many important open source licenses (such as the GPL) are unclear because they use terms, such as derivative works, which are poorly defined in copyright law when applied to software and the licenses have never been interpreted by courts. In addition, the remedies available under open source licenses, whether injunctive relief or only monetary damages, are not clear. Consequently, many companies limit the use of open source software based on the open source license under which it is provided.