RE 2015 ecosystems tutorial

Business and Software Ecosystems:How to model, analyze, and survive!

Xavier Franch, Angelo Susi, Eric S.K. Yu(UPC) (FBK) (UofT)

[email protected], [email protected], [email protected]

Tutorial at RE’15, Ottawa, Aug. 2015

Agenda

• PART I. BUSINESS AND SOFTWARE ECOSYSTEMS• PART II. INTENTIONAL MODELING AND

ANALYSIS• PART III. HANDS-ON EXERCISE• PART IV. MODELING AND ANALYSIS OF OSS

ECOSYSTEMS FROM AN INTENTIONALPERSPECTIVE

• PART V. CONCLUSIONS

Agenda• PART I. BUSINESS AND SOFTWARE ECOSYSTEMS

– Definitions– The case of OSS ecosystems– State of the art on ecosystem modeling

• PART II. INTENTIONAL MODELING AND ANALYSIS• PART III. HANDS-ON EXERCISE• PART IV. MODELING AND ANALYSIS OF OSS

ECOSYSTEMS FROM AN INTENTIONAL PERSPECTIVE• PART V. CONCLUSIONS

EcosystemA system formed by the interaction of a

community of organisms with their environment

What type of organisms and environment

Ecosystems relevant to IS

• Business ecosystem– Focus is on organizations that co-create value

• Software ecosystem– Focus is on software systems that deliver integrated

solutions• Not independent

Business ecosystem (BECO)An economic community supported by a foundationof interacting organizations and individuals -- theorganisms of the business world (Moore, 1993)• Produces (co-creates) goods and services of value to

customers• Work cooperatively and competitively to support new

products, satisfy customer needs, and eventuallyincorporate the next round of innovations

It’s competition among business ecosystems,not individual companies, that’s largelyfueling today’s industrial transformation

Why BECOs

• share infrastructure• share market development

capability

riskcost• lower market entry barriers• facilitates customer engagement

• access specialized skills• moves faster

↓ ↓

↑

Business ecosystem actors

business ecosystem

extended enterprise

core businesscore contributorsdistribution channelsdirect customersdirect suppliers

standardbodies

customersof

customers

suppliersof

suppliers

suppliers ofcomplementary

products

tradeassociations

investors

regulatorybodies

competitors

otherstakeholders

labourunions

Examplecontent retailersadvertiserscontent ownersinternet playersbrands…content

appsservicesmarket…

$$$user engagement

$$$productsservices

access to market

revenue share

increasedresource needs

fasteradoption

StagesThe Evolutionary Stages of a Business Ecosystem

Key Challenge Cooperative Challenges Competitive ChallengesBirth Value With customers and suppliers:

New value propositionProtect ideas.Tie up critical leadcustomers, suppliers andchannels

The Evolutionary Stages of a Business EcosystemKey Challenge Cooperative Challenges Competitive Challenges

Birth Value With customers and suppliers:New value proposition

Protect ideas.Tie up critical leadcustomers, suppliers andchannels

Expansion Critical mass With suppliers and partners:Scale-up supply to maximizemarket

Ensure that your approachbecomes market standard






Leader-ship

Lead co-evolution &innovation

With customers and suppliers:Provide a compelling vision forthe future

Maintain strong bargainingpower in relation to otherplayers in the BECO






Leader-ship

Lead co-evolution &innovation

With customers and suppliers:Provide a compelling vision forthe future

Maintain strong bargainingpower in relation to otherplayers in the BECO

Renewal Continuousperformanceimprovement

With innovators: bring newideas to the existing BECO

Prevent innovators frombuilding alternative BECOs.Maintain high customerswitching costs

Ecosystem healthAbility of the ecosystem to endure and remainvariable and productive over time

Productivity

Robustness

Innovation

Diversity

BECO health

Survival ratePersistence of structureContinuity of UX

Sustained productionRate of product release

New productsShared assets

Product hetereogenityTransaction hetereogenity

Roles in ecosystems

Keystone Dominator

Developer Niche player

Keystones

Keystone Dominator


• Boosts productivity of the ecosystem– keeps focus; solves problems– create technological platforms to be exploited by

the rest of the ecosystem• Ensures sustainability

– prevents and bridges gaps– attract new members and customers

Improves the health of the ecosys-tem as a whole acting as regulator

Developer

Keystone Dominator

Developer Niche playerContributes to the ecosystem bygiving value and beneficingwithout a clear strategic influence

Dominator

Keystone Dominator


• Physical dominator: integrates with the purpose ofowning and managing (aggressive)– large size and market power; can’t change fast– blocks and absorbs changes

• Value dominator: creates little value whileextracting as much as possible– Short-term tactic of maximum value extraction, without

attending to ecosystem health– Extreme: parasite

Strongly influences growth direc-tions and business opportunities

Niche players

Keystone Dominator


• Innovation drivers– value creation

• Provide complementary assets– collaboration, not competition

• Invest in interactions– positions product as extension vs. standalone

Develops specialized capabilitiesthat differentiate them from others

