Towards Understanding Deploying Open Source Software:

A Study of Factors That Can Impact the Economics of an Organization.

Abstract

This purpose of this paper is to present the factors that can impact the decision to deploy Open Source Software (OSS) in an organization. Many organizations fail to understand the economics involved in using open-source software and consequently suffer poor results. An explanation of the Open Source Initiative (OSI), and a definition of Free / Libre Open Source Software (F/LOSS) is provided along with a discussion of the benefits and pitfalls of deployment in the context of the value chain. The results conclude that the benefits outweigh the risks and profit/benefit is possible if the economic impact is understood.

Towards Understanding Deploying Open Source Software

Without the technology that runs Information Systems (IS) most organizations would cease to function. The business model of a typical organization is tied to the systems and technology that it uses. Since the advent of e-commerce, and the market for products becoming nearly global, organizations are constantly looking for innovation in technology that will give them a competitive edge. A recent study pointed out that the advantage is temporary as other competing companies will copy or innovate even newer and cheaper technology which creates a perpetual requirement to adapt business processes (Ward and Peppard 2004). Open Source Software (OSS), if properly implemented, can become a key part of the innovation and adaptation of business organizations helping them to maintain a competitive edge.

Background

Ever since Porter (1996) introduced the Value Chain Analysis business concept in Harvard Business Review, consultants have tried to use the subsequent methodology to evaluate the quality of each link in the chain. A value chain is a series of tasks and interrelated activities performed by an organization to produce a product. As this product passes through each activity or “link” in the chain, where it is somehow refined, and the product takes on more value. The final sum of the value of all the refinement activity is more than the value that is created at each step in the chain. One way an organization might improve the quality of the links would be to use OSS in their Information Systems (IS).

There are many advantages to using OSS to improve the value of each link and the relationships between them. How IS is used by a company has a significant influence on the relationships between the activities in a value chain (Porter and Millar, 1985). IS helps a company to create and maintain competitiveness because competitiveness flows from creating value for the customer. The activities that create value for a company, such as purchasing, production and sales, are not independent but rely on each other in the value chain. Porter and Millar (1985), concluded that the proper use of information technology minimizes costs while maximizing value, optimizing value activities, and guaranteeing competitive advantages (p 151). These relationships between activities can be strengthened by good use of IS, and quality OSS to improve competition and create greater value.

The Open Source Initiative

According to the website About the Open Source Initiative (n.d.), The Open Source Initiative (OSI), was incorporated in 1998, and is a non-profit corporation who’s primary purpose is to provide education about Open Source Software (OSS) and to advocate for the benefits of OSS. The OSI also claims they exist to build bridges among the constituents of the open-source community. They further claim that one of their most important activities is to act as a standards body that maintains the definition of OSS. They also hold a trademark called The Open Source Initiative Approved Licensearound which they attempt to build a nexus of trust so that all parties involved can cooperate on the use of OSS.

Definition of F/LOSS

The definition of free/libre open source software (F/LOSS) is often misunderstood. The free part of the definition is about the liberty of use with the product and not about the price. The Free Software Foundation (2010) maintains the following definition:

“Free software” is a matter of liberty, not price. To understand the concept, you should think of “free” as in “free speech,” not as in “free beer.” Free software is a matter of the users’ freedom to run, copy, distribute, study, change and improve the software. More precisely, it means that the program’s users have the four essential freedoms:

• The freedom to run the program, for any purpose (freedom 0). The freedom to study how the program works, and change it to make it do what you wish (freedom 1). Access to the source code is a precondition for this.
  The freedom to redistribute copies so you can help your neighbor (freedom 2).
  The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.

Embracing the Business Model

The decision to deploy OSS in an organization is difficult at best. The idea of embracing the Open Source Initiative (OSI) business model as a business strategy is even more frightening for organization executives. There are dissenting opinions on the value of using OSS from many directions that attempt to sway the decision for many reasons. Some reasons are based on misinformation, others are based in fallacious economic policies and others based in fear. Behlendorf (1999), explained that the OSI model is not for everyone, and it is often implemented incorrectly and then blamed for the failure. In fact, the failure is more often result of a poor understanding of how to embrace the model and deploy OSS than the OSS itself.

All or Nothing?

There are multiple ways to deploy OSS in an organization it is not an all-or-nothing approach. For example a school might decide to deploy open-source office suite, such as Open Office, in place of the commonly used Microsoft Office. Another example might be a commercial company decides to use a module of OSS code to provide functionality in a product or as a value add-on to an existing proprietary product. For example, the company Objectweb had several products that embed OSS components. In the most extreme example, a company might decide to open the source code of one of their products to try and create a competitive advantage and gain market share. One of the most well known examples of this move is the Netscape corporation who opened the source to their web browser Mozilla. Each of the methods of deploying OSS share some economic impact commonalities that need to be considered before making the move to OSS.

The implementation of OSS, if properly understood, can be a reliable asset in the value chain. One of the biggest hurdles to overcome is the idea that the source code, once kept secret and valued as the company profit maker is now opened and shared, even with competitors, to produce a better product. In a recent study showed that if a company decides to open the source code to a product, they will often have greater profit if they have a complimentary product that the OSS application enhances. This allows the company to exploit the benefits of combining the open and closed products (Haruvy, Sethi and Zhou, 2008). In a related study the authors explained that not all code has to be shared, those pieces that differentiate and make the organization competitive can be kept and sold separately (Behlendorf, 1999). Instead allowing the core code to be open and shared allows for innovation that can strengthen and enhance the product and provide new paths for innovation.

The Symbiosis

There is a symbiotic relationship between an organization the chooses to use OSS and the OSI community. When the two work together well, success is likely. In a recent study there were four factors that defined the most successful projects. The findings showed that projects that did well had the following characteristics: (1) a solid core developer group, (2) an active peripheral group in communication, (3) a high level of communication exemplified by a depth of threaded communications and (4) only moderate dependence on the internal community for beta testing. The research finds a direct correlation and predictability in the level of communication and the code development within the project (Vir Singh, Fan, and Tan, 2007). This means that if these qualities are shared between an organization choosing to deploy and use OSS then there is more of a chance for success. There are many examples of companies that have successfully opened their source code and created a symbiotic relationship with the OSI community.

The Mozilla Example

Organizations, even commercial firms, can benefit from opening their source code. One possible benefit is to gain ground against a competitor. In a research study Lerner and Tirole (2005), explained how Netscape in 1998 decided to open the source code of a portion of it’s browser “Mozilla”. At that time Internet Explorer was dominating the browser market and Netscape was only holding a tiny share. The study further showed how the web browser application became more accepted, and by opening this source code, Netscape experienced a market share and profit increase. This means it is possible for an organization to remain commercial, open the source code and make a profit. When the point of the OSI is understood, there is great value in the process.

The Value In Using F/LOSS

About ten years ago OSS was relegated to the role of operating system (Linux) and web server (Apache). Now OSS is firmly in the middle layer providing databases (MySQL, Postgresql) and Email servers (Qmail, Horde) among many other functions. OSS has two very distinct properties: the source code is accessible and the developer has the liberty to modify the code any way they want and redistribute pieces of it or the entire source code (Thomas and Hunt, 2004). This is important, particularly to the OSI community, because access to the source, and the liberty to reuse it, creates the opportunity to use existing software as a launching point to create new products based on new designs. This gives the developer access to high quality source code readily available with a few mouse clicks in a web browser. The liberty to use the code as desired and the availability of the source code removes several boundaries that exist when attempting to reuse code. A developer may choose to use a few lines of code, an entire class or an entire system (Frakes and Terry, 1996). This means the reuse of the source code has several advantages including the ability to break out of a lock in with a specific vendor, produce high quality products, get the product to market quicker, and foster innovation which adds value and increases customer satisfaction.

OSS is developed by many groups, often spread out globally. Most often the initial creation of the software program is done to fulfill a need by a single group of developers at one company or school. This group will release the code to the public before it is completed, usually to help spur further development. Perens (2005) explained that other companies may pick up this code and extend or adapt it to their use. This means new features and functionality can be added or adapted as needed by the organization that chooses to use OSS. The code is often of very high quality and developers are offered incentives to write high quality code.

The Quality of the Code

One common objection to using OSS as part of the IS in an organization’s strategic portfolio is the quality of the source code. Quality, in this instance, is defined as well-designed, well-written, relatively error free and functional. There are two major influences on the quality of open-source code that drive the level of quality in an open-source project. Gacek and Arief (2004), explained that the structure of an OSI development community is based most closely on a meritocracy. The better the quality of the code written, the more merit the developer has within the community. Perens (2005) explained that the developers who modify OSS code have an incentive to write the code well so that their changes get incorporated into the main body of the code. That way they don’t have to spend money to re-integrate their changes into the existing code base every time they want to implement an update. The value of a meritocracy is that a developer has incentive to write quality code and to become a respected member of the community. These incentives help to promote high quality, well written code in the OSS projects.

Some argue that the quality of the OSS code is so good, it is unfair to compare it to proprietary or closed source projects. McConnell (1999), stated that successful OSI projects should not be compared to regular closed source projects and instead should be compared with software development effectiveness as it is achieved by companies on the leading edge using multiple practices to achieve high quality software. This means the quality should be compared based on the methodologies used by the companies to determine if within the methodology, the quality of the code is equal. Golden (2008) commissioned a case study by Coverity, a company that tests software quality, and found that OSS programs averaged half the number of the bugs per thousand lines of code when compared to proprietary programs (p. 36). This study shows the quality of OSS code, when compared to equivalent proprietary programs is superior.

Breaking Vendor Lock-In

One aspect of OSS that can present an opportunity to create a competitive advantage is the ability to modify the source to meet the organization’s business model. A recent study showed that a major strategy used by software vendors is to keep the cost of switching to another product high by implementing proprietary data formats and keeping tight access on the source code (Carillo and Okili, 2008). When an expensive proprietary product is purchased for use in a company, Castelluccio (2008), explained the product often becomes “sticky” or “locked-in” either because management wants to earn a positive return on the investment or because the cost of switching would be excessively high. For example, the data storage format could lack interoperability with other vendor’s software preventing import and export of information. These concerns can also be accompanied by the inability to fix bugs in a timely manor or get the vendor to respond quickly to the organization’s need. Golden (2008) showed one of the primary reasons organizations are adopting OSS is because it includes the source code, the organization is free to strip out unneeded functions and make repairs themselves thus eliminating dependence on the vendor. The study further showed that because no single vendor controls OSS so the organization is free to pick a different provider to support their program. For the organization this means the liberty to make the changes they need, customize the software to fit their business model, which in turn, will help increase value of individual links within the value chain and increase a competitive advantage.

