"The key for us is to know what’s going on in different communities in order to assimilate that information and use it in our products. We follow a massive number of communities and what they develop, but only have the resources to build competences to use them in a handful."

Interviewee from SOT Finnish Software Engineering Ltd.
Quoted in Dahlander & Magnusson (2008)

Abstract

This article explores the relationship between firms and open source communities. Open source communities create, adopt, adapt, or disseminate innovation in a manner very different from a proprietary approach. To put this in context, we first define what is meant by open source community and then examine the roles members may play in these communities. Next, we illustrate that a firm can participate in an open source development community in different ways, depending on its level of sponsorship of that community. We assert that the degree of influence desired by the firm should connect to its business strategy and the firm needs to determine how its participation and support can be used to enhance its competitive position and provide new value to its customers. We next explore three main strategies to leverage and engage communities. We also examine how community interactions are affected by the degree of openness when engaging the community and how this relates to the firm's ability to protect the competitive advantage of its proprietary assets. This discussion will help firms with strategic planning when considering how to tap into this source of technical innovation that lies outside their boundaries.

Introduction

The success of free/libre open source software (F/LOSS) has focused attention on open source communities. These communities create, adopt, adapt, and disseminate innovation in a manner very different from the traditional commercial approach. Before analyzing the role and impact of open source communities on creativity, it is important to first understand what is an open source community. Many refer to them as innovation communities, knowledge-production communities, online communities, technical communities, among other names. But such a list does not provide much insight into what differentiates an open source community from other communities. A definition is required so that we may identify open source communities.

In this article, we use the following definition: an open source community is an interacting, self-governing group involved in creating innovation with members contributing towards a shared goal of developing free/libre innovation. This does not mean that active members of an open source community cannot be commercial firms or employees of those firms, but the scope of control, the innovation drive, and the resulting innovation are mainly governed by the rules set by open source community itself.

A firm (a corporation or business that generates revenue from the sale of software products or services) can have three basic relationships with a software development team (Figure 1). In the classic proprietary model, the software development team are all employees of the firm. In the two F/LOSS development models, the development team can be thought of partially or wholly residing outside the firm. The notion extends beyond the affiliation of a given developer to the firm (i.e., an employee-employer relationship) and includes the degree of influence on the decision-making processes in the project. This includes such factors as features, release schedules, and the direction of the project.

Figure 1: Relationship Between Firm and Development Team Under Different Software Development Models

Open source communities are an important source of technical innovation that has helped many firms develop successful market and profit strategies. This further increased the interest in studying the creation of these communities, and subsequently how firms can strategically leverage this source of innovation. As such, it became important to understand how a firm can relate to and interact with open source communities, to both enhance the firm's opportunities and bring value back to that community. The best place to start is in understanding the fabric of these communities.

Roles in Open Source Communities

Members in an open source community seek different benefits from their participation, but have a common interest in creating the open source solution. The community is made of members that can be either firms or individuals. These members constitute the governing body, sponsors, suppliers, complementors, developers, testers, single and enterprise end users, advocates, promoters, and legal experts. The motivation for joining and contributing to the community can vary. For a firm, it can be to extend their market reach, to provide a non-proprietary solution to their customers, to contribute to the public good, or to learn from and use the resources in the community. By participating, it increases the firm's opportunity to sell complementary assets and services to users and other members of the open source product.

The momentum of open source is perhaps a component of a more general trend towards openness in innovation. This shift to collaboration and partnering with communities is evident in the many dynamic roles firms have taken in the open-source environment. These roles are mainly:

• supplier partnering and co-development

• customer-based co-creation and crowd-sourcing initiatives

• co-opetition (competitive cooperation) with rivals

• open-source community extensions to internal development resources

• development of consortia

• open-outsourcing design and engineering to instantiated or existing open source communities for initial or further development.

In return, open source communities play important roles within this business environment:

• contributing to innovation and the creative process

• advocacy and marketing of the product of open source design

• complementing competitive strategy and creating alternative business models

• providing feedback, testing, and bug reporting

Because these roles played outside of the firm, their management requires a very different approach from the traditional "command and control" relationships in a business organization. It is more of a collaborative and open approach to making decisions, an approach that is a result of the historical roots of the open source movement and its emphasis on the community principles of inclusion and meritocracy.