Software ecosystems (SECO)Set of actors functioning as a unit and interacting with ashared market for software and services (Jansen andCusumano, 2012)

A collection of software projects which are developedand evolve together in the same environment (Lungu etal., 2010)

Collection of organizations that are related throughsoftware or a software related concept (a standard –XML, a product -OpenOffice, a hardware –Playstation 3, aplatform –Android)

Classification of SECOsUnderpinning

technology

Coordinators

Accessibility

SECOsExtension

market

platform standardservices

paid for freescreened

privately ownedconsortium

multiple singlelist of extensions

(Jansen and Cusumano, 2012)

Classification of SECOs: exampleTechnology Coordinators Extension

market Accessibility

Android Platform Privatelyowned

Single(commercial) Screened

Ruby Platform Consortium Multiple For free

Spotify Serviceplatform

Privatelyowned Single Screened

OSGi Standard Consortium List ofextensions Paid

Classification of SECOs: exampleTechnology Coordinators Extension

market Accessibility

Android Platform Privatelyowned

Single(commercial) Screened

Ruby Platform Consortium Multiple For free

Spotify Serviceplatform

Privatelyowned Single Screened

OSGi Standard Consortium List ofextensions Paid

The Android software ecosystem is based on a softwareplatform and coordinated by a privately owned entity

single with a single commercial extension market to whichparticipants can submit extensions which are screened by

the coordinators

BECOs and SECOs

A SECO consists of the set of software solutions that enable,support and automate the activities and transactions by the actorsin the associated BECO, and the organizations that provide thesesolutions (Bosch, 2009)

A BECO is an economic community supported by a foundation ofinteracting organizations and individuals-- organisms of thebusiness world (Moore, 1993)

• A SECO is part of a BECO– A SECO is not a different ecosystem than a BECO, but it is an ecosystem with

additional concepts and consequences

• A BECO talks about organizations and individuals, not aboutproducts

• In a SECO, products play a major role as actors in theecosystem



• PART II. INTENTIONAL MODELING AND ANALYSIS• PART III. HANDS-ON EXERCISE• PART IV. MODELING AND ANALYSIS OF OSS ECOSYS-

TEMS FROM AN INTENTIONAL PERSPECTIVE• PART V. CONCLUSIONS

OSS ecosystems

Ecosystems in which the co-creation of software isbasically open but regulated by:• strategies• licensesA community of developers play an importantpart in the evolution of the ecosystemOSS adopters may involve in the ecosystem attheir own interest

Example: XWiki BECO

• SME deploying the XWiki OSS CMS with severallicenses

• Supported by an OSS community (XWiki.org)• Integrated in the OW2 association• Strategic partnership with several companies• Active in EU projects ($$ + technical excellence)• Relying on several infrastructure providers

Example: XWiki SECO• Importance of the community (XWiki.org)• Software development infrastructure: Maven,

Eclipse, Git, Jenkins, XWiki, Nexus, JIRA• Server development infrastructure: Linux Debian,

Puppet (configuration), Vserver (virtualization),Nagios (monitoring/reporting)

• Libraries used: dozens (e.g., from Java, Apache, ...)• Deployment infrastructure: JVM, Tomcat,

MySQL, Postgres

OSS ecosystem health

(Franco-Bedoya et al., 2014)



• PART II. INTENTIONAL MODELING AND ANALYSIS• PART III. HANDS-ON EXERCISE• PART IV. MODELING AND ANALYSIS OF OSS ECOSYS-


Ecosystem modelingSeveral approaches for modeling ecosystems:• value model perspective• software product architecture in the running environment• quantitative network models• mathematical models to study particular strategies of

software vendors.We mention:• SSN: Boucharas et al. (2009)• Value Network models: Popp and Meyer (2010)• e3Value: Müller at al. (2011)• i*: Yu and Deng (2011)

Software Supply Network (SSN)• Part of the Software Ecosystem Metamodel (SEM)• Focus on the software supply chains

Company of InterestSupplier CustomerIntermediary

Trade relationships

Value Network models• Express the creation and interchange of value in

the ecosystem– goods, services, knowledge, revenue, …

e3Value models• Similar to Value Networks with focus on

economic value creation and exchange

Agenda


ANALYSIS– The i* framework– Analysis of i* models

• PART III. HANDS-ON EXERCISE• PART IV. MODELING AND ANALYSIS OF ECOSYS-


Model-based representation of ecosystems

Several approaches for modeling ecosystems:• value model perspective• software product architecture in the running

environment• quantitative network models• mathematical models to study particular strategies of

software vendors.

What about intentionality and sociality?• what are the intentions of the ecosystem actors?• what are they expectations on each other, and their

dependencies?

Strategic Modeling with i*• Origin in Requirement Engineering (RE)

o Asking the “why’s” behind requirementso Uncovering complex relationships among actors with

strategic intent• Actors are strategic

o What do I want?o How can I achieve what I want?o Who do I depend on to achieve what I want?

An intentional dependency

Car BeRepaired

ActorA

A very simple Strategic Dependency model in i*

ActorB

I want …I can

…

Actors’ Rationales

SoftwareVendor

Large customerbase

