Business Models for Open Source Hardware Design

Version 1.0. Copyright 2000, Gregory M. Pomerantz.


1. Summary

The concept of open source hardware has the potential to solve many of the problems currently facing the semiconductor industry. Commodity electronic components and implementations of industry standard protocols may be more efficiently designed and distributed in an open source fashion. Furthermore, the widely heralded system-on-chip revolution will require the "commoditization" of semiconductor intellectual property, which may in many cases be more efficiently produced in a open source model. This paper will explore those ideas and propose possible business situations in which the open source hardware model could be successful.

2. Introduction

Increasing integration is putting pressure on commodity semiconductor component markets by forcing devices to become more complex, more expensive to design, and consequently more dependent on the development of intellectual property. The so-called "system on chip" revolution will fail unless commodity component manufacturers can easily integrate IP they did not themselves create. An efficient intellectual property sharing system will have the benefit of preventing needless duplication of design effort by many competing companies, and will tend to favor the pareto optimal situation where a given piece of intellectual property is re-invented no more often than necessary. The industry recognizes these facts, and efforts are underway to formalize systems whereby manufactures can more easily license IP from one another, or from specialized IP producing firms [n1]. These efforts are necessary, but they have so far been largely neglecting an intellectual property sharing system that has proven to be quite successful in other domains -- that is, giving it away [n2].

Today, semiconductor design is conducted in a way not unlike the engineering of a large scale, mission critical software system. In order to develop a complex application specific integrated circuit (ASIC), the design is first coded in a hardware description language (HDL) such as VHDL or Verilog, based on a detailed set of implementation specifications, which are themselves based on a set of functional requirements developed by a marketing group. Once written and validated, the HDL source code is synthesized to a netlist describing the interconnection of logic gates that will appear on the silicon. Each logic gate in the netlist will map directly to a specific configuration of transistors. The netlist is loaded into another tool which chooses a physical position that each transistor and wire will occupy on the chip. The resulting physical design translates directly into the optical masks which are used to pattern circuits during the manufacturing process. The steps of synthesis, placement, and routing are roughly analogous to the compilation of a piece of software source code [n3].

Closed source information production in the semiconductor industry is not economically efficient. Right now, for any given engineering problem, there are dozens if not hundreds of teams working simultaneously, but in mutual secrecy, towards its solution. The semiconductor industry is engaged in a ridiculous game of concurrent wheel re-invention. Open source concepts can solve this pareto inefficiency for a large class of problems.

3. IP Sharing in Hardware and Software -- The Case for Open Interfaces

I will assume the reader is familiar with open source software development, and the enormous successes of the Apache server, the Linux kernel, and the various GNU projects [n4]. The counterintuitive theory is that some types of software may be developed more quickly, with higher quality, and at lower cost, by making its source code freely available, and by requiring that improvements to that software also be freely available. Experience shows that this model can work extremely well. This is no doubt partly due to the fact that it takes advantage of the peculiar nature of information as an economic entity (non-rivalry and non-excludability), while solving a significant cause of inefficiency in software markets, namely lack of transparency [n5].

My definition of open source hardware is based roughly on the Open Source Definition (OSD) written originally by Bruce Perens [n6]. A hardware design would be considered open source if its HDL source code was distributed with a license that 1) granted permission to freely distribute the source code and any hardware device based on it [n7], and 2) granted the right to create derivative works based on the source code and distribute them under the same license. An additional provision, inspired by the Gnu General Public License (GPL), would require that a special subset of the derivative works created must be available under the original license [n8].

Code sharing is nothing new in the software world, just as it was nothing new in the academic research communities out of which the field of computer science was born. Nor is the sharing of intellectual property a new idea in the hardware world. The most obvious cases in which intellectual property is shared between electronic component manufacturers are found in the development of chip to chip interfaces. A complete lack of standardization in this area would have forced single manufacturers to produce all of the necessary components required to build any given system that a customer wished to design. If a customer envisioned a system that could not be produced with components that were all manufactured by the same company, they would be out of luck. This is obviously not the way things turned out, and it is clearly a more economically efficient result to have interoperable hardware components which keep costs down and allow customers to devise innovative products.