Strategy and Communities

F/LOSS and its communities are tools that provides a new degree of freedom for developing a firms’ business strategy. Participation in a F/LOSS development community is an important strategic decision. A firm must first determine how it can leverage the community to enhance its competitive advantage and provide new value to its customers. Table 1 provides some examples of why participation in F/LOSS development may provide new opportunities or cause undesired side effects for a firm.

Table 1: Reasons for a Firm to Engage in F/LOSS Development*

Reason	Possible Strategic Implications
Promoting open development communities that create new business opportunities through adoption by customers and their suppliers	Need to define the firm's role in fulfilling customer needs in a heterogeneous environment
Promoting company branding with an increased mind share with developers in the open source community	Need to connect with the complementary products that support the firm's brand
Sustaining a product line in a small or declining markets and profit from sales of complementary assets.	Need to manage the loss of control in servicing this market.
Promoting an open standard and benefit from the network effect of expanded market share	Need to fit the open standard with product and business goals
Lowering development costs by building from open source components with more effort spent on the differentiating items for which customers are willing to pay	Need to manage the contributions back to community (required or desired) and how this may limit the ability to directly profit from code
Accelerating time to market by reusing open source components with proven functionality making it easier and faster to demonstrate capability	Need to pay attention to licenses and the possible need to rewrite code used in prototyping

*Derived from Capek (2008) and Weiss (2010)

As an example, a firm may find itself in a weak position competing against a more popular, but proprietary product. By releasing their code base and creating a F/LOSS community, they disrupt the competitive environment. New players are brought into the game, attracted by the lower costs to access this market. Every new entrant adds momentum to the open source alternative and creates new value for end users through an expanding diversity of options and overall lowered cost structure. An implication for the firm is that it will find itself now competing against new entrants in this market, each of which is leveraging the same open source solution and community. The firm must therefore think carefully about what other value they can bring to their customer base and how they will compete and profit in this new environment.

How Open is Open Enough?

There are degrees of openness. A firm must consider how open is open enough with respect to both engaging the community and protecting the competitive advantage that proprietary assets can bring to the firm. This is not an all-or-nothing situation; many firms take a balanced or hybrid position. A firm can open commoditized layers that no longer bring a competitive advantage and continue to control others that continue to differentiate their product. Table 2 summarizes the options available to firms with respect to the openness of product development.

Table 2: Product Development Openness Options*

Product Development	Characteristics
Proprietary	pioneering strategy establishes barriers to imitation appropriation of returns to platform owner winner takes all
Open standards	favoured when a firm has low market share or limited market power changes the balance of power based on adoption of open standards and shifting competitive advantages to other layers more complicated to manage; may cause loss of revenues and lock-in competition is based on marketing, customer service, product design, and operational efficiency offensive strategy is to speed the adoption of a standard and other positive network effects
Open source	compete based on implementations, rather than erecting barriers to imitation disclosing the technology prevents appropriation of the returns by any single firm hybrid is a balanced approach that opens access to commodity layers while controlling or complementing layers to retain the opportunity for differentiation increases interoperability the partly open variant should have restrictions but still provide value to customers limits the ability of competitors to use it directly

*Derived from West (2003)

In determining the openness of its strategy, a firm might want to answer the following questions:

• How does pursuing such a strategy enable value to a broader base of users (e.g., through reliability, quality, cost, variety, and the availability of complementary assets)?

• Will the firm be able to attract a critical mass of developers to serve these users?

• How will sharing increase the overall returns to suppliers of complementary assets (positive feedback due to network effects) and thus justify their participation in the community?

• How will the approach create lasting barriers to imitation?

• Is the approach likely to create a competitive advantage because it add to customer value?

Leveraging F/LOSS Communities

Once the decision has been made to leverage F/LOSS, it is important to consider how to engage and leverage these development communities. Software firms make use of open-source communities that are associated with their use, and benefit from the creative ideas of individuals outside the company. But the inflow of such ideas does not happen spontaneously. The community can help firms increase the resources they can draw upon in the innovation process, and the firms must identify where the knowledge resides and how it can be captured and subsequently used. The table below shows three strategies of engaging communities. They are accessing, aligning, and assimilation:

