SFB 901 - Service Specification Language

A Variability Model for Store-oriented Software Ecosystems: An Enterprise Perspective1 (Supplementary Material) Technical Report Version: 0.1

Bahar Jazayeri, Olaf Zimmermann, Gregor Engels, Dennis Kundisch University of Paderborn Zukunftsmeile 1 D-33102 Paderborn, Germany [email protected]

Paderborn, June 24, 2017

1

This work was supported by the German Research Foundation (DFG) within the Collaborative Research Centre “On-The-Fly Computing” (CRC 901).

Contents 1. Introduction

1

2. A Taxonomy for Variabilities of Architectural Design Decisions of Storeoriented Software Ecosystems 2.1. A Method for Taxonomy Development and Its Application in Information Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2. Meta Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3. Ending Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4. Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5. Iteration 1: Empirical-to-Conceptual Approach . . . . . . . . . . . . . . . . 2.5.1. Identifying New Subset of Ecosystems . . . . . . . . . . . . . . . . 2.5.2. Identifying Common Characteristics and Grouping Ecosystems . . . 2.5.3. Grouping Characteristics into Dimensions to Create Taxonomy . . . 2.5.4. Checking Against Ending Conditions . . . . . . . . . . . . . . . . . 2.6. Iteration 2: Conceptual-to-Empirical Approach . . . . . . . . . . . . . . . . 2.6.1. Conceptualize New Characteristics and Dimensions of Ecosystems . 2.6.2. Examine Ecosystems for the Characteristics and Dimensions . . . . . 2.6.3. Revise Taxonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6.4. Checking Against Ending Conditions . . . . . . . . . . . . . . . . . 2.7. Iteration 3: Empirical-to-Conceptual Approach . . . . . . . . . . . . . . . . 2.7.1. Identifying New Subset of Ecosystems . . . . . . . . . . . . . . . . 2.7.2. Identifying Common Characteristics and Grouping Ecosystems . . . 2.7.3. Grouping Characteristics into Dimensions to Create Taxonomy . . . 2.7.4. Checking Against Ending Conditions . . . . . . . . . . . . . . . . . 2.8. Iteration 4: Conceptual-to-Empirical Approach . . . . . . . . . . . . . . . . 2.8.1. Conceptualize New Characteristics and Dimensions of Ecosystems . 2.8.2. Examine Ecosystems for the Characteristics and Dimensions . . . . . 2.8.3. Revise Taxonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.8.4. Checking Against Ending Conditions . . . . . . . . . . . . . . . . . 2.9. Iteration 5 & Iteration 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 3 5 5 5 5 6 7 7 9 9 10 11 11 12 12 13 13 14 15 15 15 15 16 17

Bibliography

19

A. Initial Inspection of existing Ecosystems

21

3

III

IV

C ONTENTS

B. Sources of Literature Review

23

C. List of Technical Links

27

D. Iteration 3: Inspection of existing Ecosystems

29

Chapter 1. Introduction Today, the software industry delivers more than (a family of) software: it rather provides users with composed software solutions and complementary environments such as operating platforms, execution environment, and preconfigured assets. A software ecosystem is a collaborative architectural approach to create a market on top of software platforms by opening them to external actors. Examples of the external actors are third-party developers and hardware suppliers. Existing ecosystems allow the external actors to access the platforms at different levels of the software life cycle [EB12]. This has caused them to diversify in many different ways, e.g., in software type and the target group of users [MH13]. For instance, software development ecosystems (e.g., Atlassian1 and Eclipse2 ) enable collaborative work among developers by providing code sharing and development environment. On the contrary, mobile App ecosystems target a completely different user group, i.e., mobile users, by growing around mobile operating systems (e.g., iOS and Android). Whereas, a third group of ecosystems flourishes around cloud services (e.g., Salesforce3 and AWS Marketplace4 ). In all cases, third-party developers compose their functions in form of Apps, plug-ins, APIs, cloud services, etc. to the platform. The architectural knowledge of the existing ecosystems is implicit and distributed among their online portals in form of online manuals, “how to" guides and samples as well as entries in questions-and-answers developer forums. While being successful in practice, the existing ecosystems provide implicit architectural knowledge about their structure. In protection of intellectual property, existing documentation hardly reveal influential business strategies of their platform providers that affect the ecosystem structure. Thus, other platform providers can hardly learn from the existing ecosystems to systematically make reasonable design decisions with respect to their business strategies and to build their own ecosystems. In this technical report, we develop a taxonomy for variabilities of architectural design decisions of store-oriented software ecosystem product line. We mature the taxonomy using fragmentary material of the existing ecosystems and a rigorous literature review through several 1

www.atlassian.com, Last Access: March 2017 www.eclipse.org, Last Access: March 2017 3 www.salesforce.com, Last Access: March 2017 4 www.aws.amazon.com/marketplace, Last Access: March 2017 2

1

2

CHAPTER 1. INTRODUCTION

conceptual and empirical iterations. Furthermore, the technical report includes complete lists of literature and technical sources that are used during the taxonomy development.

Chapter 2. A Taxonomy for Variabilities of Architectural Design Decisions of Store-oriented Software Ecosystems In this chapter, we present the detailed process of developing a variability model for a storeoriented software ecosystem product line.

2.1. A Method for Taxonomy Development and Its Application in Information Systems N ICKERSON ET AL . [NVM13] propose a taxonomy development method based on design science research paradigm [VAMPR04] to classify objects of study based on their common characteristics. The result is a set of dimensions, while each dimension consists of mutually exclusive and collectively exhaustive characteristics. Figure 2.1 sketches the steps of the taxonomy development method. Initially, meta-characteristics are to be defined. They are the most comprehensive characteristics that serve as a basis to identify further characteristics for each dimension. The method is a combination of two types of iterations, i.e, empirical-to-conceptual and conceptual-toempirical iterations. At the end of each iteration, the taxonomy is evaluated against ending conditions [NVM13].

2.2. Meta Characteristics To derive our variability model, first we need to identify meta-characteristics of the variability model. These characteristics are used to identify concrete variation points. Our metacharacteristics refer to the initial sources of architectural variabilities in software ecosystems. We identify three meta-characteristics by referring to the definition of software ecosystem provided by B OSCH AND B OSCH -S IJTSEMA that “a software platform, a set of internal and external developers and a community of domain experts in service to a community of users

