M&A, Business Models and Ecosystems in the Software Industry

Karl´s blog

Posts tagged OS
Open Source business models

Open Source business models

Open source business models are commercial business models based on open source software. This webpage contains a short version of a chapter in the book Advances in software business.

Commercial use of open source

For a commercial company, Open Source Software is software that is licensed to that company under an open source license. The commercial company may make use of the open source, like usage or redistribution of the open source free of charge, but it also has to fulfill the obligations, like delivering a copy of the license text with the software.
So the rights and obligations have to be analyzed diligently to make sure there is no violation of the license terms.

Suppliers of open source software

Open Source software can be supplied by a community or by a commercial company. We speak of community open source and commercial open source respectively. For community open source, a community of people provides creation, maintenance and support for an open source software. In most of the cases the community provides these services free of charge.

There are, of course, differences between a company and the open source community. These differences are important to understand, because they influence a customer´s supplier decision and they also create niches for companies to establish a business in that niche.

Commercial open source vs. community open source

So a customer might decide for commercial open source if he needs customized license terms, runs open source in a mission-critical environment and thus needs service level agreements in support or if he needs maintenance provided in a different way than via the open source community.

In many business contexts it makes also sense to have liability and warranty provisions from a supplier when using open source. In most of the existing open source licenses there is exclusion of any warranty or liability (3). This is another reason why companies might choose commercial open source over community open source. Please find more information in the book “Best practices for commercial use of open source software”.

Classification of open source business models

Based on a classification of business models (Weill et al.) we will have a look at open source business models.

Open source usually is free of charge, but that does not necessarily mean there is no compensation for using the open source component.
The next figure shows a classification of generic business models. The business models relevant for commercial open source business are marked in bold. In this general classification of business models, software classifies as an intangible product, see the corresponding column “Intangible”. Software can be created or written (“Inventor”), distributed (“IP Distributor”) or licensed or rented to customers (“IP Lessor”). In addition, the customer needs services to run and maintain the software, like implementation, support and maintenance services. These classify as “Contractor” business. We assume here that all open source businesses make use of at least a subset of these four business models.

No matter if it is a community or a commercial software vendor, one or many of these business models are applied. By choosing a specific selection of business models, so-called hybrid business models are created. Creating hybrid business models means combining different business models with their specific goals, requirements and cost structures.

Since these business models are models on a type level, there might be different implementations of how a certain business models are run. An open source community might run the Inventor business for creating software in a different way (leveraging the community) than a commercial software vendor (leveraging a development team), from a process as well as from a resource perspective. But on a type level, both run the same type of business called Inventor.

So going forward, we will analyze commercial and community open source business models as a selection of a subset of the business models identified here: Inventor, IP Lessor, IP distributor and Contractor.

Community open source business model

The open source community business model usually makes use of the following business models: Inventor, IP Lessor and Contractor.

For the community, the Inventor business is what the community is most involved in. It is about creating open source software and engaging with the community members to coordinate the work and collect the contributions of the community members.

The IP Lessor business is also important for the community. The IP lessor business defines the terms and conditions of the open source license and makes the software available to customers. The license is defined by the community and all customers using the software have to comply with it. In some cases, there are multiple different licenses for an open source software that a customer can choose from.

The Contractor business contains all human services to customers. The community typically provides these via email and they contain services like maintenance, support, translation for country specific versions and the like. They are all carried out by community members. In almost every case, the customer does not pay for these services, but the customer has no rights to enforce any of these services and he does not have service level agreements, like a definition of minimum answer time for support incidents.
The community can serve two types of customers: software vendors and (end) customers. For software vendors, the open source community works as a supplier of software, for the customer, the open source community works as a software vendor licensing software to the customer.
These two relationships differ in the way that customers and software vendors might make use of the software. Customers usually license the software for internal use only. Software vendors license software for internal use and/or for distribution to customers. Often open source software is included in commercial software and provided to customers by the software vendor. In this case, the software vendor has to make sure he complies with all licenses of all open source software he is including in his software product. Please find more information in the book “Best practices for commercial use of open source software”.