Quicker To Market

Using OSS can provide a competitive advantage especially when it is used in the development of new applications. According to a research study by Ajila and Wu (2007), there is a strong correlation between the ability to get product to market sooner and the adoption of OSS, thus providing economic gains in both productivity and product quality. As long as the source code meets that needs of the project, the implementation of code into a project will shorten the development time. That means by adding OSS to a project the development time can be shortened, the cost to develop decreased and the time to market reduced. These factors can give an organization an advantage and the ability to strengthen the bond in the value chain and thus add value to the product.

Innovation

Innovation is truly a key part of the OSI movement. The ability to reuse existing code and create something new is vital to the success of an organization. Vujovic and Ulhøi (2008), explained that the model known as open innovation, now seen in a global market, allows for greater innovation in product research and development. Companies’ ability to stay competitive is no longer exclusively determined by efficient cost management and marketing capabilities. Rather, it relies increasingly on the continuous development of new and superior products and services in a business environment characterized by growing instability (with regard to consumer preferences and technology development). A recent study found that within a three year period a small core of developers, assisted by a transitory group of less committed developers were able to create several new products using existing OSS from sourceforge. The ability to use the code gave them a measurable advantage in creating applications (David and Rullani, 2008). This means the competitive edge has to come from a wider body of developers and researchers and with such strong competition in a global market, using the OSI model, where innovation happens across a wide community, will help an organization stay competitive.

The Pitfalls

There are many ways to use OSS improperly. When choosing to deploy OSS to increase or create a competitive advantage, there are just as many ways to implement the project improperly as there are to create success. Before an organization decides to incorporate a single line of OSS code into a project, or to open their source to the world, there are some concerns that bear a sober review.

No Reliable Release Schedule

The OSI community does not employ the same controls for release schedules like a commercial application. According to a recent study the level of control exerted on an OSS development project is much lower that a commercial counterpart and thus have a less reliable release schedule. Only the most active and highly used projects, such as Apache, have reliable release schedules (Capra, Francalanci, and Merlo 2006). This means the release schedules are not exact and may not deliver as planned. If an organization is counting on the deployment of a certain OSS project, there is a risk that the project might not deliver what is planned or promised as they do not exert the same type of control of release dates.

The Developer Skill Set

The developers who will implement OSS in an organization do not need special skills, but do need an understanding of OSS and how to reuse source code properly. A recent study showed that while there is no strong statistical significance between OSS reuse skill and experience, and software development economics, there is some statistical correlation pointing to the fact that software reuse experience and skill in general is important when reusing OSS (Ajila and Wu, 2007). That means it is important that the developers engaged in the process have at least a general understanding of code reuse and some familiarity with OSS before attempting to do an integration. Otherwise failure and cost overruns from a lack of preparation are likely.

Ideology Over Pragmatism

Although OSS offers many benefits it does not fit in all situations and a clear pragmatic perspective is required because relying only on the ideology can lead to missing out on possibly better solutions. OSS often makes it’s way into a company through developers who work on projects. Their mindset towards OSS can be ideological and prevent them from considering alternatives. According to a study by Ven and Verelst (2008), if the mindset of the developer is ideological in reference to OSS, their decision will not be pragmatic but instead they will have a strong preference for using OSS, without properly considering proprietary alternatives. Suitability of the OSS solution is sometimes overlooked and in the organization-specific context, and new innovations might be ignored. This means the developers, who are often the decision makers about what products to use might instead use an OSS solution that does not fit as well because they are adverse to considering proprietary solutions or do not properly consider all alternatives and find the best fit.

Maintenance

Another pitfall to deploying OSS within an organization is failure to create the symbiotic relationship with the OSI community. An organization could chose to download, modify and deploy OSS solutions within their value chain to gain a competitive advantage. According to Dahlander (2004), some organizations stop at this point and for a time, enjoy the benefit of using high quality code for free in their primary or secondary value chain activities. This however, is a short sighted plan and only a short term gain is realized as there is still cost associated as problems arise when the need for updates and upgrades appears. The organization may attempt to go back to the project where they acquired the source code only to find the project discontinued or morphed into something different that is far from meeting their needs. The modifications made to the original OSS code should be returned to the community so that they are incorporated into the code base, thus helping to maintain a symbiosis. The maintenance of the OSS code is equally important as the value gained from the low price. This means an organization should take the time to create the relationship with the OSI community and not focus solely on the short term gain realized by inserting free source code into their value chain.

Legal Issues

One important part of using OSS in a product that is distributed outside the organization is to preserve the intellectual property rights of the people who worked hard to create the software. When choosing to reuse OSS or incorporate the code into a product that is distributed outside the organization credit must be given to the original developer and the source code must be made available or the organization would be in violation of the license given with OSS. According to research performed by Walsh and Tibbets (2010), infringing a registered copyright carries with it the risk of statutory damages, injunction against shipping products incorporating the OSS, and possibly other penalties; some may find this a surprising consequence of using “free” software. That means misunderstanding the license that comes with OSS can have detrimental effects upon an organization. Use of the software is provided as long as the organization complies with the terms of the license.

Benefits Outweigh The Risks

The choice of an organization to integrate OSS into the application portfolio is not a simple task. The choice to distribute OSS as part of a product can lead to legal issues if the license assigned to the code is not fully understood. The benefits, though mixed, overall outweigh the risks according to the research offered in this paper. If an organization understands the risks and benefits of deploying OSS, and follows a systematic model for the implementation and reuse of code, there is a good chance they will achieve some economic gain from a shorter development cycle and equally important, a high quality product.

Further Study

A future project to add to this study could be a qualitative study involving several interviews with executives, mangers and developers to provide insight into the intent of each group and help understand how each of the aforementioned factors impacted each group’s decision to participating in an OSS project. Another possible project to add to to this study could be a quantifiable survey of executives, mangers and developers to provide an analysis and predictability of success based on the level of understanding of each of the aforementioned factors that impact the decisions to deploy OSS.

References

About the Open Source Initiative (n.d.). Retrieved from http://www.opensource.org/about

Ajila, S., & Wu, D. (2007). Empirical study of the effects of open source adoption on software development economics. The Journal of Systems and Software, 80(9), 1517-1529. doi:10.1016/j.jss.2007.01.011

Behlendorf, B. (1999) Open source as a business strategy. In Dibona, C., Ockman, S. & Stone, M. (Eds.), Open-sources: Voices from the open source revolution,(pp.149-170). O’Reilly. Retrieved from http://oreilly.com/catalog/opensources/book/brian.html

Capra, E., Francalanci, C., & Merlo, F. (2006). An empirical study on the relationship between software design quality, development effort and governance in open source projects. IEEE Transactions on Software Engineering, 34(6), 765-774. doi:10.1109/TSE.2008.68

Carillo, K., & Okoli, C. (2008). the open source movement: a revolution in software development.Journal of Computer Information Systems, 49(2), 1-9. Retrieved from Business Source Complete Database.

Castelluccio, M. (2008). Enterprise open source adoption. Strategic Finance, 90(5), 57-58. Retrieved from Business Source Complete Database.

Dahlander, L. (2004). Appropriating the commons: Firms in open source software. International Conference on Software Engineering: St. Louis Missouri. doi:10.1145/1083258.1083269

David, P. & Rullani, F. (2008). Dynamics of innovation in an “open source” collaboration environment: Lurking, laboring, and launching FLOSS projects on sourceforge. Industrial and Corporate Change. 17(4), 647-710. doi:10.1093/icc/dtn026

Dornan, A. (2008). The Five Open Source Business Models. Retrieved May 25, 2010, from http://www.informationweek.com.

Frakes, W., & Terry, C. (1996). Software reuse: Metrics and models. ACM Computer Surveys, 28(2), 415-435. doi:10.1145/234528/234531

Free Software Foundation. (2010). The free software definition – gnu project. Retrieved May 25, 2010, from http://www.gnu.org/philosophy/free-sw.html

Gacek, C., & Arief, B. (2004). The many meanings of open source. IEEE Software, 21(1) 1359-1360.doi:10.1109/MS.2004.1259206

Golden, B. (2008). Open source in the enterprise: an o’reilly radar report. O’Reilly Media, Inc. 1st Ed.

Haruvy, E., Sethi, S., & Zhou, J. (2008). Open Source development with a commercial complementary product or service. Production and Operations Management. 17(1), 29-43. Retrieved June 4, 2010, from ABI/INFORM Global. (Document ID: 1477481991).

Lerner, J., & Tirole, J. (2005). The economics of technology sharing: Open source and beyond. Journal of Economic Perspectives, 19(2), 99-120. Retrieved from ProQuest Database.

McConnell, S. (1999). Open source methodology: Ready for prime time? IEEE Software, 16(4), 6-8. Retrieved from Business Source Complete Database.

Perens, B. (2005). The emerging economics of open source software. Retrieved May 11, 2010, fromhttp://perens.com/Articles/Economic.html

Porter, M. (1996). What is strategy? Harvard Business Review, 74(6), 61-78. Retrieved from ProQuest Database.

Porter, M., Millar, V. (1985). How information gives you competitive advantage. Harvard Business Review, 63(4), 149-160. Retrieved from Business Source Complete Database.

Thomas, D., & Hunt, A. (2004). Open source ecosystems. IEEE Software, 21(4), 89-91. doi:10.1109/MS.2004.24

Ven, K., & Verelst, J. (2008). The impact of ideology on the organizational adoption of open source software. Journal of Database Management, 19(2), 58-72. doi:10.1109/MS.2008.73

Vir Singh, P., Fan, M., & Tan, Y. (2007). An empirical investigation of code contribution, communication participation and release strategies in open source software development: A conditional hazard model approach.Journal of Information Systems and Operations Management. Retrieved from the MIT Open-Source database.

Vujovic, S., & Ulhoi, J. P. (2008). Online innovation: The case of open source software development.European Journal of Innovation Management, 11(1), 142-156. doi:1087747

Walsh, E., & Tibbetts, A. (2010). Reassessing the benefits and risks of open source software.Intellectual Property & Technology Law Journal. 22(1), 9-13. Retrieved from the ProQuest Database.

Ward, J., & Peppard, J. (2004). Beyond strategic information systems: Towards an IS capability. Journal of Strategic Information Systems, 13(2), 167-194. Retrieved from ProQuest Database.

Value Creation/Innovation:

Exploring Value Creation Theories

By Russ Wright

Value Creation

