Business models, processes and tools for managing open source software 2nd edition
E-Book, Englisch, 124 Seiten
ISBN: 978-3-7504-4376-1
Verlag: BoD - Books on Demand
Format: EPUB
Kopierschutz: 6 - ePub Watermark
Dr. Karl Michael Popp is Senior Director M&A in the Global Business Development and Ecosystem Team in the Office of the CEO of SAP SE. In this area, he works on inorganic growth projects of SAP SE, such as due diligence and merger integration of technology companies as well as strategic partnerships. In his career, he has completed more than 30 acquisitions and corresponding merger integrations worldwide and worked with over 50 companies on partnerships. He is the author of several books and a speaker on software due diligence, post merger integration, digitization of M&A processes as well as business models and platform business models in the software industry. Dr. Popp is a long-standing member of the German M&A Association (Bundesverband M&A) as well as a former board member of the Gesellschaft für Post Merger Integration (now part of the Bundesverband M&A) and works in the program committee of the European Workshop on Merger Integration and of the Think Tank Denkfabrik Wirtschaft. He studied economics and received his doctorate in information systems from the University of Bamberg. More information can be found at https://www.drkarlpopp.com/ .
Autoren/Hrsg.
Weitere Infos & Material
2. Business Models for open source software companies
Dr. Karl Michael Popp, SAP SE In this chapter, we look at different business models for companies, that base their business model completely or in part on open source software or open source licenses. 2.1 Open source licenses as a key factor for the variety of business models
An open source license comes with rights and obligations and the search for the optimal license continues [1], [3]. A license creates limitations as well as opportunities in creating business models around open source software. For example, for a company using open source software as part of its products, the limitations can be described as follows. Example A software vendor may make use of the rights, like usage or redistribution of the open source, but it also has to fulfill the obligations, like e. g. delivering the copy of the license text with the software or revealing the source code of a software product. Another restriction is that some licenses do not allow modifications of the open source software. This would exclude the ability of a commercial open source company to provide maintenance and to fix security vulnerabilities, because the open source code must not be changed. But the limitations of open source licenses can also be an advantage for software vendors providing open source software, which will be shown later in this chapter, when we talk about dual licensing models. The key point for a commercial company is if it is willing and able to comply with the license terms of a specific open source component. The rights and obligations in conjunction with the open source software have to be analyzed diligently to make sure there is no violation of the license terms and the license terms are not in conflict with the commercial company´s business model [4], [5]. If this is ensured, the company can leverage this piece of open source software. 2.2 Suppliers of open source software for commercial use
Often, open source software is being supplied by a community or by a commercial company [6]. We speak of community open source and commercial open source respectively. Community involvement with open source products means that a community of people provides creation, maintenance and support for an open source software [7]. Sometimes the community even provides presales and sales activities for companies offering an open source version and a commercial version of their software. In most of the cases the community provides these services free of charge. By providing an open source licensed version of a product, a software vendor has the opportunity to outsource certain activities, like development, maintenance and support to the community [8]. Figure 1: Types of Open Source There are, of course, differences between a company and the open source community in providing open source software. These differences are important to understand, because they influence a customer´s software license selection and they also create niches for companies to establish a business. The differences are listed in Figure 2. Looking at licenses, community open source usually comes with a single type of license and standard terms. If a commercial company would like to have changes of the license, it is usually not possible to change the license terms with a community. Commercial open source has the advantage that a commercial company issues the license. A software vendor willing to change terms can get in contact and start negotiations of the license terms with that commercial company. Figure 2: Commercial open source vs. community open source Consulting for community open source might come from the community itself or from companies who have specialized on providing commercial consulting for community open source software. Maintenance for community open source is provided by the community only. While this is free of charge, there is no way to enforce changes and updates of the software. N evertheless, active communities have shown to perform timely updates for security vulnerabilities. A software vendor using the community open source can escape this issue by donating a source code change to the open source community. This should be a well considered decision, because the software vendor might be giving up intellectual property rights for that change. Looking at support, a community provides support without guaranteed service level agreements, which is a big issue for commercial companies using that open source software. In commercial open source, there usually is a support offering by the software vendor granting the commercial open source license. In addition, there is often the option to choose a commercial license for the open source software, too, which might also come with a commercial support offering. 2.3 Open source business models in detail
Now let us have a more detailed look at the different open source business models. Classification of open source business models
Based on a general classification of business models [9] we will have a look at open source business models. The following section arguments along the lines of [6]. Figure 3 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” in Figure 3. 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 [6]. 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, a so-called hybrid business model is created. Creating a hybrid business model 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 model is 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 proprietary 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. Figure 3: Commercial open source business model It is important to note that business model type level and business implementation level are design dimensions for describing existing and designing new open source business models [10]. So creating a new open source business might start with selecting one or more type level business models and then select from existing or new implementations for each of the business models to create a business. Going forward, we will analyze existing 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...
