Navigation

Home

Open Source Software (OSS)

Open Source Software (OSS) are programs whose licenses give users the freedom to run the program for any purpose and to redistribute copies of either the original or modified program without having to pay licensing fees or royalties to anyone. This seemingly simple concept, along with modern collaboration tools and individual motivation has had a profound effect on the business of software. Because the various aspects of OSS are vast and expansive, this paper will focus only on three of the more general and fully researched areas, namely individual motivation, the components of collaboration, and current business models that leverage OSS in a variety of ways.


Individual Motivation

At first blush it may seem odd that a large number of programmers would work without economic reward to build an application only to give the final product away free. This odd behavior however is precisely how OSS was and still is being developed today. The motivation of individuals who participate in the development of OSS has undergone significant research. Lakhani et al 1 found that enjoyment-based intrinsic motivation, or how creative a person feels when working on the project, is the strongest and most pervasive driver of individual motivation. Psychologists have understood that some activities are pursued for the sake of the enjoyment which is derived from just doing them2. This enjoyment has been described as a state of “flow”, in which “enjoyment is maximized, characterized by intense and focused concentration; a merging of action and awareness; confidence in one’s ability; and the enjoyment of the activity itself regardless of the outcome”. Popular accounts of programming attest to the flow state achieved by people engaged in writing software. Thus OSS participants may be seeking flow states by selecting projects that may not be available in their regular jobs. As an alternative explanation to individual motivation, Lerner 3 takes a more simplified economic rationale by arguing that “as long as benefits exceed costs, it makes rational economic sense for a developer to participate in a project”. Benefits in the context of OSS include meeting user needs for particular software, the enjoyment obtained by working on a “cool” project, and career advancement and ego gratification. Whatever the individual motivations, these findings indicate an inherent source of strength within the OSS community. By allowing individuals with multiple motivation types to coexist and collaborate, the OSS community can and does attract a wide range of participants. Individuals can join for their own idiosyncratic reasons, and the OSS community does not have to be overly concerned about matching motivations to incentives. Individual motivations alone are not enough however. Other more pragmatic forces must be at work. For instance the creation of an OSS accounting system is less likely to be more successful than that of a graphics system4. The potential developer pool for the former is much smaller than that for the latter – just because of interest. Paraphrasing Eric Raymond, “The best OSS projects are those that scratch the itch of those who know how to code”5. This says that a large potential user community is not by itself enough to make an open-source project successful. It also requires a large and dedicated developer community. The flipside to this however is that OSS methods work less well for the kinds of things that people wouldn’t make for themselves. Things like GUIs, documentation, and usability testing are historical weaknesses in OSS projects and present potential opportunities and/or new business models for entrepreneurial sprits.


Objects of Collaboration

Although the individual developers play a large part in the success of an OSS project, there are software issues as well. Huge, monolithic software does not lend itself to the OSS model[4, 6, 7]. Both Linus Torvalds and Larry Wall argue part of the success of their creations has also come from technical decisions that have made it easier for others to contribute. Accordingly Linux has succeeded at least in part because it followed good design principles, which allowed it to be extended in ways that were not initially envisioned. Similarly, Larry Wall explains how he created Perl in such a way that its “feature-set could evolve naturally, as human languages evolve, in response to the needs of its users”8. Modularity is necessary in OSS for a number of reasons. Firstly it allows work to be partitioned among the global pool of developers. Also, as projects progress, the learning curve of the rationale behind requirements, design decisions, and so on becomes extremely steep. Thus, to facilitate the recruitment of new contributors, developers need to be able to “reduce their learning focus below the level of the overall project”9. In fact, many successful open-source projects have a modular architecture, which allows not only users to extend the system’s functionality without having to change existing core functionality, but also facilitating project escalation in concert with its community, while allowing an original visionary developer (or team) to retain control over the core product. However, the cognitive challenge in designing a highly modular architecture of autonomous modules with minimal interdependencies is certainly not trivial. In addition common coupling between modules, where modules make references to variables and structures in other modules that are not absolutely necessary also frequently occurs. This alone has the potential to essentially halt all forward progress. Therefore OSS development requires the same sound engineering design principals as propriety software projects10. Not surprisingly the Internet has had a big role in OSS by building up stronger user communities and facilitating access to information. The source code and supporting documentation form the centerpiece of the open source development infrastructure and unfettered access is critical to the success of the project. The availability of development information is also part of how open source projects attract participants and encourage them to contribute. Tools that facilitate this access and collaboration typically go by the moniker CDE – collaborative development environment such as SourceForge.net11. SourceForge.net now hosts large development communities1 that would have previously been fragmented across isolated projects hosted on custom infrastructure. CDEs not only provide the collaboration machinery but also provide a mechanism to advertise individual contributions. Participants are able to indicate to potential employers their superior programming skills and talents by contributing code to projects where their performance can be monitored by any interested observer12, and as mentioned above this a primary driver of individual motivations.


