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)
franch@essi.upc.edu, susi@fbk.eu, eric.yu@utoronto.ca
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 INTENTIONAL
PERSPECTIVE
• PART V. CONCLUSIONS

Agenda
– Definitions
– The case of OSS ecosystems
– State of the art on ecosystem modeling
• PART II. INTENTIONAL MODELING AND ANALYSIS
• PART IV. MODELING AND ANALYSIS OF OSS
ECOSYSTEMS FROM AN INTENTIONAL PERSPECTIVE

Ecosystem
A 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 foundation
of interacting organizations and individuals -- the
organisms 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 eventually
incorporate the next round of innovations
It’s competition among business ecosystems,
not individual companies, that’s largely
fueling 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 business
core contributors
distribution channels
direct customers
direct suppliers
standard
bodies
customers
of
customers
suppliers
of
suppliers
suppliers of
complementary
products
trade
associations
investors
regulatory
bodies
competitors
other
stakeholders
labour
unions

Example
content retailers
advertisers
content owners
internet players
brands…
content
apps
services
market…
$$$
user engagement
$$$
products
services
access to market
revenue share
increased
resource needs
faster
adoption

Stages
The Evolutionary Stages of a Business Ecosystem
Key Challenge Cooperative Challenges Competitive Challenges
Birth Value With customers and suppliers:
New value proposition
Protect ideas.
Tie up critical lead
customers, suppliers and
channels
Protect ideas.
channels
Expansion Critical mass With suppliers and partners:
Scale-up supply to maximize
market
Ensure that your approach
becomes market standard
Protect ideas.
channels
market
Leader-
ship
Lead co-
evolution &
innovation
With customers and suppliers:
Provide a compelling vision for
the future
Maintain strong bargaining
power in relation to other
players in the BECO
Protect ideas.
channels
market
Leader-
ship
Lead co-
evolution &
innovation
With customers and suppliers:
Provide a compelling vision for
the future
Maintain strong bargaining
power in relation to other
players in the BECO
Renewal Continuous
performance
improvement
With innovators: bring new
ideas to the existing BECO
Prevent innovators from
building alternative BECOs.
Maintain high customer
switching costs

Ecosystem health
Ability of the ecosystem to endure and remain
variable and productive over time
Productivity
Robustness
Innovation
Diversity
BECO health
Survival rate
Persistence of structure
Continuity of UX
Sustained production
Rate of product release
New products
Shared assets
Product hetereogenity
Transaction 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
Contributes to the ecosystem by
giving value and beneficing
without a clear strategic influence

Dominator
Keystone Dominator
• Physical dominator: integrates with the purpose of
owning and managing (aggressive)
– large size and market power; can’t change fast
– blocks and absorbs changes
• Value dominator: creates little value while
extracting 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 capabilities
that differentiate them from others

Software ecosystems (SECO)
Set of actors functioning as a unit and interacting with a
shared market for software and services (Jansen and
Cusumano, 2012)
A collection of software projects which are developed
and evolve together in the same environment (Lungu et
al., 2010)
Collection of organizations that are related through
software or a software related concept (a standard –
XML, a product -OpenOffice, a hardware –Playstation 3, a
platform –Android)

Classification of SECOs
Underpinning
technology
Coordinators
Accessibility
SECOs
Extension
market
platform standard
services
paid for free
screened
privately owned
consortium
multiple single
list of extensions
(Jansen and Cusumano, 2012)

Classification of SECOs: example
Technology Coordinators
Extension
market
Accessibility
Android Platform
Privately
owned
Single
(commercial)
Screened
Ruby Platform Consortium Multiple For free
Spotify
Service
platform
Privately
owned
Single Screened
OSGi Standard Consortium
List of
extensions
Paid

Classification of SECOs: example
Technology Coordinators
Extension
market
Accessibility
Android Platform
Privately
owned
Single
(commercial)
Screened
Ruby Platform Consortium Multiple For free
Spotify
Service
platform
Privately
owned
Single Screened
OSGi Standard Consortium
List of
extensions
Paid
The Android software ecosystem is based on a software
platform and coordinated by a privately owned entity
single with a single commercial extension market to which
participants 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 actors
in the associated BECO, and the organizations that provide these
solutions (Bosch, 2009)
A BECO is an economic community supported by a foundation of
interacting organizations and individuals-- organisms of the
business 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 about
products
• In a SECO, products play a major role as actors in the
ecosystem