Value creation or innovation as defined in the question above, focuses on creating new products and new ideas within the field of software development. There is much debate in the literature over how value is created within software development. Some literature focused primarily on the economy of software development (Boehm, 2003; Boehm & Sullivan, 2000). Others took a more holistic approach and realize that the culture and process have the greatest effect on the ability to innovate (Highsmith & Cockburn, 2002; Karlsson & Ryan, 2002; Little, 2005; Prahalad & Ramaswamy, 2004; Quinn, Baruch, & Zien, 1996). Regardless of the path taken to explain value creation and innovation in software development, the general agreement was that the process needed to change to better fit the challenges and opportunities of a global market. Inasmuch, this paper will explore the value creation theories related to software development and the additional challenge of outsourcing to create innovation.

The purpose of this document is to explore how an organization can create value in the software development process. There is a discussion of the background on value creation within the context of agile software development principles, which contain many ways to innovate. This document also explores the theories of outsourcing software development and how they relate to value creation or innovation within agile development. The conclusion finds that creating value in software development is still a topic up for debate among scholars and that outsourcing can add value but is full of pitfalls.

Value Creation Theories Related To Software Development

Achieving value creation has slowly changed the way software is developed into a set of methodologies loosely called agile software development. Research conducted by Fowler and Highsmith (2001) concluded that the agile development philosophy and methods sought to remove cumbersome and time-consuming barriers to value creation. The authors instead supported a philosophy of software development that focused on the individuals, their interaction, creating working software, collaboration with the customer and quick responses to change. There are several theories of value creation or innovation embedded within the principles of the agile philosophy of software development. Therefore, several of these embedded value creation theories are explored below.

Customer Defined Software Value

One theory of value creation in software development is that customer satisfaction is achieved by delivering software that the customer actually values. According to research by Highsmith and Cockburn (2002), the authors explained that within the agile development methodologies the customer defined value for the project and set the measurement of success. For software to be valuable the customer had to find that the product not only met their needs, but also was usable and useful (Constantine & Lockwood, 1999). In an article on agile methodology, Boehm (2002) explained that generating value in the development process for the customer was achieved by emphasizing customer involvement in the development process over the traditional contract negotiation. Consequently, value creation comes from the ability of the customer to define the measure of success, including usability and usefulness of the product and their involvement in the development process as a team member. Making the customer a member of the team means that the requirements might change, many times and even late in the process.

Requirements Changes

A change in the requirements for an application, even late in the development process allows a customer to build in greater value to the product. The ability to prioritize the customer’s requirements through a cost-value approach produced a win-win result when creating software products (Karlsson & Ryan, 2002). Prahalad and Ramaswamy (2004) explained that changed requirements happened because the customer and development team developed a greater understanding of the customer’s needs. Recent research conducted by Paetsch and Eberlein and Maurer (2003) explained that the ability to adapt to the changing situation in the software development project created more value than prediction of the customer’s requirements. A study by Cao and Ramesh (2008) offered a warning against too much change in requirements leading to project failure because the customer never saw the software product. Thus the ability to change requirements is a positive, yet too much change can prevent a usable product from being delivered.

Quick Delivery

The ability to deliver the software quickly builds value for the customer. According to a recent study by Quinn, Baruch and Zein (1996) quick delivery of the software product made a significant difference in the ability to compete in the global market. Larman (2004) explained that innovation was accomplished when the developers, through an iterative cycle, delivered a working product to the customer, which allowed the customer to see the progress and adjust requirements quickly to the changing market. Yet, Nurer Mahapatra and Magalaraj, (2005) in a recent paper cautioned that organizations who attempted to adapt to agile methods that delivered quickly could fail because they were often unprepared for the radical change in behavior. Therefore, quick delivery of the software product builds value by allowing the customer to adapt and refine the product but also holds a potential for disaster if not managed well. Managers, customers and developers have to work together well to build value.

Collaboration with Managers

The development team and managers must communicate daily to build value in the development process. Cohn and Ford (2003) explained that managers had to adapt to a new style of leadership where they were required to relinquish some of what they perceived as control. The authors posited that traditional development plans which offered specific delivery dates were probably padded and inaccurate and instead needed participation to see that they could deliver the product quicker and with less resources. According to research conducted by Patton (2002) the regular discussions with managers added the benefit of clearing roadblocks and bottlenecks, which would slow down the project and add costs. The managers were also able to see how the product met the customer’s needs. A study conducted by Augustine, Payne, Sencidiver and Woodcock (2005) explained that without the constant communication, managers would often fall back into trying to manage the project using linear approaches as they attempted to gain control of the project, which lead to lost time and possibly project failure. As a result, the constant communication with managers helps create value by not only keeping them informed but also empowering them to clear obstacles that might slow down delivery. Managers can also provide considerable motivation and support to help create value in the software development process.

Motivation and Support

The motivation and support of the management team has a significant impact on the value creation in software development. According to research conducted by Ceschi, Sillitti, Succi and Panfilis (2005) into development project success factors found that team members ranked motivation from management in the form of support and training as among the top key factors for innovation. The study further showed that managers agreed that their support was a significant factor in the success and value creation within the project. A recent study conducted by Asproni (2004) into the benefits of motivation from management in software development teams showed that highly effective teams benefited most and achieved the best results when management provided among other factors, clear elevating goals, a unified commitment to the project and a collaborative climate. The study further explained that this support gave the team members the ability to innovate and build better quality software, often with fewer resources. A research survey conducted by Forward and Lethbridge (2002) found that the management team provided a significant impact on the performance of the development process when they provided the team with the proper tools to improve automation in the development process. The team saw these tools as support and found motivation to perform at a higher level. Inasmuch, support and motivation from management has a reciprocal effect on the development process and the ability of the developers to innovate and create value.

In Person Meetings for Tacit Knowledge Transfer

Value creation can be significantly effected by the ability of team members to meet and share knowledge. Nonaka and Takeuchi (1995) drew on the work of Polyanyi (1966), and explained that tacit knowledge was personal, context specific and difficult to explain. They further explained that this knowledge, gained from experience, can be lost if an individual leaves an organization and does not share it. Likewise the members of a development team, which includes the customer, must meet often to share knowledge to establish the context of the requirements and build new knowledge, which creates value (Dyba & Dingsayr, 2008). Cohn (2004) explained that when teams met to transfer knowledge, the use of stories to explain the requirements helped to build up individual and group knowledge as they shared. The author does warn that this process might not work well in really large teams, but did acknowledge the positive impact of tacit knowledge sharing on innovation. A recent study conducted by Chau, Maurer and Melik (2003) found that knowledge sharing within agile development teams, particularly when done in face-to-face settings helped to build trust among team members and increased the team’s ability to function together. Therefore, sharing of knowledge among team members, especially in face-to-face formats helps build team trust and create value in the development process.

Working Software as Measurement Of Success.

The ability for management to measure the progress of a development project has a significant impact on the ability of the software development team to create value. Boehm and Turner (2005) explained that agile development processes do not include the typical milestones and other measurement techniques common to traditional development methods. They further explained that the completed functional stories could serve as a replacement for these measures as they showed the amount of work completed on a particular development phase. A case study by Fitzgerald, Hartnett and Conboy (2006) demonstrated that the ability of the management team to measure the progress of the team, based on the amount of working code, increased the project performance by reducing the amount of paperwork needed in the previous traditional software development projects. The developers spent less time writing reports and more time on the actual development, which accelerated the development process. In a recent report, Lapham, Williams, Hammons, Burton and Schenker (2010) explained that progress within an agile project was measured by gathering the customer’s value assigned to each completed part of the development project. As these pieces were completed, they were used as a measure of how much the customer valued the product at that time. Thus, the ability of management to measure progress, along with the customer’s assigned value at each phase of development adds value to the project, particularly because it reduces the reporting workload on the development team freeing them to perform more development tasks.

Realistic Schedules

The proper attitude towards development cost and schedule when managing a project will have an impact on the development team’s ability to create value. Glass (2001) explained that successful projects had a realistic schedule that was not a death march to finish the project and the developer worked a normal workweek. Developing innovative products did not require that the software development projects be managed by the schedule or costs, as it would have distracted from the real objective of creating a profitable product that met customer needs and gave a competitive advantage (Poppendieck & Poppendieck, 2003). Likewise, and exploratory study by Begel and Nagappan (2007) explained that one of the benefits of implementing agile software methods was the flexibility of the process which gave the developers the ability to change directions when a rigid schedule would not have worked. So, a tight management of the schedule and costs, as is common in traditional development processes would inhibit value creation because they lacked flexibility.

Technical Excellence

The quality of skill for each member of a development team will have an impact on the value creation ability of an organization. An organizational culture that supported and provided opportunities for growth in skills was desirable because it lead to productivity (Wendorff, 2002). A recent study conducted by Chow and Cao (2008) showed that team capability and delivery strategy ranked highest as critical success factors. Technical excellence also extended to the tools used by the software development team, as good quality tools impacted the ability of the team to innovate (Hanssen & Fægri, 2008). For these reasons, a skilled software development team equipped with the proper tools and supported by opportunities for growth is an important factor for innovation and value creation in software development.

Keep It Simple – Maximize Effort

The design of the software program can impact the ability of the software development team to create value in the development process. In the agile development process, one of the first steps is writing the test for the specific functionality. By writing the test for the code first, the developer would write code to the test and minimize the additional code needed to meet the test requirements and functionality (Poppendieck & Poppendieck, 2003). In a recent paper by Lindstrom and Jeffries (2004) the authors explained that value was achieved by keeping the design as simple as possible so that the design matched the functionality and included no additional wasted motion. They further explained that the design was regularly reviewed to keep effort to the minimum and maximize efficiency. Hence, value creation in software development can be improved by coding only what is required and reviewing the code regularly to increase efficiency.

Team Self-Organization

The ability for a software development team to reorganize themselves into different configurations as the situation dictates can affect the organization’s ability to innovate. Cockburn and Highsmith (2002) explained that the ability of a software team to reorganize as the situation dictated was important for making decisions quickly and dealing with ambiguity. A recent paper by Decker, Ras Rech, Klein and Hoecht (2005) explained that the ability to reorganize as a development team allowed for the reuse of engineering knowledge in new projects. The benefit of knowledge reuse was a key factor in the reasons given for reorganizing the team to fit the new situation. Yet, there is reason to show caution when attempting to use a self-reorganizing team philosophy. A study conducted by Moe, Dingsoyer and Dyba (2008) found that the very specialized skills of certain team members and the uneven division of work among the team presented barriers to realizing a true self-organizing team. Therefore, value creation, in regards to self-organizing teams depends upon the ability of a development team to reorganize quickly to meet new challenges, and the balancing of skills and workload within the team.

Team Reflection