Today, even complex, high performance hardware interfaces are regularly shared between hardware manufacturers. Bodies such as the National Committee on Information Technology Standards (www.ncits.org) develop open standards for use by many participants in the computer industry. Samual H. Fuller of Digital Equipment Corporation summed up part of the motivation for this: "Standards developed in NCITS committees [...] are increasingly critical to DIGITAL's systems business now that we've moved to a business model of buying commodity storage components and adding value rather than making the components ourselves" [n9]. Digital's strategy is indicative of an overwhelming trend in the computing industry which has been going on since before the invention of the PC. Companies increasingly realize that they can succeed by integrating commodity components and technologies, and adding value to their product line in other ways. Indeed, commodity technology often tends to advance more quickly than proprietary technology, eventually becoming both better and cheaper [n10]. The best recent example of the move from proprietary to commodity technology is in fact the widespread adoption of the open source Linux operating system [n11]

When an interface is open and commoditized, the core logic required to implement that interface should also be open and commoditized. All of the arguments in favor of open interfaces weigh equally well in favor of open implementations of interfaces. Concurrent wheel re-invention results when competing engineering teams work in secret to implement the same open interface when the interface was open in the first place for the specific purpose that the resultant products may interoperate.

4. Strategies for Commodity Producers

Once a product becomes a commodity, it becomes functionally interchangeable with competitive products, and a manufacturer may no longer rely on the value of its intellectual property in its basic design (but see note 1, since intellectual property in the product's physical design may remain very important). In order to stay profitable, commodity manufacturers must attempt to reduce cost, increase price, increase volume, or de-commoditize. If open source design can reduce development costs while increasing quality, then the first three strategies may be advanced by increased sharing of intellectual property, while only the fourth strategy relies on ownership and control. Besides, efforts to control standards can easily backfire [n12].

Two recent examples in the hardware space of the de-commoditization of interfaces are Intel's P6 microprocessor bus and the Rambus memory interface. The P6 bus is used by Intel Pentium Pro, Pentium II, and Pentium III processors to connect to a component called a chipset, which in turn controls access to the systems memory, IO, and graphics systems. Today, the vast majority of computer systems use commodity memory components which connect to the chipset using an industry standard, open protocol. The Rambus interface, on the other hand, is a proprietary, patent protected chipset to DRAM interface that cannot be implemented by a chip designer without paying royalties to Rambus. The proprietary nature of Intel's P6 bus tends to de-commoditize the markets for Intel compatible processors and for PC chipsets [n13]. The Rambus interface attempts to de-commoditize the memory industry. DRAM manufacturers have been working very hard to devise an open alternative to Rambus which will allow them to continue to sell their products without the overhead of royalty payments, and without loss of control over a key technology [n14].

The distinctions between Intel's P6 bus and the Rambus interface are instructive. Rambus Inc. has invested $100 million over the past 10 years in an effort to design a high performance DRAM interface. Rambus has no product other than its intellectual property. That product is proprietary because it must be in order for them to recoup their investment -- their chosen business model requires it [n15]. However, it is difficult to determine if the DRAM industry, working cooperatively, could have more efficiently solved the engineering problem that Rambus attempted to solve. This is a complicated question that is far beyond the scope of this paper. The point of the example is that open source is not compatible with all business models (even though some business models incompatible with open source may prove to be inefficient).

When designing the Pentium Pro, Intel knew that the bus it had been using for its Pentium processors was insufficient technology to fulfill the requirements of the new processor. In order to maintain its position as a CPU supplier, Intel needed to design a new bus in order to realize the potential of the P6 CPU core. The interface design was a necessary enabling technology of the Pentium Pro, and was a required investment even though the bus was not intended to be a product in its own right. The P6 bus would have been designed even if it could not be protected by intellectual property law. Today Intel's control of the P6 bus serves them only as a means of exercising control over the PC platform, and as a means to increase the cost of competition for its competitors [n16]. However, if Intel's efforts to de-commoditize the PC are successful, the resulting inefficiencies may provide other advantages to Intel's competitors, because Intel may begin to lose the price/performance advantage that it has enjoyed.

5. Economic Motivations

Several factors may motivate a shift towards open source hardware development. First, as already mentioned, open chip to chip interfaces should always have open source implementations. This concept is often put into practice in the software world by the Internet Engineering Task Force. The standardization process for a proposed internet protocol is customarily accompanied by an open source "reference implementation" [n17]. Hardware standardization bodies could benefit by embracing this practice, because it promotes both rapid and high quality implementations of standards. The benefits of providing a reference implementation are significant, but there are many other reasons why open source hardware design could be successful. I have already mentioned the economic waste involved when multiple closed design teams implement the same interface. However, in order for one company to initially release its own implementation to the open source community, the costs and benefits to that company must be in favor of them doing so. Assume that the open sourcing company did not develop its intellectual property with the intent to sell it, but rather in order to integrate it into a product or service from which it can derive revenue and recoup its development costs. What follows is a very sketchy hand-waving economic analysis of the situation.

There are three types of costs involved for our hypothetical company in releasing its design as open source: 1) existing competitors may improve their own designs by looking at the code, 2) competitors who do not yet have designs ready for the market may shorten their design cycle and save costs, and 3) new competitors who may not have had the resources to compete may now be able to enter the market. As interfaces and designs become commoditized, market efficiency will increase and all of these costs will approach zero. Interestingly, the use of a GNU style open source license, which requires the publication of derivative works, means that none of the aforementioned costs can occur without a corresponding benefit to the open sourcing company. This is so because the value of the design, once open sourced, increases as the number of co-developers increases, and no competitor may benefit significantly from the design without becoming a co-developer. Furthermore, additional benefits will accrue "for free" when code is adopted by companies that can use the code but are not competitors with the open sourcing company. For example, 3Com's network interface card business would not be harmed if the PCI interface logic for one of their products was adopted by a manufacturer of digital video capture boards. 3Com only competes with a tiny subset of all companies that need to implement the PCI interface. In other words, in the set of all potential co-developers, the vast majority do not compete with 3Com. This kind of situation will be very common when the code in question is an implementation of an open interface, because such interfaces tend to be used in multiple, non-competing products. Compare this situation to the case of Intel's P6 bus. Intel is a manufacturer of both microprocessors and chipsets, which are the only two components that will ever need to implement the P6 bus. If Intel open-sourced this design, they would have no non-competing co-developers. An open source strategy here might make sense for other reasons, or might simply be inappropriate. Balancing the costs of an open source strategy versus the benefits from acquiring competing and non-competing co-developers, it is clear that there must be many business situations in which an open source hardware strategy makes sense.

