Karl Popp 11/28/22 Karl Popp 11/28/22

How to: Partner Decisions in the Software Industry

Regardless, of whether you're in the market to build a new product, acquire a software system or partner with a third party, there are certain questions you should be asking yourself to ensure your decision will meet your needs and your goals.

Understand how a new or enhanced product fits into the technology ecosystem

Whether you're considering a new or enhanced product, you'll need to consider how it fits into the larger ecosystem. This includes how it fits into your overall technology strategy. Having a clear understanding of how your products fit together will make a big difference when you're deciding what partners to work with.

The technology ecosystem is comprised of the many applications, tools, and services that are used by your company´s customers on a daily basis. These include customer relationship management (CRM), email marketing, ecommerce, accounting, and more. These applications are the backbone of their business and help them store data and handle day-to-day tasks.

A technology ecosystem also includes a variety of other companies, vendors, and tools. This could include third-party products, industry-specific products and services providers, and even managed services providers. All of these entities help you fill in gaps in your service offerings. You might not consider these providers in your technology ecosystem, but they play a critical role in delivering the value your products promise.

While no single solution can handle all of your organization's needs, you can choose to work with a number of vendors to build an integrated solution. This may be in the form of a co-marketing partner that markets your products to the same customer base. You might even consider working with a strategic technology integration partner that will help you strengthen the features and functionality of your products.

While there's no hard and fast rule, integrating with other solutions that have been proven to be successful will help your product stand out from the crowd. This may be in the form of incorporating a new product into your overall strategy or purchasing an off-the-shelf solution.

One of the best reasons to partner with an industry-specific product and services provider is because it allows you to verticalize your technology platform. This means that you're able to resell the vendor's solution with industry-specific services.

Establish strict SLAs with your partner

Having strong service level agreements (SLAs) with your partner in the software industry is essential to maintaining service quality. These contracts provide transparency, accountability, and remediation. They can help ensure smooth business operations, happy customers, and growth.

There are many components to a service-level agreement, from the parties involved to KPIs for evaluating service levels. It's important to have a thorough understanding of each part before drafting. This will help you avoid drafting too vague SLAs, which can result in confusion or failure.

SLAs are legally binding contracts that set specific service levels and usually penalties for failure to meet them. These documents are important because they provide a way for customer support teams to know what to expect from the support team. They also give the customer the ability to terminate the contract.

Choosing the right metrics to evaluate service levels is crucial. These metrics should reflect only factors that the service provider is reasonably able to control. In addition, they should not include measurements that produce large amounts of data.

In addition to evaluating service levels, it's important to assess the capabilities of your client support team. This includes their ability to respond to customer requests quickly and effectively. If the team has a reputation for poor customer service, the client may decide to look for another vendor. It's also important to set a fair compensation regime for shortfalls in service delivery.

Developing a clear understanding of your client's goals and objectives is the first step to drafting an SLA. These goals can change over time. As you work with your support team to develop an SLA, you'll want to make sure you're keeping up with these changes.

Your team can help you develop realistic service level agreements by participating in the drafting process. They can also provide insight into the goals and objectives that are realistic for your team.

Service level agreements should include a list of parties involved, service definitions, inclusions, and exclusions. They should also include KPIs, penalties for non-performance, and an end date. The list of parties and service definitions should be concise and accurate, to prevent confusion.

The cost of a software partnership

Creating a software partnership can be a challenging decision. Choosing the right partner is critical to success. It's important to be clear about what you want, set clear expectations, and make sure you communicate effectively. It's also important to choose a partner that understands your vision.

Before choosing a software development partner, you'll need to understand their culture and what they expect. Make sure to check if they are open and transparent about their processes. If you're unsure about the process, don't be afraid to ask questions.

You'll also want to make sure they have a friendly corporate culture. This will help you feel comfortable and confident about working with them. Also, you'll want to ensure that your partner is experienced and capable. If your partner doesn't have experience, you may want to consider hiring someone else.

When choosing a software development partner, be sure to look at their certification program. This is important because certification can improve the quality of integration. You might also want to consider their language expertise.

You may want to consider choosing a partner that offers a dedicated team model. This will give you more control over your project and allow you to spread the work out among specialists. It's also an excellent option for long-term partnerships.

A successful software partnership requires strong communication skills and technical expertise. You'll also need to determine the exact scope of your joint project. This will help you visualize the full project life cycle and final goals. You'll also need to consider the needs of your audience. If your software is intended to drive mission-critical functions, you'll want a partner that can help you meet these requirements.