3

4

CHAPTER 2. A TAXONOMY FOR VARIABILITIES OF ARCHITECTURAL DESIGN DECISIONS OF STORE-ORIENTED SOFTWARE ECOSYSTEMS

Figure 2.1.: Taxonomy development method [NVM13]

2.3. ENDING CONDITIONS

5

that compose relevant solution elements to satisfy their needs" [BBS10a]. Thus, our metacharacteristics are: a) What a platform consist of, b) Collaborations upon which a platform supports service provision, and c) What a platform offers as products / services.

2.3. Ending Conditions We set the ending conditions as follows: The development of variability model is terminated when the last iterations do not result in identification of any new variability or when currently identified variabilities are not further enriched.

2.4. Approach As our first iteration, we choose to begin the taxonomy development by conducting an empirical-to-conceptual approach, because a diverse range of ecosystems already exists in real-world. This can be a valuable source of data, which is very beneficial for an empirical approach. Furthermore, we present the state of the variability model at the end of each iteration using the orthogonal variability model (OVM) notation [MPH+ 07]. We use the OVM notation, because it enable us to represent the variabilities as first class architectural knowledge entities.

2.5. Iteration 1: Empirical-to-Conceptual Approach In this section, the first version of the taxonomy including a set of dimensions and characteristics is derived by investigating existing store-oriented software ecosystems using an empiricalto-conceptual iteration.

2.5.1. Identifying New Subset of Ecosystems According to the taxonomy development method, first researchers need to identify an initial subset of objects, which are subject to the classification. This subset is most likely the one that there are most relevant data available to it or the one that the researchers are the most familiar with it. Our objects of classification are store-oriented software ecosystems. As the initial subset, we choose to use our list of software marketplaces that we develop in our previous work [JPEK16a, JPEK16b]. We decide to use this list as the initial subset, because it includes ecosystems from a diverse range of domains. The list is shown in Table 2.1. Among the list, we include the ecosystems, which conform to our meta-characteritics, i.e., having a software platform, including external collaborations, providing a kind of software service / product.

6

CHAPTER 2. A TAXONOMY FOR VARIABILITIES OF ARCHITECTURAL DESIGN DECISIONS OF STORE-ORIENTED SOFTWARE ECOSYSTEMS Mobile App stores Apple App store Google Play

Amazon Appstore Mobango Cloud service marketplaces

Telecommunication carrier App store MediaTek App Store

StrikeIron

T-Mobile Web2go

Black Berry World

SalesForce AppExchange

Verizon VCast

Nokia Ovi Store

AWS Marketplace

Vodafone 360

Component repository

Mashery

ATT AppCentral Research

Microsoft Store

Third-party (Android/iOS App stores)

Programmable Web

4CaaSt OTF Markets FOR 1371

API repository Vitual Fort Knox

F-Droid

Binpress

GetJar

Slideme

SourceForge

Java Store

Eclipse Marketplace

Aptoide

CPAN, CTAN

OpenIntents

SteamPowered

Cydia

Envato

Mashape

Bowser Marketplace (Firefox, Chrome,...)

Others

Cytoscape

Table 2.1.: The initial list of store-oriented software ecosystems adopted from [JPEK16b]

2.5.2. Identifying Common Characteristics and Grouping Ecosystems In this step, researchers identify common characteristics of the objects in the initial subset. Such characteristics are logical consequences of the meta-characteristics. Each characteristic needs to be defined in a way that it discriminates the objects, otherwise, it is not beneficial to taxonomy development. To identify common characteristics of the ecosystems in our initial subset, we refer to the meta-characteristics in Section 2.2. We inspect the ecosystems with respect to the metacharacteristics and we document the collected data in a table. The documentation collected during this inspection can be found in Appendix A. During this inspection, we analyze the ecosystems by exploring their technical documentation that are available on the Internet. Such documentation usually comes in the form of online manuals in developer portals, “how to" guides, and official documentation provided by platform providers as well as samples and demos. In addition, if enrollment in the ecosystems is made possible, we register as developer and experiment the way that the ecosystems work.

2.5. ITERATION 1: EMPIRICAL-TO-CONCEPTUAL APPROACH

7

Up to this step, the mentioned activities do not help us to deeply understand business strategies of platform providers. Therefore, we additionally explore their annual reports e.g., using AnnualReports.com, and well-reputed business magazines as well as entries in questions-and-answers forums. Moreover, we identify groups of ecosystems, i.e., mobile App stores, cloud services, API repositories, enterprise applications, open source development, etc. Our inspection of the initial subset results in the following common characteristics: • The platforms are mobile operating systems, web browsers, cloud services (SaaS and PaaS), or software development platforms. • The collaborations include open source communities, programmers, web developers, hardware assemblers, manufacturers, B2B partners, or consultants. • The products /services are mobile Apps, browser add-ons, software development plugins, cloud services, or open source projects.

2.5.3. Grouping Characteristics into Dimensions to Create Taxonomy After defining the set of characteristics, we group them to form the first dimensions of the taxonomy. The grouping action follows the goal of taxonomy, i.e., to identify architectural variabilities of store-oriented software ecosystems. Following the notation used by N ICKERSON ET AL . [NVM13], Di and Cij respectively represent ith dimension of the taxonomy and j th characteristics of Di . Our first dimensions are as follows: • D1 = complementary Partnership with characteristics C11 = strategic partner, C12 = supplier, and C13 = independent developer. This variability addresses strategic decisions that platform providers make to choose ecosystem partners. Platform providers choose such partners in a way that each partner contributes to final service provisioning to ecosystem users. To this end, the partners support the ecosystem by providing valueadding solutions. • D2 = deliverable with characteristics C21 = software product, C22 = software service, and C23 = source code. Deliverable is the type of software artifact that an ecosystem delivers to its users. This can be software products, software services as well as source code. We distinguish between software products like mobile Apps that are installed on local devices and software services like cloud services that are the result of some execution on a remote server.