Agenda
– Definitions
– The case of OSS ecosystems
– State of the art on ecosystem modeling
• PART II. INTENTIONAL MODELING AND ANALYSIS
• PART IV. MODELING AND ANALYSIS OF OSS ECOSYS-
TEMS FROM AN INTENTIONAL PERSPECTIVE

OSS ecosystems
Ecosystems in which the co-creation of software is
basically open but regulated by:
• strategies
• licenses
A community of developers play an important
part in the evolution of the ecosystem
OSS adopters may involve in the ecosystem at
their own interest

Example: XWiki BECO
• SME deploying the XWiki OSS CMS with several
licenses
• 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)

Ecosystem modeling
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.
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 IV. MODELING AND ANALYSIS OF ECOSYS-
TEMS FROM AN INTENTIONAL PERSPECTIVE

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 requirements
o 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 Be
Repaired
Actor
A
A very simple Strategic Dependency model in i*
Actor
B
I want …
I can
…

Actors’ Rationales
Software
Vendor
Large customer
base
Attractive to
new customer
Customer
loyalty
Profitability
Run software
business
High value
User
satisfaction
Quick time-to-
market
High quality Software be
produced
Sell software
portfolio
Provide portfolio
related services
Build software
in-house
Integrate OEM
software
Help
AND AND
Help
Help
Help Help
Help
Hurt
End User
Satisfaction
Affordable
quality
variety
Acquire
software
Have
software
Software
Software be
supported and
maintained
AND
AND AND
Help
Help Help
User
satisfaction
License and
maintenance
fee
TaskTask
Means-Ends
Link
Means-Ends
Link
GoalGoal
Decomposition
Link
Decomposition
Link
Contribution
Link
Contribution
Link
Dependency
Link
Dependency
Link
SoftgoalSoftgoal
ResourceResource
ActorActor
A not-so-simple Strategic Rationale model in i*

i* Concepts
Softgoal
Goal
Task
Resource
Means-Ends link
Decomposition link
Make
Help
Contribution link
Dependency link
Unknown
Hurt
Break
Actor

Two Contrasting Configurations
Traditional Software Supply Chain
• Actors: Software Vendor, End-
User, OEM Supplier
• Predominantly linear relationship
from the end-user to the
software vendor and from the
vendor to its suppliers
Open Ecosystem
• Actors: Software Vendor, End-
User, Developer
• Complex network relationship
between the software vendor and
a large number of developers and
end-users it aims to attract

Understanding Software Ecosystems: A
Strategic 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: A
Strategic Modeling Approach
Open Ecosystem
Software Vendor wants:
- Platform-specific applications
be developed
- Revenue share
- Creativity
- Developer satisfaction
Developer wants:
- Platform
- Platform be supported and
maintained
- Powerful features
- Fair condition of use
- Market channel be provided
- Quick to market
- Visibility

For each actor: Are strategic goals met?
√ satisfied
√. weakly satisfied
X denied
X. weakly denied
What if the vendor’s platform
is not easy-to-use from
the developer’s viewpoint?

Contrasting Two Software Ecosystems
A fundamental ecosystem challenge for Platform
Developers: How to build, grow and sustain a software
ecosystem?
• 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 Sustainable
Collaborations. CAiSE 2015 Workshop on Digital Business Innovation and the Future Enterprise
Information Systems Engineering .

To develop and sustain a software ecosystem
Developer’s satisfaction is a critical dependency
for 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 analyze
What factors lead to developers’ satisfaction?

The Apple iOS Software Ecosystem
What do Apple iOS App developers want?

Elicit and Identify
Developers’
Objectives and
Decision Criteria
1.1
What factors lead to iOS developers’ satisfaction?

Apple third-party developers are mainly driven by financial
gain.
- Koch& Kerschbaum (2014)
Elicit and Identify
Developers’
Objectives and
Decision Criteria
1.1

