Single-Vendor Open Source Firms (and Their Intellectual Property Strategies)

Dirk Riehle, dirk@riehle.org

An edited version was published in Computer magazine, April 2020

Abstract

This article present a particular business model for commercial open source firms, called the single-vendor open source model. This model has long dominated venture capital funding for open source software firms, contributing to the long-term sustainability of open source. As such, it is of high economic relevance. It is also an excellent example to show how open source licensing and related strategies really are just tools in the design of a business model and not philosophies.

1. Types of business models

A business model describes how a company operates and achieves its goals. Open source itself is not a business model, but it can be an important strategy to help a company reach its goals. While each firm has its own distinct business model, there are naturally distinguishable types of business models [1] [2] [3].

In my work, I have found three distinct coarse-grain types of open source business models, based on their value proposition and the intellectual property that supports it [5]. The three core models are:

1. Open source service and support firms,
2. Open source software distributors, and
3. Single-vendor open source firms.

Service and support firms do not necessarily own specific intellectual property, but rather service users of existing community open source projects. Open source distributor firms provide a complex assembly of community open source components as one well working product to its customers, but typically don’t own the components they distribute. Service firms scale mostly with labor, so of the two, only distributors can earn return on investments that make them of interest to venture capitalists.

2. Single-vendor open source

Single-vendor open source firms are software vendors that exclusively own some piece of software, which they provide to the world under an open source license. Typically, these firms develop the software themselves. They earn money through complementary (to the open source code) products and services.

In the design of their business model, such a firm has many options. To avoid confusion, I’d like to first clarify two strategies often used by these firms, called dual licensing and the open core model:

• Licensing strategy. In addition to providing an open source project to the world, the vendor also sells the software to customers using a proprietary license, together with the set of services and warranties that customers are usually asking for. Providing the software under two different licenses, one open source, the other proprietary, is called the dual (or multi) licensing strategy. This strategy was pioneered by Ghostscript provider Aladdin Enterprises [6].
• Intellectual property (IP) modularity strategy. Sometimes, the vendor withholds some functionality from the open source version and provides this functionality only as part of a paid-for version. Making a distinction between an open source core and non-open-source extensions that customers pay for has been called the open core model. In more general terms, it is called IP modularity [4].

There are at least three generations of companies that utilize the single-vendor open source model:

1. The pioneers. The idea of open source software owned and exploited by a single vendor dates back to the nineties. Pioneers include MySQL AB, Sleepycat Software, Inc., and Trolltech (now Qt Group).
2. The second wave. In the early two-thousands, entrepreneurs and venture capitalists realized that open source is an effective strategy for disrupting existing enterprise software markets. In 2004, newly incorporated single-vendor open source firm SugarCRM Inc. coined the term commercial open source to alleviate fears potential customers might have of open source software. Other examples are Jaspersoft, which was acquired by TIBCO in 2014, and MuleSoft, which went public in 2017, providing their investors the desired return on investment [7].
3. The current breed. The idea of single-vendor open source is well and alive in the current generation that started at around the 2008 recession. Example companies are MongoDB Inc., Redis Labs, and Neo4j Inc. The focus has shifted from enterprise applications to DevOps tooling and infrastructure, usually with a cloud component.

Some single-vendor open source firms have had sizable exits, including IPOs, and of the current breed, many are considered to be worth more than $1bn. No other type of open-source-based business model has seen this many companies with such returns on investment for its venture capitalists.

2.1 Revenue streams

Venture capital funding only flows if a firm can believably promise significant returns to their investor’s money, and single-vendor open source firms achieve this by promising the same revenue streams that traditional software vendors are offering.

Revenue streams must be based on some complement to the open source code, otherwise it makes no sense to purchase. These revenue streams consist of, but are not limited to:

1. Commercial license for core software and possible extensions
2. Guarantees like warranties, indemnification, and certification
3. Early and preferential access to bug fixes and new features
4. Support services like hotline support and on-site servicing
5. Operational services like hosting the software in the vendor’s cloud
6. Complementary materials for documentation, training, etc.
7. Access to self-help services like forums, chat bots, etc.

None of these revenue streams should be surprising to practitioners; they are common to traditional vendors and single-vendor firms alike. The main difference between single-vendor and traditional firms is that single-vendor firms often forego the initial license fee and start right away with what is traditionally called maintenance fees for the product and service. Charging maintenance fees is also often called the subscription model.

Increasingly, companies have been focusing on the cloud. The broad feature array listed above then gets focused on the vendor’s cloud service as the primary reason for a customer to buy.

The critical challenge of the single-vendor model that makes or breaks the company is how to turn non-paying users into paying customers. Behind each non-open feature is a motivation for a non-paying user to become a paying customer. For example, some users may not like a Coypleft-based open source license or they may need 24 hour support and so forth and hence may decide to upgrade to the paid version or service.

2.2 Business Functions

Given that product and revenue of single-vendor open source doesn’t look much different from traditional software vendors, one might wonder why the software is provided as open source software in the first place. Does it not only have downsides like not turning a user into a customer, because the open source version is sufficient and the services are not that important?

