NEWS

Karl Popp 3/16/21 Karl Popp 3/16/21

Software partnerships and business models: Revenue share: join the European workshop on software ecosystems

The European Workshop on Software Ecosystems is an annual event which connects top notch researchers and business professionals in the field of software and platform ecosystems as well as business networks. Here is an example of a topic we will discuss at the event.

Revenue share

The software vendor endorses the product of the revenue share partner. if the customer buys the partner´s product, the software vendor gets a share of the partner´s revenue.

Revenue share partnerships are also popular in the software industry and are usually used as door opener into other companies´ customers. Revenue share makes sense if the product offerings of the partner and software vendor are not competitive, but complementing.

Advantages of Revenue share are: software vendor participates in revenue that is generated by other companies, limited cost for software vendor for endorsing other vendor since cost of sales stays with the revenue share partner.

Business Model Canvas for Revenue share

The value proposition of this business model is clearly additional revenues for the partner, who does the revenue share with SAP. For the company engaging with revenue share partners, the generic model is not limited to specific customer segments. But depending on the products for the revenue share there can of course be customer segments.

Incentified by the revenue share, the company gets license, support and maintenance revenue streams.

Key activity is endorsing the partner´s software to start the revenue share, key partners are the software vendors providing the software. Key resources are the sales people hunting for customer contracts triggering the revenue share.

More details and background information can be found in these books:

Karl Popp 3/3/21 Karl Popp 3/3/21

Software partnerships and business models: Resell: join the European workshop on software ecosystems

Resell

Resell works as follows: Products of the software vendor are supplied to a resell partner. The partner resells the software vendor´s products to the customer.

This is a close relationship between a software vendor and a resell partner.

Three main drivers exist for a partner to resell solutions: significant revenue for the Partner Company, solution fit of the resell solution with the partner´s solutions and non-competitive offering; with revenue being the main driver for the resell.

Business Model Canvas for Resell

In a generic model, a Value Added Reseller (VAR) provides resold products as well as additional value related to these products. The added value can come from a special expertise of the VAR related to a customer segment like consulting expertise in the oil and gas industry. So the value proposition for the customer comes from both, solutions and added value.

The customer relationship is direct and thus the channel is a direct channel to the customer. Customer segments cannot be determined in this generic model, they depend on the partner.

Resell revenue streams are from license and support and maintenance fees. Key activities in this model are selling to customers and enabling sales people to sell. Key resources are sales people and the software provider´s Channel sales manager. Key partner is the software provider.

The cost structure in this model contains cost for customer acquisition, cost of sales in general and cost of partnership management.

More details and background information can be found in these books:

Karl Popp 3/1/21 Karl Popp 3/1/21

Software partnerships and business models: Referral: join the European workshop on software ecosystems

Referral

Referral means that the software vendor has outsourced lead generation to a partner company. The partner company creates the leads, passes the leads back to the software vendor. The software vendor pays a referral fee to the partner for a qualified lead and/or a closed deal with the lead.

Referral is very popular in the software industry. It can be used as a one-time or repetitive form of cooperation between two software companies. Advantages of referral are easy creation of the program and of the leads, low impact on both organizations, partner and software vendor, and limited risk.

A Referral program has a very low entry barrier and low maintenance effort.

Business Model Canvas for Referral

Mapping referral into the business model canvas results in the following: The value proposition of referral for the partner is the additional revenue he/she can get via the referral fee from SAP or the SAP VAR. Customer relationships: the software vendor has to care for the referral relationship to the partner and the customer. The key channel is the partner network.

Revenue streams for the software vendor are the usual license, support, maintenance fees.

Key activity is enabling partners to properly present, position and show the value of the solutions to customers. They might need marketing material, price lists, demo systems to make referrals happen.

The cost structure is referral fee cost besides normal software vendor cost structure.

More details and background information can be found in these books:

Karl Popp 2/23/21 Karl Popp 2/23/21