Intellectual stimulation is also an important factor for the
developers who join Apple iOS ecosystem.
Elicit and Identify
Developers’
Objectives and
Decision Criteria
1.1
Non -Technical
Requirements

These developers often prefer to charge fee for their
application being used by Apple iPhone/iPad end users.
Elicit and Identify
Developers’
Objectives and
Decision Criteria
1.1

The main characteristics of the iOS platform that motivate this
group to join Apple iOS ecosystem are as follows: (a) Large network
size of the platform (composed of the number of users, the market
size, and the number of applications), and (b) the tight integration
of the platform. - Koch& Kerschbaum (2014)
Technical
Requirement
Elicit and Identify
Developers’
Objectives and
Decision Criteria
1.1

A tightly integrated platform makes the complementary
application development process easier for developers with
strong motivations in financial gains by optimizing development
efforts and facilitating the targeting of the applications.
Elicit and Identify
Developers’
Objectives and
Decision Criteria
1.1

What factors and features influence or
increase intellectual stimulation in
application developers?
To what factors and features tight
integration of software platform
refer to?
Refine the
Objectives and
Decision Criteria
2.1

1
2
3
Hypothetical Prioritization
Real-world data is required to prioritize the
requirements
Identify the
Importance and
Priority of the
Decision Criteria
2.2




Hypothetical Evaluation
Real-world data is required to evaluate the
fulfillment of the requirementsIdentify the Degree
of Fulfillment of the
decision Criteria
2.3
Fully-
Satisficed
Partially-
Denied


How to improve the
fulfillment of the financial
gain motivation of application
developers?
Hypothetical Conclusion
Financial gain is the first priority requirement
of iOS application developers

Mobile Software
be developed
Open
Innovation
iOS Platform
be Developed
iOS Applications
be Developed
Delegate Development of iOS
Applications to External Developers
External
Developers
Attracted
Apple – iOS
Platform
Developer
iOS
Application
Developer
Mobile Applications
be Developed
Obtain Software
Development
Toolkit
Software
Development
Toolkit
Development
Satisfaction
Developer’s
Satisfaction
Provide Software
Development Toolkit
iOS Apps be
Developed
Financial Gain from
Application Development
Intellectual
stimulation
Increased attractiveness
of [Mobile] platform
Increased Number of Supporting
Applications
Tight Integration
of Platform
Sell Mobile
Applications
Large Network
Size of the
Platform
Optimized
Development
Efforts
Easy to Target
Application
The same modeling steps can be followed to explicate
the objectives and decision criteria of the platform
developerDerive Alternative
Design Solutions
4

Mobile Software
be developed
Open
Innovation
iOS Platform
be Developed
iOS Applications
be Developed
External
Developers
Attracted
Apple – iOS
Platform
Developer
iOS
Application
Developer
Mobile Applications
be Developed
Obtain Software
Development
Toolkit
Software
Development
Toolkit
Development
Satisfaction
Developer’s
Satisfaction
Provide Software
Development Toolkit
iOS Apps be
Developed
Financial Gain from
Support Application
Developers
Intellectual
stimulation
Applications
Tight Integration
of Platform
Sell Mobile
Applications
Large Network
Size of the
Platform
Optimized
Development
Efforts
Easy to Target
Application
Derive Alternative
Design Solutions
4