The short answer is that going-to-market with an open source strategy drives adoption faster, better, and cheaper than any comparable approach.

The longer answer as to why to open source some or all of the product is that it improves core business functions so that they become superior to traditional competitors. Marketing, sales, product management, engineering, etc. all are different but better with a single vendor strategy than without.

The source of this advantage is the community of non-paying users that is utilized by the different business functions for company gain.

2.2.1 Marketing

High quality software for free is a great value proposition. As a consequence, word-of-mouth marketing is particularly effective for single-vendor firms. Happy users like to talk about the software that makes their work life easier. They also make good reference material to the extent that they are willing to talk about their use of the software.

This helps build a large non-paying user base, which feeds sales, and which supports a more efficient and effective product management, engineering management, and support functions.

2.2.2 Sales

By open sourcing some or all of its product, a single-vendor firm allows potential customers to use its product with minimal friction. Unlike trials, open source licenses permit users to use the software as long as they want to, for whatever purpose. As a consequence, as long as the software fulfills the needs of its users, those users happily will keep using it.

From a sales perspective, having an installed base of non-paying users is not a problem but rather an opportunity. A single-vendor firm often tracks who downloads the open source software and gathers email addresses. Email addresses at corporations are a good indicator of a potential customer for a follow-up. Multiple email addresses of different users at the same corporation are a clear indicator that a sales call may be fruitful. This way, the open source strategy allows the sales organization to prioritize where to spend their efforts.

The actual sales process also becomes more effective. The initial users of the free version are often line-of-business (LoB) users, in particular for hosted software which can be subscribed to with a credit card. With multiple LoB users in one company, the IT department may want to rein in the use of the service and purchase it centrally. In a comparative evaluation of possible vendors, the single-vendor open source firm has a leg up on its competitors. Its product is already in use and has champions inside the buying organization, while its competitors do not. You can ask yourself: “What would you rather buy, a product from a vendor that you have yet to test and evaluate, or a product already in use at your organization where you can ask actual users about it?”

2.2.3 Product management

A large user base, even one including non-paying users, is a great resource for product managers to draw on for new product feature discovery. Product managers can do so by tracking user problems and requests in product forums. They can make an issue tracker publicly available so that users can report on problems and they can create user polls to prioritize upcoming features, among other things that product managers do. Due to the large user base, this takes place on a level of scale that traditional vendors at the same stage cannot match.

2.2.4 Engineering management

A large user base finds problems faster than a small user base. A user might not only file a bug report, they might also provide the patch that fixes the problem. In general, single-vendor open source does not expect the community of non-paying users to help develop the software, but they surely will not reject a code contribution if it happens. The submitter of a patch, however, usually has to sign over their copyright to the firm, as discussed in the section on intellectual property.

At the same time, occasional contributions by developers are an excellent indicator of that developer’s capabilities and potential interest in a position at the firm. Single-vendor open source firms use their community edition as a recruiting mechanism for identifying and acquiring engineering talent.

2.2.5 Product support

Non-paying users typically understand that open source software does not come with a right to support. As a consequence, and for many in the spirit of open source, users are willing to help each other. If the single-vendor firm provides appropriate tools like forums and wikis, users may become active to create documentation and self-help materials. Product support can benefit from understanding user problems and utilizing the materials users develop.

2.2.6 Community management

As explained, most of the benefits of open sourcing accrue due to a large but non-paying user base. Creating this user base comes at a cost, though: The company actively needs to manage this community. Community management requires labor. Community managers need to engage with the community, and should provide, for example, a website, forums and wikis, and a software forge.

Most of these costs are variable costs that scale with the number of users. Given that these are non-paying users and the hope is that its size grows as quickly and to as large as possible, the primary efficiency consideration of community management is how to scale with as little effort as possible.

Community managers achieve this using various best practices. Mostly, they try to establish a community that helps itself, and in which company resources are only the helper of last resort. If, for example, a non-paying user asks a question in a forum, a community manager will not answer directly. They will wait for another user to answer. If nothing happens they will nudge existing users to help out, and only if that doesn’t work, may they decide to provide an answer themselves.

3. Intellectual property

For the single-vendor open source firm, open sourcing their product to achieve the described benefits creates two additional business concerns:

1. How to motivate a non-paying user to become a customer of the commercial product?
2. What if a competitor takes the product and competes with the single-vendor open source firm?

Both problems are being addressed by the same intellectual property strategy. I have previously called it the intellectual property rights imperative of single-vendor open source firms:

Always act in such a way that you, and only you, possess the right to provide the open source project under a license of your choice.

By remaining the sole proprietor of the intellectual property, a single-vendor open source firm can multi-license, that is, provide the product under different licenses to different parties. Usually, it is only two different licenses: An open source license to build the large but non-paying user community, and a commercial license for paying customers.

3.1 Basic strategy