2.5.4. Checking Against Ending Conditions At the end of each iteration, we check whether the process of taxonomy development needs to be continued or not. Figure 2.2 shows the taxonomy of variabilities of store-oriented soft-

8

CHAPTER 2. A TAXONOMY FOR VARIABILITIES OF ARCHITECTURAL DESIGN DECISIONS OF STORE-ORIENTED SOFTWARE ECOSYSTEMS VP

Complementary Partnership 1..3

Business View

V

Strategic Partner

V

Independent Developer

V

Supplier

VP

Deliverable 1..3

Application View V

V

Legend

VP

VP

V

Software Product

Mandatory Variation Point Optional Variation Point

Source Code

Software Service

[min..max]

V

Variant Mandatory Variability Dependency Optional Variability Dependency

Alternative Choice Requires Excludes

Figure 2.2.: Taxonomy of variabilities of store-oriented software ecosystems after iteration 1 ware ecosystems after the iteration 1. The iteration 1 results in identification of new variabilities. Therefore, according to the ending conditions, which are introduced in Section 2.3, the taxonomy development continues with further iterations.

2.6. ITERATION 2: CONCEPTUAL-TO-EMPIRICAL APPROACH

9

2.6. Iteration 2: Conceptual-to-Empirical Approach In the conceptual-to-empirical iteration, we continue with the taxonomy development by defining further dimensions and characteristics. According to the research method [NVM13], in a conceptual-to-empirical iteration, these dimensions and characteristics can be defined based on researchers’ knowledge and expertise. Afterwards, they are validated by examining further objects of study. To define the dimensions and characteristics in this iteration, we perform a literature review that captures the most important aspects of software ecosystems. Our search terms for the initial search are “software ecosystem” , “variabilities”, and “architecture”. To capture as many relevant sources as possible, we consider alternative words for the search terms. Alternative words for “software ecosystem” are “open software platform”, “open software development”, “open software product line”, “multi software product line”, and “software ecosystem governance”. Furthermore, “architectural”, “design decision”, and “design” are alternative words for “architecture”. In addition, to reasonably narrow the search results, we build search phrases out of the search terms by using AND and OR logical operations. An example of our search terms is (“software ecosystem” OR “open software platform”) AND “variabilities” AND “architecture”. Furthermore, we use Google Scholar as a meta-search engine that searches through several digital libraries. We include a search result in our literature review when the “software ecosystem” , “variabilities”, and “architecture” search terms, or their alternatives, appear in the title or abstract. Furthermore, we add quality criteria to our search by considering most influential journal, conference, and workshop publications that are relevant to software ecosystems. Moreover, we include the publications from the International Workshop on Software Ecosystems (IWSECO). A complete list of sources that are included in the literature review can be found in Appendix B.

2.6.1. Conceptualize New Characteristics and Dimensions of Ecosystems We supplement the taxonomy with our implication from the literature regarding the metacharacteristics and the differences between the existing ecosystems and the concepts addressed in the literature. In particular, we pay attention to the following questions that are raised in the previous iteration: a) Where are deliverables executed? b) How do complementary partnerships add value to software ecosystems? c) Are software platforms open to external developers? d) How is extending software platforms made possible for external developers? The literature review results in identification of the following dimensions and characteristics: • D3 = openness with characteristics C31 = open and C32 = closed. This variability determines whether content and methods of ecosystem are opened and subject to change by external developers. Openness has two variants, i.e., open and closed. However,

10


ecosystems can hardly be judged as completely open or closed. The degree of openness in ecosystems depends on the realization of this variation point at management and practical levels [JBSL12]. • D4 = platform interfaces with characteristics C41 = user interface and C42 = System libraries. The interfaces of software platform need to provide the right modularity and granularity so that the external developers become able to correspond to relevant components of the platform [Bos10]. • D5 = extension development with characteristics C51 = platform SDK, C52 = integrated development environment (IDE), C53 = choice of programming language, C54 = choice of communication protocol, and C55 = testing functions. This variability defines development tools and techniques that enable external developers to add their applications to ecosystems. Moreover, techniques like using Wikis and forums support social communication in communities of developers, who usually work independently [SEL14]. • D6 = security check with characteristics C61 = leak and bugs C62 = policy violation. This variation point includes a wide range of security and privacy checking functions to protect ecosystems from malware, unwanted actions, and misuse. Furthermore, different communities of external actors may be granted with different access to software platform. For instance, a strategic partner receives deep access to the platform functions [BBS10b]. • D7 = service execution with characteristics C71 = operating system and C72 = compute center. This implies suitable infrastructure for the execution of deliverables. It is an optional variation point, i.e., in some ecosystems, e.g., where deliverable is source code, no execution of deliverables is needed. While in other ecosystems, e.g., mobile ecosystems, applications require an operating system to be executed on [Bos09].

2.6.2. Examine Ecosystems for the Characteristics and Dimensions In this step, researchers examine actual objects of study to check whether they support the dimensions and characteristics that are identified in the previous step. This means that the researchers need to answer the question whether “Are there objects that have each of the characteristics in each dimension?” [NVM13]. To do so, we refer to our initial list of existing ecosystems in Section 2.5.1. We inspect the existing ecosystems. In general, D3 = openness is a fundamental design decision of software ecosystems that is supported by all of the ecosystems. Different realization of openness causes the existing ecosystems to differ greatly. For instance, while the source code of Android OS is open to modification by external developers, Windows Mobile is rather a closed source OS.


11

In addition, the existing ecosystems support D4 = platform interfaces. However, they introduce a new group of platform interfaces, i.e., platform features. The platform features are specific to a certain platform or domain and developers often require to work with them in order to develop domain-specific features. GPS, camera, and audio control are examples of features in mobile OS platforms. We discover that D5 = extension development is an obligatory architectural decision of the existing ecosystems if a platform provider would like to allow a platform to be extended by external developers. Moreover, some ecosystems may allow for the composition of external applications. For instance, in the ecosystem of Android operating system, Intents1 facilitate the composition of Apps on Google Play. Furthermore, the existing ecosystems support D6 = security check by providing more concrete information. We observe that a typical way to realize security checks is to apply a review process when external developers would like to enter the ecosystem. The review process mainly considers security leaks, bugs, and policy violations of externally developed applications before being published on stores. During the examination of the ecosystems, we identify a new characteristic for D7 = service execution, i.e., C73 = data center. We observe that ecosystems in cloud computing and mobile domains, which require high quality of data delivery, require the support of data centers. This can be provided internally by platform providers or by external suppliers.