Mobile Software
be developed
Open
Innovation
iOS Platform
be Developed
iOS Applications
be Developed
External
Developers
Attracted
Apple – iOS
Platform
Developer
iOS
Application
Developer
Mobile Applications
be Developed
Obtain Software
Development
Toolkit
Software
Development
Toolkit
Development
Satisfaction
Developer’s
Satisfaction
Provide Software
Development Toolkit
iOS Apps be
Developed
Financial Gain from
Support Application
Developers
Intellectual
stimulation
Build Market Channel
for Applications
Applications
Become Visible to
the Market
Tight Integration
of Platform
Sell Mobile
Applications
Large Network
Size of the
Platform
Optimized
Development
Efforts
Easy to Target
Application
For selling the mobile applications, developers become
dependent 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 developers
To “Build market channels for applications”, and to
“Build app store”
Derive Alternative
Design Solutions
4
Mobile Software
be developed
Open
Innovation
iOS Platform
be Developed
iOS Applications
be Developed
External
Developers
Attracted
Apple – iOS
Platform
Developer
iOS
Application
Developer
Mobile Applications
be Developed
Obtain Software
Development
Toolkit
Software
Development
Toolkit
Development
Satisfaction
Developer’s
Satisfaction
Provide Software
Development Toolkit
iOS Apps be
Developed
Financial Gain from
Support Application
Developers
Intellectual
stimulation
Build Market Channel
for Applications
Applications
Become Visible to
the Market
Registration Fees
Tight Integration
of Platform
Sell Mobile
Applications
Large Network
Size of the
Platform
30% Revenue
Share
Optimized
Development
Efforts
Build App
Store
Easy to Target
Application

The Google Android Software Ecosystem
What do Android app developers want?

Elicit and Identify
Developers’
Objectives and
Decision Criteria
1.1
What factors cause Android developers’ satisfaction?

Refine the
Objectives and
Decision Criteria
2.1 The same modeling steps has been followed to
explicate the objectives and decision criteria of
Android Application Developers

How to improve the fulfillment of the
feeling of being recognized in the
Android application developers?
The same hypothetical analysis steps have been
followed to conclude the requirements.

Solution for supporting Google external developers
To “Develop Community Websites” in order to
publicize the information about the innovations to
the end users and the developers’ community
Derive Alternative
Design 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 the
Requirements of
a Sustainable
Collaboration
Derive Alternative
Solutions for Designing
a Collaborative
Environment
1
Identify and
Categorize Different
Types of Application
Developers
2 3
Elicit and Model
Developers’
Objectives and
Decision Criteria
Refine the
Objectives and
Decision Criteria into
Requirements
Identify the
Degree of
Fulfillment of the
Requirements
Identify the
Importance and
Priority of the
Requirements
1.1 2.1 2.2 2.3
Model
Stakeholders
as Actors and
Roles
Model Operations
and Activities of
stakeholders as
Goals and Tasks
Model the objectives
and Decision Criteria
of Collaborators as
Soft Goals
Model the Reasoning
behind the Adoption of
Activities as
Contribution Links
Model the Relationships
among Stakeholders as
Strategic Dependencies
Use Decomposition and
Means-Ends Links to
Refine the Objectives and
Decision Criteria
1.1.1 1.1.2 1.1.3 1.1.4
1.1.5 2.1.1
Guidelines for modeling the objectives
and decision criteria using the i*
modeling technique
Mahsa H. Sadi, Jiaying Dai, Eric Yu (2014). Designing Software
Ecosystems: How to Develop Sustainable Collaborations. CAiSE 2015
Workshop on Digital Business Innovation and the Future Enterprise
Information 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 of
the 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* wiki
http://istarwiki.org/tiki-index.php?page=i*+Tools&structure=i*+Wiki+Home

Agenda
ANALYSIS
• 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 satisfied
X denied
X. weakly denied
What if the vendor’s platform
is not easy-to-use from
the developer’s viewpoint?
[Yu Deng IWSECO’11
Understanding Software Ecosystems
Using Strategic Modeling]

Analysis of i* models
• “Qualitative” techniques (e.g., logic based)
• “Quantitative” (e.g., based on propagation
algorithms and and feed via statistical
evidences…)

The XWiki case – revisited
• SME deploying the XWiki OSS CMS with several
licenses
• 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 Source
product - also to minimise costs – and has, among others the
following 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 the
OSS 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

XWiki actors
The XWiki
company
Enablers
Host
Customers

XWiki actors
Partners
Resellers

What XWiki provides to its BECO

The role of the community
The relationships between the community and
XWiki adopters greatly determine the
relationships in the ecosystem
The XWiki OSS community