You should also consider the resources and budgets you'll need to collaborate with a partner. This will help you decide if the cost of a software partnership is reasonable for your business. It's also important to consider the location of the partner. If you're based in a different country, it may make the search more difficult.

Finally, be sure to find a partner that understands your business goals. You'll want a partner that's innovative and has a vision for the future.

Supplier Relationships and Mergers & Acquisitions in the Software Industry (Copy)

Digitization of the M&A process: the due diligence phase (Copy)

Best practices for commercial use of open source software (Copy)

Karl Popp 1/29/22 Karl Popp 1/29/22

Strategy 101: Building strategy with strategic entities

Strategic entities

There are several occasions where we need to look at and compare strategies. Starting with creating an M&A strategy early in the M&A process, several possible strategic scenarios (strategies) are compared and one or more of such strategies for the buyer company are chosen.

When modeling strategies, how do we make sure they are complete and consistent? I propose to make use of so-called strategic entities. They are views based on the data model for M&A processes.

Model-based strategy definition

We all have seen enough examples of failed strategies based on unstructured documents like powerpoint slides. We can do better. So, i started to create deteiled definitions of strategic entities that can be used for planning. Based on the M&A date model with about 800+ objects i created a dozen strategic entities and implemented a tool to define them. Here is an example.

Target Go-To-Market Model

We will analyze the Target Go-To-Market Model step by step. As we can see in the following picture, the target resides in several target countries, where there are subsidiaries (target companies). To analyze the Target Go-To-Market Model Products of the target are important, as well as the sales numbers of the target. The target also has different relationships with partners in the different countries. My tool creates the view on the M&A data model and repositions the data objects and exports windows metafiles that i can use to create pictures.

Figure 1: Strategic entity Target GotoMarket (1)

Now. let us have a look at the Product of the target and its relationships. Here, the products are sold directly and indirectly. so we need representations for prices and contracts for direct and indirect sales via partners. As you can see in the next picture, there are two types of customer relationships and contracts, the direct Target customer contract and the indirect Customer contract of the partner. Both relate to pricing conditions specific to the customer relationship.

Figure 2: Strategic entity Target GotoMarket (2)

What else is needed to build a strategy for Go-To-Market? Details of the GTM model and operations. So, we have to look at the processes and the applications for GTM activities and their cost. In an acquisition situation, we also should look at how well the target GTM fits the acquirer´s GTM model (called complementarity). Since every activity carries a risk, the Target GTM risk has to be analysed. For the indirect channel, for selling via and with partners, partnering models exist and should be analysed, too.

Figure 3: Strategic entity Target GotoMarket (3)

By leveraging the strategic entity Target GTM, the definition of a GTM strategy is enabled. Its details allow to build a holistic strategy, since not only strategy, but also operations are part of the picture.

Read more in my upcoming book on M&A strategy

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

Software partnerships and business models: OEM

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.

OEM

In an OEM scenario the software vendor provides OEM software to the software partner. The software partner sells the OEM software as part of his solution. Usually, the software partner charges no price for the OEM software, but for his own solution. This is the key difference between OEM and resell.

The software vendor delivers the OEM software to the partner, which pays a license fee and maintenance fee to the software vendor. The license fee for the OEM might be a share of the revenue of the partner product containing the OEM software. Or it might be a constant fee that applies per copy of the OEM software shipped to the customer.

Business Model Canvas for OEM software

In a generic view, the value proposition of outbound OEM for a customer (software vendor) is that the customer saves development cost and time and gets a quality product.

For customer segments, this business model is generally limited to software vendors but might also apply to hardware vendors shipping hardware with embedded software. Based on the specific functionality of the OEM software, it might be further limited to specific software vendors. Customer relationships to software vendors using the software are important. As a consequence, the network of partner companies is the main channel.

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

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

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/26/21 Karl Popp 2/26/21

Disruptive Business Models in the software industry and beyond

Software industry and disruption

The software industry is all about disruptive business models. The key question remains: How do you plan and build disruptive business models? What are examples of disruptive business models? What did companies with distruptive business models do different than other companies? How can a company offer for the prize of zero? All of these questions can be answered by looking at disruptive business models.

Business model canvas and disruption

Let us adress these questions based on the business model canvas. The business model canvas is a well known approach by Osterwalder to model business models. Osterwalder published his approach in the book Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers.

A business model is described there on a "canvas" that shows e.g. the value proposition, cost, channels, revenue, suppliers, key resources and key partners.