2.6.3. Revise Taxonomy The examination of the existing ecosystems results in confirming the validity of the newly identified dimensions and characteristics in this iteration. Furthermore, in the previous step, the following characteristics are introduced newly: • D4 = platform interfaces with characteristic C43 = platform features • D7 = service execution with C73 = data center

2.6.4. Checking Against Ending Conditions The iteration 2 results in identification of new variabilities. Therefore, according to the ending conditions, which are introduced in Section 2.3, the taxonomy development continues with further iterations. Figure 2.3 shows the taxonomy of variabilities of store-oriented software ecosystems after the iteration 2.

1

https://developer.android.com/reference/android/content/Intent.html, Last Access: May 2017

12


VP

Complementary Partnership

Business View

Openness

1..3 V

Strategic Partner

V

1..2 V


Open V

V

Closed

Supplier

VP

Deliverable

VP

VP

VP

Extension Development

Platform Interfaces

Security Check

1..3

1..3

Application View

V V

V

Software Product V

Source Code V

Software Service

1..2

Platform SDK V

V

Programming Language

V

Testing

IDE V

Communication Protocol

User Interface V

V

System Libraries

Platform Features

V

V

Policy Violation

Leaks & Bugs

VP

Service Execution

Infrastructure View

1..3

V

Operating System V

V

Data Center

Compute Centre

Figure 2.3.: Taxonomy of variabilities of store-oriented software ecosystems after iteration 2

2.7. Iteration 3: Empirical-to-Conceptual Approach In this section, we perform another iteration to enrich the taxonomy. There is a set of open questions that are going to be answered. Since existing ecosystems provide concrete information from the real world, we decide to perform an empirical-to-conceptual approach by exploring existing ecosystems. Examples of open questions are: a) How do users receive deliverables?, b) Do the ecosystems provide any asset?, and c) What are incentives for external developers?

2.7.1. Identifying New Subset of Ecosystems We continue using our list of existing ecosystems. We assume that this list is useful, because these ecosystems have not been examined with respect to the newly risen questions. Further-

2.7. ITERATION 3: EMPIRICAL-TO-CONCEPTUAL APPROACH

13

more, we continue to identify new ecosystems (i.e., Atlassian2 and GitHub3 ) that are not in our list.

2.7.2. Identifying Common Characteristics and Grouping Ecosystems Inspecting the ecosystems with respect to the open questions results in identifying a new set of characteristics. Similar to the previous empirical-to-conceptual iteration, we analyze the ecosystems by inspecting the technical documentation and information that are available on the Internet. The list of links to technical documentation can be found in Appendix C. Furthermore, the details of this inspection can be found in Appendix D. Result of this inspection is the identification of following common characteristics: • The ecosystems motivate external developers by introducing incentives. Examples of incentives are rating, reputation, funding, discounts on platform fee, advertisement of external applications in form of featured applications, etc. • The deliverable are delivered as web services, cloud services, or generally using a remote server. Or, They are applications that users need to download and install them on their devices. Furthermore, some ecosystems provide their own asset (device). For instance, iOS is runnable only on the proprietary asset of Apple Inc., i.e., iPhone, iPad, and iPod. • To deliver and execute deliverables, the ecosystems require variety of hardware and software resources, e.g., content delivery network services to cache information and ensure a high quality service delivery. While some ecosystems only rely on world wide web for the purpose of service delivery, some others use telecommunication services that are provided by Telco companies.

2.7.3. Grouping Characteristics into Dimensions to Create Taxonomy Similar to Section 2.5.3, we group the newly emerged characteristics to form new dimensions of the taxonomy. The grouping action follows the goal of taxonomy, i.e., to identify architectural variabilities of store-oriented software ecosystems, which results in identifying the following dimensions and characteristics: • D8 = incentive with characteristics C81 = moral value and C82 = material value • D9 = delivery mode with characteristics C91 = local installation and C92 = remote delivery 2 3

https://www.atlassian.com/ https://github.com/

14



Business View

VP

VP

Openness

Incentive

1..3 V

Strategic Partner

V

1..2

1..2 V3.1

V


Open

Moral Value V3.1

V

V

Material Value

Closed

Supplier

VP

Deliverable

VP

VP

VP


Platform Interfaces

Security Check

1..3

Application View

V

V

Software Product V

Platform SDK

Source Code V

Software Service

V

User Interface

Testing

IDE Programming Language

V

V


VP

VP

V

V

System Libraries V

Platform Features

Policy Violation

Leaks & Bugs

VP

VP

Delivery Mode

Service Delivery

Asset 1..3

1..2

1..3 V V

Operating System V

Legend

V

V

Service Execution

Infrastructure View

1..2

1..3 V

VP

VP

V

Data Center

Local Installation

Compute Centre

Mandatory Variation Point Optional Variation Point

V V

Cloud Delivery

Telecommunication

V

Exclusively WWW

V Content Delivery Network

[min..max]

V



Figure 2.4.: Taxonomy of variabilities of store-oriented software ecosystems after iteration 3 • D10 = service delivery with characteristics C10 1 = exclusively over telecommunication networks provided by telcos, C10 2 = content delivery network (CDN), and C10 3 = exclusively over WWW • D11 = asset



15

2.8. Iteration 4: Conceptual-to-Empirical Approach We need to perform another iteration, because, there are open questions left from the previous iterations. The following questions are to be considered in this iteration: a) How do ecosystems provide software licensing? b) What is the degree of freedom given to developers in choosing a suitable license for their applications? c) What are typical fees and charges in software ecosystems? We choose the conceptual-to-empirical approach for this iteration, because, during the literature review, we have encountered concepts in the literature that are related to the newly risen open questions.

