Control Points and Steering Mechanisms in Open-Source Software Projects

Citable reference (including PDF file)

Most commercial software today depends on open source software. The commercial software might be using an underlying open source platform, or it might be incorporating open source components, or it might be provided as a commercial open source product itself. Whichever the case, the software firm behind the commercial software needs to ensure that its interests are met by the open source software projects it depends on. This article shows how commercial software firms manage or steer open source software projects to meet their business needs.

1. Introduction

Open source software has become an important part of the software business. In a large 2009 survey, Forrester Research found that 46% of all responding enterprises were using or implementing open source software [3]. Moreover, in 2009 Gartner Group estimated that by 2012, at least 80% of all software product firms will use open source software in their products [2].

With open source software being an important part of closed source software products in addition to being its own product category, it is important to understand how software product firms depend on open source and how they manage that dependency to meet their business goals.

In this article, we classify software product firms into three main categories: Traditional closed source firms, single-vendor open source firms, and open source distributors.

• Closed source firms are software firms that own all competitively differentiating software components their product is based on; these components are all closed source. Product examples are Microsoft’s Windows, Oracle’s same-name database, and SAP’s Business Suite.
• Single-vendor open source firms also own all competitively differentiating components, but they make some or all of these available as open source [6]. Product examples are Alfresco’s same-name product, Jaspersoft’s BI tool suite, and (formerly) MySQL’s same-name database.
• Open source distributors are firms that integrate a large set of open source components and distribute the assembly for a fee. Distributors typically don’t own their components. Product examples are Suse’s Linux, Red Hat’s Linux, and Acquia’s Drupal.

What is common to these three types of firms is that in some form they exclusively own some intellectual property they capitalize on. In the case of closed source and single-vendor open source firms, it is the software itself, in the case of distributors it is the branded configuration. Thus, in this article we are not talking about pure services firms selling consulting or maintenance services. Also, our analysis is independent of the software delivery model, be it on-premise or hosted (software as a service).

It is important to understand that while open source may be freely available under an open source license, open source software nevertheless has an owner. There are two main forms of ownership:

• Single-vendor open source software. This type of software has a single legal copyright owner, typically a software firm, that aggressively maintains its ownership rights [6].
• Community open source software. This type of software either has a diffuse set of owners (the code contributors) or is owned by a foundation, acting on behalf of its members [1] [8].

Moreover, it is important to understand the two main categories of open source software licenses. For the purposes of this paper, we simplify these categories to reciprocal (“viral”) and permissive licenses:

• The use of an open source software component under an reciprocal license may require a firm to open source its product source code. Examples licenses are the GPL and AGPL licenses.
• The use of an open source software component under a permissive license does not require such open sourcing. Example licenses are the Apache and BSD licenses.

How then does any of the three types of software firms depend on any of the two types of open source projects and what are their business goals for employing open source?

2. Software Products and Open Source

Any real-world software product is made from multiple software components, all of which may have different licenses and hence come with different usage conditions. Figure 1 identifies the different types of components one might find in a software product.

The product illustrated in Figure 1 has a closed source and an open source part. In the closed source part, we find owned and licensed closed source:

• Owned closed source are software components that the firm owns and uses it in its products. Ideally, they help to differentiate the product from its competitors.
• Licensed closed source are software components that the firm licenses from other software firms in order to complete their product.

A closed source software firm, by definition, builds its products this way. A single-vendor open source firm may have closed source components in its products if it distinguishes a commercial version of its products from an open source community version through feature differentiation (so-called open core model). Open source distributors typically don’t have closed source components in their offering.

In the open source part of the component stack in Figure 1 we distinguish single-vendor open source from community open source:

• Single-vendor open source are software components that a firm owns but makes available to the world under an open source license for strategic reasons [6].
• Community open source are software components owned by a community of stakeholders, that is, they are not under the control of a single legal entity [7].

Closed source software firms don’t offer open source components; single-vendor open source firms do so by definition. All three types of software product firms use community open source. Closed source firms and single-vendor open source firms prefer community open source that comes with a permissive license in order to not risk having to open source their closed source components. Open source distributors use all types of open source irrespective of their license because their competitive differentiator is not the software itself but their capability of keeping the components configured and integrated.

Jaspersoft is a single-vendor open source firm that provides business intelligence software products, most notably JasperServer, a report generator. In its enterprise edition, JasperServer contains closed source code owned by Jaspersoft, it builds on the open source community edition of JasperServer which it wholly owns, and it uses community open source packages like Hibernate, an object to relational database mapper. JasperServer runs on both Windows and Linux.