Here is an example of Google´s search business on the business model canvas:

Where in the business model can disruption happen?

Now that we know the business model canvas, we can take disruption mechanisms and put them into the canvas. I use the information from Mark W. Johnson´s ideas on seizing the white space and put them on the canvas. And i use information from Profit from Software Ecosystems book.

Let me explain some of the boxes below.

Offer standardized low price version of high price product

There is a high price product, like secure data rooms. You build disruptive business models by offering that product in a standardized low price version. Examples i like are

UberX, a service from Uber that offers cheap transportation services
Motel One which is a motel chain that offers very affordable overnight stays
Securedocs, who disrupt the secure data room industry by offering a cheap yet safe data room for companies.

Shop at home with device

Nothing is more convenient than shopping at home. Technology can put that convenience to a new level.

Here are my most-liked examples:

Amazon has invented Amazon Fresh, a device that can scan barcodes of products at home or can listen to your wishes. Just say: chocolate sprinkles and the sprinkles will be at your door the next morning.
Amazon Fire scans for products that can be ordered, from Amazon, of course. no more searching for names or products in catalogs. scan, shop, done.
hybris Commerce Suite: lets you shop on any device (smart tv, Ipad, Phone)

Integrate and combine channels

In some industries there are opportunities in integrating and combining channels to build disruptive business models. No matter how you reach customers to sell goods, no matter where customers turn their attention, you might leverage all these channels as one.

Here are my favorites:

Stylight social shopping. Stylight has integrated normal people showing off purchased apparel in social networks with a shopping experience. Pictures of these people can appear in the shop and items can be ordered right away.

Prize of zero fed by other revenue streams

There is no better way to disrupt than offering a product or service for a price of zero. But you have to make sure you get some compensation or you finance that business model with revenues from your other business models. Advertising revenue has been stressed a lot in the software business for this purpose, but it only works in rare cases. So, which other sources of revenue to fund a low price are there? Here are my examples:

Google search. The service offered by Google is free. If you look at it more carefully, there is a compensation. it is data about the interest and the searches a user starts. This data is sold to advertisers. Revenue from advertising feeds free search.

Communities instead of sales force

Outsourcing for the prize of (almost) zero and scaling your salesforce dramatically. These are the benefits of leveraging product communities for supporting, maintaining and even selling your products. Network effects can accelerate this effect even more. Examples are:

Nespresso community
Skype was and is mostly promoted by its community. the network effects of having additional people join.
Open Source communities

Do more to adress the job

Just do a little more than your competition. Sounds easy, but it might take some hard thinking to deliver. Here are examples:

German epost does not only store your mail while you are away from home, they will scan all incoming letters and provide them online for you to look at it.
Life is good. Social retail. Shopping is great. Might be even greater if you are doing good while you are shopping.

More information to come soon. Many of these ideas are in the book Profit from software ecosystems

Literature

Content on this site comes from the following book and the ones in the gallery:

Mergers and Acquisitions in the Software Industry

other background literature is:

Osterwalder, Business model generation

Mark W Johnson, Seizing the white space

R. Meyer, K.M. Popp, Profit from software ecosystems

Karl Popp 2/25/21 Karl Popp 2/25/21

Software partnerships and business models: Distributors

Distributors

A Distributor gets software directly from a software vendor and sells this software to Authorized resellers. The relationship with Authorized resellers is handled by the Distributor.

Business Model Canvas for Distributor

The value proposition for the customer of the distributor is that he provides the distribution service to resellers and that the distributor provides great margins for the resellers and that he supports resellers in selling the solutions. The customer relationship is direct to the resellers. Customer segments cannot be determined in this generic distributor business model.

Revenue streams are license, support and maintenance fees flowing in from the customers and resellers to the distributor.
A distributor key activity for making business in this business model is convincing and onboarding resellers. As soon as the resellers are on board, the next key activity kicks in: enabling the resellers to sell. Key resources are sales support for resellers and support for the resellers´ customers.

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

Karl Popp 2/24/21 Karl Popp 2/24/21

Software partnerships and business models: Revenue share

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 2/24/21 Karl Popp 2/24/21

Software business models: Google´s Business Model

Google

Google is a software company that started in the search and online advertising business and has extended its business to many other areas. Google´s revenue is mainly from broker business.

What Google does successfully is matchmaking between online advertisers and potential customers. But Google has more products and services than just online advertising and search. Let us have a look at the business model. We start with the products/services offered and the business model archetype.