Commercial open source business models overview

In the last section we described the community business model, now we turn to the commercial open source business model. Figure 4 shows the typical business models implemented by commercial software vendors. As mentioned before, a commercial software vendor does not have to implement all of these business models, but can rather build unique business models by selecting a subset of available business models. One basic difference to community open source is that the IP Distributor business model is an option for commercial companies.
The history of commercial open source companies shows that in the beginning the companies focused on services around open source software, which matches the Contractor business.

The next step was to build distributions for open source software, like e.g. for Linux. This matches to the IP Distributor business model.

Today, we find all kinds of hybrid business models around open source. Companies are building software and donate it, completely or partially to the open source community (Inventor business model). Commercial software vendors often package or change or extend existing community open source software, so the community acts as a supplier of open source software to the software vendor. In some cases the software vendor does not use existing open source software from a community, but chooses to offer its proprietary software under a dual licensing strategy, e.g. under a commercial and an open source license. Please find more information in the book “Best practices for commercial use of open source software”.

Commercial services for open source

Since open source licenses are free of charge, commercial companies first and foremost focused on providing services around open source software. The expectation was simply that customers would still need services and since the license was free, that customers would have more money to spend on services.

Commercial open source companies provide the following services for open source software: Maintenance, Support, Consulting and Extension or adaption of open source software to a customer´s needs.

Maintenance services consist of the following activities: building future versions, bug fixes and upgrades and providing them to the customers.

Support services contain of accepting, maintaining and resolving incidents that the customer has while using the software.

Consulting services mean planning and executing the installation and go-live of customers´ system landscapes containing the software.

Extension or adaption of open source software based on customer´s requests is designing, programming, testing and delivering open source software that has been modified or expanded. Examples for extensions and modifications are:

  • Functional Extensions for open source applications with country-specific functionality or customer specific functionality;

  • Extending the usage scenarios for open source to additional countries by adding additional translations of user interfaces;

  • Adapting open source software means to make open source software run on customers´ hardware and software platforms.

Summary and outlook

The evolution of open source and commercial open source business is still underway. In the future we will see additional varieties of open source business licenses, such as in open source hardware or designs, and new open source business models, like in open source on demand applications or open source software in cloud environments. Please find more information in the book “Best practices for commercial use of open source software”.

Best practices for commercial use of Open Source

Open Source best practices

Today, all software vendors make use of open source.

  • They strive for excellence in leveraging using open source software in commercial software products while ensuring licensing compliance and governance.

  • They strive for excellence in using open source based business models for commercial success.

  • They strive for excellence in leveraging development models that are used in open source communities in adapting these for in-house use at commercial software vendors.

  • They analyze usage of open source software during due diligence in acquiring software companies.

To reach excellence you have to be equipped with knowledge about best practices for open source. This blog is meant to provide you with the latest knowledge about open source, esp. open source licensing in commercial software, to reach excellence in open source matters. Please find more information in the book “Best practices for commercial use of open source software”.

Open Source  and Open Source Licensing for commercial software

This page shows you why you should carefully consider using open source software in commercial software: Advantages and disadvantages of open source usage, why open source is used in commercial software and how to manage open source licensing and to control open source usage.

Most important is professional management of open source usage by defining an open source policy for your software company and by following structured processes for open source licensing approval and control. Rest assured that attorneys, consultants and tool vendors are there to assist you.

Advantages of Open Source usage

Simple and fast access to open source are often named as key advantages. Low cost and high quality are additional reasons to consider open source. For a software vendor, there might also be a strategic advantage to use open source software to provide the "non-competitive" part of a solution, while the developers care for the competitive part of the solution.

Motivation for open source usage in commercial software

Usually there are numerous open source components used in commercial software. It makes sense to use open source in commercial software if and only if you can comply with the open source license attached to that open source software. If you do so, you can leverage open source to quickly create functionality and to build on trusted functionality that is provided by software vendors or the open source community.

Relevance of Open Source Licensing