Our analysis of various product component stacks and the corresponding firms’ behavior identified the following three strategic business goals:

• Reduce development costs. Closed source and single-vendor open source firms use community open source or license closed source to reduce development costs.
• Maximize customer exposure. Single-vendor open source firms actively promote their open source project with the strategic goal of selling a superior product faster at lower costs.
• Minimize competition. Open source invites competition, and both single-vendor open source and open source distributors employ various strategies to keep competition at bay.

Maximizing customer exposure is a catch-all for the benefits expected from open sourcing one’s intellectual property. The benefits derive from a self-sustaining community around the project, as we discuss elsewhere [6]. Maximizing customer exposure and minimizing competition are strategic goals joined at the hip. Firms have to open source to get the benefits of an open source go-to-market strategy, but that same move invites competition they now have to deal with.

Reaching these business goals requires that the software firm actively manages or at least influences the open source projects it depends on.

3. Control Points and Steering Mechanisms

Software products firms use a toolbox of mechanisms to manage open source projects to varying degree to support their business goals. In the following, we discuss how these mechanisms help meet business goals, depending on the type of open source component at hand. In the discussion, we distinguish control points (enforceable through the legal system) from steering mechanisms (not enforceable through the legal system but based on social contracts and corresponding behavior).

We identified the following control points that give a firm significant control over an open source project:

• Copyright. While a software firm may grant third parties usage rights through an open source license, it may retain ownership of the copyright. As the owner, it can stop third parties from using the software under a different license than the open source license.
• Trademarks. Almost all software embeds trademarks in the form of logos or slogans or names. Trademark owners can stop third parties from using trademarked open source software as is, requiring the potentially expensive removal of the trademarks.
• Domain ownership. Owning domains that users and customers look up for information about a product are an important means of influencing customer perception. Trademarks allow stopping competitors from using domains with similar names.

One might have expected patents to be in this list. However, patent-based lawsuits are mostly used by software firms to stop other firms from using a particular software, the one violating the patent owner’s rights. Patents are typically not used to exert control over an open source project that a firm’s own products build on and hence are not relevant to this analysis. In addition, with increasing dependence on community open source, retaliation clauses in the community open source licenses push back patent lawsuits. The retaliation clause retracts usage rights from the suing party, making the lawsuit potentially hurtful to the plaintiff.

Next to these control points, we identified the following three steering mechanisms that allow a software firm to influence a project’s direction.

• Social leadership. Leaders of open source projects have substantial leverage to direct that project. This includes the early license choice, the project culture and corresponding practices, and how the release plan and feature road-map develop.
• Development process. To the extent that a firm employs the developers on a project, it can influence the development process. Actual development may not be public, code contributions may be time-delayed, only snapshots may be provided, etc.
• Strategic positioning. Some marketing and outreach channels are better than others. Most notably, open source foundations provide important marketing opportunities. By locking up a project, firms can improve their customer exposure while keeping competition at bay.

In the following, we discuss these mechanisms and how they help reach business goal. All mechanisms are multi-purpose with possibly broad effects.

4. Use of Control Points

We have identified the following practices around control points and how software firms use them to achieve some or all of the business goals of reducing costs, maximizing customer exposure, and minimizing competition from the open source project.

4.1 Copyright practices

Copyright practices are most important for single-vendor open source firms. They are used to minimize competition. Single-vendor open source firms open source some or all of their product components, giving the world corresponding usage rights to their software. However, for components considered competitive differentiators, single-vendor open source firms will want to avoid that competitors utilize their work to compete with them. In addition, single-vendor open source firms typically want to be able to sell a commercial license for the same software they make available as open source, because some customers simply insist on a commercial license.

There are two best practices that single-vendor open source firms use to control projects they open source:

• They maintain effective ownership by requiring a copyright transfer for any outside code contribution. The copyright transfer is realized by having contributors sign a copyright transfer agreement (sometimes relicensing rights grant). The agreement serves to transfer not only copyright but also to settle other issues like patents employed in the contribution.
• They use an aggressive reciprocal license for the open source software that will require that any competitor’s software built on the open source software will have to be open source as well. No traditional competitor will touch this software then, because it prevents the creation of competitively differentiating closed source software.

With copyright ownership maintained, the single-vendor open source software firm can sell a traditional closed source license while still reaping the benefits of an open source strategy its products.

The details of contributor agreements and open source license choice depend on the particular business model of the single-vendor open source firm. Typically, the GPL license is used, and we expect an increased use of the AGPL license as the world moves into the cloud.