Another possible business model that could benefit from open source is third party development. A design could be built from the ground up as open source by a design firm working under contract from one or more chip manufacturers. Third party chip makers who have an interest in the product but were not privy to the original contract would have incentives to contribute additional funds in order to speed development or influence the specifications of the product. In addition, companies that do not wish to fund the design, but who nevertheless have an interest in the product under development, would have incentives to donate engineering resources to the project. This style of design would encourage the development of generic and customizable cores that could serve multiple purposes for many different users. Furthermore, the design firm would be in the best position to leverage code reuse methodologies in order to reduce its engineering costs. Lastly, although the source code to a completed design would be freely available, the design firm could generate significant revenue from support contracts. This support model has been very successful for Cygnus Solutions, which generates its revenue by providing commercial support for open source software development tools [n18]. The suppliers of electronic design automation tools may be particularly well positioned to take advantage of this opportunity, since an open source hardware design could become a powerful revenue driver for their core software business.

6. The System On Chip dilemma

Creative products are more easily designed when high quality building block components can be easily acquired and glued together into a system. For decades, those building blocks have been individual, general purpose chips supplied by commodity markets. Increasing integration renders this arrangement inefficient. For example, state of the art technology may permit a given system to be implemented in a single chip. However, if no single commodity component is available which is capable of implementing the system, a designer may be forced to build and market a more costly system comprised of multiple components. The solution to this dilemma is to allow the system designer to purchase intellectual property components that can be integrated into a single chip, a so-called "system on a chip." Unfortunately, such a market in intellectual property would exhibit all of the traditional inefficiencies in a market for software, though probably to a far greater extent. [n19].

Open source hardware design can solve many of these problems. Open source is known to promote uniform, high quality standards, while competitive design can often fragment standards as companies vie for control (see Java-Script for an example of a software platform that was demolished by competition). An open source hardware development model would help establish a standard design automation tool chain and would strongly influence EDA tool vendors to work towards compatibility. Participants in IP markets often employ means of encryption and access control designed to limit a licensee's access to the intellectual property. These measures impose transaction costs and raise prices for consumers [n20]. Also, they further reduce transparency in a market that already suffers from a lack of transparency. An open source strategy eliminates many legal issues that give rise to transaction costs, eliminates the need for cumbersome access control measures, and achieves the highest level of transparency possible in an intellectual property market [n21].

Notes

n1. See for example www.rapid.org.

n2. Although David Kessner has suggested that an open source hardware development model may solve the problems caused by system on chip design. See "Open-source IP could ignite system-on-chip era," EE Times, January 31, 2000. Kessner is the founder of the Free-IP project (www.free-ip.com).

n3. The placement and routing steps often involve significant human intervention, and the netlist is "linked" to a design library which is almost always proprietary and specific to a particular manufacturing process. Therefore the final physical design of a chip typically contains more intellectual property than is represented in the HDL source code. This is one of the reasons why physical designs in an open source hardware context should be treated differently from the way compiled binaries are treated in an open source software context.