The ability for a development team at regular intervals to reflect upon the entire project can impact the ability of the team to create value. According to research conducted by Salo,Kolehmainen, Kyllönen, Löthman, Salmijärvi and Abrahamsson (2004) the post-iteration workshops provided significant help to improve and optimize practices and enhance the learning and satisfaction of the project team. The authors further explained that the cost of the workshops was quite small, and the benefits quite large. Cockburn (2002) echoed this same idea and explained that the after process reviews were helpful in growing the skill of the team and improving the skill sets of the participants. A review at the end of the development cycle where the participants shared their experiences significantly enhanced the development process (Dingsøyr & Hanssen, 2003). Thus, reflection builds the ability of a software development team to innovate by improving and optimizing the team practices.

Within each of the principles behind agile software development are theories of value creation for a software development team. By allowing the customer to set the measures of success within the product, brings value creation by building trust. The ability to adapt to changing requirements allows the development team to innovate and meet the customer’s needs. Quick and often delivery of a working product, even if it is not complete, builds value for the customer and the development team as they both gain credibility. Constant communication with management helps to build trust in the team and give them the freedom to innovate and create value for the organization. Closely related to this theory is the need for management to be able to measure progress by measuring the completeness of the project. By using the completeness of the project for measure the management is able to see progress and eliminate additional paperwork for the developer, which freed them to write more code. Also related to management was using other measures instead of cost and schedule as they would detract from the real goals of the project. Another way that value is created is through the support of management with proper training and tools, which brings about excellence. The adaptable and self-organizing team, a difficult goal to reach, also brings about value creation by allowing the team to adapt to the fluid situations found in software development. And lastly, one of the important and relatively inexpensive ways that a software development team can create value is by reflecting regularly on the development process and integrating the lessons learned, thus constantly improving the ability to innovate.

Value Creation Theories and Outsourcing Of Software Development

So far the exploration of value creation has focused on software development teams in local settings. The additional factor of distance between the development team and the customer or another development team, or even members of the same team presents some additional factors for innovation as well as failure. A review of the current literature shows much disagreement about the benefits and potential for success when outsourcing the development of software. Some of the theories, both pro and con, related to value creation, agile development and outsourcing are explored below.

Effects on Many Levels

Outsourcing of software development in general creates new opportunities for value creation, but also brings many challenges. A recent paper by Hersleb and Moitra (2002) explained that the separation of the software development team over the globe could add many problems. These problems included how the project manager divided up the work and how they handled resistance to the process. They further added that many cultural issues, including the attitude towards management, perceptions of time and communication styles all contributed to the successful outsourcing of a project. A paper by Agelfalk, Fitzgerald, Holstrom, Lings, Lundell and Conchuir (2005) explained that the process of communicating between team members, coordination of activities and control of the project were all challenged by distance. The authors further explained that only when strong supporting processes were in place could the outsourced project work. Hence, the challenges of distance, communication, culture and command and control in an outsourced software development project must be addressed with strong supporting principles and methodologies, like agile, to support value creation.

Even if an organization uses agile methods, because of the focus of the processes for dealing with ambiguity, change and communication, to create value in an outsource project, there are still many challenges that must be overcome. According to research by Carmel and Agrawal (2002) the authors identified three critical challenges of outsourcing software development as: (1) coordination, (2) control and (3) communication. Coordination was defined as integrating tasks across each unit so they all contribute to the whole. Control was defined as following the goals, policies and standards of the organization. Communication was defined as the exchange of information that is understood by those communicating. Thus, an understanding of how to deal with these three critical challenges is required to achieve value creation when outsourcing. Each of these challenges to outsourcing of software development, within the context of agile development principles, is explored further below.

Coordination

The division of tasks when outsourcing software development can impact the ability of an organization to create value. According to Shrivasta and Date (2010) agile teams that were distributed across too wide of a time zone difference suffered from poor performance as they had little overlapping time to coordinate activities. One possible solution to coordination problems suggested by the research of Carmel, Espinoza and Dubinsky (2010) was handing off the work from one site to the next toward the end of the work day going around the globe in the direction of the sun. The authors admitted that this solution was still not entirely proven, yet did present a method that might help in the coordination of distributed software development teams. Another possible solution to the problems of coordination suggested by the research of Wahyudin, Matthias, Eckhard, Schatten and Biffl (2008) was the use of a notification software tool that supported the agile development methodology and managed the interdependent tasks, which gave the project manager and the team members a way to coordinate activities. Hence, the coordination of tasks by the project manager and team members must be managed well to achieve value for the software development project.

Control

Adherence to organizational policies, goals and standards can impact value creation when outsourcing software development. In his research of outsourcing strategies Jennings (1997) explained that one of the most important factors for successful outsourcing was protection and development of the core capabilities that gave an organization their competitive edge. According to research by Sutherland, Schoonheim, Rustenburg and Rijk (2008) the authors found that exceptional productivity, and therefore value creation, in a development project among distributed teams was possible when the teams fully integrated the agile method into their development teams. This was achieved by bringing the teams together, instilling the agile goals and methods and then separating them. The authors acknowledged that the time spent instilling the agile principles and philosophy was a major contributing factor for success. Therefore, instilling the relevant goals and standards, especially the principles of agile development as mentioned above, gives a competitive edge, contributes to the success of outsourced projects and helps build value.

Communication

The most important factor for value creation when outsourcing software development is communication. Research conducted by Sutherland, Viktorov , Blount and Puntikov (2007) showed that communication, particularly when crossing cultures presented a significant obstacle as it limited productivity. The authors further explained that the solution that worked best was a full integration of the agile teams with members distributed around the globe as opposed to teams divided by geography. They argued that although this method slowed down the development process some when compared to an agile project done in a local space, it increased communication and built trust among the team members. A recent research paper by Shrivasta and Date (2010) concluded that knowledge management and communication were among the major problems encountered when software development was outsourced. They proposed an interesting solution were the agile teams used a web-based knowledge management wiki to assist in the capture of experiences. They further suggested that teams should still be brought together at different times in the development process and work together to build trust. Hence, a solid plan for communication among distributed software development teams is required to achieve value creation.

No Easy Answers

Agile software development philosophies and methods provide many opportunities to create value in software development. Much of the research into agile shows the potential for value creation when an organization is willing to embrace the philosophy and create a culture that supports and celebrates innovation. The process of embracing the philosophy and building the culture will take time and training on all levels of an organization to see the process happen. There is still much to be researched and solved to realize true value creation when outsourcing software development. Agile methods hold much promise, but still face many challenges to make the process work with teams spread across the globe. For an organization that already uses agile development principles, outsourcing might create additional value. For an organization that already has outsourced projects, adding agile development principles might also increase innovation. However, an organization with weak development procedures would risk much by trying to add agile principles and outsource at the same time and are likely to reduce instead of improve value creation.

References

Ågerfalk, P. J., Fitzgerald, B., Holmström, H., Lings, B., Lundell, B., & Conchúir, E. (2005). A framework for considering opportunities and threats in distributed software development. InInternational Workshop on Distributed Software Development (pp. 47–61). Citeseer.

Asproni, G. (2004). Motivation, teamwork, and agile development. Agile Times, IV (1), 8–15.

Augustine, S., Payne, B., Sencindiver, F., & Woodcock, S. (2005). Agile project management: Steering from the edges. Communications of the ACM, 48(12), 85-89.

Begel, A., & Nagappan, N. (2007). Usage and perceptions of agile software development in an industrial context: An exploratory study. In First International Symposium on Empirical Software Engineering and Measurement (ESEM 2007) (pp. 117-125). Presented at the First International Symposium on Empirical Software Engineering and Measurement, Madrid, Spain: ESEM. doi:10.1109/ESEM.2007.85

Boehm, B. (2002). Get ready for agile methods, with care. Computer, 27(4), 64-69.

Boehm, B. (2003). Value-based software engineering. ACM SIGSOFT Software Engineering Notes, 28(2), 1-12.

Boehm, B., & Turner, R. (2005). Management challenges to implementing agile processes in traditional development organizations. IEEE software, 21(2), 30-39.

Boehm, B. W., & Sullivan, K. J. (2000). Software economics: A roadmap. In Proceedings of the conference on The future of Software engineering (pp. 319-343). ACM.

Cao, L., & Ramesh, B. (2008). Agile requirements engineering practices: An empirical study.Software, IEEE, 25(1), 60-67.

Carmel, E., & Agarwal, R. (2002). Tactical approaches for alleviating distance in global software development. Software, IEEE, 18(2), 22-29.

Carmel, E., Espinosa, J. A., & Dubinsky, Y. (2010). Follow the sun workflow in global software development. Journal of Management Information Systems, 27(1), 17-38.

Ceschi, M., Sillitti, A., Succi, G., & De Panfilis, S. (2005). Project management in plan-based and agile companies. Software, IEEE, 22(3), 21-27.

Chau, T., Maurer, F., & Melnik, G. (2003). Knowledge sharing: Agile methods vs. tayloristic methods. In Enabling Technologies: Infrastructure for Collaborative Enterprises, 2003. WET ICE 2003. Proceedings. Twelfth IEEE International Workshops on (pp. 302-307). IEEE.

Chow, T., & Cao, D. (2008). A survey study of critical success factors in agile software projects.Journal of Systems and Software, 81(6), 961-971. doi:10.1016/j.jss.2007.08.020

Cockburn, A. (2002). Agile software development. Boston, MA USA: Addison-Wesley.

Cockburn, A., & Highsmith, J. (2002). Agile software development: The people factor. Computer,34(11), 131-133.

Cohn, M. (2004). User stories applied: For agile software development. Addison-Wesley Professional.

Cohn, M., & Ford, D. (2003). Introducing an agile process to an organization [software development]. Computer, 36(6), 74-78.

Constantine, L. L., & Lockwood, L. A. D. (1999). Software for use: A practical guide to the models and methods of usage-centered design. New York, NY, USA: ACM Press/Addison-Wesley Publishing Co.

Decker, B., Ras, E., Rech, J., Klein, B., & Hoecht, C. (2005). Self-organized reuse of software engineering knowledge supported by semantic wikis. In Proceedings of the Workshop on Semantic Web Enabled Software Engineering (pp. 126-135). ACM.

Dingsøyr, T., & Hanssen, G. K. (2003). Extending agile methods: Postmortem reviews as extended feedback. Advances in Learning Software Organizations, 4-12.

Dyba, T., & Dingsayr, T. (2008). Empirical studies of agile software development: A systematic review. Information and Software Technology, 50(9-10), 833-859. doi:10.1016/j.infsof.2008.01.006

Fitzgerald, B., Hartnett, G., & Conboy, K. (2006). Customising agile methods to software practices at Intel Shannon. European Journal of Information Systems, 15(2), 200-213.

Forward, A., & Lethbridge, T. C. (2002). The relevance of software documentation, tools and technologies: A survey. In Proceedings of the 2002 ACM symposium on Document engineering (pp. 26-33). ACM.