To remain the sole proprietor, the company must own 100% of the software, community-developed extensions notwithstanding. For this, it either initially buys or develops the software themselves. Community contributions are only accepted if the contributor signs over their copyright to the firm or provides it with a re-licensing right.

Almost always, the open source license is the most far-reaching reciprocal license available, which at the time of writing is the AGPLv3 license.

1. One goal of the AGPLv3 license is to make as many use cases of the licensed software as possible trigger the Copyleft clause of the license. Simplifying, this clause requires that in case of passing on the software (a “distribution”), all touched source code be laid open. Competitors, who distribute a modified product, can therefore do so only under the AGPLv3 license, preventing the creation of intellectual property unique to the competitor, and weakening their competitive position.
2. Another goal is to help make software patents go away through a patent retaliation clause. Again simplifying, the retaliation clause revokes the usage right of the software by the user in case of a software patent lawsuit being brought forward by that user against someone else.

Both commercial users as well as potential competitors generally dislike such licensed code. Thus, the choice of this license (a) motivates non-paying users to become paying customers and (b) discourages potential competitors from picking up the product and competing with the single-vendor open source firm.

Until recently, as the venture capital returns show, this intellectual property strategy worked well, and a single-vendor firm rarely faced serious competition from someone using the single-vendor firm’s product against them. The advent of large public cloud infrastructures, most notably Amazon Web Services (AWS), has changed this.

3.2 Cloud strategy

Increasingly, software products are being hosted in public clouds. The provision of their product as a cloud service is a key offering of many single-vendor open source firms. Users build applications utilizing the service. Example companies which do this are the aforementioned MongoDB, RedisLabs, and Confluent, all valued above US$1bn. For this to work, the vendor’s cloud service needs to be better than the user hosting the software in their own cloud. This can be achieved through additional functionality, as discussed, or simply superior and more cost-effective service. However, providing a secure multi-tenant cloud service at scale is not a trivial undertaking: It increases the engineering challenges of the vendor significantly.

The move into the cloud coincided with a shift from enterprise applications (second generation) to infrastructure software (the third generation). For developers, to use some open source software, it cannot have a Copyleft license that touches the developer’s code. Otherwise, the developer would have to open source their own product, which for most commercial development is not acceptable.

As a consequence, some single-vendor open source firms have packaged their Copyleft-licensed core using permissively licensed shims that shield user code from the Copyleft effect. A surprising consequence was that large cloud operators like AWS started to compete with single-vendor open source firms by offering the vendor’s product as their own using the open source license. With pure Copyleft licensing by the vendor, this would not have happened, because no cloud operator would like to open source their own infrastructure software.

As a consequence, some single-vendor open source firms have changed their licensing to proprietary “almost open source” licensing. An example of such “almost open source” licensing is MongoDB’s Server Side Public License. This license is similar to the Apache 2.0 license, but does not allow for competition with MongoDB using its software. After intense discussion, the Open Source Initiative, the provider of the open source definition and arbiter of licenses decided that the SSPL is not an open source license. As a consequence, MongoDB and others who took similar measures are not considered open source companies any longer.

The licensing change drew the ire of the open source community at large and generated bad publicity. However, those vendors who took this step were all mature and successful vendors whose product could stand on its own without an open source license. Whether this will be possible for less mature vendors remains to be seen.

4. Summary

Single-vendor open source firms have positioned themselves as superior successors to classic proprietary software vendors, utilizing an open source strategy to drive adoption in the market and to enable better business functions. However, the move of applications and components into the cloud has opened the door to competition by large cloud vendors, leading to changes in the licensing strategies, with unclear consequences for the future and the viability of the model.

Acknowledgments

I would like to thank Ann Barcomb, Andreas Bauer, Maximilian Capraro, Michael Dorner, Nikolay Harutyunyan, Joseph Jacks, Andreas Kaufmann, Heather Meeker, Georg Schwarz, and Mathias Zinnen for feedback on earlier versions of this article.

References

[1] Capra, E., & Wasserman, A. I. (2008). A framework for evaluating managerial styles in open source projects. In IFIP International Conference on Open Source Systems (pp. 1-14). Springer, Boston, MA.

[2] Daffara, C. (2007). Business models in FLOSS-based companies. In Workshop presentation at the 3rd Conference on Open Source Systems (OSS 2007), 1-8.

[3] Ågerfalk, P. J., & Fitzgerald, B. (2008). Outsourcing to an unknown workforce: Exploring opensourcing as a global sourcing strategy. MIS quarterly, 385-409.

[4] Henkel, J., Baldwin, C. Y., & Shih, W. (2013). IP modularity: Profiting from innovation by aligning product architecture with intellectual property. California management review, 55(4), 65-82.

[5] Riehle, D. (2012). The single-vendor commercial open course business model. Information Systems and e-Business Management vol. 10, no. 1, pp. 5-17. Springer Verlag.

[6] The information about Ghostscript was added after publication and was provided by Marten Mickos in an email of 2020-04-13.

[7] The original article stated that Mulesoft was acquired, but it actually first went public; this correction was provided by Marten Mickos in an email of 2020-04-13.