Attractive tonew customer

Customerloyalty

Profitability

Run softwarebusiness

High value

Usersatisfaction

Quick time-to-market

High quality Software beproduced

Sell softwareportfolio

Provide portfoliorelated services

Build softwarein-house

Integrate OEMsoftware

Help

AND AND

Help Help

Help Help

HelpHurt

End User

Satisfaction

Affordable

qualityvariety

Acquiresoftware

Havesoftware

Software

Software besupported and

maintained

ANDAND AND

Help

Help Help

Usersatisfaction

License andmaintenance

fee

TaskTask

Means-EndsLink

Means-EndsLink

GoalGoal

DecompositionLink

DecompositionLink

ContributionLink

ContributionLink

DependencyLink

DependencyLink

SoftgoalSoftgoal

ResourceResource

ActorActor

A not-so-simple Strategic Rationale model in i*

i* Concepts

Softgoal

Goal

Task

Resource

Means-Ends link

Decomposition link

Make

HelpContribution link

Dependency link

Unknown

Hurt

Break

Actor

Two Contrasting ConfigurationsTraditional Software Supply Chain

• Actors: Software Vendor, End-User, OEM Supplier

• Predominantly linear relationshipfrom the end-user to thesoftware vendor and from thevendor to its suppliers

Open Ecosystem• Actors: Software Vendor, End-

User, Developer• Complex network relationship

between the software vendor anda large number of developers andend-users it aims to attract

Understanding Software Ecosystems: AStrategic Modeling Approach 40

