Free and open source software (F/OSS) is emerging as a promising alternative to proprietary software. The interest in F/OSS solutions is growing as firms realize that it could help reduce IT expenditures. Unfortunately, despite the heightened interest, F/OSS solutions remain misunderstood, and a number of myths regarding this approach still prevail.
F/OSS has been described as simply software, or even software specific for the Linux operating system, with hardly any reliable support available. Some have considered it a silver bullet solution that will always create superior quality software at lower or no cost (Wheatley, 2004).
The purpose of this article is to demystify these misconceptions surrounding F/OSS and provide an understanding of its basic concepts. Then, based on these concepts, we try to illustrate how companies can benefit from F/OSS. Our hope is that this article would assist interested observers to better understand F/OSS and help managers make more informed decisions regarding F/OSS solutions.
When computers first originated, the norm in most academic and corporate labs was to freely exchange programs and ideas between programmers. This was the early form of F/OSS. This norm changed when IBM unbundled its software and hardware in the 1970s. This move created a market and value for software. In order to preserve this newly found software value, software producers restricted user access to human readable source code in order to protect software secrets (Glass, 2004). This meant that users could not modify the software that they owned and more importantly, restricted the free flow of ideas. This did not fit well with many programmers, most notable was Richard Stallman from MIT's Artificial Intelligence Lab. Stallman believed strongly in the freedom of the user to use his software and created the Free Software Foundation (FSF) in 1985 to promote the development and use of free software. The following success of projects using the free software development model, such as Apache and Linux, inspired Eric Raymond to write his seminal piece The Cathedral and the Bazaar in 1997 that brought the attention of the corporate world to the free software development model (Raymond, 1999a). In a brain storming session on February 3, 1998 Todd Anderson, Christine Peterson (of the Foresight Institute), John “maddog” Hall and Larry Augustin (both of Linux International), Sam Ockman (of the Silicon Valley Linux User's Group), and Eric Raymond, agreed on the need for a marketing campaign to win the support of fortune 500 companies to ensure the long-term survival of the movement. The participants saw the need to use a term other than “free” which they figured would hurt the movement's chances of gaining support from the corporate world because of its ambiguous meaning. As a result of this session, the term open-source was coined by Christine Peterson and the Open Source Initiative Organization (OSI) was established (“History of the OSI,” n.d.).
Richard Stallman of the FSF opposed this movement because in his opinion the term open-source was not pure enough. So the FSF and OSI remained separate movements promoting similar practical principles, but with different philosophies and beliefs. FSF decided to be vocal about its beliefs and maintained the free software label. They believed that the user's “freedom” is a priority, an end of itself, and they should be able to do whatever they want with their software. OSI on the other hand did not explicitly express the user's right for software freedom, but promoted it as a means of producing better software. The end is to get the corporate world to buy into this concept. Because of the coexistence of both philosophies, we refer to the group of software that adheres to the OSI or FSF principles as free and open source software (F/OSS).1
The F/OSS development system can be conceptualized as an input-process-output (IPO) system, with the license as the boundary, the community as the input provider, the F/OSS development methodologies as the process, and the software as the output (see Figure 1). So we would expect that all four components to have implications on the quality of the final product (software).
The F/OSS license acts as the boundary that identifies the system as an F/OSS system. It specifies the terms by which the software is to be used and distributed. It serves as a governing mechanism that enforces the norms of the F/OSS community and provides motivation for programmers by protecting their efforts from appropriation (Bonaccorsi & Rossi, 2003).
There are numerous F/OSS licenses available that all maintain the openness and free redistribution of the source code.2 The difference between the licenses reflects the philosophical differences between the FSF and OSI on how to advance the F/OSS projects. There are two principles that observers should be aware of (Lee, 1999):
The copyleft principle: Software derived/revised from original F/OSS source code must remain F/OSS, and privatization of any part or whole of the program is prohibited.
The GPL compatibility principle:3 Licensed F/OSS cannot be mixed with proprietary source code.
Both the FSF and OSI have very similar criteria in qualifying licenses and there is a great deal of overlap between the approved licenses of both organizations. The fundamental difference between the two lies in the underlying philosophy. FSF recommends more open licenses that enforce both the GPL compatibility and copyleft principles, while the OSI is less stringent on this matter. Generally, an F/OSS license must allow programmers to access, modify, and redistribute the source code. F/OSS licenses do not prevent a software producer from demanding a distribution fee for his product. F/OSS licenses however prevent the software producer from placing restrictions on how the software should be used or redistributed after it is in the hands of the users (“Selling Free Software,” n.d.).
The community consists of all the developers and users of the F/OSS. The community and all their contributions are conceptualized as the input to the IPO system, which includes source code, documentation, and feedback (i.e., bug reports, support requests, and feature requests) (Raymond, 1999b).
The growth of the community ensures the ongoing survival of the F/OSS project and further improvement of the product. The advancement of the projects and community is dependent on the members who have the motivation and the ability to contribute. The most active of the community contributors are known as the core. The core is responsible for the majority of source code development. They also have the most control over the features and design of the software product. Occasional source code contributors are known as co-developers. They contribute by modifying or reviewing code or submitting bug fixes in addition to feedback. But the majority of the community members are the users who do not contribute with code submissions. Depending on the level of feedback, users can be active by providing some feedback, or passive, by providing none (Crowston & Howison, 2005).
F/OSS development communities do not seem to adopt or practice traditional software development processes (e.g., the waterfall model). Many F/OSS projects begin with a prototype with predefined requirements developed from scratch or based on existent older product (Scacchi, 2002). Then, this early version incrementally evolves through rapid development iterations from the community, while concurrently managing as many designing, building, and testing activities as possible. Five main steps were identified for this approach: (1) code submission, (2) peer review, (3) precommit test, (4) development release and parallel debugging, and (5) production release (Jorgensen, 2001).
The F/OSS development process is an iterative process with feedback loops in every stage. The source code is constantly updated to meet the dynamic requirements that change along with the needs of the users (see Figure 2). These requirements are updated based on user feedback.
A continuous output of the F/OSS system is the software, which demonstrates some unique benefits when compared to proprietary software, such as:
Reliability: The reliability of F/OSS can be best reflected in Linus' Law, “Given enough eyeballs, all bugs are shallow.” (Raymond, 1999b, p. 41). Due to a virtually unlimited number of contributors, software bugs are more likely to get uncovered. Short feedback and revision cycles also mean that improvements are incorporated quickly (Williams, Clegg, & Dulaney, 2005).
Security: In a similar vein, community access to the source code makes it more likely to uncover and solve security problems. In contrast, securing the software by restricting access to the source code will only create a false sense of security, as it might take extended periods of time to locate and fix security holes (Raymond, 1999b).
Low Cost: Software operation costs are drastically reduced due to the elimination of multiple licensing fees and the availability of support and updates from the community. However, when considering the total cost of ownership (TCO), training and customizing cost should also be accounted, which may vary by company (Stevenson, 2005).
All four components of F/OSS will have different implications on the quality of the software. The development process and community have a direct impact on the quality of the software. A large community will be worthless if the members are not motivated to contribute source code and feedback to the development process. The restrictions of the license will mean that only those who can accept these restrictions can contribute—essentially affecting the level and quality of contributions. Even the software design will have an effect on not only the quality of the software, but also how the community will organize around it (Crowston, Annabi, & Heckman, 2004).
With a better understanding of F/OSS, we now discuss how companies can maximize the benefits gained from F/OSS depending on their specific needs. We have identified three distinct approaches centered on three components: software, community, and license. With these approaches on a rough continuum, companies can choose to have no involvement in the community or to be part of the F/OSS community core. Regardless of approach chosen, all four components of the F/OSS system should be evaluated (AlMarzouq, Zheng, Rong, & Grover, 2005).
The software-centered approach is about the autonomous use of the final product of the system (software). The software could be directly obtained from the community or provided by a vendor (who is usually part of the F/OSS community). It is most appropriate for companies with static and clear requirements that need well-developed software with a strict budget or time line. It focuses on utilizing the product and follows the same selection criteria as proprietary software.
In addition to reduction in time and costs in obtaining the desired software, companies can enjoy the improved reliability and security of F/OSS. However, less involvement and less input mean that the companies would have no influence on the features of the software. As passive users, companies have to accept the restrictions set up by the software and license.
Technical support or minor customization requirements also posit potential concern. Since technical support for F/OSS is dependent on the community, the evaluation should include an assessment of how responsive and supportive the community is or the availability of support vendors.
For the community-centered approach, the companies become more involved into the F/OSS community, and therefore are entitled to some influence on the features of the software. It is more suited when the desired software product or the requirements of the company are evolving.
The companies could get involved through this approach in two ways depending on the capabilities of the company. They can either be active users providing feedback and feature requests on the product. Or they can, as co-developer, further contribute by providing source code contributions that would help enhance the software and make it more suitable for their use.
Becoming a co-developer has its benefits over being an active user. By participating in the development process, companies can improve the software development skills of their employees as the training process is embedded into the participation process (Lussier, 2004). Such valuable learning experience could enhance a companies' technical capability and facilitate the in-house application or customization of the software or even build competencies associated with the software that can be leveraged so the company could act as a support vendor for the F/OSS. The challenge with this approach is that companies have to devote more time and effort and possess certain technical capabilities to be able to act as an active player or co-developer in the community. Meanwhile, as players but not initiators, they still have to follow the restrictions of the licenses. Furthermore, the desired level of control over the software is not guaranteed since the company is part of a community. A potential challenge specific to becoming a co-developer with this approach is that in some cases companies have to adjust their own routines and structures to fit in the F/OSS development process. Such adaptation might introduce further costs and conflict within the company.
The idea from this approach is to initiate an F/OSS community. As a result, the initiator has control over the choice of the terms of the license and becomes part of the core of the community, hence the term license-centered. An initiator can either release existing code, or embark on creating the initial prototype of the F/OSS.
Since users of the software can potentially be active members and developers within the F/OSS community, the initiating company can tighten the relationship with its customers should they get involved with the community. The customers can then be leveraged as a resource for innovative ideas, feedback, and developmental assistance to improve user satisfaction and prolong the product life cycle (Scacchi, 2004). This approach is most suited for companies seeking to improve their competitive position, especially with the existence of network effects working against the company. But given the long-term nature of the community building process, the benefits from this approach will be realized in the long run (West, 2003).
The biggest issue with having a company release software as F/OSS is that it might relinquish any competitive advantage associated with the software as the secrets of the software can be easily obtained by competitors. One solution is to “open parts,” which is to release commoditized layers that are not a source of competitive advantage and retain full control of the layers that can be a source of competitive advantage. Another solution is to “partly open” the source code through using licenses to put legal restrictions that can provide value for the customer but prevent competitors from using the technology (West, 2003).
The biggest challenge that remains after releasing the software is getting the community to participate. Having the project develop into a self-sustaining one will require foresight from the company that initiated the effort in setting up the control structures and a willingness to hand off that control to the community (West & O'Mahony, 2005). The initiating company has to make a trade-off between its own interest and the growth of the community.
Another challenge is to align the company's internal development process with an F/OSS development process that enables community contributions. This may require some change management on the part of the initiating company.
Overall, the benefits and challenges of the three approaches are summarized in Table 1.
As chief information officers (CIOs) get pressured to further reduce IT expenditures, we expect to see increased adoption and improved understanding of the benefits and utilization of the F/OSS system as a whole. We will not only see the success and influence of F/OSS on infrastructure-type software such as operating systems and database system (e.g., Linux and MySQL), but more complex applications. This move has already started with systems such as Compiere which is an F/OSS ERP system.
While research will continue to advance our understanding of the structure, efficacy, and strategic implications of F/OSS, there will clearly be regulatory issues (e.g., software patents) that will need resolution. It will be interesting to see how the change in legal environment will affect the F/OSS movement and whether F/OSS licenses can be effectively enforced.
Given the increasing pervasiveness of F/OSS, it is important that business managers evaluate alternatives to proprietary software and explore potential opportunities F/OSS may bring to their business. In doing this, they should understand and evaluate all the components of F/OSS that will impact the quality of the software. F/OSS is not software that is specific to an operating system, nor is it simply just software, but it is a complete system that includes the license, the community, the development process, in addition to the software.
Level of involvement in the community
Low to medium
Cost saving has been the main driver for F/OSS adoption, but even these savings might not be realized when the total cost of ownership is factored in. However, managers can maximize the benefits they could gain from F/OSS should they understand the whole system and learn to leverage all of its components. We have identified three different approaches companies could use to benefit from F/OSS. In addition to software cost saving, these different approaches (summarized in Table 1) could reduce development costs, increase innovation, improve technical training, and improve competitive position. Each approach provides a different set of benefits and challenges.
1 For more information on understanding the difference between OSI and FSF please refer to: OSI perspective: http://opensource.org/advocacy/free-notfree.php FSF perspective: http://www.fsf.org/licensing/essays/free-software-for-freedom.html
2For a comprehensive list, please visit: OSI approved licenses: http://www.opensource.org/licenses/FSF approved licenses: http://www.fsf.org/licensing/licenses/index_html
3The “GPL compatibility” name is used by the FSF, please see http://www.fsf.org/licensing/licenses
Adding manpower to a late software project makes it later.Copyleft:
The copyleft principle prevents the privatization of the whole or parts of the software that has a license that implements this principle.Free Software:
Software is considered free software if the user has the freedom to run, copy, distribute, study, change and improve the software (“The Free Software Definition,” n.d.).General Public License (GPL):
GNU General Public License is a license developed by Richard Stallman to ensure that the GNU system remained free. It employs the copyleft principle and prevents mixing with proprietary source code (GPL Compatibility) (O'Mahony, 2003).GNU:
A recursive acronym that stands for GNU is Not Unix. It is a UNIX compatible operating system.Open Source Software:
Software that complies with the criteria set forth by the OSI which can be found at http://www.opensource.org/docs/definition.php
Related Credo Articles
Open source software development (OSSD) is a community-oriented, network-centric approach to building complex software systems. What are the...
The open source movement has emerged during the past two decades as a powerful enabler for change in relation to software in particular and...
Software that comes with permission for users to have access to the software source codes. ‘Open’ in this context does not necessarily mean free...