Update, 2010-11-05: If you like this blog post, you might also like my artikel on the single-vendor commercial open source business model.
This afternoon, I’ll be presenting my thoughts on the current state of open source business research and future directions at the OpenWorldForum 2010 in Paris. I have summarized these thoughts in this blog entry, and they are aligned with the presentation I’ll be giving. I should add that business research here means academic business strategy and economics research, to the extent that a computer scientist can relate to it, and that most of my research is actually still traditional software engineering research.
INTRODUCTION
To survey the research space, I’m breaking it up along the lines of involved actors or key roles these actors play. I see three main types of actors:
- Producers
- User/customers
- Laborers
Software developers are part of the producers category as long as it is volunteer work; they are part of the laborer category when it comes to non-self-determined work.
PRODUCERS
Let’s first turn to producers, that is, the software developers, vendors, and distributors who make much of open source happen. A simple framework to characterize these producers asks the questions of who, what, how, and why:
- Who: volunteer or corporate (employed) work
- What: commercial or non-commercial software
- How: community owned or proprietary
- Why: out of altruism or for-profit
The “what” dimension tries to capture whether there is significant revenue potential in the software being produced, which typically implies that commercial parties will join the table. In the “why” dimension, “altruistic” is a catch-all for any motivation that is not strictly for profit, for example, fun or altruism.
In theory, most combinations are possible, but in reality we observe three main types of open source software projects and the respective actors behind them:
- traditional open source = {volunteer, *, community, altruism}
- open source distributors = {corporate, commercial, community, for-profit}
- single-vendor open source = {corporate, commercial, proprietary, for-profit}
Traditional Open Source
Traditional open source is the original open source. It is not a business model, however, it is a model of open source software development. Research here mostly addresses questions like those for volunteer motivation, e.g. fun or altruism or Lerner and Tirole’s signaling hypothesis [6] (which has recently been called into question by Bitzer et al. [2]). Also, best practices of open collaboration are active subject of study, given that no single person can enforce particular behavior and that many parties desired at the table are volunteers [12].
Open Source Distributors
A traditional project with commercial potential sooner or later will be picked up by a service company and/or distributor to provide services that allow for efficient operation of the project inside a customer enterprise. Hard economic questions faced by such companies are how much to contribute to the project to keep it moving forward, as well as how much innovation to contribute or potentially keep private for competitive advantage. I’m not aware of any economic models that can handle such multi-player situations. The well-known tragedy of the commons problem plays out here, as do questions of product strategy, for example, forced early revealing of innovation that would preferably have been kept private.
To regulate issues of project governance, collaborative innovation, and intellectual property, most of these projects will eventually move under the umbrella of an open source foundation [8] [10]. Capra and Wasserman call this managed open source [3], I’ve called it second generation community open source [11]. Here, best practices of foundation governance are research topics. This includes practices of project and community management, conflict resolution, intellectual property handling, etc. Also of interest is path dependence, that is the (initial) conditions that let a traditional open source project grow into a successful managed community open source project or that make it fail.
Single-Vendor Open Source
Single-vendor open source firms are software vendors who maintain control over the open source project and extract most of the value using strategies like dual-license or open-core approaches [13] [9]. Given that exerted control typically hinders community growth, one research question is how much control to maintain and how much to relinquish for what form of return from a user community. What exactly are the levers of control?
The best practices of single-vendor open source firms are not well understood and are an active subject of research. Tony Wasserman and I have been conducting interviews to elucidate exactly those best practices that front-running companies in this space are employing. Our goal is to understand the best practices by business function as well as by cross-cutting business processes and how they are superior to traditional closed source vendors. Financial benchmarking is part of this research and our goal is to validate whether long held claims, for example, of lower sales and marketing or lower research and development costs are true.
It is also an open research questions whether traditional software vendors will be able to remain competitive, whether they can adopt open source best practices without becoming single-vendor open source firms, or, if they prefer, how they can transition to an open source business model without losing their shirt.
USER/CUSTOMERS
Existing research work already investigates how open source has made it into user companies [5], though we can still improve our understanding of open source adoption and technology diffusion. For user companies engaged with open source, the question not only becomes whether to use it, but also whether to contribute. Should it spend resources on the project? Should it gather influence and for what benefit?
Open collaborative innovation is a major research topic of how users can innovate to their own and a community’s benefit [1] [4], but of course it also raises questions of competitive gain and loss. From a producer’s perspective, the question becomes what intellectual property practices to put in place and how to set up an open source software project, including its technical architecture, to allow for best possible user innovation.
In recent years, we have seen users not only adopt open source, but actively create and drive projects forward. The traditional organizational form of a consortium allows like-minded user firms to collaborate on and facilitate and finance the development of community open source software. As a variant of the open source foundations discussed earlier, such user consortia need to answer questions of project, community, and intellectual property governance. How open or closed should such a consortium be to its non-members? And also, again, how to make the economic case for participation given the threat of a tragedy of the commons situation?
LABORERS
Open source is commoditizing software [14]. Significant barriers exist to learn a closed source component (license fees, education fees), while little or no barriers exist to learning an open source component. Thus, cheap labor can more effectively compete with high-priced labor, and the usual mechanisms will play out. This is perhaps where public policy research is most likely to become important, as may be national security concerns.
Already today can we observe that a new class of open source software developers, committers to high-profile projects, are appropriating some of the value that the software they are developing is creating [7]. These committers are gaining more independence from employers as their economic value lies increasingly in themselves as an agent of their own interests. Whether this leads to a two-class society of committers and less self-determined laborers remains to be seen and I view it as an interesting labor economics research topic.
INDUSTRY
One of the enjoyable things about open source business research is that theory and practice, that academics and practitioners, can be closely related. I follow the writings of well-known analysts, consultants, journalists, and industry thought leaders like Carlo Daffara, Roberto Gallopini, Matt Aslett of 451 Group as well as the Red Monk analysts and Olliance Group, Glyn Moody, Matt Asay and many more (less frequent) writers. To the aspiring Ph.D. student in search of a topic I recommend to follow them as well.
CONCLUSIONS
Exciting times! I see a lot of business and economics research ahead. As a summary of this blog entry, you can download the OWF 2010 Slide Presentation as a PDF. As mentioned, it is neither complete nor fully consistent but I believe it should serve well as an idea-generating survey for future research.
REFERENCES
[1] Baldwin, C., von Hippel, E. Modeling a Paradigm Shift: From Producer Innovation to User and Open Collaborative Innovation. HBS Working Paper 10-138/MIT Sloan Working Paper 4764-09, 2009.
[2] Bitzer, J., Geishecker, I., Schröder, P. Returns to Open Source Software Engagement: An Empirical Test of the Signaling Hypothesis. Wissenschaftliche Diskussionspapiere V-321-10, University of Oldenburg, 2010.
[3] Capra, E., Wasserman, A. A Framework for Evaluating Managerial Styles in Open Source Projects. In Proceedings of OSS 2008. Springer Verlag, 2008.
[4] Chesbrough, H. Open Innovation. Harvard Business School Press, 2003.
[5] Dedrick J., West, J. Why Firms Adopt Open Source Platforms: A Grounded Theory of Innovation and Standards Adoption. MISQ Workshop on Standards Making, 2003.
[6] Lerner, J, Tirole, J. Some Simple Economics of Open Source. Journal of Industrial Economics, June 2002.
[7] Hann, I. et al. “Why Do Developers Contribute to Open Source Projects?” In Proceedings of Second Open Source Software Workshop, 2002.
[8] O’Mahony, S. Non-Profit Foundations and their Role in Community-Firm Software Collaboration, 2003.
[9] Olson, M. “Dual Licensing.” In Open Sources 2.0, Chapter 5. O’Reilly, 2005.
[10] Riehle, D. “The Economic Case for Open Source Foundations.” IEEE Computer vol. 43, no. 1 (January 2010). Page 86-90.
[11] Riehle, D. “The Economic Motivation of Open Source: Stakeholder Perspectives.” IEEE Computer vol. 40, no. 4 (April 2007). Page 25-32.
[12] Riehle, D., Ellenberger, J., Menahem, T., Mikhailovski, B., Natchetoi, Y., Naveh, B., Odenwald, T. “Open Collaboration within Corporations Using Software Forges.” IEEE Software vol. 26, no. 2 (March/April 2009). Page 52-58.
[13] Riehle, D. “The Commercial Open Source Business Model.” Information Systems and e-Business Management vol. 8, no. 4. Springer Verlag, 2010. Forthcoming.
[14] Riehle, D. “Open Source Developer Careers.” Linux-Tag, 2010.
Leave a Reply