Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Business and Software Ecosystems:
How to model, analyze, and survive!
Xavier Franch, Angelo Susi, Eric S.K. Yu
(UPC) (FBK)...
Agenda
• PART I. BUSINESS AND SOFTWARE ECOSYSTEMS
• PART II. INTENTIONAL MODELING AND
ANALYSIS
• PART III. HANDS-ON EXERCI...
Agenda
• PART I. BUSINESS AND SOFTWARE ECOSYSTEMS
– Definitions
– The case of OSS ecosystems
– State of the art on ecosyst...
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
– Foc...
Business ecosystem (BECO)
An economic community supported by a foundation
of interacting organizations and individuals -- ...
Why BECOs
• share infrastructure
• share market development
capability
riskcost
• lower market entry barriers
• facilitate...
Business ecosystem actors
business ecosystem
extended enterprise
core business
core contributors
distribution channels
dir...
Example
content retailers
advertisers
content owners
internet players
brands…
content
apps
services
market…
$$$
user engag...
Stages
The Evolutionary Stages of a Business Ecosystem
Key Challenge Cooperative Challenges Competitive Challenges
Birth V...
Ecosystem health
Ability of the ecosystem to endure and remain
variable and productive over time
Productivity
Robustness
I...
Roles in ecosystems
Keystone Dominator
Developer Niche player
Keystones
Keystone Dominator
Developer Niche player
• Boosts productivity of the ecosystem
– keeps focus; solves problems
...
Developer
Keystone Dominator
Developer Niche player
Contributes to the ecosystem by
giving value and beneficing
without a ...
Dominator
Keystone Dominator
Developer Niche player
• Physical dominator: integrates with the purpose of
owning and managi...
Niche players
Keystone Dominator
Developer Niche player
• Innovation drivers
– value creation
• Provide complementary asse...
Software ecosystems (SECO)
Set of actors functioning as a unit and interacting with a
shared market for software and servi...
Classification of SECOs
Underpinning
technology
Coordinators
Accessibility
SECOs
Extension
market
platform standard
servic...
Classification of SECOs: example
Technology Coordinators
Extension
market
Accessibility
Android Platform
Privately
owned
S...
Classification of SECOs: example
Technology Coordinators
Extension
market
Accessibility
Android Platform
Privately
owned
S...
BECOs and SECOs
A SECO consists of the set of software solutions that enable,
support and automate the activities and tran...
Agenda
• PART I. BUSINESS AND SOFTWARE ECOSYSTEMS
– Definitions
– The case of OSS ecosystems
– State of the art on ecosyst...
OSS ecosystems
Ecosystems in which the co-creation of software is
basically open but regulated by:
• strategies
• licenses...
Example: XWiki BECO
• SME deploying the XWiki OSS CMS with several
licenses
• Supported by an OSS community (XWiki.org)
• ...
Example: XWiki SECO
• Importance of the community (XWiki.org)
• Software development infrastructure: Maven,
Eclipse, Git, ...
OSS ecosystem health
(Franco-Bedoya et al., 2014)
Agenda
• PART I. BUSINESS AND SOFTWARE ECOSYSTEMS
– Definitions
– The case of OSS ecosystems
– State of the art on ecosyst...
Ecosystem modeling
Several approaches for modeling ecosystems:
• value model perspective
• software product architecture i...
Software Supply Network (SSN)
• Part of the Software Ecosystem Metamodel (SEM)
• Focus on the software supply chains
Compa...
Value Network models
• Express the creation and interchange of value in
the ecosystem
– goods, services, knowledge, revenu...
e3Value models
• Similar to Value Networks with focus on
economic value creation and exchange
Agenda
• PART I. BUSINESS AND SOFTWARE ECOSYSTEMS
• PART II. INTENTIONAL MODELING AND
ANALYSIS
– The i* framework
– Analys...
Model-based representation of ecosystems
Several approaches for modeling ecosystems:
• value model perspective
• software ...
Strategic Modeling with i*
• Origin in Requirement Engineering (RE)
o Asking the “why’s” behind requirements
o Uncovering ...
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 softw...
i* Concepts
Softgoal
Goal
Task
Resource
Means-Ends link
Decomposition link
Make
Help
Contribution link
Dependency link
Unk...
Two Contrasting Configurations
Traditional Software Supply Chain
• Actors: Software Vendor, End-
User, OEM Supplier
• Pred...
Understanding Software Ecosystems: A
Strategic Modeling Approach 40
`
Traditional Software Supply Chain
Software Vendor wa...
Understanding Software Ecosystems: A
Strategic Modeling Approach
Open Ecosystem
Software Vendor wants:
- Platform-specific...
Agenda
• PART I. BUSINESS AND SOFTWARE ECOSYSTEMS
• PART II. INTENTIONAL MODELING AND
ANALYSIS
– The i* framework
– Analys...
For each actor: Are strategic goals met?
√ satisfied
√. weakly satisfied
X denied
X. weakly denied
What if the vendor’s pl...
Contrasting Two Software Ecosystems
A fundamental ecosystem challenge for Platform
Developers: How to build, grow and sust...
To develop and sustain a software ecosystem
Developer’s satisfaction is a critical dependency
for a mobile platform develo...
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...
Intellectual stimulation is also an important factor for the
developers who join Apple iOS ecosystem.
- Koch& Kerschbaum (...
These developers often prefer to charge fee for their
application being used by Apple iPhone/iPad end users.
- Koch& Kersc...
The main characteristics of the iOS platform that motivate this
group to join Apple iOS ecosystem are as follows: (a) Larg...
A tightly integrated platform makes the complementary
application development process easier for developers with
strong mo...
What factors and features influence or
increase intellectual stimulation in
application developers?
To what factors and fe...
1
2
3
Hypothetical Prioritization
Real-world data is required to prioritize the
requirements
Identify the
Importance and
P...



Hypothetical Evaluation
Real-world data is required to evaluate the
fulfillment of the requirementsIdentify the Degr...
How to improve the
fulfillment of the financial
gain motivation of application
developers?
Hypothetical Conclusion
Financi...
Mobile Software
be developed
Open
Innovation
iOS Platform
be Developed
iOS Applications
be Developed
Delegate Development ...
Mobile Software
be developed
Open
Innovation
iOS Platform
be Developed
iOS Applications
be Developed
Delegate Development ...
Mobile Software
be developed
Open
Innovation
iOS Platform
be Developed
iOS Applications
be Developed
Delegate Development ...
Solution for supporting iOS external developers
To “Build market channels for applications”, and to
“Build app store”
Deri...
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 ...
How to improve the fulfillment of the
feeling of being recognized in the
Android application developers?
The same hypothet...
Solution for supporting Google external developers
To “Develop Community Websites” in order to
publicize the information a...
Activities in the modeling process
• Identify the main actors in the ecosystem
– roles and agents
– others may emerge as w...
Proposed Approach- Modeling Guidelines
Elicit the
Requirements of
a Sustainable
Collaboration
Derive Alternative
Solutions...
The “i* book”
Social Modeling for Requirements Engineering
• MIT Press 2011. 742 pp.
• E. Yu, P. Giorgini, N. Maiden, J. M...
iStar workshop series
1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013
• iStar worksho...
Industry showcase/tutorials
• “Exploring the Goals of your Systems and
Businesses: Practical experiences with i* modelling...
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 ...
Tools
• Canada (U Toronto)
– OME, OpenOME
• Canada (U Ottawa)
– jUCMnav for URN
• England & Spain
– REDEPEND- REACT
• Ital...
Agenda
• PART I. BUSINESS AND SOFTWARE ECOSYSTEMS
• PART II. INTENTIONAL MODELING AND
ANALYSIS
• PART III. HANDS-ON EXERCI...
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
i...
Analysis of i* models
• “Qualitative” techniques (e.g., logic based)
• “Quantitative” (e.g., based on propagation
algorith...
The XWiki case – revisited
• SME deploying the XWiki OSS CMS with several
licenses
• Supported by an OSS community (XWiki....
A small exercise on ecosystem modelling using i*
• Ecosystem with three actors:
– “OSS adopter”, a small software company
...
The i* modelling task
• Model the ecosystem
– The relationships between the three actors
– The internal goals and tasks of...
An initial idea
Thinking time…
Agenda
• PART I. BUSINESS AND SOFTWARE ECOSYSTEMS
• PART II. INTENTIONAL MODELING AND
ANALYSIS
• PART III. HANDS-ON EXERCI...
XWiki actors
The XWiki
company
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 and
XWiki adopters greatly determine the
relationships i...
XWiki SAS and XWiki.org
Community in the SECO
Community structure
Refining the SECO actors
Agenda
• PART I. BUSINESS AND SOFTWARE ECOSYSTEMS
• PART II. INTENTIONAL MODELING AND
ANALYSIS
• PART III. HANDS-ON EXERCI...
Organization adopting XWiki
Let’s imagine an organization that needs a CMS
Why it may select XWiki:
1. Best tool in an eva...
The organization in XWiki’s SECO
Assume 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 pub...
Analysis of OSS adoption strategies
Initiative Release Fork Acquisition Integration Takeover
Departing
project
No No Yes Y...
Relation to Business Goals
Initiative Release Fork Acquisition Integration Takeover
Make the change to
OSS for a product
M...
Relation to Business Goals
Initiative
is part of
Exploiting i* roles
(Costal et al., 2015)
Agenda
• PART I. BUSINESS AND SOFTWARE ECOSYSTEMS
• PART II. INTENTIONAL MODELING AND
ANALYSIS
• PART III. HANDS-ON EXERCI...
Risk in OSS ecosystem
“Identifying and evaluating the risks of OSS adoption
exploiting the information form the OSS strate...
Il progetto RISCOSSRISCOSS project
Start 01/11/2012
Duration 36 months
Call FP7‐ICT‐2011‐8, Objective 1.2
Budget 3.2 Milli...
Approach for risk assessment
Software and Business Model
Measurements
OSS project
indicators
OSS community
indicators
Cont...
RISCOSS platform
Examples of OSS adoption Risks
• Component selection risks
– Selection effort ill-estimation
– Risk of wrong component sel...
Examples of OSS Measures and Risk indicators
in OSS ecosystems
• Measures
– Long bug fix time: Critical & Blocker
– Long b...
Modeling Risks: entities
• Risk characterized by
– Event(1); “the OSS component not maintained”
Situation(2,3); “the commu...
Modeling Risks: relationships
• Relationships between situations and events
– “expose”, “protect”
Tell when a situation ma...
Timeliness
Difficulty in code
refinement
people
on project
expose
expose
measure of
bug fixing time
impact
Maintain
software
...
Meta-Model of the risk language
• Connected to the
goal-models of the
ecosystems
• Allows for the
specification of risk
im...
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 t...
• Analysis of the “structure” of the OSS communities and of
their “evolution” via Social Network Analysis
– Centrality mea...
Scenario for expert assessment
Scenario 1 Scenario 2 Scenario N
15 21 …
3 3 …
15 23 …
mostly
morning
mostly
night
…
mostly...
Resulting Bayesian Network
• Bayesian network (BN)
– BN is a Directed Acyclic Graph (DAG)
– Enable an effective representa...
Example: Risks analysis in a model
Example: Risks analysis in a model
impact
Example: Risks analysis in a model
125 125
impact
300Bugs$Fix_time
count
1000 200
250
1000
1250
0
300
#contributors
#patch...
Reasoning on models
Risk and goal model reasoning
• Risk and Goal model analysis
– starting from the knowledge about values of
properties of s...
Reasoning Techniques: logic based
• Model analysis via Disjunctive logic
– Declarative logic language that offers primitiv...
Reasoning Techniques: propagation based
• Some subjective knowledge is partially available from involved
stakeholders
• Di...
Propagation: satisfiability and deniability
• Propagation of the
evidences in two
channels
• Satisfiability
– There is som...
Example: Risks analysis in a model
131 131
impact
300Bugs$Fix_time
count
1000 200
250
1000
1250
0
300
#contributors
#patch...
Example: Risks analysis in a model
132 132
impact
300Bugs$Fix_time
count
1000 200
250
1000
1250
0
300
#contributors
#patch...
Example: Risks analysis in model
133 133
impact
300Bugs$Fix_time
count
1000 200
250
1000
1250
0
300
#contributors
#patches...
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 ...
Some Questions
• What are the possible risks connected to
licensing and maintenance issues of the
components ?
• What are ...
LICENSE RISKS
Licenses in an OSS Adoption context
• Licenses of the components (decided by the
community)
– automatically retrieved by t...
Acquisition of OSS
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 ar...
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-heuri...
The risk analysis process in the
RISCOSS platform
• Specification of the organisational setting
Organisation ontology
• sp...
LICENSE RISKS IN THE PLATFORM …
MAINTENANCE RISKS
Maintenance issues
• The organization needs to use components whose
communities can assure a long term and satisfactory
ma...
Back to the specific case in FBK
• We aim at analysing the “Angular” library (we
use in the “Webheuristics” project)
• Do ...
A risk model
(using Github indicators)
Maintenance Risk
MAINTENANCE RISKS IN THE PLATFORM …
MAINTENANCE RISK MITIGATIONS
Possible mitigation activities for the
adopting organisation
• Not using OSS …
– Closed source
– In house
• Search for oth...
A model describing possible protections
Context of the
project/organisation
MAINTENANCE RISKS MITIGATION IN THE
PLATFORM …
Maintenance Risk
Integration
of OSS
Agenda
• PART I. BUSINESS AND SOFTWARE ECOSYSTEMS
• PART II. INTENTIONAL MODELING AND
ANALYSIS
• PART III. HANDS-ON EXERCI...
Summary
• Ecosystems provide a perspective that adapts with socio-
technical systems today
• The case of OSS ecosystems is...
Future work
• Complete the role-based view in OSS ecosystems
strategies
─ analysis with roles
• Apply the same principles ...
References
• Bosch, J.: From Software Product Lines to Software Ecosystems. SPLC 2009
• Boucharas, V., Jansen, S., Brinkke...
Thanks to
David Ameller, Claudia Ayala, Ron Ben-Jacob,
Dolors Costal, Daniel Gross, Ron Kenett, Lidia
López, Mirko Morandi...
Thanks for your attention!
RE 2015 ecosystems tutorial
Upcoming SlideShare
Loading in …5
×

RE 2015 ecosystems tutorial

1,048 views

Published on

Tutorial on business and software ecosystems given at RE 2015

Published in: Software
  • Be the first to comment

RE 2015 ecosystems tutorial

  1. 1. 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
  2. 2. 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
  3. 3. 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
  4. 4. Ecosystem A system formed by the interaction of a community of organisms with their environment
  5. 5. What type of organisms and environment
  6. 6. 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
  7. 7. 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
  8. 8. Why BECOs • share infrastructure • share market development capability riskcost • lower market entry barriers • facilitates customer engagement • access specialized skills • moves faster ↓ ↓ ↑
  9. 9. 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
  10. 10. 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
  11. 11. 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 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 Expansion Critical mass With suppliers and partners: Scale-up supply to maximize market Ensure that your approach becomes market standard 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 Expansion Critical mass With suppliers and partners: Scale-up supply to maximize market Ensure that your approach becomes market standard 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 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 Expansion Critical mass With suppliers and partners: Scale-up supply to maximize market Ensure that your approach becomes market standard 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
  12. 12. 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
  13. 13. Roles in ecosystems Keystone Dominator Developer Niche player
  14. 14. Keystones Keystone Dominator Developer Niche player • 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
  15. 15. Developer Keystone Dominator Developer Niche player Contributes to the ecosystem by giving value and beneficing without a clear strategic influence
  16. 16. Dominator Keystone Dominator Developer Niche player • 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
  17. 17. Niche players Keystone Dominator Developer Niche player • 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
  18. 18. 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)
  19. 19. 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)
  20. 20. 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
  21. 21. 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
  22. 22. 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
  23. 23. 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 ECOSYS- TEMS FROM AN INTENTIONAL PERSPECTIVE • PART V. CONCLUSIONS
  24. 24. 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
  25. 25. 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
  26. 26. 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
  27. 27. OSS ecosystem health (Franco-Bedoya et al., 2014)
  28. 28. 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 ECOSYS- TEMS FROM AN INTENTIONAL PERSPECTIVE • PART V. CONCLUSIONS
  29. 29. 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)
  30. 30. Software Supply Network (SSN) • Part of the Software Ecosystem Metamodel (SEM) • Focus on the software supply chains Company of InterestSupplier CustomerIntermediary Trade relationships
  31. 31. Value Network models • Express the creation and interchange of value in the ecosystem – goods, services, knowledge, revenue, …
  32. 32. e3Value models • Similar to Value Networks with focus on economic value creation and exchange
  33. 33. Agenda • PART I. BUSINESS AND SOFTWARE ECOSYSTEMS • PART II. INTENTIONAL MODELING AND ANALYSIS – The i* framework – Analysis of i* models • PART III. HANDS-ON EXERCISE • PART IV. MODELING AND ANALYSIS OF ECOSYS- TEMS FROM AN INTENTIONAL PERSPECTIVE • PART V. CONCLUSIONS
  34. 34. 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?
  35. 35. 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?
  36. 36. An intentional dependency Car Be Repaired Actor A A very simple Strategic Dependency model in i* Actor B I want … I can …
  37. 37. 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*
  38. 38. i* Concepts Softgoal Goal Task Resource Means-Ends link Decomposition link Make Help Contribution link Dependency link Unknown Hurt Break Actor
  39. 39. 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
  40. 40. 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
  41. 41. 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
  42. 42. Agenda • PART I. BUSINESS AND SOFTWARE ECOSYSTEMS • PART II. INTENTIONAL MODELING AND ANALYSIS – The i* framework – Analysis of i* models • PART III. HANDS-ON EXERCISE • PART IV. MODELING AND ANALYSIS OF ECOSYS- TEMS FROM AN INTENTIONAL PERSPECTIVE • PART V. CONCLUSIONS
  43. 43. 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?
  44. 44. 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 .
  45. 45. 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.
  46. 46. Mobile platform developer needs to elicit and analyze What factors lead to developers’ satisfaction?
  47. 47. The Apple iOS Software Ecosystem What do Apple iOS App developers want?
  48. 48. Elicit and Identify Developers’ Objectives and Decision Criteria 1.1 What factors lead to iOS developers’ satisfaction?
  49. 49. Apple third-party developers are mainly driven by financial gain. - Koch& Kerschbaum (2014) Elicit and Identify Developers’ Objectives and Decision Criteria 1.1
  50. 50. Intellectual stimulation is also an important factor for the developers who join Apple iOS ecosystem. - Koch& Kerschbaum (2014) Elicit and Identify Developers’ Objectives and Decision Criteria 1.1 Non -Technical Requirements
  51. 51. These developers often prefer to charge fee for their application being used by Apple iPhone/iPad end users. - Koch& Kerschbaum (2014) Elicit and Identify Developers’ Objectives and Decision Criteria 1.1
  52. 52. 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
  53. 53. 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. - Koch& Kerschbaum (2014) Elicit and Identify Developers’ Objectives and Decision Criteria 1.1
  54. 54. 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
  55. 55. 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
  56. 56.    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 
  57. 57. 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
  58. 58. 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
  59. 59. 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 Support Application Developers 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 Derive Alternative Design Solutions 4
  60. 60. 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 Support Application Developers Intellectual stimulation Build Market Channel for Applications Increased attractiveness of [Mobile] platform Increased Number of Supporting 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
  61. 61. 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 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 Support Application Developers Intellectual stimulation Build Market Channel for Applications Increased attractiveness of [Mobile] platform Increased Number of Supporting 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
  62. 62. The Google Android Software Ecosystem What do Android app developers want?
  63. 63. Elicit and Identify Developers’ Objectives and Decision Criteria 1.1 What factors cause Android developers’ satisfaction?
  64. 64. 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
  65. 65. 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.
  66. 66. 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
  67. 67. 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, …
  68. 68. 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 .
  69. 69. 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
  70. 70. 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
  71. 71. 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
  72. 72. http://istarwiki.org/tiki-index.php?page=i*-related+Phd+Dissertations
  73. 73. • 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
  74. 74. 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
  75. 75. 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 • PART V. CONCLUSIONS
  76. 76. Analyzing vulnerabilities • Example of enforcement mechanism – Reciprocal dependency • Loop analysis
  77. 77. Analyzing vulnerabilities • Example of assurance mechanism – Goal synergy or conflict • Node analysis
  78. 78. 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]
  79. 79. Analysis of i* models • “Qualitative” techniques (e.g., logic based) • “Quantitative” (e.g., based on propagation algorithms and and feed via statistical evidences…)
  80. 80. 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
  81. 81. 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
  82. 82. 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
  83. 83. An initial idea
  84. 84. Thinking time…
  85. 85. 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 • PART V. CONCLUSIONS
  86. 86. XWiki actors The XWiki company Enablers Host Customers
  87. 87. XWiki actors Partners Resellers
  88. 88. How XWiki relies on its BECO
  89. 89. How XWiki relies on its BECO
  90. 90. What XWiki provides to its BECO
  91. 91. The role of the community The relationships between the community and XWiki adopters greatly determine the relationships in the ecosystem The XWiki OSS community
  92. 92. XWiki SAS and XWiki.org
  93. 93. Community in the SECO
  94. 94. Community structure
  95. 95. Refining the SECO actors
  96. 96. 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 • PART V. CONCLUSIONS
  97. 97. 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 • …
  98. 98. The organization in XWiki’s SECO Assume that it wants to contribute back to XWiki.org
  99. 99. Goals for the organization
  100. 100. Active Committers: Detail
  101. 101. 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)
  102. 102. 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 Initiative Release Fork Acquisition Integration Takeover Departing project No No Yes Yes Yes Yes New project Yes Yes Yes No No No Effect on community Co-creation Influence in the project Initiative Release Fork Acquisition Integration Takeover Departing project No No Yes Yes Yes Yes New project Yes Yes Yes No No No Effect on community New Not formed New / Split departing No effect Enlarge No effect Co-creation Influence in the project Initiative Release Fork Acquisition Integration Takeover Departing project No No Yes Yes Yes Yes New project Yes Yes Yes No No No Effect on community New Not formed New / Split departing No effect Enlarge No effect Co-creation Yes No Yes No Yes Yes Influence in the project High No High No Medium Maximum Initiative Release Fork Acquisition Integration Takeover Departing project No No Yes Yes Yes Yes New project Yes Yes Yes No No No Effect on community New Not formed New / Split departing No effect Enlarge No effect Co-creation Yes No Yes No Yes Yes Influence in the project Much No Much No Quite Maximum
  103. 103. Relation to Business Goals Initiative Release Fork Acquisition Integration Takeover 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
  104. 104. Relation to Business Goals
  105. 105. Initiative is part of
  106. 106. Exploiting i* roles (Costal et al., 2015)
  107. 107. 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 • PART V. CONCLUSIONS
  108. 108. 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
  109. 109. 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
  110. 110. 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
  111. 111. RISCOSS platform
  112. 112. 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
  113. 113. 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 – …
  114. 114. 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.
  115. 115. 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
  116. 116. 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
  117. 117. 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 satisfied Situation probability extent Event expose protect Goal impact Actor desire Task means-end govern increase mitigate performs depend value Indicator evidence
  118. 118. Statistical analysis of OSS projects and communities
  119. 119. 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
  120. 120. • 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
  121. 121. 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
  122. 122. 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
  123. 123. Example: Risks analysis in a model
  124. 124. Example: Risks analysis in a model impact
  125. 125. Example: Risks analysis in a model 125 125 impact 300Bugs$Fix_time count 1000 200 250 1000 1250 0 300 #contributors #patches #bugs_solved #bugs
  126. 126. Reasoning on models
  127. 127. 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
  128. 128. 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)
  129. 129. 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
  130. 130. 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. Example: Risks analysis in a model 131 131 impact 300Bugs$Fix_time count 1000 200 250 1000 1250 0 300 #contributors #patches #bugs_solved #bugs
  132. 132. Example: Risks analysis in a model 132 132 impact 300Bugs$Fix_time count 1000 200 250 1000 1250 0 300 #contributors #patches #bugs_solved #bugs
  133. 133. Example: Risks analysis in model 133 133 impact 300Bugs$Fix_time count 1000 200 250 1000 1250 0 300 #contributors #patches #bugs_solved #bugs
  134. 134. Example: Risks analysis in model 300Bugs$Fix_time count 1000 200 250 1000 1250 0 300 measures 134 134
  135. 135. OSS ECOSYSTEM IN THE RISCOSS PLATFORM
  136. 136. 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
  137. 137. 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 ?
  138. 138. LICENSE RISKS
  139. 139. 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)
  140. 140. Acquisition of OSS
  141. 141. External incompatibility risk Future License Uncertainty risk Internal incompatibility risk
  142. 142. 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)
  143. 143. License risk model …. …. CENATIC, license rules for Spanish gov. Licenses of the component License of the project
  144. 144. Licenses of the components License of the project
  145. 145. 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 ?
  146. 146. 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
  147. 147. LICENSE RISKS IN THE PLATFORM …
  148. 148. MAINTENANCE RISKS
  149. 149. 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)
  150. 150. 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 ?
  151. 151. A risk model (using Github indicators)
  152. 152. Maintenance Risk
  153. 153. MAINTENANCE RISKS IN THE PLATFORM …
  154. 154. MAINTENANCE RISK MITIGATIONS
  155. 155. 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)
  156. 156. A model describing possible protections Context of the project/organisation
  157. 157. MAINTENANCE RISKS MITIGATION IN THE PLATFORM …
  158. 158. Maintenance Risk
  159. 159. Integration of OSS
  160. 160. 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 • PART V. CONCLUSIONS
  161. 161. 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
  162. 162. 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, …
  163. 163. 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.
  164. 164. 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.
  165. 165. Thanks for your attention!

×