Fowler, M., & Highsmith, J. (2001). Manifesto for agile software development. Retrieved February 6, 2011, from http://agilemanifesto.org/

Glass, R. (2001). Agile versus traditional: Make love, not war! Cutter IT Journal, 14(2), 12-18.

Hanssen, G. K., & Fægri, T. E. (2008). Process fusion: An industrial case study on agile software product line engineering. Journal of Systems and Software, 81(6), 843-854.

Herbsleb, J. D., & Moitra, D. (2002). Global software development. Software, IEEE, 18(2), 16-20.

Highsmith, & Cockburn. (2002). Agile software development: The business of innovation.Computer, 34(9), 120-127.

Jennings, D. (1997). Strategic guidelines for outsourcing decisions. Strategic Change, 6(2), 85-96.

Karlsson, J., & Ryan, K. (2002). A cost-value approach for prioritizing requirements. Software, IEEE, 14(5), 67-74.

Lapham, M. A., Williams, R., Hammons, C., Burton, D., & Schenker, A. (2010). Considerations for using agile in DoD acquisition (Technical Note No. CMU/SEI-2010-TN-002). Hanscom AFB, MA: Carnegie Mellon.

Larman, C. (2004). Agile and iterative development: A manager’s guide. Prentice Hall.

Lindstrom, L., & Jeffries, R. (2004). Extreme programming and agile software development methodologies. Information Systems Management, 21(3), 41-52.

Little, T. (2005). Value creation and capture: A model of the software development process.Software, IEEE, 21(3), 48-53.

Moe, N. B., Dingsoyr, T., & Dyba, T. (2008). Understanding self-organizing teams in agile software development. In Software Engineering, 2008. ASWEC 2008. 19th Australian Conference on(pp. 76-85). IEEE.

Nerur, S., Mahapatra, R. K., & Mangalaraj, G. (2005). Challenges of migrating to agile methodologies. Communications of the ACM, 48(5), 72-78.

Nonaka, I., & Takeuchi, K. (1995). The knowledge creating company: How Japanese companies create the dynamics of innovation. Oxford, UK: Oxford University Press.

Paetsch, F., Eberlein, A., & Maurer, F. (2003). Requirements engineering and agile software development. In Enabling Technologies: Infrastructure for Collaborative Enterprises, 2003. WET ICE 2003. Proceedings. Twelfth IEEE International Workshops on (pp. 308-313). IEEE.

Patton, J. (2002). Hitting the target: Adding interaction design to agile software development. InOOPSLA 2002 Practitioners Reports (p. 1). Presented at the Object-Oriented Programming, Systems, Languages, and Application Conference, Seattle, WA: ACM.

Polanyi, M. (1966). The tacit dimension. London: Routledge and Kegan Paul.

Poppendieck, M., & Poppendieck, T. (2003). Lean software development: An agile toolkit. Addison-Wesley Professional.

Prahalad, C. K., & Ramaswamy, V. (2004). Co-creation experiences: The next practice in value creation. Journal of Interactive Marketing, 18(3), 5-14.

Quinn, J. B., Baruch, J. J., & Zien, K. A. (1996). Software-based innovation. The McKinsey Quarterly, (4), 94-96.

Salo, O., Kolehmainen, K., Kyllönen, P., Löthman, J., Salmijärvi, S., & Abrahamsson, P. (2004). Self-adaptability of agile software processes: A case study on post-iteration workshops.Extreme Programming and Agile Processes in Software Engineering, 13(2), 184-193.

Shrivastava, S. V., & Date, H. (2010). Distributed agile software development: A review. Journal of Computer Science and Engineering, 1(1), 10-17.

Sutherland, J., Schoonheim, G., Rustenburg, E., & Rijk, M. (2008). Fully distributed scrum: The secret sauce for hyperproductive offshored development teams. In Expanding Agile Horizons (pp. 339-344). Presented at the Agile 2008 Conference, Toronto, Canada: IEEE.

Sutherland, J., Viktorov, A., Blount, J., & Puntikov, N. (2007). Distributed scrum: Agile project management with outsourced development teams. In Information Technology in Health Care (pp. 274-284). Presented at the 40th Hawaii International Conference on System Sciences, Waikoloa, Big Island, Hawaii, USA: IEEE Computer Society. doi:10.1109/HICSS.2007.180

Wahyudin, D., Heindl, M., Eckhard, B., Schatten, A., & Biffl, S. (2008). In-time role-specific notification as formal means to balance agile practices in global software development settings. In Lecture Notes in Computer Science (Vol. 5082, pp. 208-222). Springer.

Wendorff, P. (2002). Organisational culture in agile software development. Lecture Notes In Computer Science, 17(2559), 145-157.

Leadership in Open Source Software Development:

Past, Present and Future

By Dr. Russ Wright

Abstract

This paper explores the past, present and future of leadership and governance within Open Source Software (OSS) development projects. This paper also explores the current factors for successful leadership and governance of OSS development. As background, this paper explores the beginnings of the “hacker” culture that became the current geek and OSS culture. The future implications for leadership in regards to the Open Innovation model are also explored. The conclusion is that the OSS development model is morphing and changing so quickly that research cannot keep up with the change.

Leadership in Open Source Software Development

The nature of geek work is cerebral, most of the effort takes place inside the head of the geek, who uses their smarts to find solutions to problems. Typical leadership methods, designed for people who work on something external to themselves is not going to work on geeks. (Glen, 2003) How is it possible to lead these people? Before an answer is offered consider these addition factors: The people who do this work are volunteers, they are also spread over the globe and might not ever meet in person. How can a development project with these seemingly insurmountable factors actually work?

What defines OSS?

There are two basic camps that occupy the Open Source Software definition. The more radical of the two camps, holds to the belief that closed source software is dangerous and harmful and holds firmly to the belief that software should be open for the public good. (Stallman, 2001) There are others, perhaps with a more moderate philosophy, is that closing the source is a defect, as it prevents public inspection and that makes the program inferior. They desire open software to remedy the quality of the programs and make them more secure. (Perens, 2005). Other recent research contends that “OSS ‘hackers’ conceive of themselves as a movement to correct the failure of existing institutions (both industry and academia) to produce software adequately. (de Laat, 2007) By opening the source code of a software application, the developers were able to make changes to the programs as they pleased, create a whole new development methodology and build whole new communities around projects. As a result, a new term was needed to manage the licensing, ownership and copyright issues that blossomed along with the movement. Thus the term Open Source Software (OSS) was created by Raymond and Perens to define the situation.

Defining Leadership Challenges in OSS Development Projects

Leadership, or more precisely governance, which encompasses the leadership and the structure of the organization, in the OSS development environment must take on some different strategies to work. The volunteer, not motivated by the reward of a paycheck, must be motivated by other factors. Some recent research showed that the average volunteer software developer spends about 14 to 18 hour in a week working for free on OSS projects. These developers are mostly full time employees at commercial software companies, yet contribute for free. (Lakhani & Wolf, 2007) Thus, the leader must not only appeal to these other motivations, but also put in place a structure that cultivates the rewards that will motivate the volunteer.

The existing research into the leadership of OSS development communities created multiple definitions, each coming from different perspectives and does not provide a single clear encompassing explanation. For example: To provide rules, formal and informal that help identify developer identity, and help assign people to tasks. (Crowston, Li, Wei, Eseryel, & Howison, 2007) Another definition given: To control outcomes, people and communication. (Lattemann & Stieglitz, 2005) Yet another: To provide the normal methods of exchange using the commonly held values structure and the belief in sharing code with others. (Shah, 2006) Thus, none of these definitions fully define the role of leadership within an open source project.

The reason it is difficult to create a single definition for leadership or governance within an OSS community is because the communities and their purposes are widely varied. Some OSS projects do little more than build a single simple program, others become organizations, with a simple legal shell to provide a holding place for the assets and allow the project to take donations. At the extreme, some are non-profit foundations with committees and managed releases and possibly employees on a payroll. Other recent research attempted to create a definition which stated: “Thus, OSS governance can be defined as the means of achieving the direction, control, and coordination of wholly or partially autonomous individuals and organizations on behalf of an OSS development project to which they jointly contribute.” (Markus, 2007, p. 152) Although purposefully vague, this definition does provide a good starting point for defining the role of leadership in OSS development projects.

The Markus (2007) definition is good because it does not seem in conflict with traditional software development leadership responsibilities, and only highlights those additional aspects unique to OSS development. Her research revealed three particular goals of OSS development leadership and structure: (1) Keeping developers motivated, (2) solving coordination problems, and (3) cultivating a climate where developers will want to participate. These three goals are explored below.

The Motivation Dilemma

In traditional software development the developer is hired to do a job to create some product and receives compensation in the form of a paycheck for the effort. The developer might also take the job because they are interested in learning about the particular area of programming and want to advance their skills or they are motivated to solve the problem because it intrigues them. These factors fall into two different categories. According to Glen (2003) the software developer can be motivated by extrinsic factors, most often the paycheck, or intrinsic factors such as the desire to learn. He further explained that most of the factors will be intrinsic over the extrinsic. This idea is support by the research of Roberts, Hann and Slaughter (2006) who discovered in OSS development projects that even when extrinsic motivations exist, such as a paycheck, they do not crowd out the intrinsic motivators. Thus the developers who work on OSS projects, more often than not, can only rely on intrinsic factors and the leadership of the project must identify and build on those factors to keep the developers interested in the project.

Development Coordination Problems

In typical OSS projects the developers are spread out over the globe and this can present special problems for the leadership of the project especially when coordinating the interdependence of pieces of the software program. Traditional development leadership would assign tasks to specific individuals and organize the workers to performs certain tasks best fitted to their skills. (Glen, 2003) A study of virtual teams by Kayworth and Leinder (2001) discovered that leadership of virtual teams is fraught with difficulties because the solutions to the problems are much fewer because of the great distance between members. This problem of assignment and coordination does not seems to be as much an issue in OSS development projects. A recent study by Crowston et al, (2007) showed evidence that the most common method used in OSS development is a self-assignment process where the OSS developers would do the work by choice. One example given in the research showed an email where a developer called “dibs” on a particular part of the project because he wanted to learn how to make it work. The research further showed that instead of a hierarchy in assigning tasks, the developers will politely ask or just take on the task and do the work. Thus, the leadership of OSS projects do not seem to have the same issue, at least of assigning tasks and coordinating interdependencies as the developers seem motivated to pick up the tasks themselves.

Cultivating The Climate