Software partnerships and business models: Certified solutions

Customers are looking for minimizing their integration cost in a heterogeneous landscape of software solutions. To proof that the integration between two software solution exists and has some level of quality, software vendors are offering certification programs. Certification allows competition between software partners to keep prices low while certification increases integration quality.

The software vendor provides certification services for a certification fee and logo usage to software companies. Software companies sell their software to customers. No revenue share is paid to the software vendor.

Business Model Canvas for Certification

The value proposition contains the following values:

Reduced development cost and time for integrating solutions since the integration already works based on the certifiable interface.
Quality products are being integrated to avoid that customer value is destroyed by bad quality.
Partners that get certified on an interface create value for the company that offers the interface on their solutions because the solution scope is extended by the partner products.

More details and background information can be found in these books:

Karl Popp 2/22/21 Karl Popp 2/22/21

Open Source Business Models

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.

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, 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 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.

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 a unique business model 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.

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.

For best practices in open source use in commercial products see these books:

Karl Popp 1/5/17 Karl Popp 1/5/17

EWSECO 2016 Proceedings are in preparation

Dear all,

the proceedings for the 2016 European workshop on software ecosystems are being prepared and will contain the following 2016 presentations:

Roger Kilian Kehr, Huawei
Huawei Connected World based ICT ecosystems

Abilio Avila
Management of Partner Ecosystems in the Enterprise Software Industry: The Partner Selection - A Comparison of Partner Selection Criteria with Existing Literature

Matthias Walter
How to define a platform business model with the platform business model canvas

Slinger Jansen
Ecosystem Driven Development

Christopher Jud
The Influence of Platforms on Software Products

Maximilian Schreieck
Analysis of Platform Governance in the Internet of Things

Dominik Dellermann, Christopher Jud
Towards Vivid Ecosystems: Configuring Costs and Benefits via Design Choices

Ralf Meyer
Impact of restrictive legal and license conditions on software ecosystem success

They will be published via Books on demand and will be available as print and on demand version of the proceedings.

The ISBN will be 9783743165830.

We expect the proceedings to be available soon. We will keep you posted on the progress.

best regards

The program committee

Karl Popp 7/6/16 Karl Popp 7/6/16

Preparations for the European workshop on software ecosystems

Preparations are starting

Set up program committee meetings, organize location and sponsors and speakers. This is what the organizing committee works on at the moment.

This year, the workshop will again feature many outstanding researchers and practitioners participating in the workshop.

With software business models entering classical industries and with increasing digitalization of whole business networks, our topics in 2016 will be:

Software ecosystems
Business networks
Platform Business Models
Growth strategies based on software ecosystems and business networks.

We are looking forward to your

Karl Popp 10/23/15 Karl Popp 10/23/15

The program will be announced soon

The program committee has decided about the presentations that will be part of the workshop. The job was not easy, since we had many interesting submissions.

As promised, EWSECO will be bigger than 2014. As a full day event, EWSECO will have space for eight presentations, two sponsor keynotes and a panel, more coffee breaks and more participants.

So stay tuned for our program page to be published soon.

Karl Popp 10/10/15 Karl Popp 10/10/15

International Association for SAP Partners sponsors EWSECO 2015

The International Association for SAP Partners (IA4SP), an independent association of SAP ecosystem partners, sponsors the European workshop on software ecosystems 2015.

IA4SP offers a singular network of SAP partners and real life information about the SAP ecosystem. Members of IA4SP work together to create joint success in the SAP partner ecosystem.

Members of IA4SP are invited to join EWSECO and to leverage the key knowledge provided in the workshop.

Karl Popp 9/29/15 Karl Popp 9/29/15

Netfira signed up as homepage logo sponsor

Netfira is homepage logo sponsor of the Fourth European workshop on software ecosystems.

With Netfira and their consistent sponsoring of this event, we will be able to provide better service to the participants of the workshop.

find more information here: http://www.ewseco.org