Dirk Riehle, firstname.lastname@example.org
In this article, we define and discuss one particular commercial open source business model, called the (open source) distributor model. It has been popularized by Linux distributors like SUSE and Red Hat and is one of two business models that can attract significant venture capital, thereby contributing to the long-term sustainability of open source.
1. Types of business models
A business model describes how a company operates and achieves its goals. Open source itself may not be a business model, but it can be an important strategy to help a company reach those goals. While each firm has its own distinct business model, there are naturally distinguishable types of business models   .
In our research, we have found three distinct coarse-grain types of open source business models, based on their value proposition and the intellectual property that supports it . These three models are:
- Open source service and support firms,
- Open source software distributors, and
- Single-vendor open source firms.
Service and support firms typically do not own specific intellectual property but rather service a small number of existing community open source projects. Single-vendor open source firms provide a product that they typically develop themselves and of which they own the key intellectual property; unlike traditional software vendors, however, they make some or all of the software available under an open source license, in addition to a commercial license and services .
2. The open source distributor model
Open source distributor firms are software vendors that build a cohesive product from existing open source components that they typically don’t own. The core focus of a distributor is on making a large set of possibly disparate components work together well so that they can be used by customers with as little problems as possible. The corresponding core intellectual property of open source distributors therefore is not the software itself, but rather centers on component integration. It includes build systems and processes, compatibility matrices, configuration databases, and test suites.
The general public mostly associates Linux distributors with this business model. Prime examples are SUSE, Red Hat, and Canonical, provider of Ubuntu. There are also many smaller domain-focused Linux distributors like Univention, the provider of a Linux distribution to the public sector.
However, there are many other distributors and distributions. They typically emerge where integration complexity is too much for users to handle themselves. One example is Mirantis’ OpenStack distribution, another example is Acquia’s Drupal distribution, and yet another example is the EasyEclipse PHP distribution of plug-ins for the Eclipse integrated development environment. Sometimes, larger distributions incorporate smaller distributions.
2.1 Revenue streams
Venture capital funding only flows, if a firm can believably promise significant returns to their investor’s money, and open source distributors achieve this by promising many of the same revenue streams that classic software vendors promise.
These revenue streams consist of, but are not limited to:
- Services like hotline support and remote or on-site servicing
- Access to software updates, incl. new features and bug fixes
- Guarantees like warranties, indemnification, and certification
- Commercial license for proprietary tools and trademark use
- Operational services like hosting the software for customers
- Complementary materials for documentation, training, etc.
- Access to self-help services like forums, chat bots, etc.
None of these revenue streams should be surprising to practitioners; they are endemic to traditional vendors and distributors alike.
Distributors can often sell a commercial license, even if the product consists mostly of (single-license) open source software. This is possible, because next to source code, other forms of intellectual property are being integrated. The most noteworthy intellectual properties are trademarks that the distributor owns and that are being displayed in various places to inspire user confidence in the quality of the software. Other intellectual properties can be scripts and configuration files that tie the system together and make it function well and that are not necessarily provided under an open source license.
Such mixing of proprietary intellectual property with open source would probably allow a distributor to prevent the use of the distribution by non-paying users. In practice, this rarely happens. For example, the CentOS project, an independent community project, provides the most recent Red Hat Enterprise Linux (RHEL) release, stripped of the Red Hat trademarks, to the world, for free. The CentOS release is often available within a day after the corresponding RHEL release.
A main difference between distributors and traditional software vendors is that distributors generally forego an initial license fee and jump straight to a software subscription. A software subscription is a bundle of services and rights, as described before, provided to customers for a defined time-period, for example, a year. Traditionally, this was called and managed as maintenance.
2.2 Business Functions
Distributor firms do not own the source code of much of that they are integrating into a viable product. Rather, they use original open source components, build them from source, and integrate them with many others, so that taken together they become the intended product.
There are three main aspects of the distributor model, that are different from traditional product vendors and make this model unique and successful:
- A distributor participates in the development of the software components from which the product is built. They do so, however, not exclusively but rather together with other companies. This can easily be the largest engineering cost of the distributor, yet it does not provide a unique competitive advantage to the distributor.
- The actual product, the distribution, is not a set of components, but rather the well-integrated software built from components, complemented with various services. From this observation follows a necessarily capability-based competitive advantage as well as the unique intellectual property that a distributor typically does not open source:
- Build processes for building the product from its components,
- Compatibility matrices and configuration data,
- Knowledge databases for support, and
- Tests and test suites.
- The distributor almost always provides a free version of the distribution (without any of the commercial services listed above) to drive adoption by non-paying users.
The first two aspects are unique to the product development process of distributors and the competitive advantage they can build.
A well-working free version of the distribution not only creates goodwill for the company and product in general, but it helps the distributor grow a large community of non-paying users. Unlike trials or other restricted forms of software, 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 distribution fulfills the need, users will happily keep using it.
A large community of non-paying users helps the distributor have more efficient and effective business functions; it improves sales and marketing, product management and engineering, and support. It comes with a cost, though, the added need for scalable community management. We will discuss these business functions in turn, now.
The marketing function and processes of most commercial open source distributors include those of traditional vendors but also go beyond them. Following traditional patterns, distributors use the usual channels, for example, trade magazines, conferences, and mass mailings, to generate leads for sales.
A well-working free version of the distribution, however, can tap into the power of word-of-mouth marketing using a much larger community of users than a traditional vendor can do. High quality software for free is a great value proposition. Happy users like to talk about the software that makes their work life easier. Happy users also make good reference material to the extent that they are willing to talk about their use of the software.
It is important for a distributor to be visibly involved with some or all of the components of the distribution. Such involvement, for example, by employing key developers of the core components of the distribution, inspires trust among potential customers that this distributor will be able to resolve any problems that might arise with the software.
The sales function and process of most commercial open source distributions also include those of traditional vendors and also go beyond them. As it is traditionally done, marketing primes the sales funnel and sales people pick up any leads and try to sell the product.
However, a well-working free version of the distribution can have a significant impact on the sales process. From a sales perspective, having an installed base of non-paying users is not a problem but rather an opportunity. A distributor may want to track who downloads the free version and gather their email addresses. Email addresses at corporations are a good indicator of a potential customer. Multiple email addresses of different users at the same corporation are a clear indicator that a sales call may be fruitful. This way, a free version allows a 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, who did not want to go through a purchasing process with their IT department. With multiple LoB users in one company, the IT department may want to rein in the use of the software and purchase it centrally. In a comparative evaluation of products, the distributor 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. Asking rhetorically: 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
Product management of distributions also has its challenges. As mentioned, developers of the company are typically involved in the development of the underlying open source components. Product managers need to watch out that such developer engagement does not have negative effects, such as early revealing of product strategy or intellectual property that should not have got out. Developers are often not aware of the side-effects of what they are doing and need to work with product and engineering management to avoid such effects.
A large user base, including non-paying users, is a great resource for product managers to draw on for product feature discovery. Product managers can learn from users by tracking problems and requests in 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 right, among other things. Due to the large user base, this takes place on a level of scale that traditional vendors at the same stage cannot meet.
Employing developers to work on the open source components is often also the main way to get features implemented that customers want, but that aren’t available yet.
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 provide the patch that fixes the problem as well. This helps mature the components of a distribution and thereby the overall distribution faster.
Engineering managers, on the one hand, have to manage those software developers who work on the open source components of relevance to the distribution, and on the other hand, they have to manage those developers who create the actual distribution. Usually, these tasks fall to different engineering managers and different developers. Those developers working open source also often serve as a conduit for contributions from other developers within the company who cannot or don’t want to be public about their contribution.
Creating the actual product, the distribution, involves significant integration work. The engineering focus is therefore on the aforementioned capabilities of build processes as well as the intellectual property of configuration data, compatibility matrices, and test suites. If certification for specific hardware and software is important, the corresponding processes and documentation need to be considered as well. All of this needs to be performed sometimes at a large scale.
2.2.5 Product support
Non-paying users of a free version 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 distributor 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 a free version 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 and budget for travel and events. Community managers need to engage with the community, and should provide and operate, for example, a website, forums and wikis, and a software forge. Often, they organize one or more user conferences.
An important aspect of community management is continuity. Community managers cannot be exchanged at random, because users and the user community often build relationships with specific community managers rather than the role. The less turnover, the better for the distributor, because established community managers can use their relationships for the distributor’s benefit more easily.
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 (of non-paying users) that helps itself, and in which company resources are only the helper of last resort. If, for example, a new non-paying user asks a question in a forum, a community manager will not answer directly. They will first wait for another user to answer. If nothing happens, they will nudge existing users to help the newcomer, and only if that doesn’t work, they may decide to provide an answer themselves.
2.3. Intellectual property
Contrary to popular belief, distributors can own significant intellectual property that they don’t necessarily make available under an open license.
A distributor, like any other commercial company, both creates, uses, and protects its trademarks. The main use of trademarks corresponds with their raison d’être: To identify a product and company and to inspire trust in an assumed level of quality associated with and represented by the trademark. Distributors do not grant broad usage rights to non-paying users, if they grant usage rights at all.
A distributor may also own software patents. However, they are either licensed openly, typically by way of open source licenses to the code in which the patents have been realized, or solely for defensive purposes, for example by way of patent networks whose goal it is to protect the network members from lawsuits over other party’s patents.
A distributor may own various copyrightable materials, most notably, copyright to source code, configuration data, and knowledge databases. The source code is usually licensed in accordance with the project being contributed to. Sometimes, distributors hold back particular extensions or tools as proprietary software that they make available only in binary form and through a paid subscription.
The installer (and later, the update service) plays a particularly important role, because in this process the distributor’s knowledge on how to create a well-working system from disparate components is being applied. The source code of the installer is typically not as important as the configuration and rule data that adjust the configuration of various components as the user is making choices during system installation.
It is this type of intellectual property at scale, separate from the underlying open source code, that is not easy to create and evolve and that allows a distributor to maintain a strategic advantage over potential competitors seeking to enter the market.
The distributor business model, while not entirely new, is nevertheless a model that has reached significance mostly because of the size and complexity of the open source world. Some of the world’s most important software companies are built on this model, providing significant returns on investments to entrepreneurs and investors. Therefore, this model is making an important contribution to the long-term sustainability of open source software and the good it does for the world.
I would like to thank Ann Barcomb, Michael Dorner, Matthias Eckermann, Andreas Jaeger, Nikolay Harutyunyan, and Markus Rex for feedback on this article.
 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.
 Daffara, C. (2007). Business models in FLOSS-based companies. In Workshop presentation at the 3rd Conference on Open Source Systems (OSS 2007).
 Ågerfalk, P. J., & Fitzgerald, B. (2008). Outsourcing to an unknown workforce: Exploring opensourcing as a global sourcing strategy. MIS quarterly, 385-409.
 Riehle, D. (2019). The innovations of open source. IEEE Computer vol. 52, no. 4 (April 2020), pp. 59-63.
 Riehle, D. (2020). Single-vendor open source firms. IEEE Computer vol. 53, no. 4 (April 2020), pp 68-72.