The developers that participate in OSS development project come from two basic sources. A recent study defined two distinct categories of OSS developers as need-driven and hobbyist. (Shah, 2006) The need-driven participants consciously made the choice to use an OSS product, rather than a commercial solution so they could view and change the code to meet their own needs and solve a particular issue for a work-related purpose. The hobbyist programmer viewed participation in a particular OSS development project as a hobby activity and described the work as fun and challenging. Thus, each group has a different set of motivations and the leadership must be aware of these differences if they want to cultivate participation and contribution. Having a voice within the community is a potential solution to the motivation dilemma.

Because the OSS projects have little if any extrinsic motivators, such as a paycheck, to offer the leadership must capitalize on the intrinsic motivators available to them. A recent study by Manville and Ober (2003) explored the potential of using the voice of democracy as motivator. The study explained a situation where a developer might consider two different jobs, which have different working conditions and different pay scales. Some developers might always consider the paycheck the most important factor and choose the job with higher pay. Other developers might choose to work at a lower paying job because of greater opportunity to shape the direction of the organization. Thus the ability to have a voice in the decision making process might be a positive motivator for participation within a project.

A Brief History Of OSS Developer Culture And Ideology

To understand these struggles in leading an OSS development project requires some background. The history of OSS development is a tangle of political and personal motivations that evolved over forty years from the early computer programmers of the first mainframes all the way to the current personal computer users. After several attempts to untangle hype from fact, this author found it near impossible to determine the real facts and history of the Open Source Software movement. Below is a brief history, amalgamated from multiple sources into a single time-line. The history provided here only includes information that can be corroborated from at least one other source and is limited to details that reflect the transformation of the original computer hacker culture into the Free and Open Source software development culture of today.

The Big Iron

To fully understand the culture that permeates the OSS development world, will require some background on the origins of the hacker culture that become the OSS developer culture. According to Raymond (1999) the first group to begin the OSS developer culture began in 1961 when Massachusetts Institute of Technology (MIT) acquired a Digital Equipment Corporation PDP-1. This is often called the beginning of the “Big Iron” batch processing computers. In 1969 the addition of ARPAnet, the forerunner of the Internet built by the Defense Department as an experimental digital communications network, brought these programmers together allowing them to collaborate via electronic discussion groups despite being spread across the US. The computing culture flourished across ARPAnet particularly in the computer science department of colleges and universities who all used DEC PDP computers.

The birth of collaborative development started with a project at the MIT labs in 1967. MIT bought a PDP-10, yet the team rejected the existing operating system and built their own. According to Raymond (1999) they built their own operating system because they wanted to work their own way. This point is important because it shows the first real example of OSS developer attitude when a group of developers started a project because they want to solve a need not met by existing programs. This attitude is echoed by Perens (2005) when he stated: “Open source is an indication of an unfulfilled need.” Thus, the current Open Source Software developer mentality was influenced by the actions of MIT in 1967 when the existing software did not meet the needs and the group developers decided to make their own operating system that did things their way.

The Unix Gurus

The second group who influenced the current Open Source Software developer culture started in a very different way. Raymond (1999) explained that Ken Thompson working at Bell Labs in New Jersey resurrected parts of the failed Multics operating system and combined it with his own ideas and created a new operating system to run on a scavenged DEC PDP-7. While still in the very early stages of creating Unix, another developer named Dennis Ritchie created a development language called C to run on Thompson’s fledgling Unix operating system. Raymond (1999) explained that two major factors propelled this OS into popularity. First, this OS could run on essentially unaltered on several platforms and second, computer hardware was getting cheaper and faster and the operating system did not need to eek out every possible ounce of power from the hardware. Thus, Thompson’s Unix and Ritchie’s C language started a change in development, that allowed developers to take and move source code with them to any project running on multiple platforms. This portability, the ability to take and reuse software for other projects is part of the Open Source Software developer mindset today.

Commercial Destruction

A major solidifying factor for the Open Source developer culture came about through the commercialization and subsequent destruction of both the Big Iron and Unix cultures. According to Levy (2002) several startup companies lured away the talent from the MIT Big Iron labs and started rival fractured groups who were once good friends. A few years later similar attempts to commercialize Unix started enormous infighting and knocked them out of the market. According to Raymond (1999) “The proprietary-Unix players proved so ponderous, so blind, and so inept at marketing that Microsoft was able to grab away a large part of their market with the shockingly inferior technology of its Windows operating system.” (p. 164) Thus the infighting and the commercialization attempts caused many years of efforts to create a free and open operating system to flounder.

One of the most influential figures of the Free Software ideology is Richard Stallman who was a developer during the time when the commercialization of some of the MIT lab technologies saw the fracturing and destruction of the Big Iron and the Unix cultures. According to Levy (2002) Stallman was so depressed by the schism in the labs that he would tell strangers he met that his wife had died. This fracturing obviously colored his perceptions of software ownership and continues to affect the OSS developer culture.

In 1982 Stallman founded the Free Software Foundation, which holds the philosophy that software should have essential user freedoms anmd maintains the following definition of free software:

Free software is a matter of the users’ freedom to run, copy, distribute, study, change and improve the software. More precisely, it means that the program’s users have the four essential freedoms:

The freedom to run the program, for any purpose (freedom 0).
The freedom to study how the program works, and change it to make it do what you wish (freedom 1). Access to the source code is a precondition for this.
The freedom to redistribute copies so you can help your neighbor (freedom 2).
The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.

According to Raymond (1999) Stallman’s idea of a free clone of Unix, which later became GNU/Linux, and his stubborn adherence to a free and open operating system epitomized the OSS developer culture. Thus Stallman, influenced by witnessing the destruction of computing cultures by commercialization forwarded through his creation of the Free Software Foundation another aspect of the Open Source developer culture.

Stallman began the construction of a Unix clone in 1983, that would be free and open. The original project was called the GNU (Gnu’s Not Unix) operating system. The project moved along slowly developing many tools and really floundered when AT&T sued over Unix rights in 1992. Stallman wanted to make sure that his software would stay publicly available and created a regulatory framework that came to be known as the GNU Public License (GPL). (“The GNU General Public License,” 2007) The GPL allows the developer to use, modify and redistribute the modified program, with one very important rule. The new code created from the original code must carry the same license. Thus this self perpetuating licensing scheme kept the source code always in the public domain. Around the same time a Helsinki University student named Linus Torvalds began developing a free Unix kernel for 386 machines using the Free Software Foundation’s toolkit. His initial, rapid success attracted many Internet hackers to help him develop Linux, a full-featured Unix with entirely free and re-distributable sources.

The Birth Of The OSS Development Method.

The OSS development methodology underwent a significant change when Linus Torvalds started developing his Linux kernel. The application development methods used reflected a significant culture shift from the previous development style. Raymond (1999), explained the difference in the development style by comparing the typical commercial development style of the time to building a cathedral and the development style of Linux to a marketplace bazaar. The cathedral style of software development was typified by a small group of experts working away in isolation with few code releases. The bazaar was a much more open style of development typified by many developers contributing updates continuously and many and often releases of the code. From the late 90′s through the early part of 2003 OSS development saw an enormous explosion using the Torvald’s model of development.

The Early Leadership Problems