2.8.1. Conceptualize New Characteristics and Dimensions of Ecosystems [AAS09] defines licensing as a set of legal rules that defines cases and scope of software use and its redistribution. There are public software licensing systems such as GNU General Public License or shortly GPL. GPL allows free usage, execute, and altering source code. Ecosystems may use such public licenses or may introduce their own licensing system to protect external developers’ right. Fee has a direct relation to different degree of access to software platforms that is granted to an actor. Moreover, external developers, who wish to publish their application on the store, may need to pay certain amount of periodic or one-time entrance fee [VAKJP11].

2.8.2. Examine Ecosystems for the Characteristics and Dimensions In this step, we try to answer the question whether “Are there objects that have each of the characteristics in each dimension?” by examining existing ecosystems. To do so, we refer to our list of existing ecosystems. We inspect the ecosystems. The result is that not any ecosystem provides software licensing. Moreover, not any ecosystem expect users and developers pay for platform usage or store usage. Therefore, we consider licensing and fee as optional variation points. Furthermore, we notice that, in open source communities, the ecosystems usually use licenses that are publicly available. Whereas commercial ecosystems invent their own licensing system that conforms to their license of agreements and regulations.

2.8.3. Revise Taxonomy According to the conceptualization performed in Section 2.8.1 and the examination in Section 2.8.2, we define the following dimensions and characteristics:

16


• D12 = licensing with characteristics C12 1 = public licensing and C12 2 = ecosystemspecific licensing. This variability determines the way that platform providers regulate software licensing at developers and end-users sides. • D13 = fee with characteristics C13 1 = platform fee and C13 2 = entrance fee. Fee is a medium for platform providers to protect intellectual property by introducing different degree of payments for platform users and complementary partners.


2.9. Iteration 5 & Iteration 6 Until this step, the open questions regarding the meta-characteristics are answered by the previous iterations. In the following, we continue the process of taxonomy development with another conceptual-to-empirical iteration. We consider whether the literature addresses new characteristics or dimensions, which have not been included in the taxonomy. This process results in conceptualization of no characteristic or dimension. According to the ending conditions, the taxonomy is not further enriched in this iteration. In this situation, researchers are allowed terminate the process of taxonomy development. To ensure about the validity of our decision regarding the termination of taxonomy development, we conduct another empirical-to-conceptual approach as our 6th iteration. In this iteration, we inspect the existing ecosystems to check whether further common characteristics can be identified. This inspection results in identifying no common characteristic, which has not been included in the taxonomy. We observe that the variability model provides a suitable abstraction to describe important aspects of store-oriented software ecosystems.Therefore, according to the ending condition, no other empirical-to-conceptual iteration is necessary. At this point, we terminate the process of taxonomy development.

17

2.9. ITERATION 5 & ITERATION 6

VP


Business View

VP

VP

Openness

Incentive

Licensing

1..3 V

Strategic Partner

V

1..2

1..2 V

V


VP

VP

V

V

V

Closed

Supplier

VP

Deliverable

V

Software Product V

Source Code

VP

VP

VP


Platform Interfaces

Security Check

V

Software Service

V

V

V

User Interface

Testing

IDE V

Programming Language


VP

VP

1..2

V

V

V

System Libraries V

Platform Features

Policy Violation

Leaks & Bugs

VP

VP

Delivery Mode

Service Delivery

Asset 1..3

1..2

1..3 V V

Operating System V

Legend

Entrance Fee

Platform SDK

Service Execution

Infrastructure View

V

V Ecosystemspecific Licensing

Material Value

1..3 V

V

Platform Fee

V

Public Licensing

1..3

Application View

1..2

1..2 V

Moral Value

Open

Fee

VP

VP

V

Data Center

Local Installation

Compute Centre Mandatory Variation Point Optional Variation Point

V V

Cloud Delivery

Telecommunication

V

Exclusively WWW

V Content Delivery Network

[min..max]

V



Figure 2.5.: Taxonomy of variabilities of store-oriented software ecosystems after iteration 4

Bibliography [AAS09]

Thomas A Alspaugh, Hazeline U Asuncion, and Walt Scacchi. The role of software licenses in open architecture ecosystems. In International Workshop on Software Ecosystems@ ICSR, 2009. 15

[BBS10a]

Jan Bosch and Petra Bosch-Sijtsema. From integration to composition: On the impact of software product lines, global development and ecosystems. Journal of Systems and Software, 83(1):67–76, 2010. 5

[BBS10b]

Jan Bosch and Petra M. Bosch-Sijtsema. Softwares product lines, global development and ecosystems: Collaboration in software engineering. In Collaborative Software Engineering, pages 77–92. Springer, 2010. 10

[Bos09]

Jan Bosch. From software product lines to software ecosystems. In Software Product Line Conference, pages 111–119. Carnegie Mellon University, 2009. 10

[Bos10]

Jan Bosch. Architecture challenges for software ecosystems. In ECSA- Companion Volume, pages 93–95. ACM, 2010. 10

[EB12]

Ulrik Eklund and Jan Bosch. Using architecture for multiple levels of access to an ecosystem platform. In International ACM SIGSOFT Conference on Quality of Software Architectures, pages 143–148. ACM, 2012. 1

[JBSL12]

Slinger Jansen, Sjaak Brinkkemper, Jurriaan Souer, and Lutzen Luinenburg. Shades of gray: Opening up a software producing organization with the open software enterprise model. Journal of Systems and Software, 85(7):1495–1510, 2012. 10

[JPEK16a]

Bahar Jazayeri, Marie C. Platenius, Gregor Engels, and Dennis Kundisch. Features of IT Service Markets: A Systematic Literature Review. In ICSOC, pages 301–316. Springer, 2016. 5

[JPEK16b]

Bahar Jazayeri, Marie Christin Platenius, Gregor Engels, and Dennis Kundisch. IT Service Markets: A Systematic Literature Review – Supplementary Material. Technical Report tr-ri-16-350, Heinz Nixdorf Institute, University of Paderborn, 2016. https://www.hni.uni-paderborn.de/pub/9342. 5, 6

19

20

B IBLIOGRAPHY

[MH13]

Konstantinos Manikas and Klaus Marius Hansen. Software ecosystems–a systematic literature review. Journal of Systems and Software, 86(5):1294–1306, 2013. 1