Dahlander and Magnusson (2008) have identified three strategies that firms can employ when engaging open source communities: accessing, aligning, and assimilating.

The accessing strategy extends the resource base by creating new communities that attract outsiders to firm’s area. Firms in these communities identify and expand niches by developing unique offerings, attracted by the opportunities that mass customization brings. To sustain these communities, it is important to establish critical mass and firms must invest in the community. These communities themselves are a good marketing channel and can enhance a firms brand. Alternatively, a firm can invest in one or more existing communities without the need to build a new one from scratch. This avoids the cost and risks related to community building but does have a drawback of fewer opportunities to directly influence or control the community.

The second strategy is to align the firms strategy with that of the community. Alignment is not without its challenges since members are often driven by different motives. One particularly important element to clarify is ownership of the source code, which impacts the basis for collaboration between the firm and the community. Clarity in licensing is needed for mutual trust and to avoid conflicts. Another alignment tactic is to influence direction of the development by providing incentives and creating stimulating challenges. This can be done through competitions and awards for developing specific features.

The third and final strategy is to assimilate the work developed in open source communities. This does require resources to evaluate and select source code from communities. The parameters for selection must include how the license may determine the future degree and scope of control over the entire code base. The firm also needs to decide what tasks are best done internally and how to best leverage the community resources. In a reverse flow, non-strategic source code can be delivered to the community, building legitimacy. Of course, a careful decision must be made as to what remains proprietary and outside the scope of community development, given that competitors will have equal access to the code and cannot be excluded from the distribution.

Firms can use these strategies to effectively scan the environment, evaluate the developments outside the core areas of activities, and rapidly integrate the external knowledge and its components to its products and services. Use of these strategies is fundamental to developing and sustaining a competitive advantage if a firms shifts from internal development and manufacturing to assembling knowledge and components available through open source communities. When firms rely heavily on communities, the potential for firms’ specific knowledge to provide competitive advantage will be reduced. Using communities is a way for a firm to increase the total amount of resources it can draw upon in the innovation processes, but at the same time there is a counter-acting need to appropriate the potential value of an innovation by limiting other firms from accessing to the same resources and information. The distributed nature of open source innovation puts different demands on firms aiming to use the knowledge residing in these communities for their business purposes and calls for new means to coordinate and control the development and use of knowledge over time.

How to Build an Open Source Community

It is easy to start a F/LOSS project but it difficult to succeed with it. There are many more failures than successes in open source projects, with figures from SourceForge suggesting that 80% of all hosted projects account for a very low proportion (0.5%) of total downloads. This should not be surprising; many things driven by human social dynamics follow such power-law relationships. Therefore, there is a real need to establish a critical flux of support and activity in the community. In simple terms, this means recognizing that there is competition for resources and the project initiator must pay attention to both attracting and motivating developers for their project.

Joining or forming a F/LOSS community is not without its costs, either to individuals or firms. But in an open source community there is no singular source of binding financial compensation for the membership. Therefore, there is a need to contend with the lack of traditional command-and-control methods and to deal with the generally higher turnover, a usual feature of F/LOSS communities. Understanding the joining process will help manage the barriers to joining that new community members face. Typically joiners must show technical expertise to make a contribution, which follows the principle of meritocracy. The joining script is behavioural and is based on the type and intensity of the activity. Often starting with lurking (quietly viewing) or reporting a bug, users will generally have to find a place to make a contribution themselves. Other project aspects can be reviewed to reduce the barriers to joining, which includes modularization, forum management, documentation, design framework for adding features independent of the kernel, and choice of programming languages. There is also a need to establish trust within the community, which might include commercial firms. This includes making a clear licensing agreement and appropriating and sharing of value among members of the community.

Conclusion

F/LOSS and its communities help firms tap into a source of technical innovation outside the boundaries of the firm. Going down this path will often require revisiting and tuning the firm's product and business strategies so it can profit from the new value that comes from the contributions of the whole community. In this article, we have shown how the creation and strategic cooperation with these communities can both enhance the firms opportunities and bring value back to that community.

Recommended Reading

• The Art of Community: Building the New Age of Participation, by Jono Bacon

• The Metropolis Model: A New Logic for Development of Crowdsourced Systems, by Rick Kazman and Hong-Mei Chen