Here is where the paths of the Free Software Foundation and the Open Source Initiative really began to diverge on philosophy. Raymond (1999) explained that shortly after a presentation of his paper on Torvald’s development model, Netscape announced that they would try this model and open the source of their browser. He further explained that over the next several days, in meetings with many influential figures, the decision was made to create a definition of Open Source Software through an organization called the Open Source Initiative. Raymond (1999) Explained: “What we realized, under the pressure of the Netscape release, was that FSF’s actual position didn’t matter. Only the fact that its evangelism had backfired (associating `free software’ with these negative stereotypes in the minds of the trade press and the corporate world) actually mattered.” (p. 256) Thus, a conscious decision was made to create a definition that would be more appealing to the business person as the definitions of the FSF did not translate well to business.

Over the next few years a great injustice was done to Stallman. As previously mentioned, Stallman had a large chunk of an operating system completed, but lacked a kernel and Torvald’s Linux kernel filled that gap. Often developers refer to an operating system by it’s kernel, despite the fact that many other pieces exist to make it an operating system. Perens (2005) notes: “Although Stallman did a great deal of the work that made Linux possible, Torvalds’ team of kernel contributors was not closely allied with Stallman, and announcements of Linux were not attributed to FSF.” Thus the considerable work of Stallman was not credited in the Linux announcements creating a division within the community that still exists today.

These major events shaped the culture that is the OSS community today. From the Big Iron era the early developers demonstrated the desire to meet a need not met by the existing operating system. This desire was carried forward into the Unix and C microcomputer era where tools and languages become portable and could be carried to other jobs so developers did not have to start over on each new assignment. Then the birth of the personal computer, and the explosion of the Internet brought together these developers from around the planet to work together to create software, GNU/Linux for example, that introduced a new way of creating software, and all the new challenges of leading these developers.

Major Intrinsic Motivation Factors In The Current OSS Development Culture

Like all development projects, regardless if the project is open-source or not, one of the major jobs of the leadership is to keep the team motivated. According to Glen (2003) the leadership must set a tone for the work environment to cultivate motivation. The unique qualities of an open-source project require the leadership of the project to take on some different attributes than their commercial counterpart. A recent study by O’Mahoney (2007) defined five specific intrinsic motivation traits of OSS development that manage and motivate the developers: (1) Independence, (2) Pluralism, (3) Representation, (4) Decentralized decision-making, and (5) Autonomous participation. Each of these traits are interrelated to each other and build a cohesive model of the motivations of the OSS volunteer developer. Thus, these traits are the basis of a community managed OSS project and represent the primary motivations for volunteer involvement. Each of these traits are explored in detail below as they relate to OSS development practices and other research.

Independence

For a mature OSS project, independence is natural, as the gained experiences of the community will form their own culture. Independence, according to O’Mahoney (2007) is defined as “A community that is independent does not rely upon the resources from any one organization, but is supported by a diverse body of participants.” (p. 144) This seems to resonate with Glen (2003) where he explains that the culture of a community will grow over time and establish shared patterns of interaction and will limit the ability of any one entity to control the group. Thus, independence seems a natural part of an OSS project as leadership cannot exert control but only nurture the environment.

This issue of project control and leadership came to a head with the development of the Linux Kernel. An article by Lemos (2002) explained that the developers who worked with Linus Torvalds on the Linux kernel were frustrated by the lack of response and tight control Torvalds was exerting over the development process. Changes and bug fixes would be submitted only to be ignored or flat out rejected without explanation which angered the developers. This created a delicate situation for Torvalds as the developers could easily fork the project, taking a set of the existing code, walking away from the existing Linux kernel project and starting a new project of their own. To resolve the problem Torvalds appointed several new people, he called lieutenants, who took over different segments of the development and code integration responsibilities. Torvalds had to give up some control to keep control of the project. Thus the kernel development project was establishing patterns of interaction that went beyond the control of the Torvalds.

Pluralism

The intrinsic motivator of pluralism has two dimensions, that partially overlap. The first part of the definition has to do with the governance of the project. For a project to recruit and retain talented developers, no one organization may own or control too much of the project and stifle other voices. According to research by West and O’Mahoney (2008), project with sponsors have a special problem as talented developers, which the project desires, will want freedom to act and share their thoughts. These developers will test the ability share and become vocal and critical of the project leadership if their voice is not heard and respected. Thus, the leadership must be cautious to not let any one sponsor dominate the project or talented developers will not want to participate.

The second part of pluralism deals directly with the voice of the developer. Because the work done in the development of a software programs comes from the creative mind of the developer, there can be multiple solutions to the same problem. Some solutions will be better that others, but all must be heard. O’Mahoney (2007) defined pluralism as: “A pluralistic community allows many approaches, methods, theories or points of view to be legitimate or plausible in pursuing a course of action” (p. 146) This also resonates with Glen (2003) who explained that one of the important roles for the leadership of a project is to create an environment that is safe for the presentation of ideas and that freedom of speech exists within the community. Thus the intrinsic motivator for the OSS developer is the freedom to present ideas that they know will be heard and considered as part of the solution.

Representation

The developers must also have a voice in the direction of the project. The definition of representation provided by O’Mahoney (2007), was a system of democratic representation within the project. However, the researcher does differentiate that the authority of the representative is limited to making decisions on the project and not in control over other members. The Glen (2003) research seemed to agree with this position as he stated, “everyone should feel that what they have to say is valued and becomes part of the discussion about how to proceed” (p. 127). Thus, even if the voice is representative and not a pure democracy, the members must feel that their voice impacts the direction of the project.

Decentralized Decision Making

To understand the organization of OSS development requires an understanding of the social structure, often called a social network. In the research by Wasserman and Faust (1998) they defined the structure within a social network as a grouping of units who depend upon each other and who are connected by relationships. In an OSS development project, where the participants are scattered about the globe and interact and connect with each other over the Internet, these units might be the groups of developers, testers and users. The relationships might be the direct discussions between two developers via a conversation or the bonds of trust formed between the users and developers. This social network is how the groups of people share knowledge and solve problems.

In OSS development the structure of the social network, usually comes in two distinct styles. The first style is centralized or group centralization, which Wasserman and Faust (1998) explained and modeled as equivalent to a solar system with a star in the middle and planets in orbit about them. The model they created of group centralization provides a simple measurement of the inequities of the team members based on the differences on actions and the patterns of interaction. This is the model initially used to create the Linux kernel as Linus Torvalds acted as the star and hundreds of developers worked though him suggesting changes which he accepted or rejected. (Raymond, 1999) The second style, as defined by Wasserman and Faust (1998), is core-peripheral which exhibits a central dense interconnected core surrounded by a halo of unconnected peripheral participants. Decentralized decision-making according to O’Mahoney (2007) is defined as a model where some of the decision making rights are distributed to the community members. The decision making rights generally deal with or fall into three distinct categoris of (1)code, (2)sub project and (3)community wide issues. This is the development model used on the FreeBSD operating system where some 300 core developers all have the ability to add and update the source-code at the same time. (Jørgensen, 2007) Thus, the collaboration and decision making process is influenced by the style social structure within the OSS development project and can affect how well a project team performs and the perception of belonging and satisfaction each member of the team experiences.

Autonomous Participation

Developers working on OSS projects will often desire to stake a claim on a particular part of the program and work on that part of the code. The research by O’Mahoney (2007) defined autonomous participation as one of the most important factors where developers are attracted to projects by the opportunity to learn, solve problems and improve their skills. This seems to agree with earlier research by Hackman and Oldham (1980) where their Job Characteristic Model (JCM) defined autonomy as a precondition for high motivation potential that multiplies the other intrinsic motivators. Glen (2003) also discussed the importance of autonomy:

With a solid understanding of the environment, they are able to make their own decisions about day-to-day matters without having to check with the boss constantly. For geeks, who generally have a strong independent streak, autonomy fosters motivation.(p. 110)

Therefore the ability to operate freely within a particular area of the code is a large motivating factor and the existence of autonomy will be a deciding factor for an OSS developer to join a project.

The Future of OSS Leadership: Harnessing Innovation

The OSS development model is currently jumping over to physical products such as beer and bread, and into other disciplines such as biotechnology and government policies. This new development process for physical products is often called Open Innovation. (Chesbrough & Garman, 2009) The research by de Laat (2007) made a bold proclamation about the flexibility of the OSS development model when he suggested that this model is the only known model of development that can be applied across products and is not restricted software alone. He tried to find an example of the closed source software development model that can be used for physical products and was unsuccessful in finding any examples. Thus the OSS development model, renamed Open Innovation for physical products is unique in the ability to be used in other industries. This concept is still relatively new to researchers and there is much territory still unexplored.

There is not much current research on how the leadership or governance will be affected by the shift of the OSS development model to other physical product industries. Most of the research continues to demonstrate the need to provide extrinsic motivators but also maintain a focus on the intrinsic motivators. (Chesbrough & Garman (2009), Dahlander, (2008); Grönlund, Sjödin, & Frishammar, 2010)

Most of the current research on Open Innovation looks at the for-profit companies and how they will need to shift their thinking about corporate boundaries. The companies will have to accept that the boundaries of their organization, once firmly defined will now have to be permeable and allow for interactive and distributed innovation where the resources, ideas and people move in and out of organizations constantly. (Laursen & Salter, 2006) This means that employees will need to experience those same intrinsic motivators as defined by O’Mahoney (2007) as their affiliations with a company will be much looser and not tied to the extrinsic motivation of a paycheck.

The research by Chesbrough & Garman offers an example of the Phillips company who, seeing a failure in their research model, opened up their R&D facility and created a open campus where now some 7000 researchers from multiple organizations share knowledge about products they create. The authors explained how this style of leadership prevented lay-offs and prevented the “high emotional and economic costs of severance while boosting morale for remaining and departing workers alike ” (p. 75). Thus the current research still reflects the regular needs of leadership as defined in Glen (2003), but also recognizes the advantages of embracing an Open Innovation model.

Changing Fast

All the research uncovered by this author had a common thread of exasperation among the researchers. The OSS development process is changing and morphing quickly. So quickly in fact, that the research cannot keep up. The research into the motivators of OSS developers by O’Mahoney (2007) explicitly stated that the rapid evolution occurring in the OSS development process as new hybrid models appear made defining the responsibilities of leaders and the structure of governance difficult to define. The leadership of the future version of an OSS development project, or Open Innovation product, will require a cyclic return to the list of extrinsic and intrinsic motivating factors to determine how well they are meeting the needs of their open communities.

References

The Open Source Phenomenon:

How it is Affecting Business and Education.

By Dr. Russ Wright

Abstract

Open source software, with the unique license that gives the user many rights and freedoms, is transforming business and education. Once thought of as hobbyist programming, open source now has many products that are competitive with commercial proprietary software. This paper explores the perception of programming methods used to create open source programs, the security of the open source model, the evolution of the business model used to sell open source software, and the impact of open source on education and business.

The Open Source Phenomenon: How it is Affecting Business and Education.

The phenomenon of open-source software is permeating the software market. There is much debate over which type of software is best, open source or proprietary, over topics such as security, development methodology and business models. Open Source Software (OSS) is now posing significant competition to proprietary or closed source software in several markets (Jaisingh, See-To, & Tam, 2008). Open source software has matured to the point where it is a viable alternative to proprietary commercial offerings (Fitzgerald 2006). Ignoring the benefits of open source in the ever-changing software market would be a foolish decision for a development shop, and a blind allegiance or strict adherence to either software model will eliminate possible solutions to technological problems.

Open Versus Closed Source

In the world of software development, there are basically two types of software. The first type is open source, where the source code is freely provided with the application. The second type is closed source, where the application comes pre-compiled for installation and the owner of the program does not freely provide the source code. A simple definition of open source software (OSS) is software that allows the users access the source code, to which they may make improvements, perform bug fixes, change or enhance the functionality, and redistribute the original program or the derivative work to others who can, in turn, do the same according to their own needs (Sen, Subramaniam, & Nelson, 2008). Closed-source software, more often referred to as proprietary, usually has a copyright owner who can exercise control, through the use of a license, over what users can do with the software. This limit includes the type or number of machines on which the software can be installed and the number of users who can use the application (Castelluccio, 2008). Therefore by the nature of the license, open-source software gives the user more freedom to decide how they will use the software, what they will modify to meet their needs, and when it is most advantageous to make changes to the program in their environment. Open source software, because of the open nature, also has a unique development model causing companies to rethink the way they do business.

Security

There are many arguments both for and against the security of open source code. Some believe because the source code for open source software is readily available for inspection by “many eyes”, then the code is inherently more secure. On the other side of the debate, others believe that through secrecy and obscurity, the code is secure because only a few people truly know how it works. In a recent study by Hoepman & Jacobs (2007), the authors make the argument that opening the source code allows a third party to determine how much risk is involved in using a particular program, allows developers to create fixes for the bugs found, and forces the developer to allocate more time to writing better quality code (p. 81). The argument presented here has merit. By allowing “many eyes” to see the code, the problems can be fixed must faster. The one possible exception is if no one bothers to look at the code until the security is breached. Still, the advantages of having open source code critiqued by many will far outweigh the disadvantages of closed source.

There are those in the open source community who believe that the “many eyes” model is not good enough because it does not go far enough. Laurie (2006), posits in the paper on open source and security that the “many eyes” concept only applies when a bug is found. Then the developer who found the bug can post the issue and many developers will work together to quickly find the solution. Most developers do not have the experience to identify where the problem exists just by looking at the source code (p. 60). This theory is still contested and supported by many within the open source community. There is no clear answer and this point of contention continues to be a stumbling block for open source adoption.

Proponents of proprietary software often argue that opening the source code allows an attacker access to information that would be helpful in creating and launching an attack against an application. In a recent study of increasing software security, the authors contend that closed source projects often use poor methods for coding practices, project management, change control and quality control (Hoepman & Jacobs, 2007). The authors also posit that when the source code is opened, the software projects cannot get away with poor practices because they are immediately evident as discovered when the source code. This fact was made evident when the source code for the Deibold voting machines was distributed on the Internet and the source code revealed horrible programming errors and vulnerabilities. Therefore open source software, by providing the source code and more rigorous coding standards and methods, provides the most security. The myth of open source programmers being lazy coders when compared to the proprietary development shops is more often than not, quite the opposite.

Programming Model Perception

The perception of the development model for open source software is often incorrect as popular opinion portrays a group of lonely geeks in their mom’s basements working to create a program that will be released into the wild without support. According to Baird (2008), although some open source projects are still created by volunteers working in an ad-hoc fashion, most are developed by paid programmers working for not-for-profit organizations or by proprietary companies that support internal open source development and proprietary development (p. 233). It is very rare to find a developer who only works on open source projects. More often than not, an open source developer also works on proprietary projects. Developers from both open and proprietary shops benefit from the body of source and libraries that are free for use in developing their programs. A great example of a company that pays programmers to work on open source projects is the end-user software OpenOffice. The OpenOffice project is strongly supported by Sun Microsystems, who pays and provides developers to maintain the program (Woods, 2005). OpenOffice is an open source office suite with word processor, spreadsheets, presentations and database tools that rivals any commercially available office suite. Therefore this incorrect perception of open source software creation adds to the confusion over how free software can yield profit or reduce costs. Finding the true total cost of ownership (TCO) of open source software is a confusing topic for many and requires further discussion.

Business Model

In the early years of open source software commercialization, there were two basic models. According to Baird (2008), the two forms were value-added support or software-as-a-loss-leader (p. 235). For the value-added model, a vendor would provide the software for free and get the customer to sign up for support to install and configure the open source application. In the other model, the vendor would provide the open source program and then sell proprietary extensions that added more functionality to the open source program. This business model has evolved into vendors providing a real mix of both open and proprietary packages.

The blending of open and proprietary software creates much confusion about how free software can be profitable for a company. Economists are often mystified and struggle to identify how open source software can generate income for a company and struggle to come up with new models to define Total Cost of Ownership (TCO). Fichman (2004) developed a possible solution that might fit the constantly shifting world using a theory of real options investment analysis. In summation, real options analysis is a method used in stock analysis to provide a way to calculate TCO where flexibility must be exceptionally high and much uncertainty is possible. This exceptionally high flexibility and much uncertainty defines the world of open source software. As a result of this research companies can quantify and report upon the costs associated with using open source software. This represents a significant step forward in the acceptance of open source software in both education and enterprise.

Maturation of Open Source

In a paper on the transformation of open source software, Fitzgerald (2006), posited that the changes in security, programming model and business model have all contributed to the open source phenomenon taking on a new form he calls OSS 2.0. This theory is echoed in the Scacchi (2007), paper where the author discusses the recent research results and emerging opportunities in Free/Open Source Software development (FOSSD). The author concludes that open source development has created new types and kinds of socio-technical work practices, development processes and community networking (p. 465). There is also much opportunity for researchers to discover, observe, analyze, model and simulate these practices and processes primarily because of the open nature of the projects themselves, publicly provides the research materials.

FOSSD project source code, artifacts, and on-line repositories represent and offer new publicly available data sources of a size, diversity, and complexity not previously available for research, on a global basis. FOSSD projects and project artifact repositories contain process data and product artifacts that can be collected, analyzed, shared, and be re-analyzed in a free and open source manner. (p. 466)

Therefore the open source community has evolved past the early days and stereotypical models into a modern and mature solution, called OSS 2.0, for both education and enterprise. Corporations and places of learning can both benefit from incorporating OSS 2.0 into their technology structure.

The Impact of Open Source on Education

The apparent readiness of open source in the market sparked many changes in the attitude of educators towards using FOSS to educate students. This shift in perception, although not complete, is creating an environment where open source is finding purchase, albeit small, in both education and enterprise. According to a study of the willingness of Chief Information Officers, (CIO) and Chief Academic Officers (CAO) to use open source software conducted by Van Rooij (2007), the participants had negative perceptions of the value of commercial software because of the problems experienced with implementation of commercial software and the lack of fit with the desired needs and functions. Because of the situation of limited funding for education projects and the enticement of an opportunity to collaborate with peers, open source software was the best perceived solution because it provided the promise of control over the end result (p. 446). Therefore open source represents a viable alternative to proprietary solutions because the decision makers and staff perceive the value of open source to be first the lower cost, second they value the opportunity to collaborate with peers and third the control over the end result of the programming effort. The failure of vendors to meet the needs of the customer pushed the educators towards open source because it holds the promise of a solution that offers the ability to meet the desired needs. These perceived benefits sparked the creation of some exceptional open source programs for education.

oodle, a software program for Internet-based courses and websites, with functionality similar to the commercial program Blackboard, is a great example of open source education software. According to the Moodle website:

The word Moodle was originally an acronym for Modular Object-Oriented Dynamic Learning Environment, which is mostly useful to programmers and education theorists. It’s also a verb that describes the process of lazily meandering through something, doing things as it occurs to you to do them, an enjoyable tinkering that often leads to insight and creativity. As such it applies both to the way Moodle was developed, and to the way a student or teacher might approach studying or teaching an online course. (“About Moodle – MoodleDocs,” n.d.)

One shining example of innovation with Moodle is covered in a case study (Marquart & Rizzi, 2009) where they used Moodle to move from a predominantly classroom model to a blended learning and training environment for the tutoring staff. The BELL (Building Educated Leaders for Life) program uses tutors to teach children living in low income, urban communities. The BELL program selected Moodle because of the open source and therefore cost effective (p. 52). The study concludes that using Moodle saved them money and it provided an exceptional platform for the tutoring program which produced significant measurable benefits and outcomes. Therefore the implementation of Moodle allowed a not-for-profit organization to positively transform a tutoring program on a small budget and see significant educational benefits. This is one of the positive ways that open source is transforming education.

The Impact of Open Source on Enterprise

Although many still debate open source software as an alternative to proprietary solutions, this is merely noise designed to draw attention to open source products because most IT shops are no longer supported by one vendor but are instead blended shops of both open source and proprietary products. In a study of several IT shops, Baird (2008) puts forth the notion that most current enterprise IT is a mix of both proprietary and open-source solutions. The study goes further to explain that this phenomenon is true in both the private sector and government facilities. The reasons given for this blend are practical more than idealogical. As governments and companies reorganize and offices are merged, multiple disparate IT systems must be integrated together. According to the study, there are four primary reasons that despite the rhetoric to the contrary, IT shops are a mix:

(1) an enterprise’s IT is essentially built anew and requires specific solutions, some of which are open-source and some proprietary, (2) an enterprise builds upon legacy systems and the “modernization” requires implementation of both approaches, (3) a government enterprise has to interface with technology that is popular with its citizens which may encompass both approaches, and (4) vendors have embraced business strategies that incorporate the distribution and support of both open-source and proprietary software. In all of these cases, the key to success for the enterprise is to assure interoperability and maximize the efficiency and value of the combined technologies (p. 234).

Therefore the rhetoric about open source not being a viable solution for IT shops is false. The use of open source along side proprietary software is the correct model of implementation that will meet the most needs of technology users.

A second place where open source really impacts enterprise is the development methods used by programmers. Open source software development methodology evolved just like the software and developed an exceptionally good model for delivering quality code. The Mozilla project exemplifies the development process used in open source. The methodology used by the developers of Mozilla, who make the open source browser Firefox, is an extremely disciplined methodology that is copied by many open source and proprietary development shops (DiBona, 2006). Many of the tools created by the Mozilla team were released as open source and then found their way into other large development shops that adopted the tools and methodology proven by the success of the Mozilla software projects. Therefore the methodology developed by the Mozilla organization has added a significant amount of quality not only to open source projects but to proprietary software development too.

Ignoring Open Source is a Mistake

Despite the attention seeking noise from both camps, Open source is here to stay and ignoring the benefits in the ever-changing software market would be a foolish decision for a vendor, educator or development shop. The costs, which can be measured in TCO, provide a clear analysis of how open source, when mixed with proprietary software creates a beneficial solution. Right now the education market has an opening for open source to truly take advantage of the maturity achieved by software vendors. Open source projects also contributed many tools and methodologies that will benefit any software development project regardless of the license assigned to the final product.

Use What Works Best for Your Situation

A blind allegiance and strict adherence to either software model will eliminate possible solutions to technology problems. Open source is attractive because of the control over the code and the ability to make changes and fixes as desired. Proprietary software also has merits in the support provided and the stability of a long term relationship company. A CIO or CAO, if they are honest with themselves should seriously consider the possibility of using open source and proprietary solutions together to create a best-fit solution. Each model has merits that when properly implemented together in a mixed environment represent to best possible solutions for the majority of situations and users.

References

About Moodle – MoodleDocs. (n.d.). . Retrieved March 3, 2010, from http://docs.moodle.org/en/About_Moodle

Baird, S. A. (2008). The heterogeneous world of proprietary and open-source software. InProceedings of the 2nd International Conference on Theory and Practice of Electronic Governance – ICEGOV ’08 (p. 232). Presented at the the 2nd International Conference, Cairo, Egypt. doi:10.1145/1509096.1509143

Castelluccio, M. (2008). Enterprise Open Source Adoption. Strategic Finance, 90(5), 57-58.

DiBona, C. (2006). Open sources 2.0 : the continuing evolution (1st ed.). Beijing;Sebastopol CA: O’Reilly.

Fichman, R. G. (2004). Real Options and IT Platform Adoption: Implications for Theory and Practice. Information Systems Research, 15(2), 132-154.

Fitzgerald, B. (2006). THE TRANSFORMATION OF OPEN SOURCE SOFTWARE. MIS Quarterly,30(3), 587-598.

Hoepman, J., & Jacobs, B. (2007). Increased security through open source. Commun. ACM,50(1), 79-83.

Jaisingh, J., See-To, E. W. K., & Tam, K. Y. (2008). The Impact of Open Source Software on the Strategic Choices of Firms Developing Proprietary Software. Journal of Management Information Systems, 25(3), 241-275.

Marquart, M., & Rizzi, Z. J. (2009). Case Study of BELL E-learning: Award-Winning, Interactive E-learning on a Nonprofit Budget. (Vol. 2, pp. 50-56). Retrieved from http://search.ebscohost.com

Scacchi, W. (2007). Free/open source software development: recent research results and emerging opportunities. In The 6th Joint Meeting on European software engineering conference and the ACM SIGSOFT symposium on the foundations of software engineering: companion papers (pp. 459-468). Dubrovnik, Croatia: ACM. Retrieved from http://portal.acm.org.library.capella.edu/citation.cfm?id=1295014.1295019

Van Rooij, S. W. (2007). Perceptions of Open Source Versus Commercial Software: Is Higher Education Still on the Fence? Journal of Research on Technology in Education, 39(4), 433-453.

Woods, D. (2005). Open source for the enterprise : managing risks, reaping rewards (1st ed.). Sebastopol CA: O’Reilly.