Open source components like the International Components for Unicode, ICU,or Hibernate are used in many commercial software solutions. Non-compliance with the license terms can have dramatic consequences. To avoid these open source licensing consequences, a software vendor has to install an open source licensing policy and practice. But what are the negative aspects and side effects of open source licenses? Open source licensing is also a relevant part of due diligence efforts in the software industry as explained in this book:

Potential disadvantages of open source usage

Use of open source in commercial software can show the following disadvantages:

  • Missing commercial services, like support and service level agreements impact the ability to run in commercial environments;

  • Commercialization of software might be blocked;

  • Missing or incomplete license attributes, like e.g. for sublicensing software or running software in an on demand environment;

  • Missing warranty and liability;

  • Non-compliance with license terms might lead to litigations.

Open Source licenses and software supply chains

Usage and licensing rights are transferred between players in the software supply chain. Software passed along the supply chain might contain open source software, too. Due to the copyleft effect in certain licenses, the non-compliance of one supplier might impact all other software companies down the supply chain.
So software vendors should diligently check which open source components are contained in the software supplied to them and which license terms apply.
The use of tools eases the work on this problem. You can use open source scanners to find open source code and the corresponding license terms. Please find more information in the book “Best practices for commercial use of open source software”.

Open Source Software License Due Diligence

Often, commercial software contains open source components. In the due diligence for acquiring a commercial software company, you have to check if the company complies with the licenses for open source software contained in their products (open source due diligence). The following figure shows typical components of commercial software that are analyzed during due diligence. They are coming from service providers, from suppliers for OEM software, freeware and open source software and they are created by employees, too.

Next in due diligence we look at the utilization of open source software. In the following figure the software vendor distributes the software products to resellers and to direct customers. The key fact that triggers open source license compliance is often distribution. With the distribution, the open source license terms apply and have to be complied with. Often open source license terms require that the source code is revealed and/or the software has to be provided free of charge. This is of course a critical issue in the due diligence of commercial software.
Software vendors´ core business is monetization of usage rights granted to customers. Open source software and corresponding licenses have to be diligently analyzed in open source due diligence.

You have to ensure that

  • all current and planned utilizations of open source software are covered and that

  • no open source license terms are violated.

Open Source Software Governance

Open Source Governance is the risk management process for using open source software in commercial software products. So what is the risk in using open source software?

Open source usage has several risks, like:

  • Operational risk: Missing commercial services, like support, might impact the ability to serve customers well in commercial environments;

  • Commercial risk: Monetization of software products might be blocked by open source licenses; Missing warranty and liability terms for software increase the warranty and liability risk for the commercial software vendor; Limitation of business models and delivery models might occur if the open source license does not explicitly allow or even forbid them.

  • License attribute risk: Missing or incomplete license attributes, like e.g. for sublicensing software or running software in a cloud environment; Non-compliance with license terms might lead to litigations.

  • Patent litigation risk: open source software might violate intellectual property rights like patents and this poses a legal risk.

Establishing open source governance

Proactive management of open source usage and open source licensing is paramount for commercial software vendors. From design to shipment of software solutions, open source governance is demanded. Please find more information in the book “Best practices for commercial use of open source software”.

Before you start with open source governance, you have to define your open source policy containing:

  • Strategic topics:

    • Risk level accepted by the management

    • Overall investment in organization, processes and tools for open source compliance

  • Tactical topics:

    • Level of management to approve open source usage

    • Frequence and intensity of governance

    • Software license tracking: Open source scan tool selection

    • Size of open source governance functions

  • Operational topics:

    • List of acceptable open source licenses based on risk level

    • Budget for Open Source Scan Tools

    • A process for governance of used open source components.

We see two types of open source governance: reactive and active. Reactive open source governance just reacts to open source components used in a commercial software and provides an evaluation if an open source use is acceptable or not. As a result, the open source component can be used or has to be removed from the product.

An active approach to open source governance is to provide access to open source componentsfrom within development tools. The development tools allow open source components, that the company allows under the open source policy. Please find more information in the book “Best practices for commercial use of open source software”.