[MPH+ 07]

Andreas Metzger, Klaus Pohl, Patrick Heymans, Pierre-Yves Schobbens, and Germain Saval. Disambiguating the documentation of variability in software product lines: A separation of concerns, formalization and automated analysis. In RE, pages 243–253. IEEE, 2007. 5

[NVM13]

Robert C. Nickerson, Upkar Varshney, and Jan Muntermann. A method for taxonomy development and its application in information systems. European Journal of Information Systems, 22(3):336–359, 2013. 3, 4, 7, 9, 10

[SEL14]

Klaus-Benedikt Schultis, Christoph Elsner, and Daniel Lohmann. Architecture challenges for internal software ecosystems: A large-scale industry case study. In ACM SIGSOFT International Symposium on Foundations of Software Engineering, pages 542–552. ACM, 2014. 10

[VAKJP11] Joey Van Angeren, Jaap Kabbedijk, Slinger Jansen, and Karl Michael Popp. A Survey of Associate Models used within Large Software Ecosystems. In International Workshop on Software Ecosystems, pages 27–39. Citeseer, 2011. 16 [VAMPR04] R. Hevner Von Alan, Salvatore T. March, Jinsoo Park, and Sudha Ram. Design science in information systems research. MIS quarterly, 28(1):75–105, 2004. 3

Appendix A. Initial Inspection of existing Ecosystems In this section, we provide the details that we document during the inspection of the initial subset of existing ecosystems with respect to the meta-characteristics.

No.

Ecosystems (named after their store)

Platform

- Mobile OS (iOS) 1

Apple App Store

2

Google Play

3

Microsoft Store

- Mobile OS (Android)

-

- Android

-

Browser (Mozilla Firefox)

- Open source community of developers - Open source community of developers - B2B Partners - External developer

Amazon.com: Apps & Games

6

Mozilla Firefox Marketplace

7

Browser (Google Google Chrome Chrome) Store SAP Store

-

for manufacturing iPhone and iPad External developers Hardware and software suppliers External developers Hardware and software suppliers External developers Hardware and software suppliers External developers

- BlackBerry OS

5

SAP Services

Service / Product

- External developers - Mobile Apps - Hardware suppliers - iCloud services

- Mobile OS (Microsoft Windows)

4 BlackBerry World

8

Collaboration

- Mobile Apps - Google services - Mobile Apps - OneDrive services - Mobile Apps - OneDrive services - Android Apps - Extensions

- Add-ons

- SAP solutions - 3rd-party solutions

21

22

APPENDIX A. INITIAL INSPECTION OF EXISTING ECOSYSTEMS

No.


Platform

cloud services 9

StrikeIron

Collaboration

Service / Product

- B2B Partners - Cloud-based data - External developers services: - Enterprises and - email verification business experts - Address verification

- Phone validation 10

SalesForce AppExchange

- Salesforce - force.com

- Consulting Partners - CRM Apps - External developers - Enterprise Cloud - Infrastructure & SaaS

- AWS

- Commercial vendors - AWS-based SaaS,

Software supplier

11 AWS Marketplace

12

Oracle Cloud Marketplace

13

Eclipse Marketplace

14

15

16

17

18

Oracle Cloud services (SaaS, PaaS, IaaS)

Eclipse IDE

including IBM, Microsoft, etc. - Open-source provision from Nginx - Consulting Partners - External developers - Infrastructure & Software supplier - Eclipse Foundation consists of several collaborators - External developers

- products for external platforms like Envato Wordpress, Joomla, Drupal, etc. Development platforms - Open source Mashape (Galileo, Kong, Gelato) community of developers/freelancers - Generally avialable - Open source platforms: community of developers/freelancers - Programming Binpress languages - Mobile - Desktop - Web - Network visualisation - Open source Cytoscape App and analysis platform community of Store developers/freelancers - TEX - Open source community of CTAN: Packages developers

PaaS, and IaaS

Oracle-based cloud services

- Eclipse plug-ins - Eclipse projects - Digital arts and artifacts

- APIs

- Commercial and open source projects

- Commercial and open source projects - TEX-related packages

Appendix B. Sources of Literature Review This section provides the complete list of literature sources that are used in the conceptual-toempirical iterations during the taxonomy development.

[1]A. Baars and S. Jansen, “A framework for software ecosystem governance,” in International Conference of Software Business, 2012, pp. 168–180. [2]G. K. Hanssen, “A longitudinal case study of an emerging software ecosystem: Implications for practice and theory,” Journal of Systems and Software, vol. 85, no. 7, pp. 1455–1466, 2012. [3]M. Cataldo and J. D. Herbsleb, “Architecting in software ecosystems: interface translucence as an enabler for scalable collaboration,” in Proceedings of the Fourth European Conference on Software Architecture: Companion Volume, 2010, pp. 65–72. [4]M. Che and D. E. Perry, “Architectural design decisions in open software development: A transition to software ecosystems,” in 2014 23rd Australian Software Engineering Conference, 2014, pp. 58–61. [5]K.-B. Schultis, C. Elsner, and D. Lohmann, “Architecture challenges for internal software ecosystems: a large-scale industry case study,” in Proceedings of the 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering, 2014, pp. 542–552. [6]J. Bosch, “Architecture challenges for software ecosystems,” in Proceedings of the Fourth European Conference on Software Architecture: Companion Volume, 2010, pp. 93–95. [7]U. Eklund and J. Bosch, “Architecture for embedded open software ecosystems,” Journal of Systems and Software, vol. 92, pp. 128–142, 2014. [8]S. Jansen, A. Finkelstein, and S. Brinkkemper, “A sense of community: A research agenda for software ecosystems,” in Software Engineering-Companion Volume, 2009. ICSE-Companion 2009. 31st International Conference on, 2009, pp. 187–190. [9]J. Van Angeren, J. Kabbedijk, S. Jansen, and K. M. Popp, “A Survey of Associate Models used within Large Software Ecosystems.,” in IWSECO@ ICSOB, 2011, pp. 27–39. [10]A. Ghazawneh and O. Henfridsson, “Balancing platform control and external contribution in thirdparty development: the boundary resources model,” Information Systems Journal, vol. 23, no. 2, pp. 173–192, 2013.

