Open source software — where the source code for programs, such as the Linux kernel and popular applications provided by Red Hat and similar software companies is freely available — has become a major and fast-growing presence in recent years. New research suggests that a key factor in companies’ decisions about whether to create open source software is the market for support, integration, and related services for the programs.
In many cases, the real money lies not in selling the original software, but in the services associated with helping customers integrate such products and maximize the value derived from their use. Both small and large companies providing open source products and related services are engaged in a delicate dance in which they are at times in symbiotic cooperation, and at other times in heated competition.
In a recent paper, Tunay Tunca, associate professor of Operations, Information, and Technology at Stanford GSB, and two co-authors investigate this phenomenon and map out conditions showing when a software firm should consider pursuing an open source licensing strategy.
Tunca and his coauthors, Terrence August, PhD ‘07, and Hyoduk Shin, PhD ‘08, assistant professors at UC San Diego’s Rady School of Management and Northwestern’s Kellogg School of Management, respectively, distinguish between “originators” — those companies that create a piece of software — and “contributors” — those companies who help improve the software through products providing modifications, tools, modules, ancillary applications, and other embellishments. Frequently, both originators and contributors can also provide installation and integration services, as well as maintenance services necessary to keep the software up and running in reliable fashion.
“There’s a competitive ecosystem that exists between originators and contributors of open source products,” says Tunca. In some cases, the software originator assumes the role of primary developer, while subsequent contributors take more minor development roles. Red Hat, for example, leads development and is a big player in the services market for the JBoss Application Server, which is an open source product. In other cases, a smaller organization may originate a software product, but a large outside firm plays a big role and leads toward its development. IBM, for example, has more than 700 developers working on open source software development.
Using mathematical models, the investigators find that the size, capability, and efficiency of software originators, in contrast to contributors to the software, is an important factor in determining whether it makes sense to distribute a product as open source or not. Specifically, the study finds that despite the development benefits strong contributors may bring to the quality of the software, a software company may be hesitant to choose an open source path for a software product when faced with contributors with high efficiency in building expertise and utilizing that expertise to provide higher-quality secondary services.
“A contributor that is really strong in this area could start encroaching on the originator’s market share for those related services,” explains Tunca. “In that case, a firm is better off keeping the software proprietary.”
Another major factor involves the costs associated with creating services to support the open source product, such as software installation, maintenance contracts, and integration processes. Such costs get higher with increased complexity of the software product. An originator firm can be better off releasing products in open source fashion when service costs are relatively high, say Tunca, August, and Shin.
“The originator here gains leverage to differentiate against smaller service providers and get increased market share in the services arena,” Tunca observes. In cases where service costs are high, the public may also benefit when higher service costs induce a major firm to release open source software with a strategic eye toward offering the services itself. The public not only gets free software but also enjoys improved quality of the software as a result of increased development investments.
The researchers also identify the ways originator firms benefit most by structuring their open source licenses. GPL (General Public License) style licenses restrict subsequent developers to make all of their code based on the open source product publicly available. BSD (Berkeley Software Distribution) style licenses, on the other hand, permit contributors to retain the rights to their modifications and improvements.
The study indicates that a less restrictive license (such as BSD) is most advantageous both for the originator and the public welfare if the potential contributors are larger and strong. “Allowing subsequent contributors the option of being proprietary with their own products gives them more incentive to create products and services that enhance the original product,” explains Tunca. “The originator benefits by not having to spend lots of money on developing the initial software — there will be others who come along to improve it. Having an enhanced product is also good for the general public.”
On the other hand, when the originator is better equipped to compete in the services market, a more restrictive (e.g., GPL style) license, coupled with increased development investment, can be a better strategy for a software originator who decides to go open source. “A higher originator investment in software helps subsequent developers, and could coax them to contribute while the originator reaps the benefits from those contributions more effectively. It can result in a win-win,” Tunca observes.
As the study concludes, robust economic structures and instruments by which open source developers can turn their efforts into revenues have just begun to emerge. “Continued formal analysis and research is needed to build an understanding of the developing underlying complex structures,” says Tunca. For now, it’s apparent that being generous with software you create can indeed — in some cases at least — pay dividends.