Economic Models

The increased visibility and disruptive potential of OSS has not surprisingly attracted the interest of the entrepreneurial community. As opposed to the traditional software distribution model where users pay for software license with restrictions and no access to the source code, progress and success in OSS is contingent on coders freely revealing their innovations. To economists, free revealing without exclusivity is surprising, because it violates a central tenant of the economic theory of innovation. In this classical view, appropriating returns to innovation requires innovators to keep the knowledge underlying an innovation secret or to protect it by patents or other means13. OSS seems to depart wildly from this model. OSS companies, have had to create new value offers predicated on software as a service, value of software use rather than value of software purchase, and so on. And like every other component of OSS, licensing has shaped the developed business models as well14. Briefly, there are a number of licenses that OSS communities can choose from. Some licenses (e.g. BSD2 and the Apache license3) are relatively permissive, while others (e.g. GPL4) force the user to distribute any changes or improvements if they distribute the software at all. Therefore if a company incorporates GPLed source code in its products, it must make the source code for any product it sells in the marketplace available to any interested party under the terms of the GPL. Generally speaking, the use of GPL reduces the profit potential of companies though other licenses that do not have this stipulation. Depending on the licensing model there may be several economically viable OSS business models. The first model could be thought of as the general category where OSS is bundled with hardware. This was the first model created and can be traced back to the origins OSS15. For instance most organizations that produce embedded systems require some supporting software, which is usually included in the final product. If proprietary software licensing fees are required this would be viewed as an additional expense to the manufacture without a corresponding increase in marketable value. Using OSS in this manner presents an opportunity to reduce overall costs16. Although these predominantly hardware-based businesses can benefit from OSS, software and associated services are the most obvious OSS business models. Generally, these models can be broken into three sometimes-overlapping categories; the distributor model, the software producer model, and the third party service provider model. Revenues from the distributor model are created by either selling CDs to nontechnical users, providing support services to enterprise customers, or selling long-term upgrade agreements with enterprise customers. Companies adopting this model include Red Hat5. The second or software producer model provides revenue opportunity in two ways, one by incorporating the open source into a larger existing product, or two by bundling it with an existing product. To maintain an increased value proposition, organizations built on this model will most likely be required to hide their modifications to the initial OSS. As stated above this is only possible under permissively licensed OSS. There are a large number of organizations benefiting from this model and ironically some being the most vocal opponents. Finally, the mission of third party service providers is if the product you are using meets a broad set of criteria, they will fully support it. Their revenues come sole from the additional service they provide. Organizations that use OSS may find that it is less costly to pay for outside support instead of in-house expertise in the form of addition full-time staff.


Empirical Evidence?

Often the question is asked “is OSS better than proprietary software?” This of course depends on what is meant by better which is not easy to define. In addition, the closed and protective nature of proprietarily software projects, and product vendors that fund misleading research, only further impedes the assessment of valid information. However some researchers have attempted to provide quantitative data with respect to, among other things, Total Cost of Ownership (TCO) of open-source projects as a whole17. Although this is an important objective measure, TCO is predicated on the role of OSS in the business environmental. For instance costs, such as administration costs, upgrade costs, technical support, end-user operation costs, and so on will impact organizations differently. That said, OSS has many strong cost advantages in various categories that, in many cases, will result in its having the smallest TCO. Items such as less to initially acquire, lower upgrade and maintenance costs, fewer (if any) licensing costs/litigation risks, fuller utilization of older hardware, and less ongoing administration can in many cases be much less with respect to propriety software. However OSS is not appropriate in every situation. Circumstances where proprietary software is key to maintaining competitive advantage or differentiation do not lend themselves nicely to OSS. As just stated it is difficult to find an unbiased cost determination however reasonable anecdotal evidence does exists. For example, as reported by C|Net, in 2001 Amazon.com adopted Linux for most of its servers and reduced by 24% ($17 million) the IT expenditure, as reported by the IDG Group18. In August 2002, Verizon Communications, one the biggest telecommunication operator in the USA, replaced the Unix and Windows workstations of its internal developers with systems based on Linux and OpenOffice. The average desktop cost dropped from $20,000 to $3,000 per developer and in the end the company saved $6 million19. And although these few examples are by no means conclusive there are additionally many accounts where OSS has benefited in various ways the organizations in which it was used.