23

24

APPENDIX B. SOURCES OF LITERATURE REVIEW

[11]P. Kruchten, “Contextualizing agile software development,” Journal of Software: Evolution and Process, vol. 25, no. 4, pp. 351–361, 2013. [12]S. Jansen and M. A. Cusumano, “Defining software ecosystems: a survey of software platforms and business network governance,” Software ecosystems: analyzing and managing business networks in the software industry, vol. 13, 2013. [13]A. Metzger, K. Pohl, P. Heymans, P.-Y. Schobbens, and G. Saval, “Disambiguating the documentation of variability in software product lines: A separation of concerns, formalization and automated analysis,” in Requirements Engineering Conference, 2007. RE’07. 15th IEEE International, 2007, pp. 243–253. [14]K. Schmid and H. Eichelberger, “EASy-Producer: from product lines to variability-rich software ecosystems,” in Proceedings of the 19th International Conference on Software Product Line, 2015, pp. 390–391. [15]J. McGregor, “Ecosystems, continued.,” Journal of Object Technology, vol. 8, no. 7, pp. 7–21, 2009. [16]M. Anvaari and S. Jansen, “Evaluating architectural openness in mobile software platforms,” in Proceedings of the Fourth European Conference on Software Architecture: Companion Volume, 2010, pp. 85–92. [17]G. Costa, F. Silva, R. Santos, C. Werner, and T. Oliveira, “From applications to a software ecosystem platform: an exploratory study,” in Proceedings of the Fifth International Conference on Management of Emergent Digital EcoSystems, 2013, pp. 9–16. [18]J. Bosch and P. Bosch-Sijtsema, “From integration to composition: On the impact of software product lines, global development and ecosystems,” Journal of Systems and Software, vol. 83, no. 1, pp. 67–76, 2010. [19]J. Bosch, “From software product lines to software ecosystems,” in Proceedings of the 13th international software product line conference, 2009, pp. 111–119. [20]K. M. Popp, “Goals of Software Vendors for Partner Ecosystems–A Practitioner ́s View,” in International Conference of Software Business, 2010, pp. 181–186. [21]K. Plakidas, S. Stevanetic, D. Schall, T. B. Ionescu, and U. Zdun, “How do software ecosystems evolve? a quantitative assessment of the r ecosystem.,” in Proceedings of the 20th International Systems and Software Product Line Conference, 2016, pp. 89–98. [22]A. Gawer and M. A. Cusumano, “Industry platforms and ecosystem innovation,” Journal of Product Innovation Management, vol. 31, no. 3, pp. 417–433, 2014. [23]U. Eklund and J. Bosch, “Introducing software ecosystems for mass-produced embedded systems,” in International Conference of Software Business, 2012, pp. 248–254. [24]S. P. Gregg, R. Scharadin, E. LeGore, and P. Clements, “Lessons from AEGIS: organizational and governance aspects of a major product line in a multi-program environment,” in Proceedings of the 18th International Software Product Line Conference-Volume 1, 2014, pp. 264–273. [25]A. A. Albez and O. Terzidis, “Management of Partner Ecosystems in the Enterprise Software Industry–The Partner Selection.” [26]H. Hartmann and J. Bosch, “Orchestrate your platform: architectural challenges for different types of ecosystems for mobile devices,” in International Conference of Software Business, 2014, pp. 163–178. [27]A. Gawer and M. A. Cusumano, Platform leadership: How Intel, Microsoft, and Cisco drive industry innovation. Harvard Business School Press Boston, 2002. [28]K. Manikas, “Revisiting software ecosystems research: a longitudinal literature study,” Journal of Systems and Software, vol. 117, pp. 84–103, 2016.

25

[29]S. Jansen, S. Brinkkemper, J. Souer, and L. Luinenburg, “Shades of gray: Opening up a software producing organization with the open software enterprise model,” Journal of Systems and Software, vol. 85, no. 7, pp. 1495–1510, 2012. [30]K. Manikas and K. M. Hansen, “Software ecosystems–a systematic literature review,” Journal of Systems and Software, vol. 86, no. 5, pp. 1294–1306, 2013. [31]J. Bosch, “Software Ecosystems–Implications for Strategy, Business Model and Architecture,” in Software Product Line Conference (SPLC), 2011 15th International, 2011, pp. 351–351. [32]J. Bosch, “Software ecosystems: Taking software development beyond the boundaries of the organization,” The Journal of Systems & Software, vol. 7, no. 85, pp. 1453–1454, 2012. [33]J. Bosch and P. M. Bosch-Sijtsema, “Softwares product lines, global development and ecosystems: collaboration in software engineering,” in Collaborative Software Engineering, Springer, 2010, pp. 77–92. [34]R. N. Taylor, “The role of architectural styles in successful software ecosystems,” in Proceedings of the 17th International Software Product Line Conference, 2013, pp. 2–4. [35]N. Khedri and R. Khosravi, “Towards managing data variability in multi product lines,” in Model-Driven Engineering and Software Development (MODELSWARD), 2015 3rd International Conference on, 2015, pp. 1–8. [36]U. Eklund and J. Bosch, “Using architecture for multiple levels of access to an ecosystem platform,” in Proceedings of the 8th international ACM SIGSOFT conference on Quality of Software Architectures, 2012, pp. 143–148. [37]M. Galster, D. Weyns, D. Tofan, B. Michalik, and P. Avgeriou, “Variability in software systems—a systematic literature review,” IEEE Transactions on Software Engineering, vol. 40, no. 3, pp. 282–306, 2014. [38]T. Berger et al., “Variability mechanisms in software ecosystems,” Information and Software Technology, vol. 56, no. 11, pp. 1520–1535, 2014.

Appendix C. List of Technical Links In this section, we provide more details on the technical sources of information that are used in the taxonomy development. By technical source, we mean websites, technical documentation, links to developer portal, link to question & answer forums. The links to the sources are accessed in a time period from December 2016 to June 2017. Our main work, to which this document is a supplementary material, presents a comparison of existing ecosystems based on the variability model. The list of technical sources in this section includes links to the documentation that are used in the corresponding comparison.

No. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

URL https://www.apple.com/ios/app-store/ play.google.com www.microsoftstore.com https://appworld.blackberry.com/webstore/?countrycode=NL&lang=en https://www.atlassian.com/software/marketplace https://addons.mozilla.org https://github.com/forcedotcom https://chrome.google.com/webstore https://marketplace.informatica.com/index.jspa https://appexchange.salesforce.com https://aws.amazon.com/marketplace https://cloudmarketplace.oracle.com/marketplace https://www.sapstore.com https://marketplace.eclipse.org/ https://market.mashape.com https://www.binpress.com

27

28

No. 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49

APPENDIX C. LIST OF TECHNICAL LINKS

URL http://apps.cytoscape.org/ https://www.sapstore.com/ https://www.amazon.com/mobile-apps/b?ie=UTF8&node=2350149011 https://www.ctan.org/pkg?lang=en https://github.com/marketplace https://envato.com/#products https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/ sforce_api_om_outboundmessaging_setting_up.htm https://developer.apple.com/library/content/documentation/AppleApplications/Reference/ SafariWebContent/Introduction/Introduction.html#//apple_ref/doc/uid/TP40002051-CH1-SW1 https://developer.apple.com/library/content/documentation/Miscellaneous/Conceptual/ iPhoneOSTechOverview/iPhoneOSTechnologies/iPhoneOSTechnologies.html https://trailhead.salesforce.com/modules/apex_database/units/apex_database_intro www.joshmorony.com/the-challenges-of-developing-ios-applications-on-a-pc/ http://awsmp-loadforms.s3.amazonaws.com/AWS_Marketplace_-_Seller_Guide.pdf www.salesforce.com/assets/pdf/misc/Salesforce-Industry-Fullforce-Brochure.pdf https://partners.salesforce.com/ https://www.eclipse.org/membership/exploreMembership.php www.jot.fm/issues/issue_2009_09/column1/ https://developer.salesforce.com/forums/?id=906F00000008mukIAA https://developer.salesforce.com/docs/atlas.en-us.workbook_lma.meta/workbook_lma/ lma_license_details.htm adcdownload.apple.com/Documentation/License_Agreements__Apple_Developer_Program/ Apple_Developer_Program_License_Agreement_20160921.pdf https://developer.apple.com/terms/ https://aws.amazon.com/marketplace/help/seller-AMIs?ref=help_ln_sibling https://developer.apple.com/app-store/review/guidelines/#app-completeness https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/intro_framework.htm https://aws.amazon.com/tools/ docs.aws.amazon.com/AmazonS3/latest/API/APISoap.html stackoverflow.com/questions/9091767/up-to-date-instructions-on-how-to-installxmppframework-manually/30543948#30543948 stackoverflow.com/questions/204465/how-to-access-soap-services-from-iphone https://help.salesforce.com/articleView?id=integrate_what_is_api.htm&type=0 https://www.messagesystems.com/products/momentum https://www.symantec.com/about/newsroom/press-releases/2011/symantec_0503_05 www.oracle.com/us/corporate/press/1964798 https://www.apple.com/pr/library/2014/07/15Apple-and-IBM-Forge-Global-Partnership-toTransform-Enterprise-Mobility.html appleinsider.com/articles/16/06/10/intel-lte-modems-to-power-att-version-of-apples-iphone-7--report https://resources.docs.salesforce.com/206/latest/en-us/sfdc/pdf/ salesforce_apex_language_reference.pdf

Appendix D. Iteration 3: Inspection of existing Ecosystems This section provides the details regarding the inspection of the existing ecosystems in the third iteration.

No.

Ecosystems How do users Which (named after their receive technologies do store) deliverables? support service delivery? - Telco Apple App Store - download from the store companies like and install Verizon, 1 Telecom, etc. - Providers of CDN services Google Play - download - WWW from the store and install 2 - download from the store and install

- Telco

BlackBerry World - download from the store and install 4

- Telco

Microsoft Store 3

-

-

companies Providers of CDN services

Do the ecosystem provide any asset? Yes- iPhone, iPad, iPod

Yes- Google Pixel

-

- earn money - reputation - identifying the

Yes- Microsoft Surface

-

Yes- BlackBerry

-

companies Providers of CDN services

Amazon.com: Apps & Games

- download from the store and install

- WWW

- Amazon Kindle Fire

-

Mozilla Firefox 6 Marketplace

- download from the store and install

- WWW

No

-

5

What are incentives for external developers? earn money reputation identifying the best Apps as featured App

best Apps as featured App earn money reputation identifying the best Apps as featured App earn money reputation identifying the best Apps as featured App earn money reputation identifying the best Apps as featured App reputation

29

30

APPENDIX D. ITERATION 3: INSPECTION OF EXISTING ECOSYSTEMS

No.


Google Chrome 9 Store

How do users receive deliverables?

- download from the store and install SAP Store - download from 10 the store and install StrikeIron - remote delivery 11 using cloud services SalesForce - remote delivery 12 AppExchange using cloud services AWS Marketplace - remote delivery 13 using cloud services Oracle Cloud - remote delivery 14 Marketplace using cloud services Eclipse - download from the store and 15 Marketplace install Envato - download from the store and 16 install Mashape - remote delivery of functions 17 provided by web services Binpress - download from 18 the store and use Cytoscape App - download from 19 Store the store and install CTAN: Packages - download from 20 the store and install GitHub - download from 21 the store and install Atlassian - download and Marketplace install plug-ins for platforms, e.g., 22 JIRA, Confluence, etc.

Which technologies do support service delivery? - WWW

Do the ecosystem provide any asset? No

-

What are incentives for external developers? reputation

WWW, SAP No Network (e.g., intranet) - Providers of CDN No - WWW

- earn money

- Providers of CDN No - WWW

- earn money - reputation





- WWW

No

- reputation

- WWW

No


- WWW

No


- WWW

No

- WWW

No

- earn money - reputation - reputation

- WWW

No

- reputation

No


No

- earn money - reputation - identifying the

- WWW


best Apps as featured App