Besides of Google´s main business as a broker, Google is a manufacturer of the Google Search Appliance, which is a hardware appliance that includes Google´s Search Engine. Target customers are companies, that should use the search appliance for searching their intranet. Inventor business at Google is mainly focused on inventing products for the broker business and for other SaaS offerings like Google Apps, Gmail or Google Voice. The SaaS offerings are created by combining the business models Physical Lessor, IP Lessor and Contractor. In addition, Google acts as a IP Lessor for browser, operating systems and content of books.

Google business model canvas

Looking at all major Google businesses the following Google business model canvas can be created:

The key value propositions of Google circulate around free and easy to use offerings as well as apps for end users as well as online advertising and cheap online solution for corporate customers.

Customer relationships in the Google business model canvas are mainly highly automated mass relationships, while some direct relationships are kept for corporate customers.

Revenue streams of Google will be analyzed further down on this page.

If we look only at Google search, we find the following business model canvas:

Google´s revenue models

This overview of revenue models is limited to large sources of Google revenue. As mentioned above, the main source of revenue at Google is from their broker business, which we will analyze in a little more detail below.

Now let us have a look at Google´s revenue model for the broker business. As you may remember, there usually is a compensation for every product and service, not necessarily as a payment. In Google´s case the non-monetary compensation for their search offering is the key to Google´s fortune.

Here you can see that Google´s search business basically provides a search service to search customers and a PPC (Pay per click) advertising service to its advertising customers. The compensation for the PPC advertising service is payment per click on an advertisement. The non-monetary compensation for the search service is data about the user who is searching.

Google´s revenue model synergies

The Google business model has two striking advantages: The information about the search customers is provided to Google for free and Google sells advertising space, perfectly matched with the customer in-formation, to advertisers via an automatic online auction.

So Google leverages a revenue synergy between the search and advertising business. The revenue model allows the revenue generated in the broker business to be used to carry the sunk cost and operations cost of offerings like Gmail and others.

Find more information on business models in the following 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 2/22/21 Karl Popp 2/22/21

Software partnerships and business models: Appstores - online marketplaces for partner products

Appstore description

Large software or device vendors usually offer an Appstoreto sell applications based on their platforms. Customers of the Appstore gather there to look for complementing solutions from partners. Partners have the opportunity to advertise partner solutions exactly where customers are looking for the solutions.

Business model canvas for appstores

The value proposition of the marketplace for the partner contains two items. The first value proposition is access to the customer base of the appstore provider as well as to other partners and other visitors of the marketplace. The second value proposition is the additional revenue the partner can get from selling to the customers of the appstore provider.

Customer relationships: the software vendor has to care for the referral relationship to the partner and the customer. The partner might get engaged with customer segments containing customers of the software vendor, prospects of the software vendor, other partners of the software vendors visiting the marketplace and other visitors of the marketplace as well.

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

Karl Popp 9/23/18 Karl Popp 9/23/18

Proceedings of the European Workshop on Software Ecosystems 2017

The proceedings of EWSECO are out now! The European Workshop on Software Ecosystems http://www.ewseco.org is an annual event which connects researchers and fellow professionals in the field of software ecosystems.
Presentations in 2017 included:

1. Software M&A Ecosystems -- Industry Keynote by Julis Telaranta, Corum

2. Sandbox vs. Toolbox - Analyzing boundary Resource in B2B Software Platforms -- Maximilian Schreieck, Robert Finke, Manuel Wiesche, Helmut Krcmar

3. Manage multiple platform-ecosystems -- Christopher Jud, Georg Herzwurm

4. Survival of the smartest: Digitalization of mechanical engineering companies by creating a software ecosystem -- Industry Keynote by Benjamin Müller, ADAMOS GmbH

5. Building your IoT ecosystem: Proposing the Hybrid Intelligence Accelerator -- Dominik Dellermann, Nikolaus Lipusch, Philipp Ebel, Jan Marco Leimeister

6. The European Standard on eInvoicing EN16931 - Applications and Services to implement Directive 2014/55/EU on electronic invoicing -- Industry Keynote by Seeburger AG

7. Platform Business in Application Markets: Data Analytics of Mobile App Usage and Descriptions -- Lauri Frank

8. Fake it till you make it: how to bootstrap an ecosystem before your company is ready -- Alexander Eck, Benjamin Spottke

9. Strategy definition in large enterprise software ecosystems -- Ralf Meyer

BUY IT NOW

Buy on Amazon