Closed source software firms don’t open source competitively differentiating components and hence don’t have to worry about this issue. Open source distributors don’t rely on individual component control and hence contribute to open source without worrying much about copyright.

4.2 Trademark practices

Trademark practices are most important for open source distributors, but they are also used by single-vendor open source firms. Closed source software vendors use trademarks as well, but not in open source projects. Trademark practices are used to minimize competition.

Open source distributors heavily invest into their brand and corresponding trademarks, because it is the one thing that will set them apart from any competitor utilizing their work. Since distributions are typically built from community open source, anyone can take an open source distribution and provide commercial services around it.

Trademarks, like copyright and patents, are exclusive rights. Thus, competitors can’t use a firm’s distribution as is, but will have to remove the distributor’s trademarks first. The original distributor may want to make it as hard as possible to remove its trademarks to induce as long as possible a time delay between its own release and a competitor’s re-release of the same software.

In addition, removing well-known branding reduces the value of the software in the eyes of customers as the original firm and its capabilities obviously do not stand behind it any longer. Moreover, smart certification programs tied to the branded distribution increase its value further while decreasing the value of non-branded or re-branded distributions.

In a similar fashion, single-vendor open source firms brand their open source projects, threatening to sue any potential competitor who uses the software without having removed the trademarks first.

4.3 Domain ownership practices

A third control point is Internet domain ownership, where the domain names are typically reflective of the firm’s products. Domain ownership is used to maximize customer exposure. Like trademarks, this applies to all three types of firms, but only single-vendor open source and open source distributors utilize it to protect their open source intellectual property.

Both single-vendor open source firms and open source distributors maintain domains that represent their products to interested parties. By managing the corresponding websites they determine what third parties learn about the software, which in turn supports their respective business goals.

These firms then use trademarks to exclude competitors from buying and using domains that might infringe on their trademarks, thus maximizing customer exposure while minimizing competition.

5. Use of Steering Mechanisms

The control points are exclusive rights that are enforceable by law. In addition, we have identified the following steering mechanisms that–while not enforceable by law–can be equally powerful.

5.1 Social leadership practices

Social leadership plays out differently, depending on the type of firm and type of open source component. Mostly it is used to reduce development costs, but it can also be used to maximize customer exposure.

In single-vendor open source, the firm employs most or all of the key developers. At least some of them can fulfill public leadership roles. In this capacity, developers can nudge the community to focus their attention and possible contributions onto different aspects of the software, depending on the firm’s needs. As Marten Mickos observed, only a small fraction of software development cost is actual programming costs–quality assurance and testing easily consume as much if not more time and money [5]. Thus, any contribution that the firm can gather from the open source community is likely to help reduce software development costs.

Both closed source and single-vendor open source software firms use community open source in their products to reduce development costs by reusing well-working software components for free. Thus, they will want to ensure the open source software keeps meeting their needs.

In community open source, a firm can also gain influence by hiring developers and putting them to work on the open source project. To the extent that these developers focus on making the software work for their employer, the resulting community open source software will help the firm save development costs. Thus, the work of a few developers may allow for the use of a much larger software component and corresponding cost savings. The more influential the employed developers, the more they will be able to lead the community to activities that will benefit their employer and increase development cost savings.

The actual influence of a developer in a community open source project evolves over time. An extreme but important case is being a founder of the project. Most notably, twenty years after the Linux project was started, its founder Linus Torvalds remains the final arbiter of technical decisions over the Linux kernel thanks to the unique hierarchical development structure that he created. Other projects, for example PostgreSQL or the Apache projects, take a more egalitarian approach.

Social leaders of a project then use their position to craft a particular culture that attracts or repels people, and they can use it to perform or direct work to the benefit of their employers. One might think that this creates push-back from the broader community for suspicion of conflict of interest, but in general it is well understood that if someone performs work to the benefit of the whole project that person gets to choose what to work on.

Social leadership in community open source projects can also help single-vendor open source firms and open source distributors maximize customer exposure. Highly visible developers can use their position to reach out to the users of the community open source project and piggy-back a message onto their outreach. That message typically conveys how well the commercial product, be it single-vendor open source or an open source distribution, works with the community open source project they are representing. The form of outreach ranges from mailing list activities to conference speaker engagements and industry publications.

5.2 Development process practices

Both single-vendor open source firms and open source distributors use development process practices to minimize competition. Common practices include:

• Closed rather than open development. This way, competitors don’t know what’s coming nor can they adjust their own software to trail the changing code base.
• Snapshots of the code base rather than a full development history. By not providing the full history, maintaining and working with branches becomes impossible.
• Delayed or hidden publishing of source code after release of binaries. The firm may choose to delay or hide the release of the source code over the release of the binary.

The main purpose of such practices is to gain a time advantage over any possible competitor. With a significant time delay before they can catch-up, competitors find themselves at a disadvantage for utilizing the code. Sometimes, the firm doesn’t actually have to do any of these things–the threat may be enough to keep competitors away.

Another important reason is that firms sometimes don’t want their competitors to know early what they are developing. For example, hardware firms frequently perform closed development of the necessary Linux drivers of their new devices, even though the Linux kernel community demand they don’t [4]. Open development would let competitors learn early, from the code, about the specifics of the new devices and hence give the developer’s competitive strategy away.

Sometimes, firms can lock-up a community open source project by employing all core developers (“committers”) who then won’t accept anyone into the inner developer circle who doesn’t fit the firm’s strategy. However, in community open source, such behavior is likely to be detrimental to project success unless combined well with strategic positioning practices, see below.

Employing key developers is crucial to being able to establish and follow an appropriate development process that fits the employing firm’s business strategy.

5.3 Strategic positioning practices

Through smart strategic positioning, closed source and single-vendor open source firms can utilize community open source to maximize customer exposure while minimizing competition. Since they can’t do it by selling the community open source, their revenue must come from an extended or complementary offering. An example is Actuate, which is the main developer of the BIRT report designer, an Eclipse Foundation project. Actuate’s main actual revenue is from a complementary report generator.

Strategic positioning is best done by creating a community open source project under the hood of an established open source foundation. The foundation lends credibility and visibility to the project. By making one of the two or more complements available as community open source, closed source and single-vendor open source firms can utilize the supporting foundation as a marketing channel to maximize customer exposure.

To the extent that the foundation lets the firm lock up the project, the firm can also minimize the competition arising from the community open source project. For this to work, the firm has to dominate the project. This can be achieved by employing all or a majority of core developers to the project, who may then exclude anyone else from joining. This ensures the projects moves according to the firms goals.

Naturally, foundations don’t like such lock-up and work against it. The Apache Software Foundation, for example, allows for competing community open source projects and requires for any project to be accepted to show a diversity among the core developers.

Joining a foundation also serves to protect a software firm from lawsuits. To the extent that the community open source projects is part of the foundation, that foundation may protect it and the firms behind it. The public backlash over lawsuits against a community open source project may well make a potential plaintiff shy away from suing the original software vendor.

6. Conclusions

Software product businesses seeking to benefit from open source projects have three main goals: To reduce development costs, to maximize customer exposure, and to minimize competition from open source. To achieve these goals, software businesses rely on a toolbox of practices using control points (enforceable by law) and steering mechanisms (social contracts). Our analysis identifies the control points to be the established exclusive rights of copyright, trademarks, and property ownership (but not patents) and the steering mechanisms to be social leadership, development process, and strategic positioning. The article summarizes the practices around these mechanisms.

Acknowledgements

I’d like to thank my Ph.D. students Hannes Dohrn, Carsten Kolassa, and Michel A. Salim for providing thoughts and feedback that helped improve this article.

References

[1] Eugenio Capra, Anthony Wasserman. “A Framework for Evaluating Managerial Styles in Open Source Projects.” In Proceedings of the 4th International Conference on Open Source Systems (OSS 2008). Springer, 2008: Page 1-14.

[2] Mark Driver. “Key Issues for Open Source Software, 2010.” Gartner Research: 2010.

[3] Jeffrey S. Hammond. “Open Source Software Goes Mainstream.” Forrester Research, 2009.

[4] Greg Kroah-Hartman. “The Linux Kernel Driver Interface.” Blog entry posted on December 3, 2004.

[5] Marten Mickos. “Open for Business.” Presentation given at PARC on April 8, 2010.

[6] Dirk Riehle. “The Single-Vendor Commercial Open Source Business Model.” Information Systems and e-Business Management. Springer Verlag, 2011. Forthcoming.

[7] Dirk Riehle. “The Economic Case for Open Source Foundations.” IEEE Computer vol. 43, no. 1 (January 2010). Page 86-90.

[8] Dirk Riehle. “The Economic Motivation of Open Source: Stakeholder Perspectives.” IEEE Computer vol. 40, no. 4 (April 2007). Page 25-32.