n4. See www.apache.org, www.linux.org, and www.gnu.org.

n5. J. Bradford DeLong and A. Michael Froomkin, "Speculative Microeconomics for Tomorrow's Economy," First Monday, Volume 5, Number 2, February 7, 2000.

n6. Bruce Perens, "The Open Source Definition," 1997.

n7. This term differs subtly but significantly from the OSD, which splits free distribution generally and source code availability into two separate requirements. In the software world, free distribution of source code is indistinguishable from free distribution of compiled binaries, given that the recipient of the source code will practically always have access to a free compiler. Any license that required free distribution of hardware devices, on the other hand, would be ludicrous, given the non-zero cost of copying a physical hardware device.

n8. The GPL can be found at www.gnu.org/copyleft/gpl.html. It requires that all derivative works be available under the original license. That provision would impede the adoption of open source hardware if the physical design of a chip were treated as a derivative work.

n9. " Testimonial from Digital Equipment Corporation on open standards," from the NCITS web page, November 1997.

n10. For example, Intel microprocessors are developed in a competitive and high volume market. Because of the availability of alternative suppliers of Intel compatible microprocessors and the presence of multiple competing companies providing software compatible Intel based systems, an Intel microprocessor is more like a commodity than any of its direct competitors. Partly because of this, Intel has been able to achieve a price-performance ratio superior to the high-end, proprietary microprocessors that used to dominate the server market. "Intel has gone from almost zero four years ago to about 80% today because of its 'price-performance value.'" "Intel's latest Pentium IIIs alter server landscape,"Computerworld Online News, October 25, 1999. Computer manufacturers such as SGI and HP are increasingly adopting Intel microprocessors instead of their own designs. "Leading System Vendors Show Prototype Itanium Processor-Based Solutions at Intel Developer Forum," Intel Corporation press release, February 14, 2000. Furthermore, even high-end proprietary computer systems often use the same RAM and disk components as desktop PCs, and the freely available PCI bus has largely eliminated competing interface standards for many applications.

n11. See, for example, "Amerada Hess Chooses Red Hat for Supercomputing Cluster," Red Hat, Inc. press release, January 20, 2000.

n12. For example, in 1998, several major PC manufacturers were unsatisfied with the development of the PCI bus, and successfully usurped control of the specification from Intel. " OEMs call shots on future designs -- Workstation War," Electronic Buyers' News, September 14, 1998. Today, companies are generally suspicious of adopting technologies over which they have no control. This probably accounts for much of the discomfort companies feel with Rambus DRAM.

n13. Intel apparently also has plans to keep the bus for its forthcoming Willamette processor proprietary. "Intel will strictly control 400-Mhz bus," EE Times, February 18, 2000.

n14. See "Rambus insists DRAM alliance needs its participation," Semiconductor Business News, February 15, 2000.

n15. See generally this article about Rambus' patent infringement suit against Hitachi Ltd. "Rambus Sues Hitachi for Patent Infringement," Rambus press release, January 18, 2000.

n16. For example, Intel's suit against Intergraph Corp. http://www.intergraph.com/intel. Intel has also been involved in several suits against competitive chipset maker Via Technologies, including one episode in which Intel filed suit in a U.S. District Court "by accident." "Intel: To Sue is Human," Wired Magazine, May 4, 1999. For a summary of a recent dispute between Intel and Via over licensing of the P6 bus, see "Intel seeks to ban import of Via Chipsets," CNET News.com, January 20, 2000.

n17. Scott Bradner, "The Internet Engineering Task Force," 1999.

n18. Michael Tiemann, "Future of Cygnus Solutions," Open Sources, O'Reilly and Associates, Inc, 1999.

n19. Regarding legal considerations and the difficulty of licensing IP, see Rick Boyd-Merritt, "New Gold Rush," EE Times, May 10, 1999. Regarding the difficulty involved in creating open standards, see Rick Boyd-Merritt, "Spanning the Gulf," EE Times, June 28, 1999.

n20. Circuit City's Divx video format was an ill fated attempt at creating a highly controlled IP market. It was widely hated by consumers because of its inconvenience and high cost. See Lindsey Arent, " Ding-Dong, Divx is Dead," Wired Magazine, June 16, 1999.

n21. One major source of transaction costs is simply the length of time required to close an IP licensing deal. See "Rapid chairman vows to remedy IP licensing lags," EE Times, October 27, 1999.