Organization adopting XWiki
Let’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 SECO
Assume that it wants to contribute back to XWiki.org

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 Takeover
Departing
project
No No Yes Yes Yes Yes
New project
Effect on
community
Co-creation
Influence in
the project
Departing
project
New project Yes Yes Yes No No No
Effect on
community
Co-creation
Influence in
the project
Departing
project
Effect on
community
New Not
formed
New / Split
departing
No effect Enlarge No effect
Co-creation
Influence in
the project
Departing
project
Effect on
community
New Not
formed
New / Split
departing
Co-creation Yes No Yes No Yes Yes
Influence in
the project
High No High No Medium Maximum
Departing
project
Effect on
community
New Not
formed
New / Split
departing
Co-creation Yes No Yes No Yes Yes
Influence in
the project
Much No Much No Quite Maximum

Relation to Business Goals
Make the change to
OSS for a product
Make Make
Get new evolution
lines for existing
software
Some+ Help Make Help Make
Influence on
evolution of
component
Some+ Some+ Help Make
Benefit from co-
creation
Some+ Some+ Help Some+
Minimise adoption
effort
Hurt Make Hurt Make Some- Break
Community support Make Unknown Make Help Unknown

Exploiting i* roles
(Costal et al., 2015)

Risk in OSS ecosystem
“Identifying and evaluating the risks of OSS adoption
exploiting the information form the OSS strategic and business
ecosystems”
• 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 project
Start 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 project
indicators
OSS community
indicators
Contextual
indicators
Adopter
Analyst
Layer 3
Business analysis
Layer 2
Risk indicators
Layer 1
Data Gathering
Context
OSS projects
Community

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 indicators
in 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
& Risk
indicator
1. Yudistira Asnar, Paolo Giorgini, and John Mylopoulos. Goal-driven risk assessment in requirements
engineering. 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. Capturing
variability 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) an
event
– “increase”, “mitigate”
Tell when a situation makes it critical (or not influential) an
event
• Relationship between risks events and goals / tasks
– “Impact” to connect the strategic model with the risk model
expose
impact
mitigate

Timeliness
Difficulty in code
refinement
people
on project
expose
expose
measure of
bug fixing time
impact
Maintain
software
OSS
Adopter
OSS
Commu
nity
OSS
component
Actor
Goal
Resource
RIsk events
situation
Risk driver
Levels of representation:
OSS ecosystems and risks together (in i*)
Layer 3
Business / Strategic
actors and goals of the
OSS Ecosystem
Layer 2
Situations and
risks events
Layer 1
measures and risk
drivers
Timeliness
Difficulty in code
refinement
people
on project
expose
expose
measure of
bug fixing time
impact
Maintain
software
OSS
Adopter
OSS
Commu
nity
OSS
component
Actor
Goal
Resource
RIsk events
situation
Risk driver

Meta-Model of the risk language
• Connected to the
goal-models of the
ecosystems
• Allows for the
specification of risk
impact on goals,
activities and other
assets
Risk Meta-Model Goal Meta-Model
satisﬁed
Situation probability
extent
Event
expose
protect
Goal
impact
Actor
desire
Task
means-end
govern
increase
mitigate
performs depend
value
Indicator
evidence

Statistical analysis of OSS projects
and communities

Statistic: “Bug fix time”
300Bugs$Fix_time
count
1000 200
250
1000
1250
0
300
 Study the “behavior” of the community in the project
Statistical analysis of “Bug fix time” (in Xwiki
OSS community)
Date Range: August 6th 2012 to August 6th
2013

• Analysis of the “structure” of the OSS communities and of
their “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, a
decrease in the activity)
Community network analysis

Scenario for expert assessment
Scenario 1 Scenario 2 Scenario N
15 21 …
3 3 …
15 23 …
mostly
morning
mostly
night
…
mostly
weekdays
mostly
weekdays
…
never sometimes …
? ? ?
Expert assessment:
Evaluate how much the values of the Risk
drivers in the scenario impact the Timeliness of
the 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
count
1000 200
250
1000
1250
0
300
#contributors
#patches
#bugs_solved
#bugs