Conclusion

Open licensing, a viable a collaborative framework, and the modular nature and manufacturability of software applications, have proliferated OSS to where even the harshest naysayers have conceded to its success. With greater acceptance by established software companies and the increasing potential for individual gain, OSS seems to have established itself as a potentially viable alternative to proprietary software offerings.< /p>


[1] K. R. Lakhani and R. G. Wolf, "Why hackers do what they do: understanding motivation effort in free/open software projects," Perspectives on Free and Open Source Software, vol. MIT Press, Cambridge, MA, 2005.
[2] M. Csikszentmihalyi, "Flow: The Psychology of Optimal Experience," New York: Harper and Row, 1990.
[3] J. Lerner and J. Tirole, "Some simple economics of open source," Journal of Industrial Economics, vol. 50, pp. 197-234, Jun 2002.
[4] S. A. Hissam, C. B. Weinstock, D. Plakosh, and J. Asundi, "Perspectives on Open Source Software," TECHNICAL REPORT CMU/SEI-2001-TR-019 2001.
[5] E. S. Raymond, "The Cathedral and the Bazaar," O’Reilly Books 1999.
[6] T. O'Reilly, "Lessons from open-source software development." vol. 42: ACM, 1999, pp. 32-37.
[7] J. W. Paulson, G. Succi, and A. Eberlein, "An empirical study of open-source and closed-source software products," Software Engineering, IEEE Transactions on, vol. 30, pp. 246-256, 2004.
[8] B. Behlendorf, S. Bradner, J. Hamerly, K. McKusick, and T. O'Reilly, "Open Sources Voices from the Open Source Revolution," O'Reilly ∓ Associates, Inc, 1999.
[9] J. Feller, B. Fitzgerald, S. A. Hissam, and K. R. Lakhani, "Perspectives on Free and Open Source Software," pp. 93 - 112, 2005.
[10] T. J. Halloran and W. L. Scherlis, "High Quality and Open Source Software Practices," Carnegie Mellon University, 2003.
[11] SourceForge.net, http://sourceforge.net/, 2008.
[12] A. R. Jeffrey, H. Il-Horn, and A. S. Sandra, "Understanding the Motivations, Participation, and Performance of Open Source Software Developers: A Longitudinal Study of the Apache Projects." vol. 52: INFORMS, 2006, pp. 984999.
[13] F. Machlup, "An Economic Review of the Patent System," Study No. 15, Subcomm. Patents, Trademarks and Copyrights of the U.S. Senate Judiciary Comm., pp. 1-2, 20-21, 44-45, 76-80, 1958.
[14] S. Krishnamurthy, "An Analysis of Open Source Business Models," http://faculty.washington.edu/sandeep/d/bazaar.pdf, 2003.
[15] C. Daffara, J. M. González-Barahona, and E. Humenberger, "Free Software / Open Source: Information Society Opportunities for Europe?," http://eu.conecta.it/paper/brief_history_open_source.html, 2000.
[16] LinuxDevices.com, "Embedded Linux Market Survey," http://www.linuxdevices.com/articles/AT8693703925.html, 2004.
[17] D. A. Wheeler, "Why Open Source Software/Free Software (OSS/FS, FLOSS, or FOSS)? Look at the Numbers!," http://www.dwheeler.com/oss_fs_why.html, 2007.
[18] S. Shankland, M. Kane, and R. Lemos, "How Linux saved Amazon millions," CNet News Inc., vol. http://investor.com.com/How+Linux+saved+Amazon+millions/2100-1001_3275155. html, 2001.
[19] S. Shankland, "Verizon switches programmers to Linux," CNet News Inc., vol. http://www.news.com/2100-1001-949913.html, 2002.