January 2011

"I've always wanted to own and control the primary technology in everything we do."

Steve Jobs

Abstract

In this article, we examine typical fears associated with a perceived loss of control in an open source software development project. We describe various development models, including hybrid models that provide companies with control over key aspects of product development. Finally, a description of control within open source projects illustrates that self-regulating control mechanisms that exist in this model. A better understanding of control as a factor will help companies achieve their for-profit objectives using open source software.

Introduction

Open source software has become a mainstream tool that all companies consider as part of their product development strategy. Open source provides entrepreneurs with a way to increase their chances of earning revenue quickly, often with little or no start-up costs. Senior managers of existing businesses use open source to innovate faster, compete more effectively, and grow revenue.

Fears of Losing Control

Companies ignore the benefits of open source at their peril. The legitimacy of open source as a credible business strategy is illustrated by a 2009 survey of 54 private investment firms by the 451 Group. The consulting firm conducted the study to gauge the commercial adoption of open source. They found that almost three times as many investors indicated that they would invest in an imaginary start-up that used a mix of open and proprietary licensed software over the same business that used only a proprietary licensing model. It is clear that companies should not assume a proprietary model by default.

When considering relying on open source to generate revenue, companies may fear losing control over the execution of their product development strategy, including:

  • development direction, priorities, progress, and product quality

  • ability to compete effectively

  • protecting intellectual property

Models of Software Development

Watson and colleagues (2008) describe five models of software production or distribution. The first is the closed, proprietary model, and it has dominated the software industry for most of the past 40 years. The second is the open communities model, which has been around for the same length of time, but it is only in the past dozen or so years that various forms of development based on open communities have grown in popularity and support. The remaining three are open source models: i) corporate distribution of open source software; ii) sponsored open source, and iii) second-generation open source. Each of these three open source models are used by companies to generate revenue from open source software in various ways and each of them provides at least a partial solution to the four fears described above.

The corporate distribution model provides a customer with a packaged installation of the open source software combined with other complementary services, which are typically installation, training, support, and custom development. The customer receives the software in the same way that they would receive proprietary software, thus maintaining a level playing field with proprietary software vendors and not diminishing their ability to compete.

The sponsored open source model involves the application of corporate resources to provide paid developers to work on an open source software project. This approach, which can be used in combination with the corporate distribution model, provides the vendor with influence or even control over some elements of the product development, including development direction, priorities, and progress. Ideally, the paid development work undertaken would be of sufficient interest to the volunteer community so that it can be leveraged and supported, thus realizing some of the significant advantages of the open source approach, such as speed of development. This model also reduces the risk of poor product quality since testing can be one of the areas funded by the corporate sponsor.

The third approach, that of the second-generation open source (also known as OSSg2 or professional open source), represents a hybrid of the corporate distribution and the sponsored open source software models. OSSg2 companies maximize their influence over the product by funding of much of its development. Packaged software installations are available, however, unlike the corporate distribution model where packaged installations are sold, the OSSg2 model makes them available for free. The OSSg2 model involves maximizing control over the code so that the OSSg2 company can provide higher-value services based on the company's superior knowledge of the code. One of the ways that control is created is by not releasing all of the code as open source. Because these firms control parts of the code, they can use a dual-licensing strategy to sell a traditional software license in addition to the free open source license. Examples of OSSg2 companies include Trolltech (acquired by Nokia in 2008) and MySQL (acquired by SUN for $1billion in 2008). The OSSg2 model effectively addresses all three fears described above. Not only does this model maximize control over product development and provide an effective means of competing with both proprietary and pure open source vendors, some elements of intellectual property protection are maintained and exploited.

Further Hybrid Strategies

West (2003) describes two hybrid strategies that combine elements of both proprietary and open source. The goal of this hybrid strategy is to maximize control over product development in ways that maximize the advantages of both strategies while minimizing their disadvantages.

The first hybrid strategy is to open only those parts of the product that do not provide a basis for competitive differentiation. The commodity layers, once opened up to external innovation, can be used to both create communities of active contributors and drive new product innovation. This strategy can also serve both to undermine the competitive strength of competing firms and to drive broader adoption of the now-open parts of the company's product. In the extreme version of this strategy, the core product is fully open and the company derives revenue through the creation and sale of proprietary extensions.

The decision whether or not to choose the "open parts" strategy comes down to evaluating where the points of differentiation lie. If the value provided to the company and its customers is derived from the entire core of the product, then the company should retain proprietary control over the core. If the value lies in discrete, identifiable parts of the code, then the company should protect and control those elements and release the remainder as open source. If the value to the company lies in either proprietary extensions to the core or in the provision of complementary services, then the company should release the entire core as open source.

Even if a significant proportion or even all of the product is subject to an open source license, modularization can be used as a strategy to control or at least influence development. The idea behind modularization is to create separate development initiatives for different parts of the product to encourage contributions and ensure that development of the entire product cannot be as easily subverted or taken off-track (Baldwin & Clark, 2006). In this way, control can be retained using an open source approach. Modularization makes it easier for others to contribute, but also allows the company to focus on controlling the key aspects that are most important to their business objectives.

The second hybrid strategy described by West is to impose disclosure or licensing restrictions that prevent the code from being shared or used in undesirable ways. The biggest challenge with this approach is building a healthy, self-sustaining development community around the open source components when restrictions govern how the software can be used.

Control Within Open Source Projects

It is important to examine the level and types of control available within open source software projects. At least in the area of control over development direction and quality, Gallivan (2001) identified strong explicit and implicit forms of control in open source development practices. Explicit control refers to rules and norms provided in the documentation and agreements; implicit control refers to the emphasis on individual reputation, which is an important currency in open communities, especially when non-monetary motivations are prevalent.

Similarly, Markus and colleagues (2000) noted the importance of both self-control and social control in virtual organizations generally and open source development communities specifically. In this context, the desire of developers to preserve and enhance their own reputation provides self-control mechanisms; in contrast, social control mechanisms ensure that developers are monitored by their peers, who provide openly positive and negative feedback, potentially including sanctions as a further extension of explicit control.

Companies can also exert control over development by offering incentives to developers to work on particular features or tasks (Dahlander, 2008). These incentives may include competitions or even financial compensation. Similarly, more and more open source developers are being paid by their employers to contribute to open source projects, which also provides a direct form of control from sponsor companies over development efforts.

The process of applying open source principles to a product opens the innovation process to individuals outside of the company. This process also requires a change to the company's business model and drives the need for entrepreneurs and senior management to make decisions around who will control a product's development and how this control will be exerted, both explicitly and implicitly.

Customer Control

Finally, companies should also view the control issue from the perspective of their customers. Although the company may be giving up a degree of control, one of the key benefits of open source software, as expressed by customers, is the increased control over their own business processes. While the provider company may not wish to reduce the switching costs of its customers through their support of open source solutions, this effect may be counterbalanced by an increase in customers who are attracted by the increased control offered to them.

Conclusion

Despite the success of many open source strategies, proprietary-minded companies may still fear the loss of control over product development, and the resulting impacts on progress, quality, competitive advantage, and the protection of intellectual property. Understanding the mechanisms of control inherent in open source projects and the benefits of hybrid approaches helps companies articulate these fears and make appropriate strategic decisions to match their business objectives.

Share this article:

Cite this article:

Rate This Content: 
No votes have been cast yet. Have your say!