Risk and goal model reasoning
• Risk and Goal model analysis
– starting from the knowledge about values of
properties of some nodes of the model (Risk
events, Situations, Goals, Activities) infer
knowledge about values of properties of other
nodes
Specification of
models
• Goal and risk
models are
specified
Analysis of
models
• Logic based
• Label prop.
• …
Analysis of
results
• Analysis of the
possibility and
severity 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). RULES
low_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 involved
stakeholders
• 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
n3
n6
n5n4
*0.5
and(0.5)
*0.8
*0.1
*0.5

Propagation: satisfiability and deniability
• Propagation of the
evidences in two
channels
• Satisfiability
– There is some
evidence that
“there will be lack
of support”
• Deniability
– There is some
evidence that
“there will be no
lack of support”

131 131
impact
300Bugs$Fix_time
count
1000 200
250
1000
1250
0
300
#contributors
#patches
#bugs_solved
#bugs

132 132
impact
300Bugs$Fix_time
count
1000 200
250
1000
1250
0
300
#contributors
#patches
#bugs_solved
#bugs

Example: Risks analysis in model
133 133
impact
300Bugs$Fix_time
count
1000 200
250
1000
1250
0
300
#contributors
#patches
#bugs_solved
#bugs

Example: Risks analysis in model
300Bugs$Fix_time
count
1000 200
250
1000
1250
0
300
measures
134 134

OSS ECOSYSTEM IN THE RISCOSS
PLATFORM

Two case studies in an organisation
A company aims at adopting OSS implementing
an 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 like
to incorporate a component in a project

Some Questions
• What are the possible risks connected to
licensing and maintenance issues of the
components ?
• What are the organisational goals affected by
the risks ?
• What is the exposure to risks in a given
environmental situation ?

Licenses in an OSS Adoption context
• Licenses of the components (decided by the
community)
– automatically retrieved by the data sources
accessed via the risk data providers (such as Open
logic or Fossology)
• License of the project the organisation is
developing (a contextual indicator related to
the objectives of the organisation)

External
incompatibility
risk
Future License
Uncertainty risk
Internal
incompatibility
risk

Risks in licenses
• Internal incompatibility risk. Risk that two (or more) of the
adopted components have licenses that are compatible with each
other
• External incompatibility risk. Risk that the target license(s, in case
of dual licensing) is incompatible with one or more of the
component 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 given
corporate licensing scheme. It measures how this set of
components, although being compatible, deviates from the desired
scheme (as specified by the target license)

License risk model
….
….
CENATIC, license rules for Spanish gov.
Licenses of
the component
License of
the 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 library
using AngularJS
– JMetal is released under the LGPL3 license
– Angular is released under the MIT license
• The License of the Webheuristics project should be
under MIT license
• Do we risk for:
– Internal, External or Future uncertainty?
– Is our “License compatibility” objective preserved ?

The risk analysis process in the
RISCOSS platform
• Specification of the organisational setting
Organisation ontology
• specification of the relevant entities (the products, projects, OSS
components) 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 issues
• The organization needs to use components whose
communities can assure a long term and satisfactory
maintenance
• 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 (we
use 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 RISKS IN THE PLATFORM …

Possible mitigation activities for the
adopting organisation
• Not using OSS …
– Closed source
– In house
• Search for other components having a low degree of exposure to risks that have
high 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 case
of 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 the
community
– Acting on an organisational strategy and relaying on and interacting with the other OSS
ecosystem actors (in this case the community)

A model describing possible protections
Context of the
project/organisation

MAINTENANCE RISKS MITIGATION IN THE
PLATFORM …

Agenda
ANALYSIS
• PART IV. MODELING AND ANALYSIS OF OSS ECO-
SYSTEMS FROM AN INTENTIONAL PERSPECTIVE

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, Lidia
López, Mirko Morandini, Alberto Siena, …
RISCOSS project funded by the EC 7th
Framework Programme FP7/2007-2013 under
the agreement number 318249.

RE 2015 ecosystems tutorial

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to RE 2015 ecosystems tutorial

Similar to RE 2015 ecosystems tutorial (20)

More from Xavier Franch

More from Xavier Franch (12)

Recently uploaded

Recently uploaded (20)

RE 2015 ecosystems tutorial