`

Traditional Software Supply Chain

Software Vendor wants:- OEM software- Software knowledge- Good quality- Short timing

OEM Supplier wants:- License and maintenance fee- Large customer- Visibility

Understanding Software Ecosystems: AStrategic Modeling Approach

Open Ecosystem

Software Vendor wants:- Platform-specific applicationsbe developed- Revenue share- Creativity- Developer satisfaction

Developer wants:- Platform- Platform be supported andmaintained- Powerful features- Fair condition of use- Market channel be provided- Quick to market- Visibility

Agenda


ANALYSIS– The i* framework– Analysis of i* models

• PART III. HANDS-ON EXERCISE• PART IV. MODELING AND ANALYSIS OF ECOSYS-


For each actor: Are strategic goals met?

√ satisfied√. weakly satisfiedX deniedX. weakly denied

What if the vendor’s platformis not easy-to-use from

the developer’s viewpoint?

Contrasting Two Software Ecosystems

A fundamental ecosystem challenge for PlatformDevelopers: How to build, grow and sustain a softwareecosystem?• Attract external application developers• Establish sustainable collaborative relationships with

application developers

Mahsa H. Sadi, Jiaying Dai, Eric Yu (2014). Designing Software Ecosystems: How to Develop SustainableCollaborations. CAiSE 2015 Workshop on Digital Business Innovation and the Future EnterpriseInformation Systems Engineering .

To develop and sustain a software ecosystemDeveloper’s satisfaction is a critical dependencyfor a mobile platform developer

Material drawn from:Koch, S., & Kerschbaum, M. (2014). Joining a smartphone ecosystem:Application developers’ motivations and decision criteria.Information and Software Technology, 56(11), 1423-1435.

Mobile platform developer needs to elicit and analyzeWhat factors lead to developers’ satisfaction?

The Apple iOS Software EcosystemWhat do Apple iOS App developers want?

Elicit and IdentifyDevelopers’

Objectives andDecision Criteria

1.1What factors lead to iOS developers’ satisfaction?

Apple third-party developers are mainly driven by financialgain.

- Koch& Kerschbaum (2014)Elicit and IdentifyDevelopers’


1.1

Intellectual stimulation is also an important factor for thedevelopers who join Apple iOS ecosystem.



1.1

Non -TechnicalRequirements

These developers often prefer to charge fee for theirapplication being used by Apple iPhone/iPad end users.



1.1

The main characteristics of the iOS platform that motivate thisgroup to join Apple iOS ecosystem are as follows: (a) Large networksize of the platform (composed of the number of users, the marketsize, and the number of applications), and (b) the tight integrationof the platform. - Koch& Kerschbaum (2014)

TechnicalRequirement



1.1

A tightly integrated platform makes the complementaryapplication development process easier for developers withstrong motivations in financial gains by optimizing developmentefforts and facilitating the targeting of the applications.

- Koch& Kerschbaum (2014)



1.1

What factors and features influence orincrease intellectual stimulation inapplication developers?

To what factors and features tightintegration of software platformrefer to?

Refine theObjectives and

Decision Criteria

2.1

1

2

3

Hypothetical PrioritizationReal-world data is required to prioritize therequirements

Identify theImportance andPriority of the

Decision Criteria

2.2

Hypothetical EvaluationReal-world data is required to evaluate thefulfillment of the requirementsIdentify the Degree

of Fulfillment of thedecision Criteria

2.3

Fully-Satisficed

Partially-Denied

How to improve thefulfillment of the financialgain motivation of applicationdevelopers?

Hypothetical ConclusionFinancial gain is the first priority requirementof iOS application developers

Mobile Softwarebe developed

OpenInnovation

iOS Platformbe Developed

iOS Applicationsbe Developed

Delegate Development of iOSApplications to External Developers

ExternalDevelopersAttracted

Apple – iOSPlatform

Developer

iOSApplicationDeveloper

Mobile Applicationsbe Developed

Obtain SoftwareDevelopment

Toolkit

SoftwareDevelopment

Toolkit

DevelopmentSatisfaction

Developer’sSatisfaction

Provide SoftwareDevelopment Toolkit

iOS Apps beDeveloped

Financial Gain fromApplication Development

Intellectualstimulation

Increased attractivenessof [Mobile] platform

Increased Number of SupportingApplications

Tight Integrationof Platform

Sell MobileApplications

Large NetworkSize of thePlatform

OptimizedDevelopment

EffortsEasy to Target

Application

The same modeling steps can be followed to explicatethe objectives and decision criteria of the platformdeveloperDerive Alternative

Design Solutions

4


OpenInnovation






Developer




Toolkit

SoftwareDevelopment

Toolkit






Support ApplicationDevelopers









Application

Derive AlternativeDesign Solutions

4


OpenInnovation






Developer




Toolkit

SoftwareDevelopment

Toolkit








Build Market Channelfor Applications



Become Visible tothe Market






Application

For selling the mobile applications, developers becomedependent on iOS platform developer, for the goal of“Applications become visible to the market place”Derive Alternative

Design Solutions

4

Solution for supporting iOS external developersTo “Build market channels for applications”, and to“Build app store”Derive Alternative

Design Solutions

4


OpenInnovation






Developer




Toolkit

SoftwareDevelopment

Toolkit








Build Market Channelfor Applications



Become Visible tothe Market

Registration Fees




30% RevenueShare


Efforts

Build AppStore Easy to Target

Application

The Google Android Software EcosystemWhat do Android app developers want?



1.1What factors cause Android developers’ satisfaction?


Decision Criteria

2.1 The same modeling steps has been followed toexplicate the objectives and decision criteria ofAndroid Application Developers

How to improve the fulfillment of thefeeling of being recognized in theAndroid application developers?

The same hypothetical analysis steps have beenfollowed to conclude the requirements.

Solution for supporting Google external developersTo “Develop Community Websites” in order topublicize the information about the innovations tothe end users and the developers’ community

Derive AlternativeDesign Solutions

4

Activities in the modeling process

• Identify the main actors in the ecosystem– roles and agents– others may emerge as we progress

• Identify big groups of dependencies– enablers of keystone, their consumers, partnerships, …

Proposed Approach- Modeling Guidelines

Elicit theRequirements of

a SustainableCollaboration

Derive AlternativeSolutions for Designing

a CollaborativeEnvironment

1Identify and

Categorize DifferentTypes of Application

Developers

2 3

Elicit and ModelDevelopers’



Decision Criteria intoRequirements

Identify theDegree of

Fulfillment of theRequirements

Identify theImportance andPriority of theRequirements

1.1 2.1 2.2 2.3

ModelStakeholdersas Actors and

Roles

Model Operationsand Activities ofstakeholders asGoals and Tasks

Model the objectivesand Decision Criteriaof Collaborators as

Soft Goals

Model the Reasoningbehind the Adoption of

Activities asContribution Links

Model the Relationshipsamong Stakeholders asStrategic Dependencies

Use Decomposition andMeans-Ends Links to

Refine the Objectives andDecision Criteria

1.1.1 1.1.2 1.1.3 1.1.4

1.1.5 2.1.1

Guidelines for modeling the objectivesand decision criteria using the i*modeling technique

Mahsa H. Sadi, Jiaying Dai, Eric Yu (2014). Designing SoftwareEcosystems: How to Develop Sustainable Collaborations. CAiSE 2015Workshop on Digital Business Innovation and the Future EnterpriseInformation Systems Engineering .

The “i* book”

Social Modeling for Requirements Engineering

• MIT Press 2011. 742 pp.• E. Yu, P. Giorgini, N. Maiden, J. Mylopoulos• Reprint of 1995 PhD dissertation• + 18 chapters on applications from many authors

iStar workshop series

1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013

• iStar workshops– 2001 Trento– 2005 London– 2008 Recife– 2010 Hammamet– 2011 Trento– 2013 Valencia– 2014 Thessaloniki– 2015 Ottawa

• iStarT workshop– 2015 Stockholm

iStar’11 @RE Trento

iStar’13 @CAiSE Valencia

Tool demos

Industry showcase/tutorials• “Exploring the Goals of your Systems and

Businesses: Practical experiences with i* modelling”– N. Maiden, E. Yu, X. Franch, J. Mylopoulos– BCS RESG, London, 2011

• “Practical Applications of i* in Industry: The State ofthe Art”– E. Yu, D. Amyot, G. Mussbacher, X. Franch, J. Castro– Mini-tutorial @ RE’13 Rio de Janeiro

71

http://istarwiki.org/tiki-index.php?page=i*-related+Phd+Dissertations

• User Requirements Notation (URN)– Goal Requirements Language (GRL)– http://www.itu.int/rec/T-REC-Z.151/en

– Initiated from the telecom industry– ITU-T Recommendation Z.151 (2008, 2012)

• Ongoing efforts– Panel this afternoon (@iStar workshop)– Discussion tomorrow lunch (STE 5084 SITE building)

International Standard

Tools• Canada (U Toronto)

– OME, OpenOME• Canada (U Ottawa)

– jUCMnav for URN• England & Spain

– REDEPEND- REACT• Italy

– TAOM4E , GR Tool, T Tool , ST Tool• Spain

– GR-Tool , J-PRiM , HiME• Germany

– S-Net Tool• Brazil

– Istar Tool, xGOOD, GOOSE• Belgium

– DesCARTES

22 listed on i* wikihttp://istarwiki.org/tiki-index.php?page=i*+Tools&structure=i*+Wiki+Home

Agenda• PART I. BUSINESS AND SOFTWARE ECOSYSTEMS• PART II. INTENTIONAL MODELING AND

ANALYSIS• PART III. HANDS-ON EXERCISE• PART IV. MODELING AND ANALYSIS OF OSS ECO-

SYSTEMS FROM AN INTENTIONAL PERSPECTIVE– Catalogue of actors– Common OSS adoption strategies– An example: risk management in OSS projects


Analyzing vulnerabilities

• Example of enforcement mechanism– Reciprocal dependency

• Loop analysis

Analyzing vulnerabilities

• Example of assurance mechanism– Goal synergy or conflict

• Node analysis

Are Actors’ Strategic Goals Met?

√ satisfied√. weakly satisfiedX deniedX. weakly denied

What if the vendor’s platformis not easy-to-use from

the developer’s viewpoint?

[Yu Deng IWSECO’11Understanding Software EcosystemsUsing Strategic Modeling]

Analysis of i* models

• “Qualitative” techniques (e.g., logic based)

• “Quantitative” (e.g., based on propagationalgorithms and and feed via statisticalevidences…)

The XWiki case – revisited

• SME deploying the XWiki OSS CMS with severallicenses

• Supported by an OSS community (XWiki.org)• Integrated in the OW2 association• Strategic partnership with several companies• Active in EU projects ($$ + technical excellence)• Relying in several infrastructure providers

A small exercise on ecosystem modelling using i*• Ecosystem with three actors:

– “OSS adopter”, a small software company– “XWiki community” managing a content management system

named XWiki– “XWiki SAS”

• “OSS adopter” aims at including XWiki into its own Open Sourceproduct - also to minimise costs – and has, among others thefollowing objectives:– The adopted component should be maintained for at least 10 years– The adopted components should have licenses that are compatible

with its own products to avoid any legal issue• “XWiki SAS” offers services using XWiki component and so needs

that XWiki has a high quality• The “OSS adopter” also wishes to collaborate with Open source

communities exchanging experiences, releasing patches,reporting bugs, and contributing to the documentation of theOSS components

The i* modelling task

• Model the ecosystem– The relationships between the three actors– The internal goals and tasks of the “Xwiki”

community and of the “OSS adopter”– Possible risks impacting the modelled goals and

tasks

An initial idea

Thinking time…





XWiki actors

The XWikicompany

Enablers

Host

Customers

XWiki actors

Partners

Resellers

How XWiki relies on its BECO

How XWiki relies on its BECO

What XWiki provides to its BECO

The role of the community

The relationships between the community andXWiki adopters greatly determine therelationships in the ecosystem

The XWiki OSS community

XWiki SAS and XWiki.org

Community in the SECO

Community structure

Refining the SECO actors





Organization adopting XWikiLet’s imagine an organization that needs a CMS

Why it may select XWiki:1. Best tool in an evaluation process• Best-fit functionalities• …

2. Going OSS is a conscious decision• Reduce costs (development, maintenance, …)• Benefit from community work• “OSS label”• Strategic move due to context• …

The organization in XWiki’s SECOAssume that it wants to contribute back to XWiki.org

Goals for the organization

Active Committers: Detail

OSS Adoption Strategies• Initiative: start an OSS project and establish a

community around it• Release: code is made public as OSS without a

community around• Acquisition: to use the code without contributing to the

OSS project• Integration: participation in an OSS project to share and

co-create• Fork: to launch a branch of an OSS project• Takeover: to take control over an existing OSS project

(López et al., 2014)

Analysis of OSS adoption strategies

Initiative Release Fork Acquisition Integration TakeoverDeparting

projectNo No Yes Yes Yes Yes

New projectEffect on

communityCo-creationInfluence inthe project



New project Yes Yes Yes No No NoEffect on

communityCo-creationInfluence inthe project




communityNew Not

formedNew / Splitdeparting

No effect Enlarge No effect

Co-creationInfluence inthe project




communityNew Not



Co-creation Yes No Yes No Yes YesInfluence inthe project

High No High No Medium Maximum




communityNew Not



Co-creation Yes No Yes No Yes YesInfluence inthe project

Much No Much No Quite Maximum

Relation to Business GoalsInitiative Release Fork Acquisition Integration Takeover

Make the change toOSS for a product

Make Make

Get new evolutionlines for existing

software

Some+ Help Make Help Make

Influence onevolution ofcomponent

Some+ Some+ Help Make

Benefit from co-creation

Some+ Some+ Help Some+

Minimise adoptioneffort

Hurt Make Hurt Make Some- Break

Community support Make Unknown Make Help Unknown

Relation to Business Goals

Initiative

is part of

Exploiting i* roles

(Costal et al., 2015)





Risk in OSS ecosystem

“Identifying and evaluating the risks of OSS adoptionexploiting the information form the OSS strategic and businessecosystems”

• The OSS ecosystem is composed by– Adopters (Companies, Public Administrations, OSS communities)– OSS communities

• Main steps– Modelling risks in the ecosystem via extensions to i*– Reasoning on the models through the reasoning techniques– Using data from the “actors” of the OSS ecosystem

Il progetto RISCOSSRISCOSS projectStart 01/11/2012

Duration 36 months

Call FP7‐ICT‐2011‐8, Objective 1.2

Budget 3.2 Million EU

@RiscossProjecthttp://www.riscoss.eu

Approach for risk assessment

Software and Business Model

Measurements

OSS projectindicators

OSS communityindicators

Contextualindicators

AdopterAnalyst

Layer 3Business analysis

Layer 2Risk indicators

Layer 1Data Gathering Context

OSS projects Community

RISCOSS platform

Examples of OSS adoption Risks

• Component selection risks– Selection effort ill-estimation– Risk of wrong component selection

• Component integration risks– Integration effort ill-estimation– Risk of component integration failure– Security risk

• Legal risks– Intellectual property risk– Risk of license issues– Liability risk

Examples of OSS Measures and Risk indicatorsin OSS ecosystems

• Measures– Long bug fix time: Critical & Blocker– Long bug fix time: Total– Commit frequency per week & Number of Commits– Forum posts per day– Kind of licenses– …

• Risk indicators– Timeliness of the community– Activeness of the community– Licenses incompatibilities– …

Modeling Risks: entities• Risk characterized by

– Event(1); “the OSS component not maintained”Situation(2,3); “the community is not active”

• Measures & Risk Indicators

– Measure raw and derived evidences;“number of bug fixed”

Event

Situation

measure& Riskindicator

1. Yudistira Asnar, Paolo Giorgini, and John Mylopoulos. Goal-driven risk assessment in requirementsengineering. Requir. Eng., 16(2):101–116, 2011.

2. Daniele Barone, Lei Jiang, Daniel Amyot, and John Mylopoulos. Reasoning with key performance indicators.In The Practice of Enterprise Modeling, volume 92 LNBP, pages 82–96. 2011.

3. Alberto Siena, Ivan Jureta, Silvia Ingolfo, Angelo Susi, Anna Perini, and John Mylopoulos. Capturingvariability of law with Nomos 2. In ER’12, LNCS 7532, pages 383–396, 2012.

Modeling Risks: relationships• Relationships between situations and events

– “expose”, “protect”Tell when a situation makes it possible (or impossible) anevent

– “increase”, “mitigate”Tell when a situation makes it critical (or not influential) anevent

• Relationship between risks events and goals / tasks– “Impact” to connect the strategic model with the risk model

expose

impact

mitigate

Timeliness

Difficulty in coderefinement

peopleon project

expose expose

measure ofbug fixing time

impact

Maintainsoftware

OSSAdopter

OSSCommunity

OSScomponent

Actor

Goal

Resource

RIsk events

situation

Risk driver

Levels of representation:OSS ecosystems and risks together (in i*)

Layer 3Business / Strategicactors and goals of theOSS Ecosystem

Layer 2Situations andrisks events

Layer 1measures and riskdrivers

Timeliness

Difficulty in coderefinement

peopleon project

expose expose

measure ofbug fixing time

impact

Maintainsoftware

OSSAdopter

OSSCommunity

OSScomponent

Actor

Goal

Resource

RIsk events

situation

Risk driver

Meta-Model of the risk language

• Connected to thegoal-models of theecosystems

• Allows for thespecification of riskimpact on goals,activities and otherassets

Risk Meta-Model Goal Meta-Model

satisfiedSituation probability

extent

Event

expose

protect

Goal

impact

Actor

desire

Taskmeans-end

govern

increase

mitigate

performs depend

valueIndicator

evidence

Statistical analysis of OSS projectsand communities

Statistic: “Bug fix time”

300Bugs$Fix_time

coun

t

1000 200

250

1000

1250

0

300

Study the “behavior” of the community in the project

Statistical analysis of “Bug fix time” (in XwikiOSS community)Date Range: August 6th 2012 to August 6th2013

• Analysis of the “structure” of the OSS communities and oftheir “evolution” via Social Network Analysis– Centrality measures and Prestige measures to determine the

“connectivity” of nodes

e.g., to infer possible “critical” events in the community (such as a fork, adecrease in the activity)

Community network analysis

Scenario for expert assessmentScenario 1 Scenario 2 Scenario N

15 21 …

3 3 …

15 23 …

mostlymorning

mostlynight

…

mostlyweekdays

mostlyweekdays

…

never sometimes …

? ? ?

Expert assessment:Evaluate how much the values of the Riskdrivers in the scenario impact the Timeliness ofthe community (e.g., in the interval [1,5])

(Random) scenarios

Risk drivers and value of the intervals of their distributions

Resulting Bayesian Network• Bayesian network (BN)

– BN is a Directed Acyclic Graph (DAG)– Enable an effective representation and computation of the joint

probability distribution over a set of random variables

Example: Risks analysis in a model


impact


125 125

impact

300Bugs$Fix_time

coun

t

1000 200

250

1000

1250

0300

#contributors

#patches#bugs_solved

#bugs

Reasoning on models

Risk and goal model reasoning• Risk and Goal model analysis

– starting from the knowledge about values ofproperties of some nodes of the model (Riskevents, Situations, Goals, Activities) inferknowledge about values of properties of othernodes

Specification ofmodels

• Goal and riskmodels arespecified

Analysis ofmodels

• Logic based• Label prop.• …

Analysis ofresults

• Analysis of thepossibility andseverity of a risk

Reasoning Techniques: logic based• Model analysis via Disjunctive logic

– Declarative logic language that offers primitives to represent:• disjunctive facts (which introduce alternative truth values of predicates)• disjunctive rules (in which disjunctions may appear in the rule heads to

allow multiple alternative consequences to be drawn from a rule)– Allows for the analysis of alternatives (interesting also for

mitigation strategies)• Via DLV disjunctive logic reasoner

An example of rules facts and models:

lives(community) v disappear(community) :- low_active(community). RULESlow_active(community) v high_active(community). FACTS

Model 1: disappear(community), low_active(community)Model 2: lives(community), low_active(community)Model 3: high_active(community)

Reasoning Techniques: propagation based

• Some subjective knowledge is partially available from involvedstakeholders

• Directed graph (in our case for example goal models)– To each node is associated an evidence– Each relation has a weight– Compound relations have a propagation function

• Label propagation algorithm

Observable evidences Inferred evidences Target evidences

n1

n2

n3n6

n5n4

*0.5

and(0.5)*0.8

*0.1

*0.5

Propagation: satisfiability and deniability

• Propagation of theevidences in twochannels

• Satisfiability– There is some

evidence that“there will be lackof support”

• Deniability– There is some

evidence that“there will be nolack of support”


131 131

impact

300Bugs$Fix_time

coun

t

1000 200

250

1000

1250

0300

#contributors


#bugs


132 132

impact

300Bugs$Fix_time

coun

t

1000 200

250

1000

1250

0300

#contributors


#bugs

Example: Risks analysis in model

133 133

impact

300Bugs$Fix_time

coun

t

1000 200

250

1000

1250

0300

#contributors


#bugs

Example: Risks analysis in model

300Bugs$Fix_time

coun

t

1000 200

250

1000

1250

0300

measures

134 134

OSS ECOSYSTEM IN THE RISCOSSPLATFORM

Two case studies in an organisationA company aims at adopting OSS implementingan OSS “Acquisition” strategy

• Two risks are of interest:– License compatibility. Different components with

different licenses has to be integrated in a project

– Maintenance issues. The organisation would liketo incorporate a component in a project

Some Questions

• What are the possible risks connected tolicensing and maintenance issues of thecomponents ?

• What are the organisational goals affected bythe risks ?

• What is the exposure to risks in a givenenvironmental situation ?

LICENSE RISKS

Licenses in an OSS Adoption context

• Licenses of the components (decided by thecommunity)– automatically retrieved by the data sources

accessed via the risk data providers (such as Openlogic or Fossology)

• License of the project the organisation isdeveloping (a contextual indicator related tothe objectives of the organisation)

Acquisition of OSS

Externalincompatibility

risk

Future LicenseUncertainty risk

Internalincompatibility

risk

Risks in licenses• Internal incompatibility risk. Risk that two (or more) of the

adopted components have licenses that are compatible with eachother

• External incompatibility risk. Risk that the target license(s, in caseof dual licensing) is incompatible with one or more of thecomponent licenses

• Future uncertainty risk. Risk due to the low degree of freedom in

the choice of the target license of future components

• Affinity risk. Risk that arises from the need of maintaining a givencorporate licensing scheme. It measures how this set ofcomponents, although being compatible, deviates from the desiredscheme (as specified by the target license)

License risk model

….

….

CENATIC, license rules for Spanish gov.

Licenses ofthe component

License ofthe project

Licenses of the components License of the project

The specific case in FBK• “Webheuristics”, a project for the implementation of a

web based interface to JMetal meta-heuristics libraryusing AngularJS– JMetal is released under the LGPL3 license– Angular is released under the MIT license

• The License of the Webheuristics project should beunder MIT license

• Do we risk for:– Internal, External or Future uncertainty?– Is our “License compatibility” objective preserved ?

The risk analysis process in theRISCOSS platform

• Specification of the organisational setting

Organisation ontology

• specification of the relevant entities (the products, projects, OSScomponents) in the organisaiton

Specification of an organisational case of interest

• identification of the data sources for the entities (measures and indicators)

Data gathering

• Analysis of the specific risky cases

Analysis

LICENSE RISKS IN THE PLATFORM …

MAINTENANCE RISKS

Maintenance issues• The organization needs to use components whose

communities can assure a long term and satisfactorymaintenance

• Several possible aspects; here we consider:– risk of maintenance (related to bugs, obsolescence, and

analyzability)

• Measures are:– Number of subscribers, number of watchers, the presence

of documentation, … (using measures from Github)

Back to the specific case in FBK

• We aim at analysing the “Angular” library (weuse in the “Webheuristics” project)

• Do we risk for:– Possible Maintenance issues ?– Identify possible mitigation activities decreasing

the exposure to risks ?

A risk model(using Github indicators)

Maintenance Risk

MAINTENANCE RISKS IN THE PLATFORM …

MAINTENANCE RISK MITIGATIONS

Possible mitigation activities for theadopting organisation

• Not using OSS …– Closed source– In house

• Search for other components having a low degree of exposure to risks that havehigh impact on the strategy (objectives) of the organisation

– Acting through the “optimisation” of the values of the OSS component indicators

• Staffing the project in such a way to also maintain the OSS components in the caseof problems related to community inactiveness

– Acting on the project resource skills and allocation

• Change the OSS adoption strategy, for example from “Acquisition” to “Integration”,to plan and enforce an active contribution of the adopting organisation to thecommunity

– Acting on an organisational strategy and relaying on and interacting with the other OSSecosystem actors (in this case the community)

A model describing possible protections

Context of theproject/organisation

MAINTENANCE RISKS MITIGATION IN THEPLATFORM …

Maintenance Risk

Integrationof OSS

Agenda



SYSTEMS FROM AN INTENTIONAL PERSPECTIVE• PART V. CONCLUSIONS

Summary• Ecosystems provide a perspective that adapts with socio-

technical systems today• The case of OSS ecosystems is particularly interesting due

to the existence of a community behind• Intentional modeling provide the opportunity of

capturing strategic actors and relationships• The resulting models are adequated for in-depth analysis

Future work• Complete the role-based view in OSS ecosystems

strategies─ analysis with roles

• Apply the same principles to other kind of ecosystems─ e.g., app stores

• Enhance tool support─ more sophisticated models, UI, …

References• Bosch, J.: From Software Product Lines to Software Ecosystems. SPLC 2009• Boucharas, V., Jansen, S., Brinkkemper, S.: Formalizing Software Ecosystem Modeling. IWOCE 2009• Costal, D., López, L., Franch, X.: Using Roles for OSS Adoption Strategy Models. iStar@RE 2015• Franco-Bedoya, O., Ameller, D., Costal, D., Franch, X.: QuESo - A Quality Model for Open Source Software Ecosystems.

ICSOFT-EA 2014• Jansen, S., Cusumano, M.: Defining Software Ecosystems: A Survey of Software Platforms and Business Network

Governance. IWSECO@ICSOB 2012• Koch, S., Kerschbaum, M.: Joining a smartphone ecosystem: Application developers’ motivations and decision

criteria. Information and Software Technology, 56(11), 2014• López, L., Costal, D., Ayala, C., Franch, X., Annosi, M.C., Glott, R., Haaland, K.: Adoption of OSS Components: A Goal-

oriented Approach. Data & Knowledge Engineering, available online• Lungu, M., Lanza, M., Gîrba, T., Robbes, R.: Visualizing Software Ecosystems. Science of Computer Programming,

75(4), 2010• Messerschmitt, D.G., Szyperski, C.: Software Ecosystem: Understanding an Indispensable Technology and Industry.

The MIT Press, 2003• Moore, J.F.: Predators and Prey: A New Ecology of Competition. Harvard Business Review, 1993• Müller, R.M., Kijl, B., Martens, J.K.: A comparison of inter-organizational business models of mobile app stores: there

is more than open vs. closed. Journal of theoretical and applied electronic commerce research, 6(2), 2011• Popp, K., Meyer, R.: Profit from Software Ecosystems. Business Models, Ecosystems and Partnerships in the Software

Industry. Books on Demand, 2010• Sadi, M.H., Dai, J., Yu, E.: Designing Software Ecosystems: How to Develop Sustainable Collaborations.

DiFEnSE@CAiSE 2015.• Yu, E., Deng, S.: Understanding Software Ecosystems: A Strategic Modeling Approach. IWSECO@ICSOB 2011• Yu, E., P. Giorgini, N. Maiden, J. Mylopoulos (eds.): Social Modeling for Requirements Engineering. MIT Press, 2011.

Thanks to

David Ameller, Claudia Ayala, Ron Ben-Jacob,Dolors Costal, Daniel Gross, Ron Kenett, LidiaLópez, Mirko Morandini, Alberto Siena, …

RISCOSS project funded by the EC 7thFramework Programme FP7/2007-2013 underthe agreement number 318249.

Thanks for your attention!